DHCP Snooping, Dynamic ARP Inspection, and IP Source Guard can help protect access networks from unauthorized DHCP servers, ARP spoofing, and source-address impersonation. They can also interrupt legitimate traffic when bindings are missing, uplinks are incorrectly marked as untrusted, or static-IP devices have not been accounted for. This guide explains the configuration order and troubleshooting approach for Cisco Catalyst 9200, 9300, and 1300 switches.
What DHCP Snooping, DAI, and IP Source Guard Do
DHCP Snooping
DHCP Snooping filters DHCP messages on untrusted interfaces and records valid IP-to-MAC bindings. It helps prevent unauthorized DHCP servers, fake DHCP offers, and incorrect gateway information from reaching clients.
Dynamic ARP Inspection
Dynamic ARP Inspection validates ARP requests and responses against trusted information. In a DHCP environment, the trusted information normally comes from the DHCP Snooping binding database.
DAI can help reduce ARP spoofing and man-in-the-middle risks inside a Layer 2 VLAN. It is normally enabled per VLAN and should be introduced only after the required DHCP bindings have been verified.
IP Source Guard
IP Source Guard restricts traffic according to the source IP address and, where configured, the source MAC address associated with an interface. It is normally applied to client-facing Layer 2 ports.
If a host has no valid DHCP Snooping binding or approved static binding, IP Source Guard may deny its IP traffic.
Send your switch model, VLANs, uplinks, and current binding issue.
How the Three Features Work Together
These features should be viewed as a dependency chain rather than three unrelated security switches:
| Feature | Primary function | Important dependency |
|---|---|---|
| DHCP Snooping | Builds the IP-to-MAC binding database | Requires correct VLAN and trust-port planning |
| Dynamic ARP Inspection | Validates ARP packets | Uses DHCP Snooping bindings or approved ARP controls |
| IP Source Guard | Restricts unauthorized source IP traffic | Uses DHCP Snooping or static source bindings |
A safer rollout sequence is to enable DHCP Snooping first, verify the binding table, then enable DAI and IP Source Guard on selected interfaces. This makes it easier to identify whether a problem comes from DHCP filtering, ARP validation, or source-IP enforcement.
- Confirm the VLAN and trunk design.
- Enable DHCP Snooping for the required VLANs.
- Trust only approved DHCP server-facing and uplink interfaces.
- Verify that client bindings are being learned.
- Enable DAI for the selected VLANs.
- Enable IP Source Guard on appropriate client-facing interfaces.
- Add static bindings for approved static-IP devices.
- Verify counters and client connectivity.
IOS XE Configuration for Catalyst 9200 and 9300
The following examples use VLAN 10 and an uplink on GigabitEthernet1/0/48. Replace these values with the actual VLAN and interface design on the switch.
Enable DHCP Snooping
Configure the approved uplink or DHCP server-facing interface as trusted:
Ordinary endpoint ports should normally remain untrusted. Do not trust an interface simply because it is configured as a trunk; trust should reflect the direction and role of the interface.
Enable Dynamic ARP Inspection
The approved uplink or DHCP infrastructure path may also require DAI trust:
DAI should be enabled only after checking that the required DHCP Snooping bindings exist. Without valid bindings, legitimate ARP packets may be denied.
Enable IP Source Guard
On a client-facing Layer 2 interface, IP Source Guard can be enabled with:
Apply this feature selectively. A trunk or uplink usually requires a different trust and binding design and should not be restricted as a quick workaround.
C1300 Web UI and CLI Differences
The Cisco Catalyst 1300 Series uses a different management workflow from IOS XE-based Catalyst 9200 and 9300 switches.
Depending on the installed firmware, the relevant Web UI areas may include:
- Security > DHCP Snooping
- Security > Dynamic ARP Inspection
- Security > IP Source Guard
- IP Source Guard > Binding Database
- Interface or VLAN security settings
Menu names and available options may vary by firmware version. Confirm the current C1300 Administration Guide before applying changes.
Recommended C1300 workflow
- Enable DHCP Snooping globally.
- Select the VLANs that should use DHCP Snooping.
- Mark the DHCP server-facing and approved uplink interfaces as trusted.
- Enable ARP Inspection for the required VLAN.
- Enable IP Source Guard on client-facing ports or LAGs.
- Add static bindings for approved static-IP devices.
- Review the Binding Database and inactive entries.
C1300 CLI may provide commands for DHCP Snooping, ARP Inspection, and IP Source Guard, but command availability and syntax should be checked against the installed release. Do not copy a complete IOS XE configuration directly to a C1300 switch.
Trusted Uplinks and DHCP Server Ports
Incorrect trust configuration is one of the most common causes of an outage after DHCP Snooping or DAI is enabled.
Interfaces that may need to be trusted
- The interface connected to the legitimate DHCP server
- The uplink toward a distribution or core switch
- An approved trunk carrying DHCP traffic
- An authorized port channel or LAG
- A network service appliance that legitimately provides DHCP
Interfaces that should normally remain untrusted
- User access ports
- IP phone access ports
- Wireless client VLAN interfaces
- Camera and IoT access ports
- Unmanaged downstream device ports
On a port channel, verify the trust state of the logical interface and its member interfaces. A mismatch between the physical members and the port channel can create unexpected filtering behavior.
Trust should be based on the traffic source and security role of the interface, not simply on whether the port is fast, uplink-facing, or configured as a trunk.
Static IP Devices and Manual Bindings
DHCP Snooping cannot create a dynamic binding for a device that never uses DHCP. Common examples include servers, printers, cameras, access-control systems, firewalls, and network-management appliances.
When DAI or IP Source Guard is enabled for the VLAN, these devices may need an approved manual binding or another documented exception.
IOS XE static binding example
Confirm the MAC address, VLAN, IP address, and interface before adding a static binding. A wrong binding can block the intended host or permit traffic on the wrong port.
C1300 static-device handling
On C1300, review the IP Source Guard Binding Database and add approved static entries through the available interface. Check the binding status after saving the configuration.
Do not use static bindings on an uplink as a workaround for a broader trunk, VLAN, or trust-state problem. First confirm where the static host is actually connected and which VLAN should carry its traffic.
Why Legitimate Traffic Is Dropped
When security features begin dropping traffic, check the binding database and trust state before disabling all protections or marking every interface as trusted.
| Symptom | Likely cause | First check |
|---|---|---|
| Clients cannot obtain DHCP addresses | The DHCP server path or uplink is untrusted | DHCP Snooping trust state |
| DAI drops valid ARP packets | The DHCP binding is missing or incorrect | DHCP Snooping binding table |
| A static-IP device loses access | No approved static binding exists | IP Source Guard or Binding Database |
| A downstream VLAN stops working | The trunk is untrusted or the VLAN is missing | Trunk VLAN list and trust state |
| IP Source Guard blocks client traffic | The client has no valid binding | Client lease and binding table |
| ARP packets are dropped intermittently | DAI rate limit or ARP burst issue | DAI statistics and rate settings |
| C1300 binding is inactive | VLAN, trust, or hardware-resource issue | Binding Database status |
Verify DHCP Snooping
Confirm that DHCP Snooping is globally enabled, the intended VLAN is included, the server-facing interface is trusted, and client bindings are being learned.
Verify Dynamic ARP Inspection
Check whether DAI is enabled on the correct VLANs, whether trusted interfaces match the topology, and whether drops are caused by missing bindings or rate limits.
Verify IP Source Guard
Confirm that IP Source Guard is applied only to the intended client-facing interfaces, dynamic clients have valid bindings, and static devices have approved manual entries.
C1300 troubleshooting focus
On C1300, review the DHCP Snooping, ARP Inspection, and IP Source Guard pages separately. The Binding Database should be checked for VLAN ID, MAC address, IP address, interface, status, and inactive-entry reason.
Frequently Asked Questions
Final Takeaway
DHCP Snooping, Dynamic ARP Inspection, and IP Source Guard are most effective when they are deployed as a controlled sequence. Build and verify the DHCP binding database first, then introduce ARP and source-IP enforcement on the interfaces that need it.
For Catalyst 9200 and 9300, follow the IOS XE configuration path. For Catalyst 1300, use its Web UI and release-specific CLI workflow. The most important operational checks are the DHCP server path, uplink trust, static-IP bindings, VLAN consistency, and security counters.
For a configuration-specific review, submit your Catalyst model and VLAN requirements before applying the security policy to production.