How to Configure Dynamic ARP Inspection on Cisco Switches for ARP Spoofing Prevention

I once watched a man-in-the-middle attack unfold on a lab network during a security assessment, and it was almost embarrassingly simple to pull off — a laptop sending a handful of forged ARP replies, and suddenly it was intercepting traffic between two hosts that had no idea anything was wrong. That’s the entire premise of ARP spoofing, and it’s exactly what Dynamic ARP Inspection (DAI) exists to stop. In this guide I’ll walk through why ARP is so trusting by design, how DAI closes that gap, and exactly how to configure and verify it on a Cisco switch.

Why ARP Is a Security Weak Point

The Address Resolution Protocol (ARP) maps IP addresses to MAC addresses on a local segment, and it does so with essentially zero authentication. Any device on the VLAN can send an unsolicited ARP reply claiming “this IP address belongs to my MAC address,” and every other device on the segment will simply believe it and update their ARP cache. This trust-everything design is exactly what enables ARP spoofing (also called ARP poisoning) — an attacker sends forged ARP replies to redirect traffic meant for the real gateway or another host through their own machine, enabling man-in-the-middle attacks, session hijacking, or denial of service.

Networking Fundamentals Behind Dynamic ARP Inspection

DAI works by intercepting all ARP packets on untrusted VLAN ports and validating them against a trusted binding table before allowing them onto the network. Two building blocks make this possible:

• DHCP Snooping Binding Table: DAI’s default and most common source of trust. As DHCP snooping observes the DHCP lease process on trusted ports, it builds a table of IP-to-MAC-to-VLAN-to-interface bindings for legitimately leased addresses. DAI checks incoming ARP packets against this table.
• ARP ACLs: For hosts with statically assigned IP addresses (which never go through DHCP and thus never appear in the snooping table), you configure ARP ACLs to explicitly permit their known IP-MAC pairing.
• Trusted vs. Untrusted Ports: Uplinks to other switches or routers are typically marked trusted (DAI doesn’t inspect ARP traffic there), while access ports facing end-user devices are untrusted by default and fully inspected.

Because DAI relies heavily on DHCP snooping’s binding table, DHCP snooping must be enabled first for DAI to work correctly for dynamically addressed hosts.

Step 1: Enable DHCP Snooping (Prerequisite)

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10,20
Switch(config)# interface GigabitEthernet0/24
Switch(config-if)# description Uplink-to-Distribution
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# exit

Only the uplink port toward the legitimate DHCP server should be trusted; every access port facing end hosts stays untrusted by default, which is exactly what you want, since that’s where rogue DHCP or ARP activity would originate.

Step 2: Enable Dynamic ARP Inspection on the VLAN

Switch(config)# ip arp inspection vlan 10,20

This single command enables DAI validation for all access ports in VLANs 10 and 20.

Step 3: Configure Trusted Interfaces for DAI

Switch(config)# interface GigabitEthernet0/24
Switch(config-if)# ip arp inspection trust
Switch(config-if)# exit

Just like with DHCP snooping, trust the uplink toward your distribution/core switch or router. Every downstream access port remains untrusted, meaning every ARP packet arriving there gets checked against the binding table.

Step 4: Handling Static IP Hosts with ARP ACLs

Servers, printers, and network appliances with static IPs won’t appear in the DHCP snooping table, so without an ARP ACL, DAI would block their legitimate ARP traffic.

Switch(config)# arp access-list STATIC-HOSTS
Switch(config-arp-nacl)# permit ip host 10.1.10.50 mac host 0011.2233.4455
Switch(config-arp-nacl)# permit ip host 10.1.10.51 mac host 0011.2233.4466
Switch(config-arp-nacl)# exit

Switch(config)# ip arp inspection filter STATIC-HOSTS vlan 10

You can also add static to the filter command if you want to skip the DHCP snooping table entirely for that VLAN and rely only on the ARP ACL — useful in VLANs with no DHCP at all.

Step 5: Optional Rate Limiting

DAI includes a default rate limit on untrusted interfaces to prevent an attacker from overwhelming the CPU with a flood of ARP packets.

Switch(config)# interface range GigabitEthernet0/1 - 23
Switch(config-if-range)# ip arp inspection limit rate 15
Switch(config-if-range)# exit

The default rate is typically 15 packets per second on access ports, which is fine for normal end-user behavior but should be reviewed if you have devices that legitimately generate ARP bursts (some VoIP phones or virtualization hosts, for example).

Step 6: Optional Additional Validation Checks

Switch(config)# ip arp inspection validate src-mac dst-mac ip

This adds extra scrutiny: src-mac checks the sender MAC in the Ethernet header against the ARP body, dst-mac checks the target MAC in ARP replies against the Ethernet header, and ip validates the IP addresses in the ARP body (dropping invalid ones like 0.0.0.0, 255.255.255.255, and multicast addresses).

Step 7: Verifying the Configuration

Switch# show ip arp inspection vlan 10

Expected output:

Source Mac Validation      : Disabled
Destination Mac Validation : Disabled
IP Address Validation      : Disabled

Vlan     Configuration    Operation State    ACL Match             Static ACL
----     -------------    ---------------    -----------           ---------
  10        Enabled            Active           STATIC-HOSTS           No

Check trusted interface state:

Switch# show ip arp inspection interfaces

Interface       Trust State     Rate (pps)     Burst Interval
--------------- -----------     ----------     --------------
Gi0/1           Untrusted           15                1
Gi0/24          Trusted           None                N/A

And check statistics to confirm the switch is actually catching bad traffic:

Switch# show ip arp inspection statistics vlan 10

