คู่มือ DHCP Option Reference: เจาะลึก option จาก RFC 2132 และการสร้าง hex payload สำหรับ VoIP

เมื่อโทรศัพท์ VoIP บูตขึ้นมาบนเครือข่ายของคุณ การได้ IP address มาเป็นเรื่องง่าย แต่สิ่งที่ยากคือการบอกให้เครื่องรู้ว่า provisioning server อยู่ที่ไหน ซึ่งคำสั่งนั้นมักมาในรูปของ hex payload ภายใน DHCP option 43 และถ้า length byte ผิดแม้แต่ตัวเดียว โทรศัพท์ก็จะวน reboot ไปเรื่อย ๆ ขณะที่ผู้ใช้งงว่าทำไมเบอร์โทรบนโต๊ะถึงเงียบสนิท

เครื่องมือ DHCP Option Reference จาก Online Tools Forge ช่วยขจัดการเดาในจังหวะแบบนั้น คุณสามารถเรียกดู option ทุกตัวจาก RFC 2132 พร้อม type และคำอธิบายของแต่ละตัว จากนั้นสร้าง hex payload แบบกำหนดเองสำหรับ option 43 (vendor-encapsulated), option 60 (vendor class), option 66 (TFTP server) และ option 51 (lease time) โดยระบบจะจัดการรูปแบบ TLV ที่มี length prefix ให้อัตโนมัติทั้งหมด

บทความนี้จะพาไปดูว่าทำไม option เหล่านี้จึงสำคัญ เครื่องมือทำงานอย่างไร และ hex string ที่ถูกต้องช่วยให้งาน deploy สำเร็จได้อย่างไร ตั้งแต่โทรศัพท์ VoIP ทั้งองค์กร ไปจนถึง PXE boot และการ onboarding access point

ทำไมต้องใช้ DHCP Option Reference?

• ปัญหา hex ของ option 43 เป็นเรื่องจริง Cisco, Polycom, Yealink และ Ubiquiti ต่างคาดหวังรูปแบบ hex ที่แตกต่างกันเล็กน้อย การนับ byte ด้วยมือใน text editor มักจบด้วยความล้มเหลวแบบเงียบ ๆ ที่ debug ยากมาก
• รายการ RFC 2132 ครบในที่เดียว option มาตรฐานทุกตัวพร้อมหมายเลข type และคำอธิบายที่อ่านเข้าใจง่าย ช่วยให้คุณยืนยันได้ก่อนตั้งค่าว่า option 66 หรือ option 150 ส่งข้อมูลอะไรกันแน่
• จัดรูปแบบ TLV ให้อัตโนมัติ option 43 เป็นโครงสร้างแบบ code-length-value ที่มี length prefix ถ้า byte ความยาวผิด โทรศัพท์จะ parse ข้อมูลไม่ได้เลย เครื่องมือคำนวณทุก prefix ให้คุณเอง
• ผลลัพธ์ copy-paste ใช้ได้กับทุก router payload ที่สร้างได้พร้อมวางลง scope option บน Windows DHCP Server, dnsmasq, ISC dhcpd หรือ controller แบบ cloud ได้ทันที
• ทำงานในเบราว์เซอร์ทั้งหมด ไม่ต้องติดตั้ง ไม่ต้องสมัครบัญชี ไม่มีการอัปโหลดข้อมูล เหมาะกับตอนที่คุณยืนอยู่ในห้องเดินสายพร้อมแล็ปท็อปและสายแลนหนึ่งเส้น
• deploy ปลอดภัยขึ้น การสร้างและตรวจ payload ก่อนแตะ production scope ช่วยลดความเสี่ยงที่ option เพียงตัวเดียวพลาดแล้วกระทบ voice VLAN ทั้งวง

ฟีเจอร์หลัก

มีสองรายละเอียดที่น่าจับตา:

• หัวใจของเครื่องมือคือเอนจิน TLV เมื่อคุณเพิ่ม sub-option เข้าไปใน payload ของ option 43 ระบบจะใส่ code และ length byte ที่ถูกต้องให้ทุกค่า ทำให้อุปกรณ์ parse ผลลัพธ์ได้สะอาดตั้งแต่ครั้งแรก
• เพราะผลลัพธ์เป็น hex ธรรมดา payload เดียวกันจึงใช้ได้ทั้ง dnsmasq, Windows Server DHCP, UniFi และ Meraki โดยไม่ต้องจัดรูปแบบใหม่

วิธีใช้งาน DHCP Option Reference

