Cisco DHCP Snooping: Trusted and Untrusted Ports

DHCP snooping acts like a firewall between untrusted end hosts and trusted DHCP servers. The switch validates every DHCP message received on untrusted ports, drops offers and acks that do not come from a server, and builds a binding database of IP-to-MAC-to-port entries that other security features such as Dynamic ARP Inspection (DAI) and IP Source Guard rely on. A rogue "DHCP" laptop plugged into an access port becomes harmless once snooping is on. This guide covers the configuration on Catalyst IOS XE switches.

What the Feature Actually Checks

It is worth being precise about what the switch inspects, because the rules explain nearly every symptom you will ever see:

• DHCP server messages (OFFER, ACK, NAK) arriving on an untrusted port are dropped.
• DHCP client messages (DISCOVER, REQUEST, RELEASE, DECLINE) arriving on an untrusted port are forwarded only toward trusted ports.
• Client messages whose chaddr does not match the Ethernet source MAC are dropped — unless MAC verification is disabled.
• Messages carrying option-82 relay information on an untrusted port are dropped by default, which stops a host from spoofing relay agent fields.
• RELEASE or DECLINE messages whose MAC exists in the binding database but whose interface does not match the recorded interface are dropped, protecting clients from forged releases.

Only untrusted ports produce binding entries. That asymmetry is deliberate: a binding is proof that a client asked for an address on a user-facing port, so a binding learned on a trusted uplink would be meaningless.

Trusted vs Untrusted

By default every interface is untrusted. Ports connected to DHCP servers, or to other switches/routers that legitimately forward DHCP (option-82), must be configured as trusted; ports connected to clients stay untrusted. DHCP replies received on an untrusted port are dropped, and DHCP requests from untrusted ports are only forwarded toward trusted ports.

Prerequisites and Platform Notes

• Snooping must be enabled globally before it is applied to a VLAN. Adding ip dhcp snooping vlan 10 without the global command is accepted but does nothing.
• The DHCP server and any relay agent must already be working. Confirm that clients get addresses before you enable snooping, so that if something breaks afterwards the change is unambiguously the cause.
• Platform support varies. Catalyst 9000, 3000 and 1000 series running IOS XE 17.x support the commands shown here; Nexus runs a similar but not identical command set (for example ip dhcp snooping plus ip dhcp snooping trust under a VLAN rather than an interface in some releases). Check the configuration guide for your platform.
• Option 82 interacts with upstream switches. If an edge switch inserts relay information and an aggregation switch receives it on an untrusted port, the packet is dropped. Decide in advance whether the design relies on relay information at all.
• Stack and EtherChannel considerations. In a switch stack, trust and rate limits are per member port; in an EtherChannel, apply trust to the logical interface so that all members inherit it.

Configuration

Switch# configure terminal
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10,20,30
Switch(config)# ip dhcp snooping information option
Switch(config)# interface gigabitethernet1/0/24
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# exit
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# no ip dhcp snooping trust
Switch(config-if)# ip dhcp snooping limit rate 15
Switch(config-if)# end

Steps: enable snooping globally, apply it to the client VLANs, enable option-82 insertion where the switch relays toward the server, mark the uplink/server port trusted, and (optionally) rate-limit DHCP packets on untrusted ports to blunt DHCP starvation floods.

Step-by-Step: A Complete Working Example

Assume VLANs 10, 20 and 30 carry users, the DHCP server is reachable through the uplink on GigabitEthernet1/0/24, and clients attach to access ports 1/0/1 through 1/0/23.

Switch# configure terminal
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10,20,30
Switch(config)# ip dhcp snooping verify mac-address
Switch(config)# no ip dhcp snooping information option
Switch(config)# interface gigabitethernet1/0/24
Switch(config-if)# description Uplink to distribution - DHCP server path
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# exit
Switch(config)# interface range gigabitethernet1/0/1 - 23
Switch(config-if-range)# no ip dhcp snooping trust
Switch(config-if-range)# ip dhcp snooping limit rate 15
Switch(config-if-range)# end
Switch# write memory

Read the sequence as a story: turn the feature on, scope it to the client VLANs, keep MAC verification on, turn off relay-information insertion because this switch does not need to relay, trust exactly one uplink, then explicitly mark the user ports untrusted and cap how fast they can send DHCP. The no before ip dhcp snooping trust is defensive documentation — it makes the intent visible to the next engineer even though untrusted is the default.

Rate Limiting and Starvation Attacks

A rate limit is the only part of DHCP snooping that mitigates a starvation flood, where an attacker generates thousands of DISCOVER messages with random source MAC addresses to exhaust the pool:

Switch(config-if)# ip dhcp snooping limit rate 15
Switch(config)# errdisable recovery cause dhcp-rate-limit
Switch(config)# errdisable recovery interval 300

