DHCP Snooping — What It Is and How to Protect Your Network from a Rogue

Picture this: Monday morning, the office fills up — and nobody can get on the network. Laptops are pulling addresses from the 192.168.100.x range, even though you’ve had 10.0.0.x configured for years. The default gateway leads nowhere. No internet. People are furious. The CEO is already blowing up your phone. You stare at the console in a cold sweat and realize: a Rogue DHCP server has taken up residence in your network.

One DHCP server on the network — everything’s fine. Two DHCP servers — the adventure begins, and it usually ends with an unplanned all-nighter you never signed up for.

That’s exactly the problem DHCP Snooping was built to solve — a switch-level security mechanism that kills rogue DHCP before it gets a chance to ruin your workday. In this guide we’ll cover: what DHCP Snooping is, how it works, how to configure it on Cisco, D-Link, Huawei, Eltex, and MikroTik, and which pitfalls are waiting for you along the way. Buckle up.

What Is DHCP Snooping and Why Do You Need It

DHCP Snooping is an L2-switch security mechanism that inspects all DHCP traffic on the network and only allows DHCP replies from ports you have explicitly marked as trusted. All other ports are considered untrusted and are not permitted to send DHCPOFFER, DHCPACK, or DHCPNAK messages.

In plain terms: DHCP Snooping is the bouncer for your DHCP traffic. Your legitimate server sits behind a trusted port — come on in. Your colleague’s laptop accidentally sharing Wi-Fi with DHCP enabled — sorry, you’re not on the list.

What DHCP Snooping Protects Against

• Rogue DHCP Server — any device that starts answering DHCP requests instead of your server. This could be a laptop with a hotspot enabled, a VM with a misconfigured network adapter, or a deliberate attack.
• DHCP Spoofing — an attack where an adversary intentionally stands up a DHCP server and hands clients a rogue gateway and DNS, intercepting all traffic (man-in-the-middle).
• DHCP Starvation — a pool exhaustion attack: the attacker floods the server with requests using forged MAC addresses, drains the entire address range, and then spins up their own DHCP server.

Without DHCP Snooping your network is completely exposed to all of the above. With it — you have a reliable gatekeeper on every switch port.

How DHCP Snooping Works: The Mechanics, No Fluff

When a client requests an IP address, the classic DORA exchange takes place: Discover → Offer → Request → Ack. DHCP Snooping plugs into this process at the switch level and operates according to the following logic:

1. A client on an untrusted port sends a DHCPDISCOVER — the switch forwards it. It’s a request, not a reply, so it’s fine.
2. A DHCPOFFER (address offer reply) arrives from an untrusted port — the switch drops the packet. Not trusted.
3. A DHCPOFFER arrives from a trusted port — it’s forwarded. Everything’s by the book.
4. The client receives an address — the switch writes a record to the Binding Table: IP + MAC + VLAN + Port + lease time.

This binding table becomes the foundation for two other security mechanisms: Dynamic ARP Inspection (DAI) and IP Source Guard. But those deserve their own articles.

DHCP Snooping Binding Table — The Heart of the Mechanism

The Binding Table is a live journal the switch maintains in real time. It stores the following information for each client:

Field	Description
IP Address	The DHCP-assigned address
MAC Address	Client’s MAC address
VLAN	The VLAN the client resides in
Interface	The switch port the client is connected to
Lease Time	Address lease duration

To view the table on Cisco, run:

show ip dhcp snooping binding

Sample output:

MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
AA:BB:CC:DD:EE:01   10.0.10.101      86400       dhcp-snooping  10    GigabitEthernet0/2
AA:BB:CC:DD:EE:02   10.0.10.102      86400       dhcp-snooping  10    GigabitEthernet0/3

This table is more than just a log. Additional checks are built on top of it: if traffic from GigabitEthernet0/2 suddenly appears with IP 10.0.10.200 instead of the registered 10.0.10.101 — IP Source Guard will block it instantly.

Important note on table persistence. By default on many platforms, the Binding Table lives in RAM and is lost on reboot. After a switch restart, all clients need to renew their leases to repopulate the table. On Cisco you can enable persistent storage to disk:

ip dhcp snooping database flash:dhcp-snooping.db

Trusted and Untrusted Ports: The Logic Behind the Split

This is the core concept — without understanding it, configuring DHCP Snooping will turn into a mess. Commit this to memory:

