3750 stack member reload causing vPC down on N7K

ERIK LAWAETZ · ‎08-23-2010

Scenario:

- 3750 stack with two switches

- each 3750 has an uplink to a different N7K

- two N7Ks running vPC towards the 3750 stack

When Master in 3750 stack reloads failover occurs to the member switch as expected.

When that occurs the N7K with the link to the new Master logs:

2010 Aug 23 10:04:39 SR-dce2-1-vdc2 %ETHPORT-3-IF_ERROR_VLANS_SUSPENDED: VLANs 931,999,2001-2002,2008,2606,2715-2717 on Interface port-channel43 are being suspended. (Reason: vpc port channel mis-config due to vpc links in the 2 switches connected to different par
tners)

It would seem that the two N7Ks do not agree on the ID of the switch on that vPC, despite the fact that only one N7K has an active link in that vPC, and we end up in a deadlock, where the entire stack is effectively down, since all VLANs are disabled on the only available uplink by the N7K.

Is this caused by the bridge ID of the 3750 stack changing when the new master is elected?

Would "stack-mac persistent" solve that or is there a way to circumvent/recover this state?

Atif Awan · ‎08-23-2010

Yes this is most probably caused by the change in system mac address on master failure. You can work around this by configuring the 'stack-mac persistent timer 0' command and re-test.

Atif

Simon Brooks · ‎10-19-2011

I am seeing the same issue on a Nexus 5000 but I do have the stack-mac persistent timer 0 already configured but this did not prevent the problem happenning, I have however found this:

http://packetized.wordpress.com/2011/03/26/nexus-7k-vpc-and-3750x-stacks-vpc-failure-on-reboot/#comment-32

What are your thoughts?

Simon