Vlan   Forwarded    Dropped    DHCP Drops    ACL Drops
  10       4821          7            5             2

A non-zero Dropped count on a VLAN under active attack (or during a misconfiguration test) is exactly the confirmation you want.

Practical Lab: Simulating and Blocking ARP Spoofing

1. Build a topology with a switch, a legitimate DHCP server, and two end hosts (Host A and “Attacker”) in VLAN 10, plus a router-on-a-stick or L3 switch as the default gateway.
2. Configure DHCP snooping and DAI as shown above, with only the uplink to the router/DHCP server trusted.
3. From the Attacker host, attempt to send a forged ARP reply claiming to own the gateway’s IP address (using a tool like arpspoof in a controlled lab environment).
4. Observe on the switch: show ip arp inspection statistics vlan 10 should show increasing drop counts, and Host A’s traffic should continue flowing normally to the real gateway instead of being redirected.

This lab is a staple in CCNP Security and real SOC training environments because it makes the abstract threat of ARP spoofing completely concrete.

Real-World Enterprise Scenario

At a financial services branch office, an internal audit flagged that guest and corporate devices shared the same access-layer switches (on separate VLANs, but the same physical hardware). The security team’s concern was a compromised guest laptop attempting ARP spoofing to intercept corporate VLAN traffic through VLAN hopping combined with ARP poisoning on misconfigured trunk boundaries. The remediation involved enabling DHCP snooping and DAI across all corporate VLANs, explicit ARP ACLs for the handful of statically addressed printers and badge readers, and validating that every access port’s trust state was correctly set to untrusted, with only true uplinks marked trusted. Post-implementation penetration testing confirmed ARP spoofing attempts were reliably dropped and logged.

Security Best Practices

• Never mark an access port facing end-user devices as trusted — this defeats the entire purpose of DAI.
• Always deploy DHCP snooping alongside DAI; DAI without a populated binding table (and no ARP ACLs) will either block legitimate traffic or, if misconfigured, provide false confidence.
• Maintain ARP ACLs for static-IP infrastructure devices and review them whenever hardware is replaced (MAC address changes).
• Enable src-mac, dst-mac, and ip validation checks in higher-security environments for defense in depth.
• Monitor show ip arp inspection statistics regularly, or better, feed syslog/SNMP data from DAI drops into your SIEM for real-time alerting.

Optimization and Performance Tuning

• Tune ip arp inspection limit rate per port group based on realistic traffic patterns — too low a limit on ports with legitimate ARP bursts (like virtualization hosts running many VMs) can cause the port to be error-disabled unnecessarily.
• Use errdisable recovery cause arp-inspection with a sensible recovery interval so a port that hits the rate limit and shuts down doesn’t require manual intervention every time, while still logging the event for review.
• Keep the DHCP snooping binding table lease times realistic; excessively long DHCP leases mean stale bindings linger, while very short leases increase renewal-related ARP/DHCP chatter.
• In very large VLANs, consider whether centralizing DAI logging via syslog with rate limiting prevents log flooding during an actual attack.

Troubleshooting and Common Mistakes

• Enabling DAI without DHCP snooping: This is the single most common mistake — DAI has no binding table to validate against, and depending on configuration, either blocks everything or effectively does nothing useful.
• Forgetting to trust the uplink port: This causes legitimate gateway ARP traffic to be inspected and potentially dropped, breaking connectivity for the entire VLAN.
• Static IP devices losing connectivity after enabling DAI: This happens when no ARP ACL exists for them; always inventory static-IP devices before enabling DAI in a VLAN.
• Mismatched VLANs between DHCP snooping and DAI: Both features need to be enabled on the same VLAN list, or bindings won’t align with inspection scope.
• Rate limit too aggressive causing error-disabled ports: Watch for %SW_DAI-4-DHCP_SNOOPING_DENY or interface err-disable messages after initial rollout and adjust rate limits accordingly.

Frequently Asked Questions

Does DAI protect against all forms of ARP-based attacks? It protects specifically against ARP spoofing/poisoning by validating IP-to-MAC bindings; it doesn’t address every possible Layer 2 attack, which is why it’s typically deployed alongside port security and DHCP snooping as part of a broader Layer 2 security baseline.

Do I need DAI if I already have DHCP snooping enabled? DHCP snooping alone only protects the DHCP process itself (blocking rogue DHCP servers); it does not inspect or validate ARP traffic. You need DAI specifically to catch ARP spoofing.

Will DAI break connectivity for devices with static IP addresses? Not if you configure ARP ACLs for them ahead of time. Without an ARP ACL, yes — their ARP traffic will be dropped on untrusted ports.

Can DAI be enabled on a trunk port? Yes, DAI can be enabled per VLAN on a trunk, and the trunk’s trust state (trusted/untrusted) is configured just like on an access port, typically trusted if it connects to another switch you control.

Summary

Dynamic ARP Inspection closes one of the oldest and most exploitable gaps in Ethernet networking: ARP’s implicit trust model. By building on the DHCP snooping binding table, adding ARP ACLs for static hosts, and carefully setting trust states on your switch ports, you turn a wide-open attack surface into a monitored, enforced one. The configuration itself is straightforward once you understand the DHCP snooping dependency — the real work is in careful planning of trusted interfaces and static host exceptions before you flip it on in production.

References

• Cisco Catalyst Switch Software Configuration Guide — Dynamic ARP Inspection chapter, cisco.com/c/en/us/support/switches
• Cisco documentation on DHCP Snooping and Dynamic ARP Inspection interaction
• Cisco Command Reference — ip arp inspection, arp access-list, ip dhcp snooping