1. เรียกดูรายการ option เปิดเครื่องมือแล้วดูตาราง RFC 2132 เพื่อยืนยันหมายเลข option และ data type ที่ต้องการ เช่น option 43 รับ hex ของ vendor ส่วน option 66 รับชื่อ TFTP server เป็น string
2. เลือกสถานการณ์ของ vendor ดูว่าอุปกรณ์ของคุณต้องการอะไรจริง ๆ โทรศัพท์ Polycom มักใช้ option 60 คู่กับ option 66 ขณะที่รุ่น Cisco และ Yealink จำนวนมากต้องการ payload แบบ TLV ของ option 43 ที่ชี้ไปยัง provisioning server
3. กรอกข้อมูล server และ VLAN พิมพ์ address ของ provisioning หรือ TFTP server, VLAN ID ถ้ามี และค่า lease time ลงในช่องของตัวสร้าง
4. สร้าง hex เครื่องมือจะประกอบ payload แต่ละตัว เพิ่ม length prefix ให้อัตโนมัติ แล้วแสดง hex string สุดท้ายของทุก option
5. วางลง router คัดลอก payload ไปวางใน scope option ที่ตรงกันบน DHCP server หรือ controller แล้ว renew lease บนอุปกรณ์ทดสอบหนึ่งเครื่องเพื่อยืนยันว่า option มาถึงจริง

ตัวเลือกที่ใช้ปล่อยโทรศัพท์ VoIP

DHCP ส่งการตั้งค่าเหล่านี้มาพร้อมกระบวนการเช่า IP ปกติ ไคลเอนต์ broadcast DHCPDISCOVER server ตอบกลับด้วย DHCPOFFER ที่มี address และ options จากนั้นไคลเอนต์ขอเช่าอย่างเป็นทางการ และ DHCPACK ตัวสุดท้ายจะบรรจุ option set ครบชุด ทุกอย่างที่คุณตั้งใน scope รวมถึง vendor option จะขี่มากับข้อความยืนยันนี้

option 43 เป็นตัวที่ยุ่งยากที่สุด เพราะ RFC 2132 นิยามมันแค่เป็น container เท่านั้น มาตรฐานไม่ได้บอกว่าข้างในต้องมีอะไร แต่ละ vendor เติมของลงไปด้วย sub-option ของตัวเองในรูปแบบ TLV คือ code หนึ่ง byte, length หนึ่ง byte แล้วตามด้วยค่า เช่น payload ที่ชี้โทรศัพท์ไปที่ 192.168.1.10 อาจอ่านว่า 01 04 C0 A8 01 0A หมายถึง sub-option code 1, length 4 และ IP ที่แพ็กเป็น hex จุดที่ vendor แตกต่างกันคือบางเจ้านิยาม code ของตัวเอง บางเจ้าต้องการ ASCII string แทน byte ที่แพ็ก และบางเจ้าใช้ธรรมเนียมความยาวต่างกัน นั่นคือเหตุผลที่การตั้งค่าเดียวกันกลายเป็น hex คนละแบบในแต่ละ vendor

option 60 หรือ vendor class identifier ทำงานสวนทางกัน ไคลเอนต์ประกาศว่าตัวเองคืออะไร แล้ว server ใช้ string นั้นจับคู่ policy เช่น ให้ boot server กับ PXE client แต่ไม่ให้อะไรกับ workstation ทั่วไป มันจับคู่กับ option 43 ได้ดีมาก: class ระบุตัวอุปกรณ์ และ encapsulated options ทำหน้าที่ให้บริการมัน

option 66 หรือ TFTP server name เป็น boot option คลาสสิก เป็น string ง่าย ๆ ที่บอกโทรศัพท์หรือ thin client ว่าให้ไปดึง firmware และ configuration จากไหน หลายสภาพแวดล้อมยังพึ่งพามันอยู่แม้อุปกรณ์รุ่นใหม่จะย้ายไปใช้ option 150 หรือ URL แบบ HTTPS แล้ว ส่วน option 51 หรือ lease time เข้ารหัสเป็นเลข 32-bit หน่วยวินาที เครือข่าย voice มักเลือก lease ยาวเพื่อลดปริมาณ renewal ขณะที่ guest network ใช้ lease สั้นเพื่อหมุนเวียน address ได้เร็ว

ตัวอย่างการใช้งานจริง

ปรับใช้โทรศัพท์ VoIP ทั้งองค์กร

การม้วนโทรศัพท์ตั้งโต๊ะหลายร้อยเครื่องคือจุดที่ option 43 สร้างคุณค่าที่สุด สร้าง payload ของ vendor ครั้งเดียวในเครื่องมือ วางลง voice scope พร้อม option 60 และ 66 แล้วทดสอบกับเครื่องเดียวก่อนวัน cutover พอทั้ง fleet reboot กลางคืน ทุกเครื่องก็เจอ provisioning server โดยไม่ต้องแตะมือแม้แต่ครั้งเดียว

ตั้งค่า PXE และ Network Boot

PXE client ประกาศตัวเองด้วย option 60 ที่ตั้งเป็น PXEClient และย้อนยุคพึ่ง option 66 บวกกับ boot filename เพื่อค้นหา image server การสร้างค่าเหล่านี้ให้ถูกต้องตั้งแต่ต้นช่วยกำจัด error คลาสสิกอย่าง "no boot filename received" ระหว่างการ deploy ระบบปฏิบัติการ

Onboarding Access Point และการแบ่ง VLAN

