N2024 switch Configuring Dynamic ARP Inspection (DAI)

Sorry I would edit the above to fix the code format but it is not an option I have so 

As Coded

ip arp inspection filter DAIaclVLan1Default vlan 1
ip arp inspection validate src-mac dst-mac ip
arp access-list DAIaclVlan1Default
permit ip host 192.168.1.3 mac host ????.????.??40
exit

As Stored

ip arp inspection filter DAIaclVLan1Default vlan 1
ip arp inspection validate src-mac dst-mac ip
arp access-list DAIaclVlan1Default
permit ip host 192.168.1.3 mac host ??:??:??:??:??:40
exit

Software Version

!Current Configuration:
!System Description "Dell EMC Networking N2024, 6.7.1.22, Linux 4.14.174, Not Available"
!System Software Version 6.7.1.22

Hello,

it looks like you have a pretty complex setup going on. I think it seems like you need to power cycle the AP after the switch boots to get it to show up in the DHCP Snooping Dynamic Pool. This might be because the AP isn't sending DHCP requests right away when the switch boots. The switch hanging after enabling DAI suggests there might be a misconfiguration or a bug. Ensure your switch firmware is up to date . Let's our community can contribute

The router and switch in each VLan should not be an issue as they are on DHCP Snooping and DAI Trusted ports which according to the documentation indicates they are not checked.   As far as IPSG ALL IP/MAC address appear in either the fixed or dynamic lists for the entire network.

AngryIPscanner indicates the AP and PC devices are connected correctly even before the power cycling of the AP when the switch does not report them in the DHCP Snooping Dynanic list..  I had a similar problem when some Switch interfaces got their IP's via DHCP -- no longer the case I made them all static assigned in the device interfaces. The only devices that need to appear in the DHCP Snooping binding table are in VLan1 the AP and the PC and in Vlan2 to the PC alone.  I have a feeling that direct connected devices get their IP's before DHCP Snooping is activated so having them reacquire IP addresses after the switch boot is complete is required for DHCP Snooping to see the entries OR the fact they already have valid prior assigned DHCP IP addresses slips by DHCP Snooping. 

My primary concern in this message the DAI issue.  Before testing DAI as noted DHCP Snooping is checked to see the Dynamic devices are present -- in theory the  the Dynamic devices should not be a problem.

Note: the scanner limits devices actively scanned to 32 -- while this is not completing the whole block of 32 before the next 32 are released this seem to remain fairly close to that scenario.

As far as DAI the firmware for the switch is fully up to date the version is noted in the original data.  I agree there may be a misconfiguration or bug; I am looking for suggestions to help find the problem.

I have demonstrated two different scenarios using two different VLans with slightly different results.  VLan1 fails during the scan of the Router 192.168.1.1 which is one of the first devices scanned.   A note should probably be made here that the AP is at address 192.168.1.3 so it is probably being checked concurrently with the router and the switch in VLan1.  I have one idea that could possibly better isolate the device causing the problem .  If in Vlan1 the router 192.168.1.1 and switch 192.168.1.2 remain where they are.  The AP is moved to 192.168.1.127 (moving its testing roughly to the scanner group 4 and the PC is moved to 192.168.1.253 making it roughly in the 8th scanner group the problem may more clearly indicate which device is causing the problem on VLan1. Vlan2 does not fail until after the router 192.168.2.1 and switch192.168.2.2 are successfully scanned and either after or during the scan of the attached PC 192.168.2.128 or greater (which has no open ports to find the ping alone is the end of the scan results for the PC).  A similar change on VLan2 is unlikely to provide any additional information especially if in the revised VLan1 test the router and switch scan successfully before the AP is scanned well before the PC is scanned.  If the AP scan fails in VLan1 and the PC fails in VLan2 then the DAI problem will be clearly with devices in the DHCP Snooping Dynamic list and not devices on trusted interfaces.  Should I try that alternate VLan1 test?

In attempting to prepare a small file I could submit for others I made a discovery; the command "no arp inspection limit", if it works in some cases the error counts may be logged and more can be understood about the cause of the hang especially if this prevents the hang and the counts can be inspected.  Maybe by mid day I will have an answer for that.

Another question I may have hidden is what exactly is logging in the case of DHCP Snooping and DAI -- updating counts (relatively safe in terms of a hang except possibly due to overflow) or possibly filling files that could cause a hang?

This will not affect the problem of not being able to add IPs and MAC addresses to DAI ACLs.  That is a constraint I that may become an issue in the future.

Meaning the only valid setup I can achieve is to either have devices on trusted interfaces or to assure devices with DHCP assigned IP addresses appear in the DHCP Snooping Dynamic list (at this time this is appears to be a workable requirement for my design).

Lets hope that "no arp inspection limit" will eliminate the issue as the IP scanner by it's every nature generates large numbers of "invalid" packets for devices that do not exist and ports not open on devices.

Managed an early test of "ip arp inspection limit none" which appears to be the same as "no arp inspection limit".  I applied it to the Gi1/0/11 interface where the PC was performing the scan.  I should I consider applying this to the trusted interfaces (I believe I read this is not required)?

VLan 2 scanned successfully  the stats were 1786 DHCP permits and 1786 passed and the results were the desired results.

I switched to testing VLan1.  Checked those stats before enabling DAI on VLan1 -- there were a few stats present even before DAI was enabled which is curious but not fatal.  The scan of VLan1 did not display the server or router and it disconnected after scanning the PC.  BUT the entire switch did not hang -- I got in using VLan 2 and could see the stats for Vlans 1 & 2.  There were about 3000+ DHCP Drops on VLan1 (where the DHCP server is on the switch).  I have some things to investigate.  Also the switch may be hanging slowly.  DHCP seems to be working for all VLans but  VLan1 may have lost server/router access near the end of the scan.  VLan2 seems to have done the same after inquiring the statistics.  Got back in again using VLan7.  This may not be the complete DAI solution but I have a great deal of test feedback I did not have before this.  There are some outstanding questions including how eventually to set a better limit.  But for now, I am back to doing some testing with some additional information.

Just ran a test I could not consider before probably the most extreme.  Testing VLan8 scanning all 8 VLans.  VLan1 should be dropped completely by the switch ACLS.  Everything in VLans2-8 should respond positively (this is the admin VLan).  The test ran to completion no issues including hangs or disconnects.  The results of the scan matched what was expected.  Strangely I have considerable research in the statistics question.  The stats for VLan8 were 30+ dhcp permits and 30+ forwarded.  The system consists of a router with 8 vlans a switch with 8 vlans a wireless router, and the pc for a total of 18 devices.  Ran the scan a second time without rebooting -- same positive results.  Maybe there are problems with VLan2 with such high numbers and VLan 1 clearly has problems at this time for me to find.

My hang problem in terms of testing seem to be mostly solved.

Since I cannot get the DAI ACLs to actually generate entries in the table.  I am currently testing Static IP addresses in devices that are not like wireless access points (file servers, switches, routers).  I am attaching the mac addresses to ports and vlans too.  I then plan to make the single user ports trusted DAI ports.  I believe this replaces the DAI ACL that I cannot get to work.

That last message should have said I am trusting single use ports -- with file servers not wireless access points) with known mac addresses and IP addresses.  With multiple levels of MAC validations and IPSG static entries.

@DELL-Charles R​ The customer found a work around with numerous items still not working see following documentation.