All ports are untrusted by default. That’s not a bug, that’s a feature. Secure-by-default: trust nobody until explicitly told otherwise.

Which Ports Should Be Trusted

• The port connected to your legitimate DHCP server — obvious.
• Uplink ports (trunks to upstream switches) — if your DHCP server is behind another switch, the uplink must be trusted, otherwise server replies will get dropped.
• DHCP relay agent ports — if you’re using ip helper-address on a router, the port facing it must be trusted.

Which Ports Stay Untrusted

• All client-facing ports — workstations, laptops, phones, printers.
• Access point ports (unless the AP is acting as a DHCP relay).
• Any port where an uncontrolled device could potentially show up.

Classic rookie mistake: marking the entire trunk as untrusted «for security» — and then getting a flood of complaints that half the VLANs stopped getting addresses. Trusted ≠ unprotected. Trusted = «DHCP replies from this port are permitted.»

DHCP Snooping and VLANs: Why It’s Enabled Per-VLAN

DHCP Snooping doesn’t operate globally across the entire network — it works per-VLAN. That’s important. You enable snooping globally on the switch, but then explicitly specify which VLANs it’s active on.

Why the granularity? Real-world networks have dozens of VLANs with different purposes. For example, your management VLAN might have its own dedicated DHCP server, and the guest VLAN a different one. You don’t always need snooping everywhere. You decide exactly where the protection sits.

The practical recommendation for an enterprise network is simple: enable DHCP Snooping on all user-facing VLANs, no exceptions.

DHCP Snooping and DHCP Relay: Don’t Forget the Uplink

A very common enterprise scenario: the DHCP server is centralized (Windows Server, ISC DHCP), and clients are spread across multiple VLANs and L3 segments. In this case, a DHCP relay is configured on the router (or L3 switch) — ip helper-address — which forwards DHCP requests to the server.

Here’s how this interacts with DHCP Snooping:

1. Client sends DHCPDISCOVER to the broadcast address.
2. The L3 device with ip helper-address intercepts it and forwards it as a unicast to the DHCP server.
3. The DHCP server replies back through the same L3 relay agent.
4. The relay agent forwards the reply to the client via the switch’s uplink port.

Here’s the trap: if the uplink toward the L3 relay agent isn’t marked as trusted — DHCP Snooping will drop the server’s reply. Clients get no addresses. Everyone stares at you in silence.

Rule of thumb: Always mark the uplink toward the DHCP relay/server as trusted.

General DHCP Snooping Configuration Workflow

Regardless of vendor, the configuration process looks the same:

1. Enable DHCP Snooping globally on the switch.
2. Specify which VLANs it’s active on.
3. Mark the necessary ports as trusted.
4. Verify the binding table after clients acquire addresses.
5. Confirm the legitimate DHCP server works and the rogue one is blocked.

Now let’s get into the actual commands for each vendor.

Configuring DHCP Snooping on Cisco

Cisco is the gold standard. DHCP Snooping is most fully implemented here, and it’s the easiest platform to use when explaining the concept. Works on IOS and IOS-XE, including Catalyst 2960, 3560, 3750, 9200, and 9300 series switches.

Enabling DHCP Snooping on Cisco: Step-by-Step

! Step 1: Enable DHCP Snooping globally
ip dhcp snooping

! Step 2: Enable for the required VLANs
ip dhcp snooping vlan 10
ip dhcp snooping vlan 20,30

! Step 3: Disable Option 82 if not needed (often causes issues with some servers)
no ip dhcp snooping information option

! Step 4: Mark trusted ports (uplink, DHCP server port)
interface GigabitEthernet0/1
 description Uplink to Core / DHCP Server
 ip dhcp snooping trust

! Step 5: Optionally - rate-limit client ports to defend against starvation attacks
interface GigabitEthernet0/2
 description Client Port
 ip dhcp snooping limit rate 15

Verifying the Configuration on Cisco

! General status
show ip dhcp snooping

! Binding table
show ip dhcp snooping binding

! Statistics on dropped packets
show ip dhcp snooping statistics

The output of show ip dhcp snooping should show:

Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10,20,30
Insertion of option 82 is disabled
Interface                  Trusted    Allow option    Rate limit (pps)
-------------------------  -------    ------------    ----------------
GigabitEthernet0/1         yes        yes             unlimited
GigabitEthernet0/2         no         no              15

Persisting the Binding Table on Cisco:

