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

 

 

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

Page 11 of 119 

The peer switch feature in Cisco NX-OS changes this behavior. A vPC peer switch is useful exclusively in a vPC 

domain that is configured as a root in the spanning-tree topology because it reduces the convergence time needed 

when a vPC peer is reloaded. At the time of this writing, this feature is not available in Cisco NX-OS 5.1(3)N1(1) for 

the Cisco Nexus 5000 Series because in most topologies a Cisco Nexus 5000 Series device is not the root in the 

vPC topology. 

The recommended spanning-tree configuration in preparation for a vPC deployment is summarized here: 

● 

Choose the spanning-tree algorithm (this algorithm normally has already been chosen when the 

aggregation layer is deployed). Remember that the MST Protocol scales better, and the Rapid per-VSAN 

Spanning Tree Plus (PVST+) Protocol may be easier to deploy, vPC deployment brings no real additional 

benefit over deploying one separate topology per VLAN. 

● 

In most deployments, you should not modify the priorities on Cisco Nexus 5000 Series Switches deployed 

at the access layer. 

● 

Enable spanning-tree pathcost method long to account for the use of 10 Gigabit Ethernet links. 

● 

Host ports can be configured for BPDU filtering to reduce the spanning-tree load, but this recommendation 

applies mainly to the Gigabit Ethernet ports on the fabric extender. 

● 

The Bridge Assurance feature should not be enabled on the vPC member ports. Bridge Assurance does not 

add much benefit in a PortChannel-based configuration, and it may intervene in certain vPC failure 

scenarios in which it is actually less disruptive not to error-disable any port. Also, if you want to take 

advantage of In Service Software Upgrade (ISSU) on the Cisco Nexus 5000 Series, you should not enable 

Bridge Assurance on any link except the peer link (referred to as the multichassis EtherChannel trunk [MCT] 

in the command-line interface [CLI]) on which it is automatically enabled. 

● 

Disable loop guard. In a vPC topology, loop guard does not provide any additional help, and in some failure 

scenarios it may actually slow down convergence. If an interface has been configured for loop guard, 

remove the configuration with the command (config-if)# spanning-tree guard none. 

If you are using MST, you should preprovision the region configuration at the start. VLAN creation and assignment 

to trunk links and host ports can be performed after deployment without any disruption. Region modifications 

should be limited to the deployment time to reduce the need for topology recalculations and to avoid Type 1 

inconsistencies. 

The region configuration (revision number, VLAN-to-instance mapping, etc.) should be copied from the 

aggregation-layer device configuration. 

If you are using MST, make sure that the VLAN range is identical on Cisco NX-OS devices and devices other than 

those that use Cisco NX-OS. 

In an MST and vPC deployment, VLANs are typically mapped to one instance only (you do not need two separate 
topologies when using vPC). For more information about vPC with MST, please refer to the section “MST and vPC” 

later in this chapter.