DHCP snooping: how it stops rogue DHCP servers and what it breaks

DHCP snooping is a switch feature that drops DHCP server messages arriving on ports you have not marked as trusted, so a rogue or misconfigured DHCP server on an access port cannot hand out addresses. While it filters, the switch records which IP address each client leased on which port and VLAN, and that binding table is what Dynamic ARP Inspection and IP Source Guard later use to stop address spoofing.

It is a Layer 2 control applied per VLAN on access switches, and it is one of the cheapest protections in a campus network. It is also easy to get wrong in ways that stop every client getting an address, so this page covers the mechanism, the option 82 trap, a working configuration, and how to prove it works before users notice. Examples use Cisco IOS XE syntax from the Catalyst 9300 DHCP configuration guide; the concepts are the same on any vendor.

01 /What problem does DHCP snooping solve?

DHCP clients believe the first server that answers. A consumer router plugged in backwards, a test VM with a DHCP service left running, or an attacker's laptop can all answer faster than the real server, giving clients a wrong default gateway or DNS server. At best users lose connectivity; at worst their traffic is routed through the attacker. A second class of attack exhausts the real server's pool by requesting leases from thousands of forged MAC addresses.

The switch is the right place to stop both, because it knows which physical port each message came from. Servers only ever need to reply from a small, known set of ports: the uplinks toward the real server or relay. Everything else is a client port, and a client port has no business sending a DHCPOFFER.

02 /How do trusted and untrusted ports work?

Every interface starts untrusted. The Cisco guide lists the defaults: snooping disabled globally and per VLAN, every interface untrusted, MAC address verification enabled, and no rate limit configured. Once snooping is on for a VLAN, the switch inspects every DHCP message on that VLAN's untrusted ports and drops a packet when:

• a server message (DHCPOFFER, DHCPACK, DHCPNAK or DHCPLEASEQUERY) arrives on an untrusted port;
• a message arrives on an untrusted port and its source MAC address does not match the client hardware address inside the DHCP payload (the MAC address verification check);
• a DHCPRELEASE or DHCPDECLINE arrives for a binding that belongs to a different port, which stops one client releasing another's lease;
• a packet on an untrusted port already carries a relay agent address other than 0.0.0.0, or carries option 82 (unless the switch is told to accept option 82 from an edge switch).

Trusted ports are exempt and forward DHCP normally. Client messages from untrusted ports are forwarded only toward trusted ports, so a client's DISCOVER broadcast reaches the real server and no other client sees it.

03 /What is in the binding table?

For each successful lease on an untrusted port, the switch stores the client MAC address, the leased IP address, the lease time, the binding type, the VLAN and the interface. The Catalyst 9300 guide gives the table a capacity of up to 64,000 bindings on that platform and release. Hosts reached through trusted ports never appear, because their leases are not learned locally.

The table lives in memory, so a reload empties it until each client renews. That matters as soon as anything depends on it. The Cisco guide is blunt: if the binding database agent is disabled while Dynamic ARP Inspection or IP Source Guard is enabled and dynamic bindings exist, the switch loses connectivity for those hosts after a reload. The agent writes the table to flash or a network file; the guide recommends a TFTP server because NVRAM and flash are small, and its write-delay timer defaults to 300 seconds.

The binding table is the foundation for the next two layers. Dynamic ARP Inspection drops ARP replies whose IP and MAC pair is not in the table, which stops ARP spoofing. IP Source Guard filters IP traffic on a port to the addresses bound to it, which stops a host from using an address it was not given. The Ruckus FastIron DHCP guide describes the same pairing: DHCP snooping is often used with Dynamic ARP Inspection and IP Source Guard.

04 /Why does option 82 break DHCP after snooping is enabled?

This is the fault that makes engineers turn snooping off again. On Cisco switches the DHCP snooping information option is enabled by default, so when snooping is turned on, the access switch starts inserting DHCP option 82 (the Relay Agent Information option) into client requests. It is acting as a Layer 2 relay, so it does not set the gateway address field, giaddr, which stays 0.0.0.0.

The request then reaches the real relay, usually an SVI on the distribution switch. RFC 3046, section 2.1 tells that relay what to do: a relay receiving a packet from an untrusted circuit with giaddr set to zero but with a relay agent option already present SHALL discard the packet and increment an error count. The relay is following the standard, the client gets nothing, and the access switch looks innocent because it forwarded the request.

