DHCP Snooping: Trust Boundary Misconfiguration
A client can't get a DHCP lease through one access switch. Diagnose the missing trust setting and fix it yourself, live, right below.
SW-CORE · SW-ACCESS-1 · SW-ACCESS-2
The problem
Two access switches uplink to a core switch running the real DHCP server. A client behind the first access switch leases an address normally. A client behind the second access switch sends DHCPDISCOVER over and over and never completes the exchange, even though the server's own statistics show it answering both.
What you'll practice
- Confirm DHCP snooping is enabled consistently across a small switched network
- Read show ip dhcp snooping and identify a switch's trusted interfaces
- Use show ip dhcp server statistics to prove the server is answering
- Recognize a DHCP snooping trust boundary problem from those two outputs together
- Apply ip dhcp snooping trust on the correct uplink and verify the fix
1. Confirm DHCP snooping is enabled consistently across a small switched network
DHCP snooping has to be turned on globally and per-VLAN on every switch a client's DHCP traffic crosses, not just the switch closest to the server. You'll check show ip dhcp snooping on all three switches and confirm VLAN 10 is genuinely operational on each one before assuming the feature itself is the problem.
2. Read show ip dhcp snooping and identify a switch's trusted interfaces
Every DHCP snooping-enabled port starts untrusted by default. The trusted-interface table at the bottom of show ip dhcp snooping is the single source of truth for which ports are allowed to carry server-originated DHCPOFFER and DHCPACK messages. You'll learn to read that table on two switches side by side and spot the difference.
3. Use show ip dhcp server statistics to prove the server is answering
It's tempting to assume a missing lease means the server never replied. show ip dhcp server statistics gives you the real DHCPDISCOVER-received and DHCPOFFER-sent counts, proof the server is doing its job, which rules out the server and points you back at the path between it and the client.
4. Recognize a DHCP snooping trust boundary problem from those two outputs together
Neither output alone proves the cause. A server sending real OFFERs plus a switch with no trusted uplink, read together, is what actually pins the fault down to a dropped reply rather than a missing request or a misconfigured pool.
5. Apply ip dhcp snooping trust on the correct uplink and verify the fix
The fix is a single line, but it has to go on the right interface, the uplink toward the server, not the client-facing access port. You'll apply it, save it with write memory, and confirm a real DORA (Discover, Offer, Request, Ack) exchange completes afterward.
The topology
SW-CORE runs the DHCP server for VLAN 10 and uplinks to SW-ACCESS-1 and SW-ACCESS-2, each with one client attached, the minimum topology needed to isolate a trust-boundary problem to a single uplink once the server itself is confirmed healthy.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show ip dhcp snoopingshow ip dhcp server statisticsshow running-configip dhcpFrequently asked
Is this real Cisco IOS or a simulator?
Real Cisco IOS switches on virtualized platforms, full CLI behavior including real DHCP server statistics, not a simulated subset like Packet Tracer.
Does this cover the CCNA 200-301 DHCP snooping topics?
Yes. Configuring and troubleshooting DHCP snooping is an explicit CCNA 200-301 security fundamentals blueprint item, and this lab is scoped directly to that.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.