access point หลายรุ่นเรียนรู้ address ของ controller หรือ management VLAN จาก option 43 เช่น อุปกรณ์ Ubiquiti ค้นหา UniFi controller ผ่าน payload ที่เป็น sub-option code 1 ตามด้วย IP ของ controller แบบสี่ byte ซึ่งเป็น string ประเภทเดียวกับที่ตัวสร้างผลิตออกมาได้พอดี

สอนพื้นฐาน DHCP ในห้องเรียน

ผู้สอนสามารถเปิดตาราง RFC 2132 ขึ้นจอ ให้นักเรียนประกอบ payload แบบ TLV ในเครื่องมือ แล้ว capture lease จริงด้วย Wireshark เพื่อเทียบ byte บนสายกับสิ่งที่สร้างไว้ หมายเลข option ที่เคยเป็นนามธรรมจะกลายเป็น hex ที่จับต้องได้

แนวปฏิบัติที่ดีที่สุด

• ใช้รูปแบบของ vendor ให้ตรงเป๊ะ เครื่องมือรับประกันโครงสร้างที่ถูกต้อง แต่ code และการเข้ารหัสของ sub-option เป็นของแต่ละ vendor นิยาม ควรเช็กคู่มือ provisioning ของ vendor ก่อนเสมอ
• ทดสอบโทรศัพท์เครื่องเดียวก่อน apply payload กับ test scope หรือ reservation เดียวก่อนที่ VLAN ทั้งวงจะได้รับมันไปทั้งก้อน
• จดบันทึก option ต่อ VLAN บันทึกว่าแต่ละ scope ใช้ option อะไร ค่าอะไร และ hex payload อะไร เพื่อไม่ให้วิศวกรคนถัดไปต้องนั่งถอดรหัสงานของคุณ
• ทำ inventory ของ scope options ตรวจสอบ DHCP scope เป็นระยะ payload ของ option 43 ที่ค้างชี้ไปยัง server ที่ปลดระวางไปแล้ว สร้างอาการบูตล้มเหลวปริศนาได้อีกนานหลายเดือน
• เลือก lease time อย่างมีเหตุผล ใช้ option 51 ถ่วงดุลระหว่างความยืดหยุ่นกับภาระ renewal: lease ยาวสำหรับ voice network ที่นิ่ง และ lease สั้นสำหรับกลุ่ม guest และ IoT
• ตรวจสอบบนสายจริง capture ด้วย Wireshark สั้น ๆ หรือดูหน้า status ของตัวโทรศัพท์เอง เพื่อยืนยันว่า option ของคุณมาถึงอย่างครบถ้วน

พร้อมเลิกนับ byte เป็น hex ด้วยมือหรือยัง? เปิด DHCP Option Reference เรียกดู option จาก RFC 2132 แล้วสร้าง payload ที่ copy-paste ได้ทันทีสำหรับงาน deploy โทรศัพท์ access point หรือ PXE ครั้งต่อไปของคุณ — ฟรี รวดเร็ว และทำงานในเบราว์เซอร์ทั้งหมด

เครื่องมือที่เกี่ยวข้องที่คุณอาจสนใจ:

• Subnet Calculator — วางแผน addressing ของ voice VLAN ที่โทรศัพท์ของคุณจะอยู่
• IP Range Calculator — กำหนดช่วง address ที่ DHCP scope เบิกจ่ายได้อย่างเป๊ะ
• IP Lookup — สืบว่า address ของอุปกรณ์มาจากไหนเมื่อ lease เริ่มมีปัญหา

ขอให้สนุกกับการทำเน็ตเวิร์ก!

คำถามที่พบบ่อย

ถ: DHCP option 43 ใช้ทำอะไร? ตอบ: มันใช้ขนส่ง vendor-encapsulated options คือข้อมูลเฉพาะของ vendor เช่น address ของ provisioning server, IP ของ controller หรือ VLAN ID ในรูปแบบ code-length-value (TLV) แบบ hex ที่อุปกรณ์ของ vendor นั้นรู้วิธีอ่าน

ถ: ทำไม hex string ของ option 43 ถึงต่างกันในแต่ละยี่ห้อโทรศัพท์? ตอบ: RFC 2132 นิยาม option 43 เป็นแค่ container แต่ไม่ได้กำหนดเนื้อหาข้างใน แต่ละ vendor นิยาม code และการเข้ารหัสของ sub-option เอง payload ของ Cisco จึงมีโครงสร้างต่างจากของ Yealink หรือ Ubiquiti

ถ: option 60 กับ option 43 ต่างกันอย่างไร? ตอบ: option 60 คือ vendor class identifier ที่ไคลเอนต์ส่งมาบอกว่าตัวเองคืออะไร เพื่อให้ server ใช้จับคู่ policy ส่วน option 43 คือข้อมูลเฉพาะ vendor ที่ server ส่งกลับไปให้อุปกรณ์

ถ: เครื่องมืออัปโหลดข้อมูลเครือข่ายของฉันไปที่อื่นหรือเปล่า? ตอบ: ไม่เลย เครื่องมือสร้าง payload ทุกตัวในเบราว์เซอร์ของคุณ ไม่มีการส่งข้อมูลไปยัง server ไม่มีการจัดเก็บ และไม่มีการบันทึก log