DHCP Snooping in Depth: Bindings, Option 82, and Trusted Ports

Every Layer 2 security feature worth having is built on one foundation: a table that says "this IP address, with this MAC, is legitimately on this port." DHCP snooping builds that table. Dynamic ARP Inspection uses it to stop ARP spoofing. IP Source Guard uses it to stop IP spoofing. If snooping is not working, none of the things that depend on it work either.

This article covers how DHCP snooping builds its binding table, trusted versus untrusted ports, Option 82, and how to verify it - with real output from a CML lab, including an honest account of a platform limitation you need to know about. For the fundamentals, start at the complete VLAN and switching guide.

The attack it stops

DHCP has no authentication. A client broadcasts "I need an address", and it believes whatever server answers first. So an attacker plugs a rogue DHCP server into an access port, answers faster than the real one, and hands clients an address, a DNS server, and - critically - a default gateway that points at the attacker's machine. Now every packet those clients send off-subnet flows through the attacker. That is a man-in-the-middle attack, and it needs nothing more than a laptop running dnsmasq.

DHCP snooping stops it by deciding which ports are allowed to send DHCP server messages.

Trusted and untrusted ports

This is the entire concept, and it is beautifully simple:

A rogue DHCP server on an untrusted access port sends an OFFER, the switch drops it before it reaches any client, and the attack fails. The real server, reachable only through trusted uplinks, works normally.

The binding table

While snooping is watching DHCP transactions on untrusted ports, it records every successful lease. Each entry ties together four facts: MAC address, IP address, VLAN, and switch port, plus the lease time.

This table is the crown jewels. It is the switch's authoritative record of who is legitimately where, and DAI and IPSG both consult it to decide whether a frame is spoofed.

Configuration

! Enable globally, then per VLAN
ip dhcp snooping
ip dhcp snooping vlan 10,20

! Trust the uplinks toward the real server
interface Ethernet0/0
 ip dhcp snooping trust
interface Ethernet0/1
 ip dhcp snooping trust

! Rate-limit the untrusted access ports (DHCP starvation defence)
interface Ethernet0/2
 ip dhcp snooping limit rate 15

Two things people forget:

• Trust the trunks between switches. If the DHCP server is two switches away, every switch in the path needs the inter-switch trunk marked trusted, or the OFFER gets dropped at the first untrusted hop.
• Rate-limit untrusted ports. A rate limit on DHCP messages defeats DHCP starvation - an attacker sending thousands of DISCOVERs from spoofed MACs to exhaust the server's pool. 15 packets per second is generous for a legitimate host.

Operational state

SW3#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10,20
DHCP snooping is operational on following VLANs:
10,20
Insertion of option 82 is disabled
Option 82 on untrusted port is not allowed
Verification of hwaddr field is enabled
DHCP snooping trust/rate is configured on the following Interfaces:
Interface                  Trusted    Allow option    Rate limit (pps)
Ethernet0/0                      yes        yes             unlimited
Ethernet0/1                      yes        yes             unlimited
Ethernet0/2                      no         no              15

Note Verification of hwaddr field is enabled - snooping also checks that the client hardware address inside the DHCP payload matches the source MAC of the frame, catching a class of spoofing where those two disagree.

Option 82: identifying where a request came from

DHCP Option 82 (the relay agent information option) lets a switch stamp each DHCP request with which switch and which port it arrived on, before relaying it toward the server. The server can then assign addresses based on physical location, log which port a client is on, and apply per-port policy.

ip dhcp snooping information option

The default circuit-id encodes VLAN, module, and port, and the remote-id is the switch's MAC. When Option 82 is on, the switch inserts it into requests from untrusted ports on the way up, and strips it from replies on the way down.

The gotcha, and it is a common outage: when the DHCP server is a router doing relay, and Option 82 is inserted by an access switch, the relay may drop the request because a request arriving with Option 82 already present but a giaddr of 0.0.0.0 looks malformed. The fix is either ip dhcp snooping information option allow-untrusted on the relay's side, or configuring the relay to trust the option. In many enterprise designs where the L3 switch is both the snooping switch and the relay, you simply leave Option 82 off unless you specifically need location-based assignment - which is exactly what we did in the lab.

