sporadic arp issue with C5

[Robert_J]

in our network with a C5 as a Core Router, we see sporadic connectivity loss of some hosts.
These hosts are reachable from the same vlan, but from other vlans, they are not.
If I ping from the C5 Router to these hosts, they are reachable from all other vlan again.
If we wait longer, these hosts get reachable after some time ( abaut 5-30 min) again.
It seems, that this is an arp issue on the C5 Router. The Router arp has still the entry of the host.
But the Switch has no more mac entry in his Mac table, and the C5-switch does no arp request to renew this hosts mac entry.

Fw:06.71.05.0008

Any idea ?

[Robert_J]

Hello, on our last testing session now we found the reason for dropping arp and routed packets. As we are using streaming ip tv channels with more than 100 Mbit of total multicast , the securestack series have a built in hw limit for traffic going to the Switch cpu.
Although you see no dramatically high cpu rate (we had about 6%), packets are dropped over this built in limit. The only thing we could do in our case is to prioritize all the traffic to the router-mac to cos 4 with a policy and bind the policy to the physical ports of the switch.Unfortunally, policies dont work with lag port.

set policy rule 1 macdest xx-xx-xx-xx-xx-xx mask 48 cos 4
set policy port ge.*.* 1

you can troubleshoot your switch failures with this unknown commands ,

dev ipForwardStatsReset
dev ipForwardStatsShow

dev rxStats

dev osapiDebugMsgQueuePrint (be carefull)

.....
ipMap_ARP_Queue ........... failures counters

Regards

Robert

[Paul_Poyant]

Thank you for the reality check, Robert!
It is true that the stated solution did not work in this particular instance.
The original case was escalated as of August 28 2015, and the escalation is still active.

Since there are links between the escalation, the GTAC Knowledge article, and this Hub thread; I expect that the end result of the escalation will cascade accordingly for overall visibility. But in the meantime feel free to request a periodic escalation status report as needed.

[Robert_J]

Our case is still in progress. Any changing of arp or sat timers did not solved the problem.

[Paul_Poyant]

Thanks for the reminder, Sebastian!

This was diagnosed to be a Quiet Node issue as more typically seen with printers. The resolution is to change the ARP cache timeout to be less than the SAT age timeout.
See new GTAC Knowledge article "Securestack will not route to some quiet clients".