Dynamic ARP Inspection and IP Source Guard: The L2 Security Stack

ARP is the most trusting protocol in the building. A host asks "who has 10.10.10.1?" and believes whatever answer comes back, with no verification of any kind. So an attacker replies "I do" - claiming to be your default gateway - and every host on the subnet starts sending its off-net traffic to the attacker. That is ARP spoofing, and it is the basis of most Layer 2 man-in-the-middle attacks.

Dynamic ARP Inspection and IP Source Guard are the two features that fix ARP's and IP's respective trust problems, and both are built on the DHCP snooping binding table. This article covers both, with real output from a CML lab and an honest note on what a virtual switch can enforce. For the fundamentals, start at the complete VLAN and switching guide. This builds directly on DHCP snooping, so read that first.

Dynamic ARP Inspection

DAI intercepts every ARP packet on an untrusted port and checks it against the snooping binding table. The question it asks is simple: does this ARP packet claim an IP-to-MAC mapping that matches a real DHCP lease on this port?

• A host sends an ARP reply saying "10.10.10.10 is at 5254.004e.11c0" from the port where that exact binding exists. DAI permits it.
• An attacker sends "10.10.10.1 (the gateway) is at my-MAC" from a port that has no such binding. DAI drops it and logs the violation.

The attacker cannot forge a binding, because bindings are created only by real DHCP transactions (or a deliberate static entry). So the gateway-impersonation attack simply fails.

Configuration

! Enable per VLAN
ip arp inspection vlan 10

! Trust the uplinks and inter-switch trunks (same ports as DHCP snooping trust)
interface Ethernet0/0
 ip arp inspection trust
interface Ethernet0/1
 ip arp inspection trust

! Rate-limit ARP on untrusted access ports (ARP flooding defence)
interface Ethernet0/2
 ip arp inspection limit rate 15

The trust model mirrors DHCP snooping exactly: uplinks and inter-switch trunks trusted, host access ports untrusted. This makes sense - a legitimate ARP from another switch has already been validated by that switch, so you do not re-inspect it.

The rate limit matters because DAI punts ARP to the CPU for inspection. An attacker flooding ARP could turn DAI itself into a denial of service by overwhelming the CPU. The rate limit caps that; a port exceeding it is errdisabled. The default on untrusted ports is 15 pps.

Operational state

SW3#show ip arp inspection vlan 10
 Vlan     Configuration    Operation   ACL Match          Static ACL
   10     Enabled          Active
 Vlan     ACL Logging      DHCP Logging      Probe Logging
   10     Deny             Deny              Off

Enabled / Active on VLAN 10, using the DHCP binding table (DHCP Logging: Deny means it logs denied packets). This is DAI operational and watching.

IP Source Guard

Where DAI protects ARP, IP Source Guard (IPSG) protects the IP source address itself. It applies a dynamic port ACL that permits only the IP address (and optionally MAC) bound to that port in the snooping table. Any packet with a different source IP is dropped.

This stops a host from spoofing its source IP - claiming to be another machine to bypass an ACL, evade logging, or launch a spoofed-source attack.

interface Ethernet0/2
 ip verify source

Add ip verify source port-security to also enforce the source MAC, tying the port down to exactly one (IP, MAC) pair.

SW3#show ip verify source
Interface  Filter-type  Filter-mode  IP-address       Mac-address        Vlan
Et0/2      ip           active       10.10.10.10                         10

That is IPSG live: on Et0/2, the only source IP permitted is 10.10.10.10 - the address bound to that port in the snooping table. A packet sourced from any other IP is dropped in hardware. Because the binding came from DHCP, the moment that host's lease expires or moves, the filter updates automatically.

The complete stack, in order

The dependency is strict and one-directional. If DHCP snooping is broken, DAI and IPSG are broken, because they have no table to consult. When DAI blocks a legitimate host, the fault is almost always a missing snooping binding, not DAI itself. Debug the table first, every time.

Handling non-DHCP hosts

Not every device uses DHCP. Servers, printers, and network gear often have static IPs, and they have no snooping binding - so DAI would drop their ARP and IPSG would drop their traffic. Two ways to accommodate them:

A static snooping binding (the same technique we used in the lab):

ip source-binding 0011.2233.4455 vlan 10 10.10.10.50 interface Ethernet0/5

An ARP ACL for DAI, which permits specific IP-to-MAC pairs regardless of the binding table:

arp access-list STATIC-HOSTS
 permit ip host 10.10.10.50 mac host 0011.2233.4455
!
ip arp inspection filter STATIC-HOSTS vlan 10

Every static host needs one of these, or it goes dark the moment you enable DAI. Inventory your static devices before you turn DAI on, not after the help desk lights up.

Platform note: honest reporting

DAI and IPSG are hardware-enforced features - they punt ARP to the CPU for inspection and install per-port ACLs in the switch ASIC. In our CML lab on virtual IOL-L2, both features report Enabled / Active and IPSG shows the correct bound IP, but the forwarding plane does not count or enforce live traffic:

SW3#show ip arp inspection statistics vlan 10
 Vlan      Forwarded        Dropped     DHCP Drops      ACL Drops
   10              0              0              0              0

Zero, because the virtual node does not punt ARP to the inspection process - the same architectural limitation that stops DHCP snooping populating its table from live traffic. The configuration and operational state are genuine; the live enforcement counters are not reproducible on this platform. On real Catalyst hardware, an ARP-spoofing attempt from an unbound port produces:

%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Et0/2, vlan 10.
([mac]/10.10.10.1/[target-mac]/10.10.10.10/[time])

We show you the real config, the real operational state (Active, with the bound IP), and the real syslog you would see - rather than staging fake drop counters on a platform that cannot produce them. An expert reader can tell the difference, and we would rather earn the trust.

Troubleshooting

1. DAI dropping a legitimate host? Check show ip dhcp snooping binding first. Ninety percent of DAI "problems" are a missing binding. Static host? It needs a static binding or ARP ACL.
2. IPSG blocking a host? Same - the binding is missing or wrong. show ip verify source shows what IPSG thinks the port is allowed to use.
3. Port errdisabled by DAI? ARP rate limit exceeded. Either a flood/attack, or a legitimate burst - raise the limit if it is a false positive, and add errdisable recovery.
4. Everything Active but nothing enforced (in a lab)? Virtual switch limitation - the forwarding plane is not punting to the inspection engine. Expected on IOL-L2; works on hardware.
5. Static hosts unreachable after enabling DAI? They have no binding. Add ARP ACLs or static source-bindings for every static device before enabling.

Key takeaways

• ARP and IP both trust the sender blindly. DAI fixes ARP spoofing; IPSG fixes IP spoofing.
• Both read the DHCP snooping binding table. Break snooping and you break both. When DAI/IPSG blocks a legitimate host, debug the binding table first.
• DAI trust mirrors snooping trust: uplinks and inter-switch trunks trusted, host ports untrusted. Rate-limit untrusted ARP to protect the CPU.
• IPSG (ip verify source) installs a per-port filter permitting only the bound source IP; add port-security to bind the MAC too.
• Static (non-DHCP) hosts have no binding. Give each one a static snooping binding or an ARP ACL before enabling DAI, or they go dark.
• On virtual IOL-L2 the features are Active but not counter-enforced (no forwarding-plane punt); on hardware they enforce and log. We report the config, operational state, and real syslog honestly rather than faking counters.

Next: switch administration - SDM templates, errdisable recovery, and CAM aging. The full cluster index lives on the VLAN and switching pillar, and the security features cross-link to infrastructure security.