ip dhcp snooping database flash:snooping.db
ip dhcp snooping database write-delay 300

A Note on Option 82 in Cisco

By default, Cisco inserts DHCP Option 82 (relay agent information) into packets. This is useful in certain scenarios, but if your DHCP server isn’t configured to accept it — it will drop the requests and clients will get no addresses. In most cases it’s recommended to run no ip dhcp snooping information option.

Configuring DHCP Snooping on D-Link

D-Link is the go-to switch for small and medium business. DHCP Snooping is present, configurable via Web UI or CLI. Let’s cover both, using the DGS-1210/DGS-3000 series as an example.

Via D-Link Web Interface

1. Navigate to Security → DHCP Snooping → DHCP Snooping Settings.
2. Set DHCP Snooping State to Enabled.
3. Under DHCP Snooping VLAN Settings, add the required VLANs.
4. Go to DHCP Snooping Port Settings and mark uplink ports as Trusted.
5. Save the configuration.

Via CLI on D-Link

# Enable DHCP Snooping globally
enable dhcp_snooping

# Enable for a VLAN
config dhcp_snooping vlan 10 state enable

# Configure a trusted port
config dhcp_snooping ports 1 state trusted

# Verify
show dhcp_snooping
show dhcp_snooping binding_entries

On D-Link, ports are referenced as 1, 2, rather than GigabitEthernet0/1. Keep that in mind so you don’t get confused.

Configuring DHCP Snooping on Huawei

Huawei S-series switches (S5700, S6700, and others) are widely deployed in enterprise environments. DHCP Snooping carries the same name here, with slightly different commands from Cisco but identical logic.

# Enter system view
system-view

# Enable DHCP Snooping globally
dhcp snooping enable

# Enable on a VLAN interface
vlan 10
 dhcp snooping enable
quit

# Configure a trusted port (in interface view)
interface GigabitEthernet0/0/1
 dhcp snooping trusted
quit

# Verification
display dhcp snooping user-bind all
display dhcp snooping configuration

On Huawei there’s a gotcha: DHCP Snooping is first enabled globally with dhcp snooping enable, and then must also be enabled within each individual VLAN. If you skip the second step — it won’t work. Classic trap.

Huawei also supports additional DHCP packet validation options:

interface GigabitEthernet0/0/2
 dhcp snooping check dhcp-chaddr enable
 dhcp snooping check dhcp-request enable

Configuring DHCP Snooping on Eltex

Eltex is a Russian vendor with growing adoption. The MES-series switches are widely used in telecom and enterprise environments. The commands closely mirror Cisco IOS, which makes life easier for engineers already familiar with Cisco.

! Enable DHCP Snooping globally
ip dhcp snooping

! Enable for VLANs
ip dhcp snooping vlan 10
ip dhcp snooping vlan 20

! Disable Option 82 if not needed
no ip dhcp snooping information option

! Configure a trusted port
interface gigabitethernet 1/0/1
 ip dhcp snooping trust

! Rate-limit on client ports
interface gigabitethernet 1/0/2
 ip dhcp snooping limit rate 15

! Verification
show ip dhcp snooping
show ip dhcp snooping binding

Eltex configuration is as close to Cisco as it gets. If you know Cisco — you’ll be done in five minutes. Syntax is practically identical, just with different interface numbering.

DHCP Snooping on MikroTik: An Alternative Approach

Now we need to have a frank conversation. MikroTik does not have a native DHCP Snooping mechanism in the same form as Cisco, Huawei, or Eltex. Accept it and move on.

However, similar functionality can be achieved through several approaches:

Method 1: DHCP Alert

MikroTik can alert you when it detects a foreign DHCP server:

/ip dhcp-client
add interface=ether1 disabled=no

/ip dhcp-server alert
add interface=bridge1 valid-server=AA:BB:CC:DD:EE:FF alert-timeout=1m

Here valid-server is the MAC address of your legitimate DHCP server. If a reply appears on the interface from a different MAC — MikroTik fires a notification (and can trigger a script).

Method 2: Bridge Filter

A harder approach — block DHCP replies (ports 67/68) from specific ports using Bridge Filter rules:

/interface bridge filter
add chain=forward in-interface=ether2 mac-protocol=ip \
    ip-protocol=udp dst-port=68 src-port=67 action=drop \
    comment="Block DHCP Offers from untrusted ports"

This rule drops DHCP replies (src-port 67) coming from ether2 (a client port). The trusted port (e.g., ether1) has no such rule — its replies pass through.

