DHCP Snooping Deep Dive Building the Binding Table That Your Entire Layer 2 Security Stack Depends On

Executive Summary

DHCP is a protocol built on blind trust. A client broadcasts a request and accepts the first answer it hears, including the default gateway and DNS servers that will carry every byte it sends for the next lease period. Anything on the same broadcast domain can answer. That single design decision is why a laptop running a rogue DHCP service, a misconfigured home router plugged into a wall jack, or a five-line Scapy script can quietly become the default gateway for an entire VLAN.

DHCP snooping fixes that at the access switch. It splits every port into trusted and untrusted, drops server-side DHCP messages that arrive anywhere they should not, and records every successful lease into a binding table of MAC, IP, VLAN, port, and lease time. That table is the real prize: it is the authoritative source of truth that Dynamic ARP Inspection (DAI) and IP Source Guard (IPSG) consume to stop ARP poisoning and IP spoofing. Snooping alone stops rogue servers. Snooping plus its consumers closes most of the Layer 2 attack surface.

Why DHCP Is an Attack Surface

Before you can reason about what snooping filters, you need a precise model of who sends what. DHCPv4 (RFC 2131) uses UDP 67 for servers and relay agents and UDP 68 for clients. Every message type has a natural direction, and snooping enforces that direction at the port level.

The four attacks snooping is designed to stop

Rogue server / man-in-the-middle. The attacker answers DISCOVERs faster than the real server and hands out itself as the default gateway or DNS server. Every client that accepts the offer now routes through the attacker. This is the classic attack and the primary reason snooping exists. Accidental rogues (a consumer router plugged in backwards) cause the same outage without the malice.

Starvation. Tools such as Yersinia or dhcpig flood DISCOVERs with randomized client hardware addresses until the real pool is exhausted. Legitimate clients get nothing, which is often the setup step that makes the rogue server attack reliable: once the real server is out of addresses, the attacker is the only one answering.

Spoofed RELEASE and DECLINE. A client message forged with a victim’s MAC and IP tells the server to release the victim’s lease (or mark it conflicting), forcing reassignment or denial of service.

Option 82 injection. If an upstream server or relay uses relay-agent information for policy (address pool selection, rate plans in ISP networks), a client that inserts its own Option 82 can impersonate a different port or subscriber.

How DHCP Snooping Works

Trusted vs. untrusted ports

Trust is a per-port, and on most platforms per-VLAN, attribute. A trusted port is one that leads toward a legitimate DHCP server or relay: the uplink to the FortiGate, an inter-switch link, an MCLAG ICL, or the port where a Windows DHCP server lives. An untrusted port is everything else, which in a healthy design means every access port. The rule of thumb is simple: if you would not want a DHCPOFFER coming in on it, it is untrusted.

On FortiSwitch, ports are untrusted by default and you explicitly promote the ones that face servers. On Cisco, ports are also untrusted by default once snooping is enabled for a VLAN. That default is safe for clients and dangerous for uplinks: enable snooping without trusting the uplink and you have just blackholed DHCP for the whole VLAN.

What gets checked on an untrusted port

The binding table

When the switch sees a DHCPACK coming back through a trusted port toward a client on an untrusted port, it records a binding: client MAC, assigned IP, VLAN, ingress port, and lease expiry. A NAK, RELEASE, DECLINE, or lease expiry removes it. Bindings are only learned for clients on untrusted ports, which is exactly what you want, since those are the ports where enforcement happens.

Treat the binding table as a security database, not a diagnostic curiosity. DAI uses it to decide whether an ARP reply claiming 10.0.10.101 is-at 00:0c:29:aa:10:01 is true. IP Source Guard uses it to program a per-port hardware filter that only permits the bound source IP (and optionally MAC). Hosts with static IPs never generate a DHCPACK, so they never appear in the table and will be dropped by DAI and IPSG unless you add static bindings. That one fact is responsible for most failed DAI rollouts.

MAC verification and its limits

MAC verification compares the frame’s source MAC with the chaddr inside the DHCP payload. Lazy starvation tools randomize only chaddr while sending from the attacker’s real NIC, so this check kills them outright. Better tools randomize both, and then MAC verification passes every frame. The real defense against full starvation is a combination of rate limiting, a per-port learn limit on the binding table, and port security or 802.1X MAC limits. Verification is necessary but not sufficient.

Option 82: relay agent information

Option 82 (RFC 3046) lets the snooping switch stamp each client request with where it came from. Sub-option 1, Circuit ID, typically identifies the port and VLAN. Sub-option 2, Remote ID, typically identifies the switch (MAC or hostname). The server can log it, use it to select a pool, or use it to pin an address to a physical jack. The switch strips Option 82 from the server’s reply before forwarding to the client.