Rate is in packets per second. Choose a value that a legitimate client can never reach but that a flood exceeds immediately; 15 is a common starting point for an access port. Once the limit is exceeded the port enters the error-disabled state, which stops both the attack and the user's traffic, so always enable automatic recovery (or use the same errdisable recovery cause list that your port-security policy uses). Check which ports are currently in that state with:

Switch# show interfaces status err-disabled
Switch# show errdisable recovery
Switch# show ip dhcp snooping statistics

Note that the rate limit counts all DHCP messages on the port, so a port with a fan-out switch, an IP phone plus a PC, or a virtualisation host can legitimately exceed a very low threshold. Baseline the counters before tightening them.

The Binding Database and Persistence

Bindings live in memory and are lost on reload, which matters because DAI and IP source guard consult that table. In a data centre or campus where switches reload during maintenance windows, an empty table after boot means every protected host is treated as unknown until it renews its lease. Two options fix that:

Switch(config)# ip dhcp snooping database flash:dhcp_snoop.db
Switch(config)# ip dhcp snooping database write-delay 300
Switch(config)# ip dhcp snooping database timeout 300
Switch# show ip dhcp snooping database

The database agent writes the table to local flash, to a TFTP or FTP server, or to a remote URL, and restores it at boot. Write-delay and timeout control how aggressively it writes and how long it waits for a storage operation. If the file becomes corrupt or is unreachable, the switch falls back to learning bindings from scratch — so verify the agent after every software upgrade rather than assuming it survived.

You can also create bindings by hand for hosts that never run DHCP:

Switch(config)# ip dhcp snooping binding 0011.2233.4455 vlan 10 10.0.10.50 interface gigabitethernet1/0/5 expiry 86400

This is how you extend IP source guard coverage to static servers, printers and appliances on the same VLAN.

Option 82 in Practice

Option 82 carries relay agent information: the circuit ID and remote ID that tell a DHCP server where a request came from. IOS XE builds these from the incoming VLAN and interface. The three decisions are:

• Insertion. Enabled by default on the switch. Disable it with no ip dhcp snooping information option if your server does not understand relay information or if a downstream device re-inserts it.
• Receiving relay information on untrusted ports. Allowed with ip dhcp snooping information option allow-untrusted, which is the standard workaround for a two-tier topology where the access switch inserts option 82 and the aggregation switch would otherwise drop it.
• Remote ID content. Change it from the default interface identifier to a hostname or arbitrary string with ip dhcp snooping information option format remote-id hostname, which makes server logs far more readable than circuit IDs.

Full example for a two-tier campus:

Switch(config)# ip dhcp snooping information option
Switch(config)# ip dhcp snooping information option allow-untrusted
Switch(config)# ip dhcp snooping information option format remote-id hostname

Remember that allow-untrusted relaxes a real protection, so scope it to switches that legitimately receive relayed requests and keep the setting uniform across the pair — a mismatch between two stack members produces intermittent failures that are painful to diagnose.

Integration with DAI and IP Source Guard

DHCP snooping on its own stops fake servers. The bindings it produces are the input for two features that stop forged traffic from legitimate-looking hosts:

Switch(config)# ip arp inspection vlan 10,20,30
Switch(config)# ip arp inspection validate src-mac dst-mac ip
Switch(config)# interface gigabitethernet1/0/24
Switch(config-if)# ip arp inspection trust
Switch(config-if)# exit
Switch(config)# interface range gigabitethernet1/0/1 - 23
Switch(config-if-range)# ip verify source
Switch(config-if-range)# end

Dynamic ARP inspection compares ARP packets against the snooping binding table, so an attacker cannot claim another host's address. IP source guard checks the source address and MAC of every IP packet against the same table. Both fail open — meaning they permit traffic — for entries they do not know about, which is exactly why the database agent and manual bindings matter. For the port-level view, our port security and sticky MAC violation modes guide explains how MAC-based controls complement address-based ones, and 802.1X with MAB covers who is allowed on the port in the first place.

Verification

show ip dhcp snooping
show ip dhcp snooping binding
show ip dhcp snooping statistics

The binding table lists every learned client (MAC, IP, VLAN, interface, lease expiry) and is what DAI and IP Source Guard consult. show ip dhcp snooping statistics counts packets dropped on untrusted ports — a rising drop counter next to a port usually means a rogue offer or an option-82 mismatch.

The three show commands from the original checklist each answer a different question. show ip dhcp snooping proves the feature is enabled and which VLANs and ports are trusted. show ip dhcp snooping binding proves clients are learning. show ip dhcp snooping statistics proves the switch is actually enforcing the rules.

