02-28-2018 03:03 PM - edited 03-08-2019 02:04 PM
I have been working to enable DAI in my environment the past week. We have had DHCP snooping enabled for years now but we are looking to enhance our security posture. I wanted to leave a few notes to people who are trying to enable this on their switches. I have been beating my head against wall for a few days with some of this trying to nail down exactly what I'm seeing and why. While there is documentation out there to enable this feature(s) I have found that the practical part of actually deploying it has many nuances.
1. Enabling ip arp inspection validation checks increases the potential issues with end point devices that don't play well with DAI....I'm still learning on this and will update anything new I find but...Apparently a ton of different types of end points like to do a ton of gratuitous ARPing. We had logs filled with this kind of thing....
746866: Feb 27 07:55:40.174: %SW_DAI-4-INVALID_ARP: 1 Invalid ARPs (Req) on Gi1/0/48, vlan 232.([5882.a893.5acb/0.0.0.0/0000.0000.0000/10.65.64.104/07:55:39 EST Tue Feb 27 2018]) 746868: Feb 27 07:55:41.206: %SW_DAI-4-INVALID_ARP: 1 Invalid ARPs (Req) on Gi1/0/48, vlan 232.([5882.a893.5acb/0.0.0.0/0000.0000.0000/10.65.64.104/07:55:40 EST Tue Feb 27 2018])
After trading email with TAC all day they came back with adding this to the validation command, it's not been document anywhere that I can find.
ip arp inspection validate src-mac dst-mac ip allow zeros
This helped with the gratuitous ARP issues we were seeing.
2. I saw log entries for blocked/invalid ARP requests for IPs and MAC that were in the snooping binding database... What????? Example below....
750612: Feb 28 16:51:19.429: %SW_DAI-4-INVALID_ARP: 1 Invalid ARPs (Res) on Gi2/0/42, vlan 332.([001b.4f28.f793/10.66.64.105/001b.4f28.f793/10.66.64.105/16:51:18 EST Wed Feb 28 2018])
XXXXXX3750X-Acc1#sh ip dhcp sn bin | inc 2/0/42
00:1B:4F:28:F7:93 10.66.64.105 28375 dhcp-snooping 332 GigabitEthernet2/0/42
Apprently there is some time required when a new device connects to the switch for the DHCP binding database and DAI to all get in sync. I'm waiting for confirmation of this from TAC but this is what it looks like at this point.
I will add more to this as my quest continues but hopefully I'm able to spare someone some of the pain I have had.
11-30-2019 06:39 PM
Having the same issue as #2.
"entries for blocked/invalid ARP requests for IPs and MAC that were in the snooping binding database"
Did you ever get this resolved? What was the fix?
Thanks
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide