Summary Explains what DHCP snooping is, how the trusted and untrusted port model works, the binding database it builds, and the default behaviours on IOS-XE that most commonly cause unexpected outages.
DHCP snooping is a Layer 2 security feature that treats DHCP as untrustworthy by default. It exists to solve two distinct problems.
The first is rogue DHCP servers. Any device on a VLAN can answer a DHCPDISCOVER. A misconfigured home router plugged into a wall port, or a workstation running virtualisation software with bridged networking, can start handing out addresses and a default gateway pointing at itself. Clients accept the first Offer they receive, so a rogue server that happens to be closer than the legitimate one wins. The result ranges from an outage to a man-in-the-middle position.
The second is address exhaustion and spoofing. A malicious host can send a flood of DISCOVERs with randomised MAC addresses to drain a scope, or claim an address that belongs to another host.
DHCP snooping addresses both by inspecting every DHCP packet crossing the switch, dropping server-sourced messages that arrive from the wrong direction, and recording legitimate leases in a binding database.
The core concept is direction. A legitimate DHCP server's replies should only ever arrive from the direction of the server — an uplink, or the port connecting to the router acting as relay agent. They should never arrive from an access port with a workstation on it.
DHCP snooping enforces this by classifying every port as trusted or untrusted.
| Port Type | Client Messages (DISCOVER, REQUEST) | Server Messages (OFFER, ACK, NAK) |
|---|---|---|
| Trusted | Forwarded | Forwarded |
| Untrusted | Forwarded, subject to validation | Dropped |
⚠️ Every Port Is Untrusted By Default: The moment DHCP snooping is enabled on a VLAN, every port in that VLAN becomes untrusted — including uplinks. If the uplink toward the DHCP server or relay agent is not explicitly configured as trusted, all server replies are dropped and every client on that VLAN fails to obtain an address. This is the single most common way DHCP snooping causes an outage.
The messages dropped on an untrusted port are those a server or relay agent would send: DHCPOFFER, DHCPACK, DHCPNAK, and DHCPLEASEQUERY.
The defaults matter more than the configuration options, because most DHCP snooping problems are caused by a default that was not anticipated.
| Setting | Default State | Notes |
|---|---|---|
| DHCP snooping globally | Disabled | Must be enabled with ip dhcp snooping |
| DHCP snooping per VLAN | Disabled | Global enable alone does nothing; VLANs must be listed |
| Port trust state | Untrusted | Applies to all ports, including uplinks and trunks |
| Option 82 insertion | Enabled | Active as soon as snooping is enabled globally |
| Allow untrusted Option 82 | Disabled | Packets arriving on an untrusted port that already contain Option 82 are dropped |
| MAC address verification | Enabled | Source MAC in the Ethernet header must match chaddr in the DHCP payload |
| Rate limiting | No limit | Must be configured explicitly per interface |
| Binding database persistence | Not configured | Bindings are held in memory only and lost on reload |
When DHCP snooping is enabled globally, IOS-XE begins inserting Option 82 (Relay Agent Information) into client DHCP packets by default. This is intended to give the DHCP server information about which switch port the request originated from.
The problem is that a Layer 2 switch inserting Option 82 does not set the giaddr field — it remains 0.0.0.0, because the switch is not acting as a relay agent. Many DHCP servers, including IOS-XE devices acting as relay agents and some Windows Server configurations, are built to discard packets containing Option 82 when giaddr is zero, because that combination should not normally occur. The packet is silently dropped and clients fail to get addresses, with no obvious error pointing at the switch.
There are two ways to resolve this, and the right choice depends on whether Option 82 is actually wanted.
If Option 82 is not needed, disable insertion:
no ip dhcp snooping information option
If Option 82 is wanted, the upstream relay agent must be told to accept packets where giaddr is zero:
ip dhcp relay information trust-all
A related but separate issue arises on switches that receive already-relayed traffic on an untrusted port. By default such packets are dropped. Where the topology genuinely requires this, it can be permitted:
ip dhcp snooping information option allow-untrusted
This should be used deliberately rather than as a reflexive fix, since it weakens the validation snooping is there to perform.
For every successful lease observed on an untrusted port, DHCP snooping creates a binding entry.
| Field | Description |
|---|---|
| MAC address | Client hardware address |
| IP address | Address leased to the client |
| Lease time | Remaining lease duration in seconds |
| Binding type | dhcp-snooping for dynamically learned entries |
| VLAN | VLAN the client is in |
| Interface | Physical port the client is connected to |
The database is the foundation for two other security features, and this is the main reason to deploy snooping even in environments where rogue servers are not a concern:
Neither feature works without a populated snooping binding database.
⚠️ Bindings Are Lost on Reload: By default the binding database exists only in memory. After a switch reload every binding is gone. Clients holding valid leases do not re-run DORA — they are in the BOUND state and will not attempt renewal until T1 — so no new bindings are created for them. If DAI or IP Source Guard is enabled, those clients are blocked until their lease reaches T1 and they renew. Configure a database agent to persist bindings before enabling DAI or IPSG.
Persistence is configured with a database agent writing to flash or a remote server:
ip dhcp snooping database flash:dhcp-snooping.db
ip dhcp snooping database write-delay 300
There is no rate limit applied by default. Where configured, an interface exceeding the threshold is placed into err-disabled state.
interface GigabitEthernet1/0/5
ip dhcp snooping limit rate 15
A rate of 10–20 packets per second is typical for an access port. Trusted uplinks carrying DHCP for an entire building should either be left unlimited or set considerably higher, since they aggregate every client's traffic.
Automatic recovery is worth enabling, since a single burst from one misbehaving host otherwise requires manual intervention:
errdisable recovery cause dhcp-rate-limit
errdisable recovery interval 300
ip dhcp snooping
ip dhcp snooping vlan 10,20,30
no ip dhcp snooping information option
!
interface GigabitEthernet1/0/48
description Uplink to distribution
ip dhcp snooping trust
!
interface range GigabitEthernet1/0/1-47
ip dhcp snooping limit rate 15
!
ip dhcp snooping database flash:dhcp-snooping.db
ip dhcp snooping database write-delay 300
!
errdisable recovery cause dhcp-rate-limit
errdisable recovery interval 300
The order matters operationally. Configure the trusted uplink before enabling snooping on the VLANs, otherwise there is a window during which all DHCP is broken.
show ip dhcp snooping
show ip dhcp snooping binding
show ip dhcp snooping database
show ip dhcp snooping statistics
show errdisable recovery
show ip dhcp snooping confirms which VLANs are enabled, which interfaces are trusted, and whether Option 82 insertion is active. show ip dhcp snooping statistics shows drop counters, which is the fastest way to confirm whether snooping is the cause of a DHCP failure rather than something upstream.
Clients send DISCOVERs, the server replies, and the switch drops the reply at the uplink. Packet captures at the server show a normal exchange, which misleads troubleshooting toward the client side. Check show ip dhcp snooping for the trusted interface list first.
Enabled by default. Produces total DHCP failure on affected VLANs with no error on the switch. Confirmed by show ip dhcp snooping statistics at the relay or by capture at the server showing packets arriving and being discarded.
Produces no effect at all, which can lead to a false assumption that protection is in place. Both the global command and the per-VLAN command are required.
Legitimate clients are blocked because no binding exists for them. Occurs after a reload without a database agent, or immediately after enabling snooping on a VLAN where clients already hold leases. Existing clients are only recorded once they renew.
A trunk carrying client VLANs between two access switches must be trusted at both ends, otherwise server replies traversing it are dropped.
Where an MX is the DHCP server or relay for a VLAN and a Catalyst switch sits between it and the clients, the switch uplink toward the MX must be trusted. See KBA-044 - Meraki MX — LAN Port Behaviour and Limitations.