There are two fixes. Either tell the relay that this circuit is trusted to carry option 82 (on Cisco IOS, ip dhcp relay information trusted on the relay interface, or ip dhcp relay information trust-all globally), or stop the access switch inserting it with no ip dhcp snooping information option. Keep option 82 if the DHCP server uses the circuit ID for per-port address assignment or logging; drop it if nothing reads it. A server can also reject or mishandle the option, so test with the real server before rolling out.

05 /How to configure DHCP snooping, step by step

1. Confirm the real path first. Know which interfaces lead to the DHCP server or relay on each access switch, and which VLANs carry clients. The Cisco guide says to configure and enable the DHCP server and relay before enabling snooping.
2. Trust the uplinks before anything else. If you enable snooping first, the uplink is untrusted and every offer is dropped until you finish.
3. Decide on option 82 as described above, and change the relay or the access switch accordingly.
4. Enable snooping for the client VLANs, then globally.
5. Rate-limit untrusted ports. A client sends a handful of DHCP packets at boot; a limit well above that stops pool exhaustion floods. On Cisco IOS a port that exceeds its limit is error-disabled, so set the limit higher on ports that lead to many clients, such as access points on 802.1Q tagged links.
6. Persist the binding table before enabling Dynamic ARP Inspection or IP Source Guard.

! uplink toward the distribution switch that relays DHCP
interface TenGigabitEthernet1/0/48
 ip dhcp snooping trust
!
! client ports: rate limit in packets per second
interface range GigabitEthernet1/0/1 - 46
 ip dhcp snooping limit rate 15
!
! a wireless access point carries many clients
interface GigabitEthernet1/0/47
 ip dhcp snooping limit rate 100
!
no ip dhcp snooping information option
ip dhcp snooping vlan 20,30
ip dhcp snooping database flash:dhcp-snoop.db
ip dhcp snooping

The rate values are illustrative; size them from your own client counts. The example removes option 82 insertion; delete that line if you chose to keep option 82 and trusted it on the relay instead. Run the steps in this order on a live switch so there is no window in which the uplink is untrusted.

06 /How to check that DHCP snooping works

1. show ip dhcp snooping lists the VLANs where snooping is enabled and operational, whether option 82 insertion is on, and every trusted interface with its rate limit. Check the uplink is in the trusted list.
2. Renew a lease on a test client, then run show ip dhcp snooping binding. The client should appear with its MAC, IP, lease, VLAN and port.
3. show ip dhcp snooping statistics shows forwarded and dropped packet counters. A steady rise in drops on a client VLAN after the change usually means a missing trust statement or the option 82 discard above.
4. Prove the protection. On an isolated test port, run a DHCP server, for example dnsmasq on a laptop with a pool in 198.51.100.0/24, and confirm that a client on another port in the same VLAN still receives its lease from the real server while the drop counter rises.
5. Reload a test switch in a maintenance window and confirm show ip dhcp snooping database reports a successful read of the saved file.

07 /Common DHCP snooping mistakes

• Enabling it before trusting the uplink. Every client fails to renew. Trust first, enable second.
• Ignoring option 82. The relay discards the requests exactly as RFC 3046 tells it to.
• Trusting downlinks to other switches. A rogue server behind a trusted downlink gets through. Snoop on every access switch and trust only toward the server.
• Forgetting static addresses. Hosts with static IPs never create bindings, so IP Source Guard and Dynamic ARP Inspection block them unless you add static bindings or exempt their ports.
• No binding database agent. Harmless with snooping alone, an outage after the next reload once ARP inspection or source guard depends on the table.
• Treating it as IPv6 protection. IPv4 DHCP snooping does not inspect DHCPv6 or router advertisements. IPv6 needs its own first-hop features, such as DHCPv6 guard and RA guard, alongside a review of IPv6 transition design.

08 /Where DHCP snooping sits with other access-port controls

DHCP snooping protects addressing; it does not stop a device joining the network. 802.1X port authentication decides who may use a port, snooping decides who may hand out addresses on it, and BPDU guard on edge ports stops the same port from joining spanning tree. All three are configured per access port and usually per client VLAN, so they belong in the same port template. The rest of the access-layer toolkit is listed in the switching guides index.

On the Foundry side of this site's history, DHCP snooping is a later feature than most of the IronWare material in the archive. The FastIron line, now sold as Ruckus ICX, documents it in its FastIron DHCP configuration guide as a way to filter untrusted DHCP packets and block rogue servers, with the same trusted-port model described here.