DHCP snooping demystified
When reading about DHCP snooping at CCNA or CCNP level, its not very hard to get. On an access layer switch, we dont trust any port by default, and only trusted ports permit DHCP server messages. Thats not a big deal and not what this post is going to be about. But what happens in other scenarios?
There are many different scenarios when DHCP snooping can provide troublesome behavior if you don’t know what really happens under the hood of our switch functions.
This is an interesting scenario where I struggled to find distinct information about what really happens. Lets start by configuring a small topology in the lab according to the details depicted below. The client is connected to a vlan that spans from access switch and is terminated in the distributionswitch where it is relayed with “ip helper”.
What is the problem here? The DHCPDISCOVERs never make it to the DHCP server, but why?
What happens is that once DHCP snooping is enabled, switch1 is not only inspecting the traffic to decide which packet to permit and which to drop. It also adds option 82 information by default (yes, I know you didn’t ask for this to happen).
In fact the problem is not only related to DHCP snooping itself, but also to DHCP relay agent! Or more specific how the technologies interact.
When using dhcp relay agent in switch2, the switch would not trust option82 information by default, hence the DHCPDISCOVER is never relayed, and that is only decided by DHCP relay agent. The problem can however be solved by either manipulating DHCP snooping or relay agent.
To come around that issue we can either instruct our switch1 not to add this information, or tell switch2 not to care about it.
The configuration command to save the day is either on the snooping switch:
“#no ip dhcp snooping information option” which is enabled by default.
Or on the relaying switch:
“#ip dhcp relay information trust-all”
Here the switch1 is terminating the clients in vlan10, and its uplink is via a vlan-interface 20.
SVI is configured with IP helper pointing to the DHCP server.
Then we add this configuration to switch1:
ip dhcp snooping
ip dhcp snooping vlan 1-4094
What happens now?
If you learned at you CCNA that DHCP snooping only affects packets sent from the server, I would say that you now have more parameters to add to you list.
The DHCP traffic will get dropped since the vlan is inspected by snooping. If we debug on the switch a message will appear telling us that:
DHCP_SNOOPING_SW: bridge packet output port set is null, packet is dropped.
This is because traffic exits the switch on a vlan that you wanted to snoop.
- DHCP snooping catches client-traffic that:
- Has incorrect chaddr
- Has GIADDR set to something else that 0.0.0.0 i.e is relayed
- Has opt.82 set
This means that when traffic that you expect to be relayed doesn’t arrive at the DHCP server, the problem most likely isn’t in DHCP snooping per se, but more specifically speaking in DHCP relay agent. But it can be solved by changing DHCP snooping parameters.
2. DHCP snooping affects traffic that traverses or exits the switch via a vlan. If you enable DHCP snooping on all vlans and happen to use a vlan-interface as uplink, you will snoop away your own requests.