Method 3: IP/Firewall + Static ARP

In small networks on MikroTik, a combination of static ARP entries and firewall rules can be used to bind IPs to MACs and block unauthorized assignments. This isn’t DHCP Snooping in the pure sense, but it gets the job done for small offices.

Bottom line on MikroTik: If native Rogue DHCP protection at the switch level is important to you — it’s better to use MikroTik as a router paired with a managed switch (Cisco, Eltex, Huawei) where DHCP Snooping is natively implemented. MikroTik as an L2 switch in enterprise isn’t the strongest choice from a security standpoint.

5 Real-World Examples from the Admin Trenches

Example 1: Catching a Rogue DHCP Server in the Office

Situation: Some clients are getting addresses from the wrong range. Complaints about no internet access flooding in.

Diagnosis without DHCP Snooping:

# On a Windows client — check who issued the address
ipconfig /all | findstr "DHCP Server"

# On a Linux client
ip route | grep default
cat /var/lib/dhclient/dhclient.leases | grep "dhcp-server-identifier"

Found a suspicious IP? Now locate the port in the switch’s MAC table:

show mac address-table | include [attacker MAC address]

Solution: Enable DHCP Snooping — and the problem disappears automatically. The rogue server is gone; its replies are dropped at the switch level.

Example 2: IP Phones Stopped Getting Addresses After Enabling Snooping

Situation: DHCP Snooping enabled on the switch. Computers work fine, but Cisco IP phones fail to get addresses from the Voice VLAN (VLAN 20).

Cause: VLAN 20 wasn’t added to the list of snooping-protected VLANs, or the uplink wasn’t marked as trusted for that VLAN.

# Check which VLANs are protected
show ip dhcp snooping

# Add the voice VLAN
ip dhcp snooping vlan 20

# If the uplink is already trusted - everything should work
# Verify binding after the phone re-requests an address
show ip dhcp snooping binding

Example 3: DHCP Works in One VLAN but Not Another

Situation: VLAN 10 — everything’s great. VLAN 30 — clients can’t get addresses. One centralized DHCP server, via relay.

The cause is almost always one of two things:

1. DHCP Snooping wasn’t enabled for VLAN 30: ip dhcp snooping vlan 30 was never run.
2. The uplink to the relay agent isn’t marked trusted on this switch.

# Diagnose
show ip dhcp snooping statistics
! Check the "Packets dropped" counter — if it's climbing, packets are being dropped

# Enable debug (be careful on production!)
debug ip dhcp snooping packet

Example 4: How to Check the Binding Table and Verify Everything Is OK

Task: Confirm that all clients are correctly reflected in the binding table.

# Cisco
show ip dhcp snooping binding

# Filter by VLAN
show ip dhcp snooping binding vlan 10

# Huawei
display dhcp snooping user-bind all

# Eltex
show ip dhcp snooping binding

# D-Link
show dhcp_snooping binding_entries

If the table is empty right after enabling Snooping — that’s normal until clients renew their leases. On Windows clients run ipconfig /renew, on Linux — dhclient -r && dhclient eth0.

Example 5: The Classic — Forgot to Trust the Uplink and Got Pure Chaos

Situation: Enabled DHCP Snooping on all switches in the office. Ten minutes later the phones start ringing: «Internet’s down!» Half the users have addresses, half don’t.

Cause: On the access switches, the trunk port toward the distribution switch wasn’t marked as trusted. DHCP replies from the central server arrive via the trunk — the switch drops them.

# Emergency diagnosis
show ip dhcp snooping statistics
! The dropped packets counter is through the roof

# Fix
interface GigabitEthernet0/24
 description Trunk to Distribution
 ip dhcp snooping trust

The lesson: before enabling DHCP Snooping on production — draw your network diagram and mark every trusted port on it. That’s 15 minutes of prep that saves hours of incident response.

DHCP Snooping Not Working — Common Errors and Fixes

Symptom	Likely Cause	Fix
Clients can’t get addresses after enabling Snooping	Uplink not marked as trusted	ip dhcp snooping trust on the uplink port
Only some VLANs are working	DHCP Snooping not enabled for all required VLANs	ip dhcp snooping vlan X for each VLAN
DHCP via relay not working	Port toward relay not trusted	Mark the L3 relay agent interface as trusted
After switch reboot all clients lose connectivity	Binding Table not persisted	Configure ip dhcp snooping database
DHCP server is rejecting requests	Option 82 is being inserted but server doesn’t accept it	no ip dhcp snooping information option
Snooping enabled on Huawei but not working	Not enabled at the VLAN level (only globally)	Enter the VLAN and run dhcp snooping enable

