Jul
22

The DHCP Information option (Option 82) is commonly used in metro or large enterprise deployments to provide additional information on “physical attachment” of the client. Option 82 is supposed to be used in distributed DHCP server/relay environment, where relays insert additional information to identify the client’s point of attachment.

As you know, DHCP relay is supposed to insert the “giaddr” field in the relayed DHCP packets, so that DHCP server may identify the pool to be used for the request. The choice of the pool is made based on the “giaddr” field or the incoming interface, if the “giaddr” is missing or zero . Option 82 serves as refinement to the request, allowing the DHCP server to select a “sub-range” in the pool. (Notice that by default Cisco IOS devices reject packets with zero “giaddr” and by default Cisco Catalyst switches use “giaddr” of zero when configured for DHCP snooping!)

The formatting of Option 82 field is as follows. The option starts with 0×52 (82 decimal) followed by the total option length. The option is structured in sub-options, formatted in the same way: . The list of options is terminated with option 0xFF so you can easily spot Option 82 in a packet dump.

<Option 82>  ::= 0x52 | LEN | <sub-option1> | <sub-option2> |.. | 0xFF |
<sub-option> ::= <option-id> <length> <contents>

RFC 3046 defines just a couple of sub-options, namely the “remote-id” (option ID 0×2) and the “circuit-id” (ID 0×01). Those two are supposed to identify the remote device and the port where the DHCP request was received. However, many vendors prefer using their own extensions to Option 82, based on its flexible format. This freedom of choice leads to some serious consequences with respect to IOS devices configuration. We are now going to discuss this a bit later. For now, keep in mind that IOS devices use sub-option 0×6 instead of 0×1 for circuit identification (at least the more recent IOS releases). The formatting of the sub-options is also vendor and software version dependent!

In Cisco IOS devices, you configure information-option based address allocation using the concept of DHCP class. A given class specifies the range of Option 82 values and could be associated with a range of addresses in DHCP pool. Before you can use classes, make sure the command ip dhcp use class is enabled in router’s configuration (the default). After this, you may create a class as follows:

ip dhcp class TEST
  relay agent information
     relay-information hex 020c01020304*

Notice the use of “*” globbin pattern to match any string of characters after the initial substriting. This type of formatting specifies the value of DHCP Option 82 in “raw” format – that is, no structure is specified in the option. The value used in the class is everything that follows the initial “0×52 ” tuple in Option 82 – that is, the list of all sub-options, including their initial ID/Length tuples. The terminating option 0xFF is not included in the relay-information field. Due to the flexibility of Option 82 formats, Cisco IOS only allows you using the “raw” formatting, without any referencing to the sub-options and their values. In addition to the globbing character “*” you may also use inverse wildcard mask as follows:

relay-information hex  bitmask 0000000FF

where the bitmask follows the same syntax as an access-list wildcard, with “1” meaning “don’t care”. Notice that the relay-information value is formatted in hex and should contain even number of character. The bitmask should match the relay-information length.

Next, after you have the class configured, you may associate it with a DHCP pool. Remember that the pool address range should match the “giaddr” IP address found in the relayed packet:

ip dhcp pool POOL
  network 204.12.1.0 255.255.255.0
  class TEST
     address range 204.12.1.100 204.12.1.100

Notice how the range is assigned to the class associated with the DHCP pool. Now the question that people usually ask is: “If IOS uses raw formatting for Option 82, how do I find the value used by the remote relay?”. Cisco documentation refers you back to the “vendors” specifications for the use of Option 82. What if you just configured a server and a relay and want to learn the value of DHCP Option 82 used?

1) Make sure remote device is configured for insertion of Option 82. For an IOS router, you may want to have a configuration similar to the following:

ip dhcp relay information option
!
interface Fa 0/0
 ip helper-address 10.0.0.1
 ip dhcp relay information option subscriber-id TEST

The above configuration sets the value of the subscriber-ID (even though it’s NOT sub-option 0×2, but rather sub-option 0×6). Notice that by default, the information option is not being inserted by IOS routers. Furthermore, the syntax is different for IOS switches and may vary from model to model. By default, when you enable DHCP snooping in a 3550/3560 switch, the switch will be inserting the information option but will set “giaddr” to zero. To handle this in an IOS router, use the command ip dhcp relay information trust-all to accept packets with zero “giaddr”.

2) Configure a DHCP pool matching the remote “giaddr” IP address value. Create a DHCP class with a relay-information value that should never be met in real life. For example set the value to “00000000*” which should never match any sub-option. Associate this class with the pool and configure a sub-range as usual.

