Archive by category "UnetLab"

การสร้าง Initial configuration ของอุปกรณ์ใน UnetLab

กลับมาเขียนบทความลง Blog อีกครั้งหลังจากมีกิจกรรมใหม่ๆอีกครั้งครับ

รอบนี้เป็นบทความที่ค้างไว้จากที่ได้แจ้งไว้ที่หน้า FaceBook page และเป็นเรื่องที่หลายๆคนที่มีเรียน UnetLab แล้วยังมึนๆอยู่ นั่นคือเรื่องของการทำ Initial configure (Exported CFG) ของอุปกรณ์นั่นเอง

ก่อนอื่นก็ต้องขอเกริ่นกันก่อนว่า Initial configure ที่ว่านี้คืออะไรกันก่อน ลองนึกดูว่าในการทำ Lab ของแต่ละคนจะต้องทำอะไรก่อนเป็นขั้นตอนแรกหลังจากเปิดอุปกรณ์อย่าง Router ขึ้นมา? สิ่งที่หลายๆคนจะทำก็คือการตั้งค่า Hostname และการกำหนด IP address ให้กับ Interface ต่างๆของอุปกรณ์ที่ได้ออกแบบมาไว้แล้วจาก Diagram ที่เราวาดไว้ในกระดาษหรือโปรแกรมก่อนหน้านี้ (ไม่รวมการต่อสายต่างๆนะ) ซึ่งเมื่อทำขั้นตอนนี้เสร็จแล้วส่วนมากเราจะทำการ Save configuration ชุดนี้ไว้ก่อนที่จะเริ่มลงมือทำการทดลอง Lab กันต่อไป ซึ่งขั้นตอนนี้นี้ผมจะขอเรียกว่าการทำ Initial configure ของ UnetLab นั้นเอง

คำถามต่อมาทำไมเราจะต้องมาทำ Initial configure ด้วยล่ะ? ในเมื่อเวลาที่เราทำ Lab ไปแล้วเราก็ลงมือทำต่อไปเรื่อยๆได้อยู่แล้ว ไม่เห็นว่าจะมีความจำเป็นอะไรเลย? ลองย้อนกลับไปที่การทำ Lab ด้วยการใช้อุปกรณ์จริงกันก่อนละกัน ผมจะมีคำถามว่าถ้าเรา Configure อุปกรณ์ผิดไปแล้วหาจุดที่เราทำผิดไม่ได้และทำให้ต้องเริ่ม Configure อุปกรณ์ใหม่ตั้งแต่ต้นอีกครั้งหรือไม่? น่าจะเคยกันมาบ้างสำหรับคนที่ต้องการทำ Lab บ่อยๆ กรณีนี้หลายๆคนก็จะบอกว่าทำผิดก็อย่าเพิ่งไป Save configure ที่ไว้ไว้สิ พอเปิดปิดอุปกรณ์ใหม่มันก็มาเริ่มจุดที่ทำ Save ไว้ วิธีการแบบนี้ก็เป็นที่มาของการใช้งาน Initial configure แบบ Classic แบบนึงครับ แต่ที่มันเหนือกว่านั้นคือใน UnetLab สามารถทำการดึงเอา Initial configure ที่เก็บไว้นำมา Apply กลับเป็น Initial configure ที่ต้องการหลังจากที่เราได้ Save configuration ด้วย Command เช่น Write men หรือ Commit ทับ Initial configure ที่ใช้อยู่ไปแล้วไม่ว่าจะมีการ Save ทับไปแล้วกี่รอบด้วยการกดเมนูเท่านั้น ไม่ต้องทำการ Dump configuration ใหม่อีกรอบ

