[c-nsp] Quad Sup6t 6807, ARP issue.

[Sander Steffann]

Hi Hefin,

> Not getting much luck via our support provider on this one.
> We are seeing ARP packets being dropped within the VSS for some ARP packets. (We still have single connected sites to the VSS, hence the need for Quad Sup6T's)
> Some ARP requests are arriving on one chassis within the VSS, and are not being broadcast on the other chassis, resulting in the obvious communication loss.
> Manually adding the ARP entry statically to the problem system, and communication is restored.
> 
> We are currently running IOS 15.4(1)SY2, which is fairly recent, and the 4 VSS links are connected on the Sup6T's with each Sup6T connecting to both Sup6T's on the other Chassis. There is a bug reported as CSCve73632 which doesn't list our current IOS version as being affected, but we've already upgraded from 15.3(1)SY1 due to this issue. I don't want to upgrade again, only to find that the issue is still there.
> 
> Anybody else on this list see this or have had experience of it?

Not exactly like this (mine was a VPLS+VSS problem), but in the past I have experienced that ARP learning in VSS seems to depend on one or more graceful failover settings. IIRC it depends on whether the non-active supervisor is in passive or standby mode, and that depends (apparently) on graceful failover settings. In VSS clusters where the supervisors were in ACTIVE/PASSIVE mode the passive supervisor would not learn MAC addresses, but when they are in ACTIVE/STANDBY mode the standby supervisor does learn them.

Might be worth a try.

Cheers,
Sander