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 _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
