Description

This KB describes the suggested steps to introduce DHCP Snooping configuration in a current production network, even though not a best practice, it can be done, but if not done properly, it can cause loss of network connection for end clients.

Symptoms

End clients in a network are not receiving IP addresses.


Solution

What is DHCP Snooping?

DHCP Snooping is a security feature that inspects all DHCP traffic arriving on untrusted ports of a switch. When enabled on a VLAN, it examines DHCP messages, extracts IP address and lease information, and builds a DHCP Snooping binding database (IP ↔ MAC ↔ interface ↔ VLAN). Only hosts verifiable against this database are allowed network access.

It's the foundation for two other critical security features:

  • Dynamic ARP Inspection (DAI) — validates ARP packets against the snooping database
  • IP Source Guard — blocks IP traffic that doesn't match the binding database


Trusted vs. Untrusted Ports

This is the most important concept to get right before enabling the feature:

Port Type

Default Trust State

Behavior

Access port

Untrusted

DHCP DISCOVER/REQUEST allowed; DHCPOFFER blocked (assumed rogue DHCP)

Trunk port

Trusted

All DHCP traffic passes freely


Critical implications:

  • If a DHCP server (or PXE server) is connected to an access port that remains untrusted, DHCP will not function, its OFFER packets will be dropped.
  • Statically addressed devices on untrusted ports with ARP Inspection or IP Source Guard enabled will lose connectivity, they have no entry in the snooping database.
  • Access Points, infrastructure devices, or any device normally on a trunk should be marked trusted explicitly in their port profile.

When to enable it?

The ideal time to enable DHCP snooping is during initial deployment of the network, before clients connect; not retroactively on a live network. Here's why and a phased approach:

1.Pre-deployment (best): Configure it as part of the initial switch setup. No binding table exists yet, so there's no disruption risk.

2.Maintenance window on live networks: If enabling post-deployment, do it during a maintenance window. Enabling it on a live network can temporarily disrupt DHCP renewals and cause connectivity drops for statically addressed devices if trust isn't configured correctly first.

3.Before enabling DAI or IP Source Guard: Always enable DHCP Snooping first and let the binding table populate organically (or add static bindings) before activating the dependent features. Enabling DAI or IP Source Guard on an empty binding table will block all traffic on untrusted ports.


How to enable it

To enable it using Mist dashboard:


  1. Navigate to your site left side menu → Switches
  2. Select the desired switch from the list
  3. Scroll down until the Services boxes and look for DHCP Snooping
  4. Check box "Override Site/Template Settings" and select "Enable" on the radial box options.
  5. Choose whether to enable for all networks or a single network (e.g., a specific VLAN)


How to Safely Enable on a Live Network

The key is to pre-populate the binding table before enabling the dependent security features:


Step 1 — Static Bindings (most reliable)

Manually add bindings for all static leases under "Additional CLI Commands":

set groups top vlans <vlan-name> forwarding-options dhcp-security interface <ge-x/x/x.0> static-ip <IP> mac <MAC>


Pull the current lease table from your DHCP server and script the static binding entries.


Step 2 — Wait for natural renewal of current leases

After enabling DHCP Snooping only (no DAI, no IP Source Guard yet), wait for the binding table to populate organically as leases renew; cross-reference the binding table against your DHCP server's active leases to confirm coverage

Once the table is sufficiently populated, enable DAI and/or IP Source Guard


Step 3 — Force lease renewal

If needed, or to quicken the approach, during a maintenance window, force clients to release and renew after enabling snooping, so the switch can observe the full handshake and build bindings quickly.

Modification History

2026-09-08 : Article Created