Debug and Diagnostics

# Cisco — drop statistics
show ip dhcp snooping statistics

# Cisco — detailed debug (use with care!)
debug ip dhcp snooping packet
debug ip dhcp snooping event

# Don't forget to turn off debug after troubleshooting!
undebug all

DHCP Snooping: Vendor Comparison

If you’re choosing switches for a new network or expanding an existing one, here’s a quick comparison of DHCP Snooping implementations across major vendors:

Vendor	Snooping Support	CLI / Web UI	Binding Table Persistence	Configuration Complexity
Cisco (IOS/IOS-XE)	✅ Full support	CLI + Web (newer models)	✅ Flash/TFTP	Medium
Huawei (VRP)	✅ Full support	CLI + eSight	✅	Medium
Eltex (MES)	✅ Full support	CLI + Web UI	✅	Low (Cisco-like)
D-Link (DGS)	✅ Supported	CLI + Web UI	⚠️ Model-dependent	Low
MikroTik (RouterOS)	⚠️ No native support	CLI + Winbox	N/A	High (workaround)

For enterprise networks where security is critical, the recommendation is managed switches with native DHCP Snooping support: Cisco Catalyst, Huawei S-series, or D-Link DGS-series for cost-sensitive deployments. If you’re running a Cisco-heavy shop, Eltex MES is worth a look as a budget-friendly alternative with near-identical CLI syntax.

Best Practices and Prevention

Pre-Deployment Checklist for DHCP Snooping in Production

• ☑️ Network diagram drawn with all DHCP servers and relay agents clearly marked.
• ☑️ All trusted ports identified (uplinks, server-facing ports).
• ☑️ List of all VLANs that require Snooping compiled.
• ☑️ Option 82 situation evaluated (does your server need it or not).
• ☑️ Binding Table persistence configured to non-volatile storage.
• ☑️ Maintenance window scheduled for rollout (Snooping may briefly interrupt DHCP during activation).
• ☑️ Console access available as a fallback in case something goes sideways.

Combining DHCP Snooping with Other Security Mechanisms

DHCP Snooping is the foundation. Two more powerful mechanisms are built on top of it:

• Dynamic ARP Inspection (DAI) — uses the Binding Table to validate ARP packets. Protects against ARP Spoofing and ARP table poisoning attacks.
• IP Source Guard — only allows traffic from a port if the source IP matches what’s recorded in the Binding Table. Complete protection against IP Spoofing at the L2 level.

Enabling all three mechanisms together is the gold standard for client port security in an enterprise network. No rogue DHCP, no ARP spoofing, no forged IPs. As shown in the diagram below — layered defense at every level.

Regular Binding Table Audits

Make a habit of periodically reviewing the Binding Table — it’s a useful snapshot of your network’s state. See an unfamiliar MAC on a port? That’s worth investigating.

# Script for periodic Binding Table export (using EEM on Cisco)
event manager applet DHCP_SNOOPING_BACKUP
 event timer cron cron-entry "0 */6 * * *"
 action 1.0 cli command "enable"
 action 2.0 cli command "show ip dhcp snooping binding | redirect tftp://10.0.0.100/snooping-backup.txt"

Summary: What We Did and What We Got

Let’s close with the diagnosis and the prescription. DHCP Snooping is a mandatory security mechanism for any managed enterprise network. Not an optional extra, not a «we’ll do it later» item — it’s basic hygiene that:

• Eliminates the Rogue DHCP threat — the primary source of chaos in flat networks.
• Defends against DHCP Spoofing and man-in-the-middle attacks via gateway hijacking.
• Builds the Binding Table that DAI and IP Source Guard depend on.
• Takes 5–10 minutes to configure on any managed switch.

We’ve walked through configuration on Cisco, D-Link, Huawei, Eltex, and MikroTik. Covered 5 real-world cases from the field. Built a troubleshooting table for the most common errors. You now have everything you need to deploy this in your network today — no more procrastinating.

Questions about configuration on a specific platform? Hit a weird edge case? Drop a comment below — we’ll work through it together. Subscribe to the newsletter to stay up to date with new guides from the IT Infirmary.