ประโยชน์ที่ผู้ใช้งานจะได้รับอย่างเต็มที่อีกส่วนหนึ่งก็คือการสร้าง Lab เพื่อฝึกแก้ปัญหาที่เกิดขึ้น เช่น ฝึกทำ Lab สำหรับการสอบ TSHOOT หรือการเตรียมสอบ CCIE ที่มีหัวข้อ Troubleshooting นั้นเอง การแก้ปัญหาหรือ Ticket ในลักษณะนี้มักจะมีการทดลองแก้ Configuration ของอุปกรณ์อยู่เสมอๆ และบ่อยครั้งที่จะทำให้ค่าที่โจทย์ให้มีมีปัญหาหนักมากกว่าเดิม!!! เนื่องจากเราแก้ปัญหาผิดจุดนั้นเอง การนำ Initial configuration มาใช้งานในลักษณะนี้จึงมีประโยชน์อย่างมากนั้นเอง แต่ UnetLab ยังมีการทำงานทีเกี่ยวกับการจัดการ Configuration รูปแบบอื่นอีกซึ่งจะมีตัวอย่างการใช้งานด้านท้ายบทความครับ

เท่านี้ก็คงจะพอเห็นความสำคัญของการนำ Initial configure มาใช้งานกันบ้างแล้วนะครับ ในส่วนนี้เราจะมาเริ่มลงมือสร้าง Initial configure ใน UnetLab กันครับ

ก่อนที่จะลงมือสร้าง Initial configure นั้นเราจะต้องสร้าง Lab ใน UnetLab ขึ้นมาให้เรียบร้อยก่อน โดยในตัวอย่างผมจะใช้ Lab ที่ได้สร้างไว้แล้วในหัวข้อของ Service Provider (ยังไม่ได้เขียนต่อเลย ^^”)

จากรูปตัวอย่างถ้าใครสังเกตุจะเห็นว่ามีการเปลี่ยนแปลงเล็กน้อยที่ CE ทั้งสองฝั่งเมื่อเทียบกับตัวอย่างใน Blog เนื่องจากมีแผนที่จะเพิ่มรูปแบบ Lab นั่นเองครับ ^^

ขั้นตอนต่อมาให้ทำการเปิดอุปกรณ์ขึ้นมาทั้งหมดและ Configure อุปกรณ์โดยใช้ Command ที่อยู่ในหัวข้อ “Service Provider Lab Series Part 1” มาสร้างเป็น Initial configure ครับ เมื่อใส่ Command ให้กับอุปกรณ์ที่ต้องการหมดแล้วต้อง Save configuration ให้อุปกรณ์ทุกตัวด้วย Command “wr” หรือ “commit” เพื่อ Save configuration ที่เราทำไว้

ขั้นตอนนี้จะเป็นขั้นตอนพิเศษสำหรับการสร้าง Initial configure แล้ว ให้เลือกที่เมนู More actions -> Export all CFGs เพื่อให้ UnetLab ทำ Export configuration ที่เรา Save ไว้บนอุปกรณ์ออกมาเก็บไว้

จากนั้นให้ลองตรวจสอบการทำงานของ UnetLab ว่าถูกต้องหรือไม่โดยไปที่เมนู Startup-configures ถ้าเราทำถูกต้องจะต้องมี
รูป Drive A ที่มีเครื่องหมายถูกบนมุมขวาล่างขึ้นมาที่หลังรายชื่ออุปกรณ์ทุกตัวที่ได้ Save configuration ไว้ เพียงเท่านี้เราก็จะมี Initial configure ของอุปกรณ์เก็บไว้ใช้งานแล้ว

มาถึงตอนนี้หลายๆคนจะมีคำถามขึ้นมาคือ แล้วอะเอาไปใช้งานยังไง? สำหรับการใช้งานอะแบ่งออกเป็นลักษณะต่างๆดังนี้

  • เมื่อต้องการนำ Initial configure มาใช้งาน -> กด Set all startup-cfg to exported -> Wipe all nodes
  • เมื่อต้องการให้อุปกรณ์กลับไปที่สถานะที่ไม่มีการตั้งค่าให้อุปกรณ์ใดๆเลย(No configuration) -> กด Set all startup-cfg to none -> Wipe all nodes
  • เมื่อไม่ต้องการลบ Initial configuration ออกไป คือไม่ต้องการให้มีการเก็บ Initial configuration ไว้ใช้งานอีกต่อไป -> กด Delete all startup-cfg -> Wipe all nodes

