{"id":169495,"date":"2026-06-22T15:51:09","date_gmt":"2026-06-22T12:51:09","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=169495"},"modified":"2026-06-22T15:51:09","modified_gmt":"2026-06-22T12:51:09","slug":"cisco-dhcp-snooping-configuration","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/cisco-dhcp-snooping-configuration\/","title":{"rendered":"Configure Cisco DHCP Snooping to Block Rogue Servers"},"content":{"rendered":"

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.<\/p>\n\n

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.<\/p>\n\n

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.<\/p>\n\n

How DHCP snooping works<\/h2>\n\n

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.<\/p>\n\n

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<\/a> features read.<\/p>\n\n

The lab topology<\/h2>\n\n

The lab has a switch, a real DHCP server, a client, and a rogue server. SW1 runs DHCP snooping on its VLAN<\/a>. 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.<\/p>\n\n\n

\"DHCP<\/figure>\n\n\n

The same four nodes built in GNS3, where the configuration below was applied and tested on real Cisco IOS:<\/p>\n\n\n

\"GNS3<\/figure>\n\n\n

With the topology in place, turn snooping on.<\/p>\n\n

Configure DHCP snooping<\/h2>\n\n

Snooping is enabled globally and then armed per VLAN. Nothing is inspected until you name the VLANs to watch:<\/p>\n\n\n

ip dhcp snooping\nip dhcp snooping vlan 1<\/code><\/pre>\n\n\n
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:<\/p>\n\n\n
interface GigabitEthernet0\/1\n ip dhcp snooping trust\n exit<\/code><\/pre>\n\n\n
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:<\/p>\n\n\n
no ip dhcp snooping information option<\/code><\/pre>\n\n\n
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.<\/p>\n\n
Verify DHCP snooping is on<\/h2>\n\n
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:<\/p>\n\n\n
\"Cisco<\/figure>\n\n\n
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.<\/p>\n\n
Block the rogue server and read the binding table<\/h2>\n\n
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:<\/p>\n\n\n
\"Cisco<\/figure>\n\n\n
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:<\/p>\n\n\n
\"Cisco<\/figure>\n\n\n
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.<\/p>\n\n
Practice DHCP snooping<\/h2>\n\n
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.<\/p>\n\n
Loading quiz...<\/div><\/div>\n\n\n
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:<\/p>\n\n
Loading flashcards...<\/div><\/div>\n\n\n
When DHCP stops working after you enable snooping<\/h2>\n\n
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<\/code> on the path to the server, plus the option 82 line on a flat segment.<\/p>\n\n
Snooping is the foundation the rest of Layer 2 security builds on. Its binding table feeds dynamic ARP inspection<\/a> and IP source guard, and it sits alongside port security<\/a> and access control lists<\/a> as the access-layer defenses every switched VLAN should carry. The CCNA 200-301 study roadmap<\/a> shows where each of these features fits in the bigger picture.<\/p>\n","protected":false},"excerpt":{"rendered":"
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 … Read more<\/a><\/p>\n","protected":false},"author":3,"featured_media":169496,"comment_status":"open","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[299,55],"tags":[524,525],"cfg_series":[39888],"class_list":["post-169495","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-how-to","category-networking","tag-ccna","tag-cisco","cfg_series-ccna-200-301"],"_links":{"self":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169495","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/comments?post=169495"}],"version-history":[{"count":1,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169495\/revisions"}],"predecessor-version":[{"id":169497,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/posts\/169495\/revisions\/169497"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media\/169496"}],"wp:attachment":[{"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/media?parent=169495"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/categories?post=169495"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/tags?post=169495"},{"taxonomy":"cfg_series","embeddable":true,"href":"https:\/\/computingforgeeks.com\/wp-json\/wp\/v2\/cfg_series?post=169495"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}