Switch# show ip dhcp snooping
Switch# show ip dhcp snooping binding
Switch# show ip dhcp snooping statistics

In the statistics output, look for the counters Forwarded, Dropped and the per-reason drop counters. A healthy access switch forwards thousands of messages and drops a handful. A switch with a large and growing drop count on one port has either a rogue server, an option-82 mismatch, or a host with mismatched MAC addresses — the drop reason tells you which. When you need to see the decision in real time, enable targeted debugging in a maintenance window only:

Switch# debug ip dhcp snooping events
Switch# debug ip dhcp snooping packet
Switch# undebug all

Always clear debugging with undebug all or no debug all before you leave the session; DHCP debugging on a busy access switch is one of the classic ways to drive CPU to 100 percent.

Troubleshooting by Symptom

• "Everyone lost their address." The server-facing port is untrusted, so replies are dropped. Verify trust with show ip dhcp snooping and check the port table, then re-apply ip dhcp snooping trust on the uplink or on the port facing the server.
• "It worked yesterday, broke after a reload." Bindings are gone or the database agent failed to restore. Check show ip dhcp snooping database for the storage status and confirm the local file or TFTP target is reachable.
• "Only clients behind an access switch fail." Classically an option-82 drop on an untrusted uplink. Either trust the inter-switch link on the aggregation switch or enable allow-untrusted — and apply the same choice to every switch in the chain.
• "One host cannot get a lease." MAC verification is failing for that NIC. Test by temporarily disabling verification, then fix the specific case (some virtualization hosts and PXE stacks rewrite the source MAC) instead of disabling the feature globally.
• "A port keeps error-disabling." The DHCP rate limit is too tight, or a device on that port is flooding. show interfaces status err-disabled names the port, show errdisable recovery confirms automatic recovery is armed, and the statistics counters show whether the traffic is genuinely abnormal.
• "Attacks still succeed." Check that the VLAN list includes every VLAN where clients live, that host ports are not accidentally trusted, and that bindings exist for the hosts in question. A trusted host port makes every downstream protection meaningless.
• "DAI blocks legitimate traffic." The binding table is missing an entry — usually for a statically addressed host, a wireless client roaming between controllers, or a host that changed port without a new DHCP exchange. Add a manual binding or use an ARP ACL, and check show ip arp inspection statistics for the drop reason.

FAQ

Does DHCP snooping affect static IP hosts? Not directly, but they receive no protection from DAI or IP source guard because they never create a binding. Add manual bindings for the ones that matter.

Should I enable it on the management VLAN? Only if client devices live there. Snooping a purely transit or management VLAN adds state without protection.

Is there a limit on how many bindings a switch can hold? Yes — a few thousand entries on most access platforms and up to the platform maximum on chassis switches. Size the pool and L2 domain accordingly, and monitor the count after deployment.

Does it work with a DHCP relay in the path? Yes. Trust the port facing the relay, and decide deliberately whether the relay inserts option 82 and whether upstream switches will accept it.

Will DHCP snooping break IPv6? No, they are separate features. Build the same trust model with ipv6 dhcp guard and IPv6 snooping if you run DHCPv6, and read SLAAC versus stateful and stateless DHCPv6 first to decide what the clients should be using.

What about multicast snooping? Unrelated, though the naming is similar — see IGMP snooping configuration on Cisco switches for that feature family.

Can I verify all of this before touching production? Yes. Build the configuration in a lab or with containerlab, reproduce the rogue-server scenario with a laptop, and confirm both the drop counters and the binding entries before you schedule the change window.

Where do the VLANs themselves come from? If the VLAN and interface configuration is still new to you, start with Cisco VLAN configuration and verification workflow so the DHCP work sits on solid ground.

Common Pitfalls

• All clients stop getting addresses: the server-facing port was left untrusted, so replies are dropped. Mark server/uplink ports trusted.
• Aggregation switch with edge switches: an access switch inserts option-82; if the aggregation switch receives option-82 on an untrusted port it drops the packet. Either make the inter-switch port trusted on the aggregation switch, or enable ip dhcp snooping information option allow-untrusted.
• Static servers: hosts with static IPs never appear in the binding table; add manual bindings or rely on DAI's ARP ACLs instead.
• Trusted ports are not learned: snooping bindings are only built from untrusted ports by design.

DHCP snooping is the foundation that makes port security and dynamic ARP inspection effective; for the broader loop and broadcast protection toolkit see broadcast storm troubleshooting. For the Aruba equivalent of everything above, read the ArubaOS-CX DHCP snooping guide; if the DHCP server itself needs attention, the Cisco IOS DHCP server pools guide covers pools, exclusions and options.

原文链接：https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-17/configuration_guide/ip/b_1717_ip_9500_cg/configuring_dhcp.html