IpArp not learning IP

[GONÇALO_NUNO_CO]

Hi,

i am trying to troubleshoot why IPARP is not showing the IP addresses of edge devices.
Slot-1 SEDUCA050100.3 # sh iparp stats ports 3:23
IP ARP Port Statistics Thu Mar 8 08:55:47 2018
Port Link State Active ARP Total Dynamic Static
===============================================================================
3:23 A 0 0 0
===============================================================================If i do a "sh fdb port 3:23" i can see the mac of the connected device, but for some reason IPARP is not storing the Mac and the IP address of the connected device, this is hapenning on all ports, also and since IPARP doest not store any IP addresses, IdMgr doesnt show them too.

I have all vlan interfaces configured with an ip address and IPARP is enabled by default on the switch.

I wondering what commands can i use to troubleshoot this situation.

Br,
Gonçalo Reis

[M_Nees]

Unfortunately this change is currently NOT documentated - this is tested in my lab.

I have same customers with a "deny all" policy - at this ports after upgrade to 22.3 P-EAP (=802.1x) does not work anymore. GTAC workaround is adding these needed basic protocols into "deny all" policy (as execption - allow it) - i older version i do not care about that.

[GONÇALO_NUNO_CO]

Hi M.Nees, Where can i get that information?? also the policy i am applying is a permit all.

[M_Nees]

Compare 22.4 and 22.3 to 21.1 port related "policy framework" deny some basic protocols like EAP or ARP.

In this newer version you have to allow them if you use a deny all policy.

[GONÇALO_NUNO_CO]

I have the same configuration applied on all switches, the ones that are on 22.4.1.4 have this problem, the others dont.

[Sarah_Seidl]

We encounter what seems similar to what you are reporting from time to time (though ours is more sporadic - not all ports on all stacks). Generally it seems more prevalent if we have a power outage and then power is restored but users can't get to their precious internet  Almost like something got messed up in the boot up, even though the stack is a ring, slots all look good, fdb entries show perfectly on the switch but not consistent IPARP entries. A reboot of the entire stack generally resolves for us. We are on 460g1 models running 16.2.2.4 code (I've seen it on other code versions in our environment previously). We just had this the past weekend with wind storms after power was restored. Slot 2 wasn't acting right, so I ran a diagnostics which returned all clear. For good measure I rebooted the entire stack after diag was done. Then slot 3 was showing fdb entries but no IPARP for the end devices (the problem hopped slots!). So I individually rebooted slot 3 which got those devices back talking again. Maybe it's cliché but rebooting seems to help us in most cases.