Руководство По Проектированию для Cisco Cisco Nexus 5010 Switch

 

 

© 2015 Cisco and/or its affiliates. All rights reserved. This document is Cisco Public Information. 

Page 46 of 119 

To reduce the traffic loss for single-attached devices (which may be attached to the vPC primary device), you may 

want to tune the peer keepalive timer as follows: 

nexus5500-1(config-vpc-domain)# peer-keepalive destination <destination IP> 
interval <ms> 

When two vPC peers become completely disconnected, they cannot synchronize either unicast or multicast MAC 

address entries. This lack of synchronization can cause flooding for unicast traffic and traffic drops for multicast 

traffic. 

To reduce traffic loss when two vPC peers are disconnected, the peer keepalive connection is used by the vPC 

peers. If the peer link is missing and the peer keepalive connectivity is still present, the vPC primary switch keeps 

the vPCs active, while the vPC secondary switch shuts down the vPC member ports. This approach helps ensure 

uninterrupted traffic connectivity across the vPC primary switch path. 

If both the vPC peer link and peer keepalive become disconnected, all vPCs are kept active because this failure is 

undistinguishable from the loss of a vPC peer. 

This scenario works fine in double-sided vPC topologies, but it can introduce loops in designs like the one shown in 

Figure 2.In addition, spanning-tree disputes can occur in this particular design when both the peer link and the peer 

keepalive are absent. 

A particular case of a split-brain scenario occurs when the peer keepalive connectivity disappears, and afterwards 

the vPC peers are reloaded. 

Initially when peer keepalive connectivity disappears, vPC keeps functioning, because the keepalive is not strictly 

necessary for the correct forwarding of frames in a vPC topology. 

If the vPCs peers then subsequently reload, when they become active, the lack of peer keepalive connectivity 

prevents the vPC domain from forming. This scenario would keep the vPC ports down, unless autorecovery is 

configured. 

In this particular case, if autorecovery is configured, the vPC peers bring up their vPC ports, without bringing up the 

vPC peer link. The result is a split-brain scenario, which can cause loops and spanning-tree disputes as described 

in the previous section. 

The Ethernet PortChannel capability allows links to be bundled to form a single entity if certain compatibility 

conditions are met. The following is a list of conditions that are verified before ports can form a regular PortChannel 

(this list refers to regular PortChannels, not vPCs). Members must: 

● 

Have the same port mode configured 

● 

Have the same speed configured; if they are configured with speed set to automatic, they have to negotiate 

the same speed when they become active, and if a member negotiates a different speed, it will be 

suspended 

● 

Have the same MTU value configured