The value of this option is contained within the next "01" octets which contains "05". The length of the data in this option is "01" octets. Using the example above, "35" (hexadecimal) is the option "code", which, according to RFC 2132 corresponds to (ASCII 53) "DHCP Message". To read the options in the vendor specific information option, start with the first octet after the magic number. I will take the packet trace from the previous page as an example:
This portion of the packet is defined by specifying the RFC 1048 "Magic Number" - a sequence of numbers that indicates that the following portion of the packet is encoded as a sequence of code/length/value fields intended for transmitting vendor-specific information between clients and servers. The vendor specific information portion of a DHCP packet begins at octet # 0x0104. The following is a DHCP ACK packet from a NetBoot server. This article will not delve into a DHCP exchange, but it is worthwhile to understand the basic anatomy of a DHCP packet. The first half of this phase is a standard DHCP exchange. The following diagram provides a visual description of the flow of traffic between a NetBooting client, a DHCP server, and a NetBoot server during the initial phase of the NetBoot process.
In this article I explain the components of a typical DHCP packet, dig deeper into the vendor options and BSDP-specific options, then I describe the NetBoot process from the NetBoot server perspective. Understanding the content of the DHCP and BSDP communication between servers and clients can provide excellent insight for troubleshooting the NetBoot process. Options not present within the DHCP specification are provided as vendor-specific information. BSDP is implemented within the Vendor Options of DHCP as defined in RFC 2132. NetBoot uses the Boot Server Discovery Protocol (BSDP) to communicate network boot image options between clients and servers.
0 kommentar(er)
