How To

Configure Cisco DHCP Snooping to Block Rogue Servers

When a PC boots, it trusts the first DHCP server that answers. It cannot tell the company’s real server from a cheap router someone plugged into a wall jack, so whichever replies first hands out the IP address, the subnet mask, and the default gateway. Point that gateway at an attacker’s machine and every packet the victim sends to the internet runs through it. DHCP snooping is the switch feature that ends the race.

Original content from computingforgeeks.com - post 169495

DHCP snooping makes the switch inspect every DHCP message and decide which ports are allowed to send server replies. The port facing the real server is trusted; every other port is untrusted, and a DHCP offer arriving on an untrusted port is dropped before it reaches a single client. As it watches the legitimate exchanges, the switch also builds a binding table of which MAC leased which IP on which port, the table that dynamic ARP inspection and IP source guard later depend on.

This guide enables DHCP snooping, trusts the uplink to the real server, reads the binding table, then plants a rogue DHCP server on an untrusted port and watches the switch drop its offers. Every command and the rogue-server block below were captured on Cisco IOS 15.2 in June 2026.

How DHCP snooping works

Snooping splits the switch ports into two camps. A trusted port may carry any DHCP message, including the server-to-client replies (OFFER, ACK, NAK) that hand out addresses. An untrusted port may carry only the client-to-server messages (DISCOVER, REQUEST) that a normal host sends. The moment a server reply appears on an untrusted port, the switch drops it, which is exactly how a rogue server is silenced.

Only the links to legitimate DHCP servers and the uplinks toward them should be trusted. Every access port facing a user is left untrusted, because a user device has no business answering DHCP. While snooping watches the real handshakes complete, it records each lease in the DHCP snooping binding table: the client MAC, the leased IP, the VLAN, the port, and the lease time. That table is the durable record other network security features read.

The lab topology

The lab has a switch, a real DHCP server, a client, and a rogue server. SW1 runs DHCP snooping on its VLAN. Gi0/1 to the real server is the only trusted port. The client on Gi0/2 and the rogue server on Gi0/3 are both untrusted, which is what lets the switch drop the rogue’s offers while the client still gets a real lease.

DHCP snooping topology where SW1 trusts only the real DHCP server port Gi0/1 and drops rogue DHCP offers from the untrusted Gi0/3

The same four nodes built in GNS3, where the configuration below was applied and tested on real Cisco IOS:

GNS3 canvas with a client, SW1, a legitimate DHCP server, and a rogue DHCP server for the DHCP snooping lab

With the topology in place, turn snooping on.

Configure DHCP snooping

Snooping is enabled globally and then armed per VLAN. Nothing is inspected until you name the VLANs to watch:

ip dhcp snooping
ip dhcp snooping vlan 1

At this point every port is untrusted, including the one facing your real server, so DHCP would break for everyone until you fix it. Trust the link toward the legitimate server, and only that link:

interface GigabitEthernet0/1
 ip dhcp snooping trust
 exit

One more line saves a confusing failure on a flat access switch. By default the switch inserts DHCP option 82 into requests, but with no relay in the path and a zero giaddr, that request looks spoofed and the switch drops it on the untrusted port. On a simple Layer 2 segment, turn the insertion off:

no ip dhcp snooping information option

That is the whole configuration: snooping armed on the VLAN, the server port trusted, and option 82 out of the way. Confirm it took before relying on it.

Verify DHCP snooping is on

The summary command confirms snooping is enabled, which VLANs it is operating on, and which ports are trusted. Everything that matters is in one screen:

Cisco IOS show ip dhcp snooping output: snooping enabled and operational on VLAN 1 with GigabitEthernet0/1 trusted

Snooping is enabled and operational on VLAN 1, option 82 insertion is off, and the trust table lists a single trusted interface, Gi0/1. Every other port, including the rogue’s Gi0/3, is untrusted by default and never appears in that list. That one trusted entry is the whole policy.

Block the rogue server and read the binding table

With both servers powered on, the client boots and broadcasts a DISCOVER. Both servers answer, but the rogue’s offer arrives on the untrusted Gi0/3 and the switch drops it, so the client only ever sees the real server’s reply. The client ends up with an address from the legitimate 192.168.10.0/24 pool, not the rogue’s 10.6.6.0/24:

Cisco client show ip interface brief and show dhcp lease confirming it leased 192.168.10.2 from the real server, not the rogue 10.6.6.0 pool

The lease is bound to 192.168.10.1, the real server. On the switch, the binding table records that lease and the statistics counter proves the rogue was stopped:

Cisco IOS show ip dhcp snooping binding table with one client lease and statistics showing 2 packets dropped from untrusted ports

One binding exists, the client’s real lease on the untrusted Gi0/2, exactly the entry dynamic ARP inspection will later check ARP replies against. The statistics line is the proof of the block: two packets dropped, both from untrusted ports, which are the rogue server’s offer and acknowledgement that never reached the client. The attack failed silently, and the user never knew there was a second server on the wire.

Practice DHCP snooping

Run the questions to lock in trusted versus untrusted ports, what the binding table holds, and the messages an untrusted port may carry, then use the flashcards for quick recall.

Loading quiz...

Flip through the deck until the trust rule, the binding table fields, and the option 82 gotcha are automatic, or grab the Anki pack to review them anywhere:

Loading flashcards...

When DHCP stops working after you enable snooping

The most common DHCP snooping failure is self-inflicted: you enable it, every address lease across the switch stops, and the cause is a port that should be trusted but is not. The uplink toward the DHCP server, or any inter-switch trunk that carries DHCP toward it, has to be trusted, or the server’s replies are dropped exactly like a rogue’s would be. If DHCP dies the moment you turn snooping on, the fix is almost always one missing ip dhcp snooping trust on the path to the server, plus the option 82 line on a flat segment.

Snooping is the foundation the rest of Layer 2 security builds on. Its binding table feeds dynamic ARP inspection and IP source guard, and it sits alongside port security and access control lists as the access-layer defenses every switched VLAN should carry. The CCNA 200-301 study roadmap shows where each of these features fits in the bigger picture.

Keep reading

Configure Samba File Share on Debian 13 / 12 Debian Configure Samba File Share on Debian 13 / 12 Setup WireGuard VPN on Ubuntu 24.04 / Debian 13 / Rocky Linux 10 Debian Setup WireGuard VPN on Ubuntu 24.04 / Debian 13 / Rocky Linux 10 Use NetworkManager nmcli on Ubuntu and Debian Debian Use NetworkManager nmcli on Ubuntu and Debian Configure Cisco Dynamic ARP Inspection (DAI) Networking Configure Cisco Dynamic ARP Inspection (DAI) Cisco Port Security: Configure Sticky MACs and Violations Networking Cisco Port Security: Configure Sticky MACs and Violations Add DNS Forward Lookup Zone in Windows Server 2025 Windows Add DNS Forward Lookup Zone in Windows Server 2025

Leave a Comment

Press ESC to close