DHCP snooping on a Cisco Catalyst switch is one of those features that is easy to enable and easy to misapply. It watches DHCP traffic on selected VLANs, builds a binding table for clients it accepts, and blocks server replies arriving on untrusted ports. Option 82 builds on that access-layer position by inserting relay-agent information into DHCP requests so an upstream DHCP server can make policy decisions based on the client’s attachment point.

The command names have stayed recognizable across many Catalyst and IOS XE families. The defaults, supported sub-options, database behavior, and exact show-command output have not stayed identical. Treat the configuration below as a conservative deployment pattern, then verify it against the documentation for the switch model and software release you actually operate.

For the protocol model first, read What Is DHCP Option 82? Relay Agent Information Explained. This article is about safely putting that model on a Catalyst access switch.

What changes when DHCP snooping is enabled

On a snooping-enabled VLAN, Catalyst treats ports as untrusted unless you mark them otherwise. That is deliberate. A normal access port should be allowed to send DHCP client requests, but it should not be allowed to send DHCPOFFER or DHCPACK messages to other clients.

The switch normally needs to trust the interface facing the legitimate DHCP server, relay, or controlled upstream path carrying legitimate server replies. It may also need to trust a controlled inter-switch connection, but do not turn every trunk into a trusted DHCP path by reflex. First trace where client requests go and where server replies return.

If you get that trust boundary wrong, the failure can look sudden and dramatic: clients stop receiving leases. That is not a reason to skip DHCP snooping. It is a reason to pilot it on a small, observable VLAN before rolling it across a campus.

Before touching the switch

Do this reconnaissance before the first ip dhcp snooping command:

1. Pick a pilot VLAN with a small number of test clients and a rollback window.
2. Identify the DHCP server or relay, the Layer 3 gateway, and every inter-switch path between the access switch and that upstream service.
3. Confirm the current lease flow with a test client. Record its address, gateway, DNS servers, lease server, and the relevant switch interfaces.
4. Check the DHCP server can accept and, if you plan to use the value for policy, process Option 82. Insertion without server handling is not a finished design.
5. Decide what you will do with the information: logging only, a narrow pool selection rule, a lease limit, or another explicit policy. “We enabled it for security” is not an operational goal.

Cisco’s current platform guides still document the basic pattern: enable snooping globally, enable it for the selected VLANs, configure Option 82, and mark legitimate upstream paths trusted. Their details also make the point: a Catalyst 9400 IOS XE guide lists platform prerequisites and restrictions that should be checked before a broad rollout.

A safe four-step pilot

The following example uses VLAN 20 and an uplink on GigabitEthernet1/0/48. Those are placeholders, not a configuration recipe for your topology.

1. Enable snooping globally and on the pilot VLAN

configure terminal
ip dhcp snooping
ip dhcp snooping vlan 20
end

Avoid the old habit of enabling vlan 1 4094 immediately. A full-range command has a very large blast radius, especially in a switch stack or a network with unfamiliar legacy VLANs. Start with the VLAN you can observe, then expand only after you understand the trusted paths and server behavior.

2. Mark only the legitimate upstream DHCP path as trusted

configure terminal
interface GigabitEthernet1/0/48
 description Uplink toward approved DHCP relay or server path
 ip dhcp snooping trust
end

Do not apply ip dhcp snooping trust to ordinary client access ports. That would allow a rogue DHCP server on that port to answer clients. If the DHCP server is on a different switch, identify the actual return path for its replies; there may be more than one controlled inter-switch interface to evaluate.

On untrusted access ports, consider a DHCP packet rate limit when the platform supports it. Rate limiting can reduce the impact of a client sending a flood of requests, but the correct value depends on endpoint behavior and the number of clients behind the port. Start from Cisco’s platform guidance and test phones, wireless access points, and virtualized hosts before treating one value as universal.

3. Enable Option 82 insertion explicitly

configure terminal
ip dhcp snooping information option
end

On several Catalyst IOS XE families, Option 82 insertion is documented as enabled by default when snooping is configured. State it explicitly anyway. That makes the desired policy clear in the running configuration and avoids relying on a default that may differ on another platform.

The switch inserts relay information on forwarded client requests and removes it from replies before clients receive them. The format of Circuit ID and Remote ID can vary by platform. Do not build DHCP server rules until you capture or log the actual values emitted by this switch.

4. Verify before expanding the scope

Start with the switch’s snooping status:

show ip dhcp snooping
show ip dhcp snooping binding

The first command should show snooping enabled for the pilot VLAN and identify the relevant Option 82 state on platforms that expose it. The binding command should show a lease for a successful client, including its VLAN and interface. Exact fields vary, so use this as a health check rather than a parser contract.

Then test a real client:

• Release and renew its lease during the maintenance window.
• Confirm it receives the expected address, gateway, and DNS configuration.
• Verify the DHCP server logs or lease records show the expected relay context.
• Test an adjacent untrusted access port to ensure it still receives a normal lease and cannot provide server replies.
• Check switch logs and counters for snooping drops, malformed packets, or rate limit events.

Only after the pilot works should you add another VLAN or another access layer. Capture the successful Option 82 values and make a narrow server-side policy match before creating a broad set of per-port rules.

Option 82 is not a reason to trust Option 82 everywhere

An aggregation switch can sometimes be configured to accept Option 82 already inserted by a downstream edge switch. Cisco documents variants of an allow-untrusted or allowed-untrusted setting for that topology. Do not enable it on a general access switch just because a packet with Option 82 was dropped.

The configuration only makes sense when the downstream device that inserted the option is itself a known, controlled part of the trust boundary. Otherwise you have converted client-supplied metadata into “trusted” policy input. The safest default is still to reject unexpected pre-inserted Option 82 on untrusted paths.

Rollback should be boring too

Write the rollback before the pilot. If clients stop getting leases, preserve the evidence first: save show ip dhcp snooping, binding-table output, relevant interface configuration, and DHCP server logs. Then remove the smallest part of the change that restores service.

For an Option 82-only issue, that might be:

configure terminal
no ip dhcp snooping information option
end

For a pilot-VLAN problem, disable snooping for that one VLAN rather than disabling it globally:

configure terminal
no ip dhcp snooping vlan 20
end

Do not use rollback as a substitute for understanding the failure. A missing trusted uplink, a DHCP server that ignores or rejects the inserted option, and a wrong server policy need different fixes.

Common mistakes that make this feature painful

• Trusting every trunk. Trust is a DHCP-server-reply boundary, not a label for “this is infrastructure.” Review actual traffic direction and topology.
• Enabling every VLAN at once. That turns a small configuration error into a wide client outage.
• Assuming Circuit ID format. Capture the value first; formatting varies by switch family and release.
• Skipping server validation. A switch can insert Option 82 perfectly while the server ignores it, fails to echo it, or applies an unexpected policy.
• Forgetting persistence and monitoring. Binding database behavior and storage requirements are platform-specific. Check what survives a reboot and make snooping drops visible in normal operations.

The useful outcome

The point of this configuration is not to accumulate another security feature. It is to make the safe DHCP path explicit: clients request on untrusted ports, only known upstream infrastructure can answer, and the DHCP server gets the context it needs for explainable policy.

Once that works in a small VLAN, the same pattern scales well. Keep the policy small, verify each expansion, and retain enough logs to answer the only question that matters during an incident: which trusted network element told this client what to do?

For the adjacent relay behavior, see Allowing DHCP Option 82 in Cisco DHCP Relay Agents. For more networking and systems notes, visit Slaptijack.