กลับมาอีกครั้งกับการขุด UnetLab แบบที่ชาวบ้านไม่สนใจ แต่เราชอบเพราะเราอินดี้ 😛
ก่อนหน้านี้เคยเขียนเรื่อง pnet ไปแล้วดังนั้นรอบนี้ก็เลยถึงคิวของ Bridge network ซึ่งเป็น Network type พื้นฐานที่ทุกคนจะสร้างขึ้นมาเพื่อใช้เชื่อมต่อระหว่างอุปกรณ์ ต่างๆใน Lab
แต่หลายคนอาจจะไม่รู้ว่าอุปกรณ์มันเชื่อมต่อหากันได้ยังไง ให้ลองคิดง่ายๆว่า Bridge เป็น Switch ที่มีแค่ 2 Interface (เพื่อให้เข้าใจง่ายๆ) ดังนั้นเมื่อเราต้องการเชื่อมต่ออุปกรณ์ 2 ตัวเข้าหากันเราก็จะทำการเชื่อมต่อมันเข้าหากันด้วย Bridge นั่นเอง ถ้านึกไม่ออกลองดูรูปข้างล่างนี้เป็นตัวอย่างประกอบไปก่อนครับ
ต่อมาเราก็มโนต่อว่าอุปกรณ์พวกนี้เมื่อไปอยู่ใน UnetLab มันจะมีหน้าตาหรือชื่อยังไงกัน? ให้ลองดูรูปด้านล่างก่อนนะครับ
จะเห็นว่าเมื่อเข้าไปอยู่ใน UnetLab แล้ว Bridge จะมีชื่อเป็น vnet0_1 และต่อมา E0/0 ของ R1 จะเปลี่ยนเป็น vunl0_1_0 และ E0/0 ของ R2 จะเปลี่ยนเป็น vunl0_2_0 ทั้งหมดนี้จะเป็นชื่อเพื่ออ้างอิงการเชื่อมต่อในระดับ OS เท่านั้น ส่วนในระดับ Application ของ UnetLab จะยังมีชื่อในการอ้างอิงเป็น E0/0 เหมือนเดิม
ต่อมาในเมื่อเราทำการเชื่อมต่ออุปกรณ์เข้าหากันด้วย Bridge network เพียงแค่ Object เดียวดังนั้นในกรณีนี้ผมจะสมมุติให้ Bridge network มีค่าเท่ากับสาย LAN หนึ่งเส้นก็ได้ใช่หรือไม่?? ดังนั้นในเมื่อผมมองว่า Bridge network คือสาย LAN หนึ่งเส้นดังนั้นผมก็จะได้ Diagram ใหม่ตามรูปด้านล่างนี้ครับ
ต่อมาหลายๆคน (อาจจะทุกคน) ก็อาจจะสตั้นนนนน!!! ว่าไอ้ชื่อ vnet0_1 หรือ vnul0_1_0 นี่มันคืออะไรกันแน่ ก็เลยจะขออธิบายดังนี้ครับ
สำหรับ vnet0_1 คือ
ต่อมา vunl0_1_0 อธิบายจากซ้ายไปขวา
ต่อมาผมจะมีตัวอย่าง Lab ที่สร้างขึ้นใน UnetLab ตามรูปนี้ขึ้นมา
ต่อมาก็ลองเข้าไปเช็ค Device ID ตามในรูปด้านล่างนี้
จากรูปก็จะเห็นว่ามี ID: 1, 2 แน่นอนแล้ว ทีนี้เราจะรู้ได้ยังไงว่าอุปกรณ์ในรูปมีการเชื่อมต่อด้วย Bridge network ที่ระดับ OS ได้ถูกต้องแล้วหรือยัง? กรณีนี้เราก็มี Command มาช่วยตรวยสอบเนื่องจากเป็นการเชื่อมต่อใน OS level จึงต้องใช้ Command ที่เกี่ยวกับ Network ของ Ubuntu มาช่วยนั่นคือ “brctl show” และเมื่อใช้ Command นี้ไปแล้วก็จะได้ผลออกมาตามรูปครับ
จากรูปเราก็จะเห็นว่า UnetLab มีการสร้าง Bridge network ขึ้นมา 2 ตัวคือ vnet0_1 และ vnet0_2 โดยที่ vnet0_1 มี vunl0_1_0 และ vunl0_2_0 เชื่อมต่อยู่ (ให้ย้อนกลับไปดูรูปด้านบนด้วยนะครับจะได้เข้าใจมากขึ้น) ส่วนนี้ก็คือเส้นสีดำที่เชื่อต่อ Interface E0/0 ของ R1 และ R2 เข้าด้วยกันนั่นเอง ส่วนที่เหลือก็ตามรูปเลยไม่น่าจะยากแล้ว
ต่อมาอาจจะสงสัยทำไม UnetLab ต้องสร้าง Bridge network ลงมาที่ OS level ด้วย คำตอบง่ายๆเลย Interface ที่สร้างขึ้นมาที่ OS level จะสามารถนำมาใช้งานกับ TCPdump ได้นั่นเอง ดังนั้นการสร้าง Virtual interface ขึ้นมาที่ OS level นั้นก็เพื่อให่สามารถใช้งาน Packet capture ร่วมกับ WireShark ได้นั่นเองงงงงง
สำหรับวันนี้ก็ขอจบหัวข้อ Bridge network ใน UnetLab เอาไว้เท่านี้ ขอบคุณที่ติดตามคร้าบบบบบ _/|\_
Scenario:
The Agency has created a new security policy and since you are part of the security team you need to help them implement them. Some changes on the network have to be implemented through SNMPv2 and it’s up to you to configure your router as a SNMPv2 agent.
สถานะการณ์จำลอง:
ทีม Security ได้สร้าง Rule ขึ้นมาใหม่โดยที่คุณก็เป็นส่วนหนึ่งของทีม Security คุณต้องการช่วยทีมในการ Implement rule มีการเปลี่ยนแปลงบางอย่างบน Network คือการนำ SNMPv2 มาใช้งานและเป็นหน้าที่ของคุณที่จะต้องทำการ Configure SNMPv2 บน Router
Goal:
เป้าหมาย:
IOS:
c3640-jk9s-mz.124-16.bin
Topology:
ปล. เรื่องนี้ Rene ยังไม่ได้ทำ Video แต่การ Configure แนวๆนี้เคยเห็นในข้อสอบ CCIE R&S ด้วยนะ 🙂
OpenFow คือ มาตรฐานเปิดที่อนุญาตให้ผู้ใช้งานสามารถนำโปรโตคอลที่สร้างขึ้นเองนำมาใช้งานได้ในระบบเน็ทเวิร์คที่มีการใช้งานในปัจจุบันได้ โดยที่ OpenFlow จะทำงานคล้ายๆกับการเพิ่ม Feature เข้าไปที่อุปกรณ์ switch, router หรือ wireless access point โดยที่ไม่ต้องการให้เจ้าของผลิตภัณฑ์ทำการเปิดเผยขั้นตอนการทำงานภายในของอุปกรณ์ ในปัจจุบัน OpenFlow ได้มีการนำไปใช้งานกับอุปกรณ์เจ้าหลักๆ โดยจำหน่ายอยู่ในรูปแบบของ switch ที่มีการรองรับการทำงานของ OpenFlow
ในอุปกรณ์ router หรือ switch แบบเก่า fast packet forwarding (data plane) และส่วนที่ทำหน้าในการจัดการ routing protocol (control plane) จะอยู่บนอุปกรณ์เดียวกัน การทำงานของ OpenFlow จะทำการแยกทั้งสองส่วนนี้ออกจากกัน โดย data plane จะยังคงทำงานอยู่บนอุปกรณ์เดิมส่วนที่เป็น control plane (software) ที่ทำหน้าที่ในการตัดสินใจเลือกเส้นทางหรือ routing protocol จะถูกแยกไปอยู่บน controller โดยที่อาจจะเป็นเครื่อง server ทั่วๆไปก็ได้ โดยที่ OpenFlow switch และ OpenFlow controller จะทำการติดต่อกันด้วย OpenFlow protocol ด้วย message ที่กำหนดไว้ เช่น การรับและส่ง packet การเปลี่ยนแปลง forwarding table หรือการอ่านค่าสถานะของอุปกรณ์
Data plane ของ OpenFlow switch จะอยู่ในรูปแบบของ clean flow table abstraction โดยที่ในแต่ละตำแหน่งของ Flow table จะประกอบไปด้วยกลุ่มของ packet ที่มีการระบุการทำงานเอาไว้ด้วย เช่น ให้ส่งออกไปที่ interface ไหน มีการ modify field ใดบ้าง หรือให้ทำการ drop packet ทิ้ง กรณีเมื่อ OpenFlow switch ได้รับ packet เข้ามาและยังไม่เคยอยู่ใน Flow table มันจะถูกส่งไปที่ controller เพื่อให้ controller ทำการตัดสินใจว่าจะจัดการกับ packet ที่ได้รับมานี้อย่างไร โดยมันจะสามารถทำการ drop หรือนำไปใส่ไว้ที่ Flow table และกำหนดการทำงานให้กับ OpenFlow switch ว่าจะต้องส่ง packet นี้ออกไปในทิศทางใดในกรณีที่มีการพบ packet แบบนี้อีกในอนาคต
OpenFlow อนุญาตให้ผู้ใช้งานสามารถสร้าง routing และ switching protocol ขึ้นมาใหม่และนำไปใช้งานได้ง่าย โดยมันจะถูกนำไปใช้งานในรูปแบบของ application ในรูปแบบต่างๆ เช่น virtual machine mobility หรือระบบ network ที่มีความปลอดภัยสูง และ mobile network ในยุคถัดไป
แปลและเรียบเรียงเนื้อหาจาก
Ref: http://archive.openflow.org/wp/learnmore/
Original post from GNS3Vault: http://gns3vault.com/network-management/access-list-logging/
Scenario:
The local boyscout needs your help as a network engineer. They want to make sure everytime their router receives an OSPF packet this will be logged on their local router. Think you can help them out?
สถานะการณ์จำลอง:
เจ้าหน้าที่ NOC ต้องการความช่วยเหลือจาก Network engineer อย่างคุณ พวกเข้ต้องการแน่ใจว่าทุกๆครั้งที่ Router ของเขารับ OSPF packet เข้ามามันจะถูก Log อยู่บน Router ของเขา คุณคิดว่าจะช่วยพวกเขาได้ไหม?
Goal:
เป้าหมาย:
IOS:
c3640-jk9o3s-mz.124-16.bin
Topology:
Video Solution:
หมายเหตุ:
สำหรับ Configuration file ต้องทำการสมัครสมาชิกของเวบ GNS3Vault ก่อนจึงจะสามารถทำการโหลดมาใช้งานได้ครับ
ความเห็นล่าสุด