vPC is often used in the aggregation layer. Member ports are generally to either the access layer or connected devices. Uplinks from the aggregation layer to the core are generally routed ports.
So what would happen if a module with core uplinks were to fail? Links to the core on this switch would be unavailable. This peer would need to use the peer-link to forward traffic via an alternate path.
Now, imagine that the scenario gets worse. The peer-link ports are also on the failed module. This also happens to be the primary switch. The secondary will see a peer-link failure, and disable its ports to prevent loops. The secondary will not forward traffic, and the primary has no live ports to the core. Traffic is now blackholed.
One method to deal with this kind of failure is vPC object tracking. This enables the switches to track ports, and make decisions based on their status. In the scenario above, the core uplinks failed. This would trigger the secondary to transition to the primary role. The switch with the failed core ports will now be secondary, and will disable its member ports. The new primary will still forward traffic.
This works by using Boolean OR rules in tracking. Boolean AND rules are not supported. The peer-link and core uplinks are all tracked. If there's a port failure, the vPC secondary transitions to primary.
When using HSRP or VRRP, avoid using object tracking.
The configuration needs to match on both vPC peers.
! Track the vpc peer link track 1 interface port-channel11 line-protocol ! Track the uplinks to the core track 2 interface Ethernet1/1 line-protocol track 3 interface Ethernet1/2 line-protocol ! Combine all tracked objects into one. ! “OR” means if ALL objects are down, this object will go down ! ==> we have lost all connectivity to the L3 core and the peer link track 10 list boolean OR object 1 object 2 object 3 ! If object 10 goes down on the primary vPC peer, ! system will switch over to other vPC peer and disable all local vPCs vpc domain 1 track 10
Last update 2017-08-29 09:06