The classic gotcha: when a Layer 2 snooping switch inserts Option 82 it is not a relay, so giaddr stays 0.0.0.0. RFC 3046 servers are expected to handle this, but many (including older Cisco IOS DHCP servers) drop any packet with Option 82 present and a zero giaddr because it looks like an untrusted relay. If clients stop getting addresses the moment you enable Option 82, this is the first thing to check.

Rate limiting and persistence

Snooping is a control-plane function: DHCP packets on snooped VLANs are punted to the switch CPU for inspection. That makes the switch itself a DoS target. Rate limit DHCP on untrusted ports (a normal client sends a handful of packets per lease cycle; 10 to 20 pps per access port is generous) and keep the limit far higher, or off, on trusted uplinks that aggregate an entire VLAN.

The binding table lives in RAM. Reboot an access switch without persistence and every client keeps a valid lease but has no binding, so DAI and IPSG drop them until they renew. Most platforms can export the table to flash or a remote server. Plan for it before you enable enforcement features that depend on it.

The Downstream Stack: What Consumes the Binding Table

Prerequisites and Lab Architecture

Assumed knowledge

• DHCP DORA exchange and relay behavior (giaddr, UDP 67/68).
• FortiLink switch management from FortiGate, including the FortiSwitch VLAN interface model under config system interface.
• Basic 802.1Q trunking and the difference between access, uplink, and ISL ports.

Lab components

Step-by-Step Implementation (FortiLink-Managed FortiSwitch)

Step 1: Set global snooping behavior

config switch-controller global
    set dhcp-snoop-client-req drop-untrusted
    set dhcp-snoop-client-db-exp 86400
    set dhcp-snoop-db-per-port-learn-limit 8
    set dhcp-option82-format ascii
    set dhcp-option82-circuit-id intfname vlan
    set dhcp-option82-remote-id mac hostname
    set dhcp-server-access-list enable
end

drop-untrusted means client DISCOVER and REQUEST broadcasts are forwarded only toward trusted ports instead of flooding to every port in the VLAN. A rogue server on an access port never even hears the request, which is stronger than simply dropping its reply. dhcp-snoop-db-per-port-learn-limit caps how many bindings one port can create; set it to what a real access port needs (a phone plus a PC plus headroom), not the maximum.

GUI verification: No direct GUI equivalent for the global knobs; confirm with show switch-controller global.

Step 2: Enable snooping on the FortiSwitch VLAN

config system interface
    edit "vlan10"
        set vdom "root"
        set ip 10.0.10.1 255.255.255.0
        set interface "fortilink"
        set vlanid 10
        set switch-controller-dhcp-snooping enable
        set switch-controller-dhcp-snooping-verify-mac enable
        set switch-controller-dhcp-snooping-option82 enable
    next
end

GUI verification: WiFi and Switch Controller > FortiSwitch VLANs > edit vlan10. Where your build exposes the DHCP snooping toggle in the VLAN dialog, confirm it shows enabled; otherwise verify from the CLI with show system interface vlan10.

Step 3: Define the allowed server list

config system interface
    edit "vlan10"
        config dhcp-snooping-server-list
            edit "fgt-vlan10"
                set server-ip 10.0.10.1
            next
            edit "win-dhcp-01"
                set server-ip 10.0.5.10
            next
        end
    next
end

If a relay sits between the switch and the server, list the address the OFFER/ACK is sourced from as seen by the switch, which is the relay’s VLAN interface address, not the back-end server.

GUI verification: The server list is CLI-only on most builds; verify with show system interface vlan10.

Step 4: Trust the right ports (and only those)

config switch-controller managed-switch
    edit "<SWITCH_SN>"
        config ports
            edit "port46"
                set dhcp-snooping trusted
                set arp-inspection-trust trusted
            next
            edit "port3"
                set dhcp-snooping untrusted
            next
        end
    next
end

GUI verification: WiFi and Switch Controller > FortiSwitch Ports > right-click a port > DHCP Snooping > Trusted / Untrusted. Add the DHCP Snooping column to see the state of every port at once.

Step 5: Add static bindings for fixed-IP hosts

config switch-controller managed-switch
    edit "<SWITCH_SN>"
        config dhcp-snooping-static-client
            edit "printer-idf2"
                set vlan "vlan10"
                set ip 10.0.10.20
                set mac 00:1b:a9:44:20:20
                set port "port19"
            next
        end
    next
end

A port with a static entry cannot be added to a trunk until the entry is removed. If you have more than a handful of fixed-IP hosts, a better long-term answer is DHCP reservations on the server: the device gets the same IP every time and a real binding is learned dynamically.

