MAC addresses in this article have been replaced with values from the RFC 7042 EUI-48 documentation range. IP addresses and subnets shown have been replaced with representative private addressing.
While expanding my Cisco Catalyst 3850 homelab, I implemented several Layer 2 security controls. These include DHCP Snooping, Dynamic ARP Inspection, and IP Source Guard. The goal was not just to configure the features blindly, but to understand how they interact and what their failures might actually look like during normal network operation. And this was made quite clear when I disconnected and reconnected a laptop on my USERS VLAN.
The interface came back up as expected. My centralized syslog server recorded the normal link-state events, but suddenly the switch began repeatedly reporting a message like:
%SW_DAI-4-DHCP_SNOOPING_DENY: 1 Invalid ARPs (Res) on Gi1/0/3, vlan
10.([0000.5e00.5342/10.10.10.10/0000.0000.0000/10.10.10.1/...{time & date}])At first glance, the natural instinct might be that Dynamic ARP Inspection was causing the problem, and it was. But it was also doing exactly what it was supposed to do.
The Lab
The lab is built around a Cisco Catalyst 3850 running IOS XE. It contains multiple routed VLANs, with a Raspberry Pi providing centralized infrastructure services (DHCP, NTP, syslog collection).
A simplified topology looks like this:
Cisco Catalyst 3850
|
+------------+------------+
| | |
VLAN 10 VLAN 20 VLAN 30
USERS ADMIN SERVERS
| | |
Laptop Laptop Raspberry Pi
|
DHCP / NTP / SyslogDHCP Snooping is enabled so the switch can build a trusted database of DHCP-assigned addresses. Dynamic ARP Inspection then uses that information to validate ARP traffic arriving on untrusted interfaces.
DHCP assignment
|
v
DHCP Snooping
builds binding:
IP + MAC + VLAN + Port
|
v
Dynamic ARP Inspection
checks ARP claims against bindingIf a host claims an IP address that does not agree with the switch's trusted binding information, the ARP packet is rejected, and all is well in the world.
The Symptom
Upon reconnecting the USERS laptop to Gi1/0/3, the switch logged the expected interface transition as well as the repeated DAI denial messages. The detail evident in the messages was that the laptop seemed to show it was using:
10.10.10.10But when I inspected the DHCP Snooping database, the same MAC address appeared with a different IP:
10.10.10.126The switch had effectively two contradictory versions of reality:
Laptop:
MAC: 0000.5e00.5342
IP: 10.10.10.10
DHCP Snooping Binding:
MAC: 0000.5e00.5342
IP: 10.10.10.126
When the laptop sent an ARP response identifying itself as 10.10.10.10,
Dynamic ARP Inspection compared that claim against the trusted DHCP Snooping binding.
They did not match and the packet was dropped.
Checking the Binding Table
The first useful Cisco command was:
show ip dhcp snooping bindingThis displays the bindings learned through DHCP Snooping, including infromation such as MAC address, IP address, lease, VLAN, and interface. The relevant entry associated the laptop's MAC address with the DHCP-assigned IP address rather than the address the laptop was currently using.
I compared that against the laptop's actual network configuration, which proved to be more useful than changing any switch configuration.
Root Cause
The mismatch turned out to be caused by an old static configuration on the laptop.
Before I introduced centralized DHCP to the lab, the USERS laptop had been manually configured
with 10.10.10.10. Later, I configured the Raspberry Pi to provide DHCP
for the VLAN and enabled DHCP relay on the Catalyst 3850. At some point, the laptop obtained the
DHCP address 10.10.10.126.
The switch observed that DHCP exchange and added a snooping binding associating the laptop's
MAC address with 10.10.10.126.
However, I had never fully removed the laptop's earlier static network configuration. When the
laptop was later disconnected and reconnected, it returned to using it's manually configured
10.10.10.10 address.
When the laptop sent an ARP response claiming ownership of 10.10.10.10,
Dynamic ARP Inspection checked that claim against the DHCP Snooping database. The switch had
learned that same MAC address had been assigned 10.10.10.126, so the
ARP response failed validation and was dropped.
So ther underlying problem was not DAI itself, it was a configuration inconsistency I had introduced while transitioning the laptop from static addressing to DHCP.
Laptop statically configured as 10.10.10.10
|
v
DHCP introduced into the lab
|
v
Laptop receives 10.10.10.126 from Raspberry Pi DHCP Server
|
v
DHCP Snooping learns 0000.5e00.5342 is associated with 10.10.10.126
|
v
Old static configuration remains on laptop.The Resolution
Once I identified the stale static configuration, I removed it and allowed the laptop to obtain it's IP address normally through DHCP. This brought the endpoint's actual configuration back into agreement with the DHCP Snooping binding used by DAI.
After removing the static configuration, I renewed the lease, and verified the binding:
show ip dhcp snooping bindingI confirmed that the repeated DAI violations stopped and normal connectivity returned.
