Consider the following topology:
Nothing fancy is going on here. Nexus 5000s have 3 downstream (south-facing?) vPC links and a redundant vPC peer-link. The management interface on each Nexus is doing peer-keepalive duty through a management switch.
My previous builds have been somewhat paranoid about redundancy of the peer-keepalive traffic, but I no longer believe that's helpful, and I'll be doing keepalive over the non-redundant mgmt0 interface going forward.
Each Nexus knows to bring up its vPC link members because the peer-link is up, so the activity can be coordinated between chassis. If the peer-link fails each Nexus pair can still coordinate their vPC forwarding behavior by communicating each other's state over the peer-keepalive management network.
If a management link (or the whole management switch) were to fail, then no problem. It's the state-only backup to the peer-link, and not required to forward traffic.
If a whole Nexus switch fails, the surviving peer will detect the complete failure of his neighbor, and continue forwarding traffic for the vPC normally.
When the failed Nexus comes back up, he waits until he's established communication with the survivor before bringing up the vPC member links, because it wouldn't be safe to bring up aggregate link members without knowing what the peer chassis is doing.
...And that brings us to the interesting failure scenario: Imagine that a power outage strikes both Nexus 5Ks, but only one of them comes back up. The lone chassis can't reach his peer over the peer link or the peer-keepalive link. He's got no way of knowing whether it's safe to bring up the vPC member links, so they stay down.
If this happened to me in production, I'd probably do two things to bring it back online:
- Take steps to ensure the failed box can't come back to life. How do you kill a zombie switch, anyway?
- Remove the vpc statement from each vPC port channel interface
Nortel had a similar problem with their RSMLT mechanism, but that deadlock centered around keeping track of who owns the first-hop gateway address (not HSRP/VRRP/GLBP). They solved it by recording responsibility for the gateway address into NVRAM (flash? spinning rust? wherever it is that Nortel records such things).