I've got a DHCP option that may help to take some pain out of your network. If you use DHCP, you'll know how convenient it is. Imagine if you could make DHCP just a little smarter, with the help of your network switch, by inserting the switchport ID or Description into the request. Now your DHCP server would have much more useful information for identifying clients, or even making decisions based on the information.


This useful feature is called DHCP Option 82. Now, there are many many DHCP options, most of them are a mystery to myself,  many are not even widely supported. But I've found Option 82 to be widely supported in my network gear, and I'm guessing, if you are running enterprise class gear, you will find it available to you as well.


We had a particular use case, we wanted to install several dozen physical servers, have them boot automatically with the help of DHCP and PXE booting. But we also wanted these to be easily replaced, if we have a failed component, we simply swap in hardware and assume the old identity. This is a neat concept, but since DHCP is tied to the physical MAC address of the machine, any hardware swaps require configuration changes.


Enter DHCP option 82. It turns out there was a really simple solution. Each ToR switch can simply act as a partner in the DHCP process, intercepting the DHCP request, inserting the port description into the request, and stripping the description back out on the reply. Now, each time we swap out a server we inherit the same DHCP lease as long as we plug back into the same switch ports.


For our configuration we used Juniper QFX3500s and EX3300s, so those will be the platform sthat I'll use to show you the simple configuration. I've done this in Juniper and Arista as well.  You will need a DHCP server that can understand Option 82. We're using a simple Linux utility, DNSMasq, to provide the DHCP services.




The first example configuration is from a Juniper QFX3500 , with L2 server ports and L3 uplinks. The switch needs to act as the DHCP forwarder in this case.


# set interfaces xe-0/0/0.0 family ethernet-switching vlan members redvlan

# set interfaces xe-0/0/0.0 description server1

# set interfaces vlan.5 family inet address

# set vlan redvlan vlan-id 5

# set vlan redvlan l3-interface vlan.5

# set forwarding-options helpers bootp hdcp-option82 circuit-id use-interface-description

# set forwarding-options helpers bootp server

# set forwarding-options helpers bootp interface vlan.5


The second example is from a Juniper EX3300, running L2 only. In this situation, the switch only does a rewrite of the DHCP request, forwarding across subnets is performed by a separate L3 device.


# set interfaces ge-0/0/0.0 family ethernet-switching vlan members redvlan

# set interfaces ge-0/0/0.0 description server1

# set vlan redvlan vlan-id 5

# set vlan redvlan l3-interface vlan.5

# set ethernet-switching options secure-access-port vlan redvlan dhcp-option82 circuit-id use-interface-description


The DNS server will see a combination of server name and vlan name in the following format server1:redvlan


DHCP Option 82 definitely solved a real problem for us. I've shown this to quite a few peers in the network and security fields, each one of them was surprised by how simple and effective this was. I hope that this takes away a little packet pain for you.

AuthorKelly McDowell