3) Enable the following debug in the server: debug ip dhcp server class which tracks the class-based allocation. When an incoming packet contains a DHCP Option 82 that does not match any class, the output similar to the following will appear:

DHCPD: Class 'TEST' matched by default
DHCPD: Searching for a match to 'relay-information
020c020a0000cc0c010200000000060454455354' in class TEST

revealing the actual value of Option 82 in the packet. In the output above, there ate two sub-options: 0×2 with the length of 0xc and 0×6 with the length of 0×4. Using this debugging output you may quickly learn the value of Option 82 used by the remote relay, without referring to any low-level debugging commands.

The above posted quickly summarizes all you probably need to know about Option 82 and its relation to the CCIE R&S exam.

About Petr Lapukhov, 4xCCIE/CCDE:

Petr Lapukhov's career in IT begain in 1988 with a focus on computer programming, and progressed into networking with his first exposure to Novell NetWare in 1991. Initially involved with Kazan State University's campus network support and UNIX system administration, he went through the path of becoming a networking consultant, taking part in many network deployment projects. Petr currently has over 12 years of experience working in the Cisco networking field, and is the only person in the world to have obtained four CCIEs in under two years, passing each on his first attempt. Petr is an exceptional case in that he has been working with all of the technologies covered in his four CCIE tracks (R&S, Security, SP, and Voice) on a daily basis for many years. When not actively teaching classes, developing self-paced products, studying for the CCDE Practical & the CCIE Storage Lab Exam, and completing his PhD in Applied Mathematics.

Find all posts by Petr Lapukhov, 4xCCIE/CCDE | Visit Website


You can leave a response, or trackback from your own site.

10 Responses to “Understanding DHCP Option 82”

 
  1. toni says:

    Petr

    this is what i’m looking for

    thanks a lot

  2. Yuri says:

    Petr,

    When setting up dhcp snooping on a 3550 Insertion of option 82 is enabled by default. This seems to cause problems as you mention with IOS DHCP servers.

    DHCPD: inconsistent relay information.
    DHCPD: relay information option exists, but giaddr is zero

    The only ways around this it seems is to either disable option 82 on the DHCP snooping switch.

    no ip dhcp snooping information option

    Or do as you said and accept the giaddr 0 value on the switch running the DHCP server.

    ip dhcp relay information trust-all

    But is there any way to inject the giaddr value on the switch with DHCP snooping?

  3. Yuri:

    As far as i know, there is no way to have a giaddr inserted when switch is in L2 mode; you have to configure it as a DHCP relay using an SVI interface command “ip helper-address”

  4. Marco Rizzi says:

    Many thanks Petr for the explaination!

    That solved my problems between dhcp server on a router and switches with dhcp snooping.

    Marco

  5. SAVANDER says:

    Thanks Peter !

  6. mirofahmy says:

    if the relay swithc have helper address
    and dhcp snooping configure on it also
    the relyed packet with have giadd
    and snooping
    will insert option 82 and put giadd by zero
    packet now are droped in the same switch ( reley Switch)

    as example
    l2 switch
    inter vla 100
    ip add X.X.x.X
    ip helpere Y.Y.Y.Y

    and if the packet come from trusted host also it will be droped
    after it relyed by helper
    i am very confuse about that

  7. Rashed says:

    I would like to know, what is the meaning of this hex value 01030a0b0c02050000000123

  8. William Wallace says:

    Excellent information!
    We get the same issue after replace crash Juniper Router with Cisco, the main issue was that Brocade switch works fine with DHCP snooping connected to Juniper but cause problems when we try to bring WAN network with Cisco, possible bug between Cisco & Brocade.
    Thanks for this documentation.

  9. David Mitchell says:

    Thanks for this Petr

    If I have a distributed LAN environment whereby I have DHCP servers on one VLAN and Clients on another and the Client VLAN is spread out over a number of access switches, how can I implement DHCP snooping without trusting the uplinks on the L2 switches?

    My concern is that if their is a rogue DHCP server connected to one Access Switch in the Client VLAN and then if another Access Switch is trusting its trunk up to the Distribution Layer it would affectively allow DHCP responses in via that trunk/uplink from the rogue DHCP server within the same VLAN connected elsewhere in the network!

    Also, with regard to DHCP Option 82, I have read that when DHCP snooping is implemented it marks the “giaddr” value within Option 82 to zero (0). Would this then prevent the DHCP relay via the IP Helper addresses from working?

    Thanks in advance

    David

  10. Craig Thomas says:

    I understand from this that the relay information option is configured on a routed interface only?

    I was curious as to whether I could assign my layer-2 interfaces with individual subscriber-ids?

 

Leave a Reply

Categories

CCIE Bloggers