Step 6: Layer Dynamic ARP Inspection on top

config system interface
    edit "vlan10"
        set switch-controller-arp-inspection enable
    next
end

Roll DAI out only after the binding table has been populated for at least one full lease cycle, or after forcing renewals. Enabling it on a VLAN full of clients with valid leases but no bindings (for example, right after a switch reboot) drops their ARP until they renew. Where your FortiOS build offers a monitor mode for ARP inspection, use it first and review the violations before enforcing.

Step 7: Optional Option 82 per-port override

config switch-controller managed-switch
    edit "<SWITCH_SN>"
        config ports
            edit "port3"
                config dhcp-snoop-option82-override
                    edit "vlan10"
                        set circuit-id "BLDG1-IDF2-J103"
                        set remote-id "S248E-IDF2"
                    next
                end
            next
        end
    next
end

diagnose switch-controller switch-info option82-mapping snooping ascii <SWITCH_SN> vlan10 port3

Standalone FortiSwitchOS Equivalent

For a FortiSwitch in standalone mode, the same feature lives under config switch vlan and config switch interface on the switch itself.

config switch vlan
    edit 10
        set dhcp-snooping enable
        set dhcp-snooping-verify-mac enable
        set dhcp-snooping-option82 enable
        set arp-inspection enable
    next
end

config switch interface
    edit "port48"
        set dhcp-snooping trusted
        set arp-inspection-trust trusted
    next
    edit "port3"
        set dhcp-snooping untrusted
    next
end

Multi-Vendor Reference

The concepts are identical across vendors; the syntax and defaults are not. These are the equivalent minimal configs for the same lab (vlan 10, uplink trusted, access ports rate limited).

Cisco IOS-XE (Catalyst 9000)

ip dhcp snooping
ip dhcp snooping vlan 10
ip dhcp snooping database flash:dhcp-snoop.db
ip dhcp snooping database write-delay 60
! Uncomment only if the DHCP server rejects giaddr 0.0.0.0 + Option 82:
! no ip dhcp snooping information option
!
interface TenGigabitEthernet1/1/1
 description UPLINK-TO-CORE
 ip dhcp snooping trust
 ip arp inspection trust
!
interface range GigabitEthernet1/0/1 - 46
 ip dhcp snooping limit rate 15
!
errdisable recovery cause dhcp-rate-limit
errdisable recovery interval 300
ip arp inspection vlan 10

Juniper EX (ELS)

set vlans v10 vlan-id 10
set vlans v10 forwarding-options dhcp-security
set vlans v10 forwarding-options dhcp-security arp-inspection
set vlans v10 forwarding-options dhcp-security group UPLINK overrides trusted
set vlans v10 forwarding-options dhcp-security group UPLINK interface xe-0/1/0.0

On Juniper ELS, access ports are untrusted and trunk ports are trusted by default once dhcp-security is applied to the VLAN. That default is the opposite of what bites Cisco and FortiSwitch admins, and it means a trunk to an untrusted device (a hypervisor, an unmanaged AP) is trusted unless you override it.

Aruba AOS-CX

dhcpv4-snooping
vlan 10
    dhcpv4-snooping
!
interface 1/1/48
    dhcpv4-snooping trust
!
dhcpv4-snooping authorized-server 10.0.10.1 vrf default

Command translation

Verification and Validation

Check 1: Snooping state and trusted ports

diagnose switch-controller switch-info dhcp-snooping database <SWITCH_SN>

Expected: vlan10 appears under the snoop-enabled VLANs, and only your uplink and ISL ports appear under trusted ports.

S248EXXXXXXXXXXX:
snoop-enabled-vlans             : 10
trusted ports    : port46 port47 port48

DHCP Global Configuration:
DHCP Broadcast Mode              : Trusted
DHCP Allowed Server List         : Enable

Check 2: Bindings are being learned

sudo dhclient -r eth0 && sudo dhclient -v eth0

diagnose switch-controller switch-info dhcp-snooping client-db <SWITCH_SN>
diagnose switch-controller switch-info dhcp-snooping server-db <SWITCH_SN>

Expected: the client MAC, 10.0.10.1xx, VLAN 10, and port3 appear in the client database; 10.0.10.1 appears in the server database as trusted.

Check 3: The rogue server dies at the port

On the rogue host on port12, run a throwaway dnsmasq instance handing out itself as gateway:

sudo ip addr add 10.0.10.250/24 dev eth0
sudo dnsmasq --no-daemon --interface=eth0 --bind-interfaces \
  --dhcp-range=10.0.10.200,10.0.10.220,5m \
  --dhcp-option=3,10.0.10.250 --dhcp-option=6,10.0.10.250 \
  --log-dhcp

