Skip to content

Cisco Nexus vPC - Part 4 - Timers

In the last part we looked at the vPC peer priorities.

Now, we are going to look at the many timers and how they can come in handy for preventing issues with vPC and network convergence.

This is still our topology:

Image

The configuration on the switches has not changed.

When we issue the show vpc brief command, we see lots of information about timers:

VPC-1# show vpc brief 
Legend:
                (*) - local vPC is down, forwarding via vPC peer-link

vPC domain id                     : 100 
Peer status                       : peer adjacency formed ok      
vPC keep-alive status             : peer is alive                 
Configuration consistency status  : success 
Per-vlan consistency status       : success                       
Type-2 consistency status         : success 
vPC role                          : secondary                     
Number of vPCs configured         : 1   
Peer Gateway                      : Disabled
Dual-active excluded VLANs        : -
Graceful Consistency Check        : Enabled
Auto-recovery status              : Disabled
Delay-restore status              : Timer is off.(timeout = 30s)
Delay-restore SVI status          : Timer is off.(timeout = 10s)
Delay-restore Orphan-port status  : Timer is off.(timeout = 0s)
Operational Layer3 Peer-router    : Disabled
Virtual-peerlink mode             : Disabled

These are the ones seen by default. We have:

  • Auto-recovery
  • Delay-restore
  • Delay-restore SVI
  • Delay-restore Orphan-port

All of these timers have their use to prevent issues when the vPC peers converge. We have seen the suspendByVPC status on vPC interfaces in previous sections, this is the switches way of holding the links down in the event of an issue. However, we can intentionally hold interfaces down for longer if we deem necessary.

Lets run through each timer and explain what it does, and when we might find it comes in useful:

Auto-recovery

This was one we went through in Part 2 where we looked at common failure scenarios. This timer is set at 240s by default and will only trigger when the switch cannot see the peer and it assumes its dead. Once the timer expires, the switch allows itself to put its VPCs into service as it assumes the other switch is non-operational. This timer can either trigger post-boot or if this scenario happens during operation. The timer allows the peer switch to respond or come back up, before the local switch takes action.

Delay-restore

This is a generic timer that delays the VPCs being brought up to allow any Layer 3 routing protocols to converge. Failure to do this, can blackhole traffic coming from downstream devices if the links come up immediately, this gives the switch no time to for example get all the NLRI from a BGP peer. The default timer for this is 30s.

Delay-restore SVI

This timer delays the SVI interfaces, and is a further delay to help the device fully converge.

Delay-restore Orphan-port

We haven't touched on orphan ports yet, but in simple terms, they are interfaces which have no parent vPC interface. They may connect to a device that does not support normal port-channel technologies. We do have to tell the switch which orphan ports we would like this timer to apply to, that will come in its own part though. The purpose of this timer is again for convergence. Orphan ports by default begin forwarding immediately on a switch, even if vPC is enabled. As its seen as very low risk that could end up with any split-brain scenario. However, we have to take into account the possibility that if orphan ports come up, its upstream traffic may be blackholed if the vPC interfaces are still down. This timer prevents the orphan ports from coming up before the vPC interfaces come up. The idea being that all the VPCs are forwarding before they come up, and no traffic gets blackholed.

The reason we need to tell the switch which interfaces we want this to apply to is because some orphan ports we would want to forward immediately. Examples of these are standalone L3 interfaces to upstream routers etc. Which is the point of most of the other timers, we want these to come up first and converge all the Layer 3 protocols. It makes no sense to bring these interfaces up last.

Timer order

The timers are processed in the order they appear in the above list, so all timers are run in serial rather than parallel. For this reason, its normal for a vPC switch to take a little while before its fully in-service even if its booted up. Its worth monitoring these timers if you aren't seeing interfaces on downstream devices come up.