sporadic arp issue with C5

  • 0
  • 2
  • Question
  • Updated 2 years ago
  • Answered
  • (Edited)
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 ?
Photo of Robert_J

Robert_J

  • 150 Points 100 badge 2x thumb

Posted 3 years ago

  • 0
  • 2
Photo of Paul Poyant

Paul Poyant, Employee

  • 3,516 Points 3k badge 2x thumb
This issue is being troubleshot in GTAC Support case 1144194, since yesterday.
Photo of Sebastian Mueller

Sebastian Mueller

  • 62 Points
Anyupdate on this case? I do have the same issue here with two newly deployed c5 core.
Photo of Paul Poyant

Paul Poyant, Employee

  • 3,516 Points 3k badge 2x thumb
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".
(Edited)
Photo of Robert_J

Robert_J

  • 150 Points 100 badge 2x thumb
Our case is still in progress. Any changing of arp or sat timers did not solved the problem.
Photo of Paul Poyant

Paul Poyant, Employee

  • 3,516 Points 3k badge 2x thumb
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.
Photo of Robert_J

Robert_J

  • 150 Points 100 badge 2x thumb
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