From any client, probe for every server that answers. Only the FortiGate should respond:

sudo nmap --script broadcast-dhcp-discover -e eth0

Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 1:
|     Server Identifier: 10.0.10.1
|     Router: 10.0.10.1
|_    Domain Name Server: 10.0.10.1

If you see a second response with Server Identifier 10.0.10.250, snooping is not enforcing on port12. Check that port12 is untrusted and that vlan10 is listed in snoop-enabled VLANs. With drop-untrusted set, the dnsmasq log on the rogue host should show no DISCOVERs arriving at all.

Check 4: Drop counters on the switch

get switch dhcp-snooping status
get switch dhcp-snooping database-summary
get switch dhcp-snooping client-db-details
get switch dhcp-snooping server-db-details

Troubleshooting and Gotchas

Gotcha 1: DHCP dies the moment snooping is enabled

Symptom: every client on the VLAN, or every client behind a particular switch, stops getting addresses. Cause: the path to the server crosses a port that is still untrusted, usually an ISL to a downstream FortiSwitch or a trunk to a third-party switch. Fix: walk the path from client to server and trust every hop toward the server on every switch.

get switch dhcp-snooping database-summary
config switch interface
    edit "<isl_or_uplink_port>"
        set dhcp-snooping trusted
    next
end

Gotcha 2: Clients fail only after enabling Option 82

Symptom: snooping works, then enabling Option 82 breaks leases. Cause: the server rejects requests that carry Option 82 with giaddr 0.0.0.0, or a relay further upstream discards them as untrusted relay information. Fix: confirm with a packet capture on the server side, then either configure the server or relay to accept them (on Cisco relays, ip dhcp relay information trust-all or per-interface ip dhcp relay information trusted) or disable Option 82 insertion if you are not consuming it.

diagnose sniffer packet any 'udp and (port 67 or port 68)' 6 0 l

Gotcha 3: Static-IP devices go dark after DAI or IPSG

Symptom: printers, cameras, and PLCs lose connectivity right after enforcement is enabled; DHCP clients are fine. Cause: no DHCPACK, no binding, so DAI drops their ARP and IPSG drops their IP traffic. Fix: add static snooping entries (Step 5), convert them to DHCP reservations, or move them to a VLAN where enforcement is not applied. Inventory fixed-IP hosts before the change window, not during it.

Gotcha 4: Everything breaks after a switch reboot

Symptom: after a reload, DAI-protected clients cannot ARP until they renew. Cause: the binding table was RAM-only. Fix: enable binding persistence where the platform supports it (ip dhcp snooping database on Cisco), shorten lease times on enforced VLANs so renewals happen quickly, and schedule enforcement rollouts so a full renewal cycle has passed.

Gotcha 5: Starvation still succeeds

Symptom: the pool empties even with MAC verification on. Cause: the attack tool randomizes both the Ethernet source MAC and chaddr, so verification passes. Fix: cap per-port bindings (dhcp-snoop-db-per-port-learn-limit), rate limit DHCP on access ports, and enforce MAC limits through 802.1X or port security. Watch the per-port binding count for outliers.

Gotcha 6: Wireless and virtualization edge cases

A bridged-mode SSID or a hypervisor uplink puts many clients behind one switch port. That is fine for snooping (bindings record the same port for many MACs) but it collides with low per-port learn limits and tight rate limits. Size those limits per port role, and remember that if the AP or hypervisor itself runs a DHCP service, its port must be trusted, which widens the trust boundary to everything behind it.

Best Practices Checklist

• Enable snooping on every user and IoT VLAN, not just the ones that have had incidents.
• Trust only server-facing uplinks, ISLs, and ICLs; audit trust on both ends of every inter-switch link.
• Turn on the allowed server list so trust is not the only gate.
• Use drop-untrusted so client broadcasts never reach access ports.
• Set per-port learn limits and DHCP rate limits sized to the port’s real role.
• Inventory static-IP hosts and give them static bindings or reservations before enabling DAI or IPSG.
• Persist the binding table where supported, and stage enforcement after a full lease cycle.
• Deploy RA guard and DHCPv6 protection on any VLAN where clients have IPv6 enabled.
• Re-run the rogue server test after every switch replacement, firmware upgrade, or topology change.

Final Word

DHCP snooping is unglamorous, cheap, and already licensed on the switch you own. It removes the most common accidental outage on a campus network (the rogue home router) and the most common Layer 2 MITM primitive (the rogue server), and it builds the binding table that DAI and IP Source Guard need to do their jobs. Deploy it in the right order: trust the uplinks, enable snooping, verify bindings, then turn on the enforcement features that depend on it.