ลองมาสรุปการทำงานของการสร้าง Initial configuration ใน UnetLab กันด้วยรูปก็น่าจะได้ประมาณนี้ครับ

สำหรับบทความนี้สามารถโหลดบทความในรูปแบบ PDF ได้จาก ที่นี่ ครับ

สำหรับ Video เสริมความเข้าใจดูได้จากด้านล่างนี้เลยครับ

การ Convert disk image เพื่อใช้งานบน UnetLab

ทำตามสัญญาครับวันนี้ทำ Video เรื่องการ Convert disk image บน UnetLab มาให้ดูครับ ตามตัวอย่างมี 3 ตัวคือ Arista, F5 และ HP โดยทั้ง 3 ตัวสามารถไปขอใช้งานได้ฟรีแต่ต้องมีการ Register ก่อนครับ

ลองทำตามกันดูครับติดขัดยังไงก็ลอง Post ถามกันได้ครับ

Video สาธิตการใช้งาน UnetLab เบื้องต้น

กลับมาลองทำ Video เป็นทางการอีกครั้งในรอบปีเลยทีเดียว 🙂

วันนี้ขอเสนอการใช้งาน UnetLab แบบคร่าวๆมาให้ดูครับ ต้องบอกก่อนว่า Video นี้ไม่ได้มีรายละเอียดทั้งหมดแต่เป็นการให้ Idea ในการเริ่มใช้งานเท่านั้นนะครับ สำหรับรายละเอียดเดี๋ยวจะทำออกมาให้ดูบางส่วนอีกครั้งนึง

เข้าใจการทำงาน bridge network บน UnetLab

กลับมาอีกครั้งกับการขุด 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 คือ

  • vnet คือ Bridge network
  • 0      คือ Reference Object ID  ของ User admin หรือ POD 0 ในกรณีที่ Login และ Start Lab ด้วย User admin กรณีที่ Start Lab ด้วย User อื่นตัวเลขก็จะเปลี่ยนไปตาม User
  • 1       คือ Reference Object ID ของ Bridge network ในกรณีนี้คือ Object ที่ 1

ต่อมา vunl0_1_0 อธิบายจากซ้ายไปขวา

  • vunl คือ อุปกรณ์เสมือนที่อยู่ใน UnetLab
  • 0      คือ Reference Object ID  ของ User admin หรือ POD 0 ในกรณีที่ Login และ Start Lab ด้วย User admin กรณีที่ Start Lab ด้วย User อื่นตัวเลขก็จะเปลี่ยนไปตาม User
  • 1       คือ Reference Device ID ของอุปกรณ์เสมือนที่อยู่ใน UnetLab ในกรณีนี้คือ Device ID ที่ 1
  • 0      คือ Interface Index ของอุปกรณ์เสมือนที่อยู่ใน UnetLab ซึ่ง UnetLab จะสร้างขึ้นมาให้เอง

ต่อมาผมจะมีตัวอย่าง 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 เอาไว้เท่านี้ ขอบคุณที่ติดตามคร้าบบบบบ _/|\_

 

การเพิ่ม QEMU Option สำหรับ Windows host template เพื่อใช้งาน Sound card ใน UnetLab: How to add QEMU option on Windows host template in UnetLab

กลับมาแล้วหลังจากหายหน้าไปเตรียมตัวและสอบมา 🙂

Hi Dude, I’m back.

 

บทความนี้จะเป็นบทความสั้นๆในการเพิ่ม QEMU option เพื่อให้ Windows Guest OS สามารถใช้งาน Sound Card ที่ต้องการใน UnetLab ได้ เพื่อเพิ่มความสามารถให้สามารถทดลอง Lab ที่เกี่ยวกับ Voice ได้

