Hello everyone,
this post is not so much a question as an exchange of knowledge and experience about an issue we had with device tracking.
We were having issues on our network that sometimes, not reproducibly, connections between endpoint and server was droped on the L3 firewall because the firewall was not receiving an ARP response from the endpoint. ARP time-out on FW is 30 minutes.
It turned out that the ARP transaction between FW and endpoint on our L2 Core switch was dropped due to control plane policing because it was not deactivated on the ISL´s as it should be.
With device tracking, the switch does not process the ARP in hardware, but in the CPU, which caused control-plane-policing to discard about 15% of the ARP packets -> we never modified the CPP policy, so it is default.
The solution in this case was to disable device tracking on the uplinks.
Took us some time to find out what was happening so I thought it might also be an interesting share for everybody.
---- Example from our Coreswitch ---- (this class is indicating ARP drops based on Dynamic ARP Inspection (DAI))
Class-map: system-cpp-police-protocol-snooping (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: none
police:
rate 2000 pps, burst 488 packets
conformed 12577582267214 bytes; actions:
transmit
exceeded 9492998411294 bytes; actions:
drop
best regards,
steffen