Verification and a platform limitation

Here is where we are going to be straight with you. In our CML lab, we ran a real DHCP transaction - a host obtained a genuine lease (10.10.10.10) from the router's DHCP pool via udhcpc. But the virtual IOL-L2 switch reported zero packets through its snooping engine:

SW3#show ip dhcp snooping statistics
 Packets Forwarded  = 0
 Packets Dropped    = 0

The reason is architectural: DHCP snooping works by punting DHCP packets to the switch CPU for inspection, and the virtual IOL-L2 node in CML does not implement that forwarding-plane punt. The configuration applies, the feature reports operational, trust is enforced in config - but the binding table never populates from live DHCP, because the snooping process never sees the packets.

On real Catalyst hardware, this works exactly as designed. To demonstrate the downstream features (DAI and IPSG) in the lab, we populated the table with a static binding, which is a legitimate production technique in its own right for hosts with fixed addresses:

SW3#ip dhcp snooping binding 5254.004E.11C0 vlan 10 10.10.10.10 interface Ethernet0/2 expiry 86400

SW3#show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
52:54:00:4E:11:C0   10.10.10.10      86387       dhcp-snooping   10    Ethernet0/2
Total number of bindings: 1

There is the binding table with an entry, and that entry is what DAI and IPSG will trust. On hardware, an entry like this appears automatically the moment a host completes a DHCP lease. We would rather tell you the lab's limitation and show you the real static-binding technique than pretend the automatic population happened.

The database: surviving a reload

The binding table lives in RAM. Reload the switch and it is gone - which means every host has to renew its lease before DAI and IPSG will let its traffic through, and in the meantime legitimate hosts are blocked. On a busy access switch that is a self-inflicted outage after every reboot.

The fix is to persist the table:

ip dhcp snooping database flash:dhcp-snooping-db.txt
ip dhcp snooping database write-delay 300

Now the bindings survive a reload. In a larger deployment, write the database to a TFTP or FTP server instead of local flash. This one line prevents a genuinely nasty post-maintenance surprise.

Troubleshooting

1. Clients not getting addresses after enabling snooping? An uplink or inter-switch trunk toward the server is untrusted. Every hop in the DHCP path needs the server-facing port trusted.
2. Binding table empty? On hardware: the DHCP transaction has not completed since snooping was enabled - clients need to renew. On virtual IOL-L2 in CML: expected, use static bindings (see above).
3. Relay dropping requests after enabling Option 82? The giaddr-zero-with-option-82 problem. Add allow-untrusted on the relay or leave Option 82 off unless needed.
4. Bindings gone after a reload? Configure the snooping database to persist to flash or a server.
5. DAI or IPSG blocking legitimate hosts? Their binding is missing. Check show ip dhcp snooping binding first - the problem is almost always here, not in DAI/IPSG themselves.

Key takeaways

• DHCP snooping is the foundation of the whole L2 security stack. Its binding table (MAC + IP + VLAN + port) is what DAI and IPSG trust.
• Trusted ports (uplinks, inter-switch trunks) may forward DHCP server messages; untrusted ports (host access) may not. Everything is untrusted by default.
• Trust every hop toward the real server, and rate-limit untrusted ports to defeat DHCP starvation.
• Option 82 stamps requests with switch/port identity for location-based assignment, but can break relay if not handled - leave it off unless you need it.
• On virtual IOL-L2 in CML the snooping engine does not see live DHCP (no forwarding-plane punt), so the table populates via static binding; on real hardware it populates automatically. We report this honestly.
• Persist the binding database to flash or a server, or every reload blocks legitimate hosts until they renew.

Next: Dynamic ARP Inspection and IP Source Guard, the two features that turn the binding table into active protection. The full cluster index lives on the VLAN and switching pillar.