This topic a short topic about  how to add QEMU option in UNL template for support sound card in Windows guest OS. This modification will enable you to test lab that relate to voice lab.

ในหัวข้อนี้จะต้องมีการแก้ไข Host template ของ Windows โดยการเพิ่ม QEMU option “-soundhw [HW]”

โดยที่ [HW] สามารถใส่ Sound card ชนิดต่างๆได้ดังต่อไปนี้

This topic will let you modify windows host template in UnetLab (UNL) by add QEMU option “-sound [HW]” to win.php template. For [HW] is sound hardware that QEMU support in list below:

  • sb16           Creative Sound Blaster 16
  • es1370       ENSONIQ AudioPCI ES1370
  • ac97           Intel 82801AA AC97 Audio
  • adlib          Yamaha YM3812 (OPL2)
  • gus             Gravis Ultrasound GF1
  • cs4231a     CS4231A
  • hda             Intel HD Audio
  • pcspk         PC speaker

โดยเราสามารถแสดง Sound card ที่ QEMU support ได้โดยใช้ Command

We can check sound hardware that QEMU support by using this command.

“./qemu-system-x86_64 -soundhw ?”

QEMU จะแสดงรายชื่อ Sound card ที่ Support ออกมาดังนี้

QEMU will display sound hardware as below.

จากนั้นนำรายชื่อ Sound card ที่ QEMU รองรับไปใส่ใน Host template เพื่อ Enable การใช้งาน Sound card ในตัวอย่างนี้จะเป็นการแก้ Windows template เท่านั้น สำหรับกรณี Linux สามารถใช้งานแบบเดียวกันนี้ได้เช่นเดียวกัน

สำหรับการแก้ Host template ให้เข้าไปที่ path: /opt/unetlab/html/templates

จากนั้นให้ทำการแก้ Windows host template โดยใช้ Command ดังนี้

After that we can use any preferred sound hardware put in win.php template for enable sound hardware in your windows guest OS. In this case I’ll modify only Windows host template. But, you can also use this method for linux host template.

For modify Windows host template you need to do to path:  /opt/unetlab/html/templates. After that you need to modify win.php (Windows host template) by using this command:

“nano win.php”

จากนั้นให้ทำการใส่ Option -soundhw ac97 เพิ่มลงไปในส่วนของ QEMU option ใน Template ตามรูปด้านล่างนี้

I’m preferred hardware “Intel 82801AA AC97 Audio”. So, I’ll put -soundhw ac97 in to “qwmu_options” parameter as in picture below.

เมื่อแก้เสร็จแล้วให้ทำการ Save template และทำการ Start Guest OS ขึ้นมาเพื่อทำการทดสอบ Option ที่เราเพิ่มเข้าไปใหม่ โดยระหว่างที่ Windows Guest OS กำลัง Boot อยู่จะเห็น Windows ทำการ Update driver เพิ่มให้เรา และเมื่อ Windows ทำการ Update driver เรียบร้อยแล้วให้เราทำการเช็ค Hardware ที่ Device manager จะพบว่า Windows มีการเพิ่ม Sound card เข้าไปแล้วตามรูปด้านล่างนี้

After modified you need to save template and start your guest OS in UNL again for testing inserted option. After boot you will see windows update new driver that we added to your guest OS. You can check your new sound hardware by go to device manager after that you will see your new sound hardware as in picture below.

Cheers:)

จบแล้วครับสำหรับการเพิ่ม QEMU option เพื่อให้สามารถใช้งาน Sound hardware บน Windows จากนี้ไปเราก็จะสามารถนำ UNL มาทำ Lab ที่เกี่ยวกับ Voice เพิ่มขึ้นได้อีกส่วนนึงแล้วครับ

ขอบคุณที่ติดตามครับ ^^

หมายเหตุ: การแก้ Host template นี้อ้างอิงจาก UNetLab 0.9.0-96 Released

Remark: This topic test under UNetLab 0.9.0-96 Released.