DHCP by design is insecure, anyone in a broadcast domain can configure themselves as a DHCP server and can potentially start handing out IP with themselves as default gateway, redirecting all traffic to their device, becoming man in the middle.

So we want to control 2 things:

1.       DHCP request should come from a legitimate source.
2.       DHCP response comes from a legitimate DHCP server.


The first problem we can solve with option 82 and second problem we an solve with DHCP snooping. Lets talk about DHCP snooping first.

We simply configure DHCP snoping on our switch globally and it make all ports “untrusted”, switch will not trust DHCP response coming from any ports, then go ahead and trust only the ports where DHCP server is connected. In my topology DHCP server is the router. So here is my config.


Now lets see how option 82 helps solve the first problem.

To understand this we have to understand the traffic flow a little, so the client will join ssid: TEST, will perform L2 authentication and then send a DHCP Discovery on wireless network. AP will encapsulate this request send it to WLC via a CAPWAP tunnel. WLC will decapsulate the CAPWAP packet and understand it’s a DHCP Discovery, in this case WLC itself is not a DHCP server but it is relaying DHCP requet to DHCP server (router in this case). Router responds back with DHCP offer back to WLC, WLC will send it to AP ove CAPWAP. AP will decapsulate the CAPWAP header and send the DHCP offer over the air to the client. And process will continue till the client gets an IP address. Now that we understand the traffic flow, its easier to understand what option 82 does.

By enabling option 82 all we are doing Is  assigning an identifier to any device that relays DHCP information and configure that identifier on the DHCP server as option 82. Once configured if the DHCP server sees the identifier it responds to DHCP request, if the DHCP server do not see the identifier (DHCP request not coming from a legitimate source), then DHCP server simply do not respond. Since the DHCP reuest is actually sent by AP on behalf of Client and relayed by WLC to the DHCP server. Cisco WLC appends 2 sets information Circuit ID (WLC info) and Remote ID (AP info)

WLC ID is standard value of 0104000000000206 (010400000000 WLC ID + 02 agent type + 06 Remote ID type) followed by AP Ethernet mac address e4c722cdb3b4 (in this case)

This logic can be used for many other purposes, for e.g. based on ID received with DHCP request we can apply specific DHCP option or condition when responding to the DHCP request. A typical use case can be wireless Guest, lets say you have configured guest tunneling, where all guest traffic goes to DMZ controller, in this case when the DHCP request comes from an ID of DMZ controller then DHCP server can return a different gateway and a public DNS server. However if the request comes from a controller which manages corporate WiFi then DHCP server can return a different gateway with internal DNS server.


Lets start with controller since the controller is relaying the DHCP request to the server. Configure the DHCP interface on WLAN and DHCP proxy mode to global so that WLC uses global proxy setting, it can also be done on an interface by interface basis by simply selecting enable instead of global. In this case I will be using AP ethernet interface mac address as identifier.


Let’s look at the router configuration, acting as a DHCP server.


note that the relay information contains WLC ID which is standard value of 0104000000000206 followed by AP Ethernet mac address e4c722cdb3b4



For the first test, I have disabled AP4 and named it “disabled”, AP3 is renamed as “option_82_AP” and there is one client connected to it.

As you will see in the logs on the DHCP server (router) for debug ip dhcp server class


DHCP server searches to match relay information, based on the configuration the relay information is a match and it assign an IP address to the client from the DHCP IP range.


For the next test I am going to disable the radio on AP “Option_82_AP” and enable the other AP for which the relay-information is not configured, and I am expecting this to fail and not get an IP address.


NOTE: Actually, the device is connects to the other AP because of existing DHCP binding, so I had to clear ip dhcp binding *

After clearing DHCP binding I can see the relay information is not found and client is not able to get an IP.



I hope you enjoyed reading this as much as I enjoyed writing it.