Each spanning-tree enabled switch has a unique Bridge ID. This bridge ID is embedded in each BPDU frame and sent to connected switches. A unique MAC address in the switch is used to create a unique bridge ID. Every spanning-tree switch, therefore, is unique.

Then vPC moves in and changes everything. vPC switches are to be ‘seen’ as a single switch to vPC connected devices. It does this by using the system MAC to generate the bridge ID. As both switches share the same system MAC, they will share the same bridge ID. Devices that are not connected to vPC ports (orphan devices), will get normal BPDU’s. These BPDU’s contain the switch’s real bridge ID, based on a real MAC address.

By default, only the primary switch will send BPDU’s to vPC member ports. In fact, the secondary won’t process BPDU’s at all. If it receives a BPDU, it will forward it across the peer-link for the primary switch to process.

The default behaviour can be optimised with the peer-switch command. Using this command enables both the peer switches to send and process BPDU’s. Both switches will continue to use the same bridge ID, based on the System MAC.

One advantage to this is that there is less traffic loss during a peer-link restoration. Also, if there is a dual-active scenario, both switches process BPDU’s. This aids switching loop prevention. Finally, if there is a primary/secondary switchover, this will reduce BPDU loss.

Spanning-tree BPDU’s are a one-way process. That is, a switch will send BPDU’s to announce itself, but it does not expect a response. Bridge Assurance modifies this behaviour by enabling two-way BPDU communication. All operational ports, including those in an alternate or backup state, will send BPDUs.

The purpose of this is to detect unidirectional link failures or malfunctioning switches. If BPDU’s are not returned, spanning-tree will put the port into the BA-Inconsistent state. This port now blocks traffic.

Bridge Assurance is enabled automatically on the peer-link. This is because the peer-link ports are spanning tree network ports by default. All network ports automatically use Bridge Assurance. Do not disable Bridge Assurance on the vPC peer-link.

Bridge Assurance can be disabled on any member ports that connect to end devices. Don’t disable it for back-to-back vPC’s, or connections to any other switches.

A hybrid topology is where a switch connects to a vPC domain on orphan ports. One possible reason for this is that it does not support port channels.

An example of this is seen in this diagram:

There are two vPC Nexus peers. Two other switches are attached; One as a vPC member, and one connected without vPC. The Nexus switches will see the regular switch ports as orphan ports. Each link on the regular switch is just a normal trunk link, with no port channels or LAGs.

There are two main points to take note of here. First, the vPC member switch will receive BPDU’s from the regular switch and the primary Nexus switch. If the peer-switch command is enabled, BPDU’s will come from both primary and secondary. The bridge ID from the Nexus switches uses the System MAC.

The second point is that the regular switch will get BPDU’s from both Nexus switches. This will happen regardless of the peer-switch configuration. The Bridge ID’s from the Nexus switches use real (and unique) MAC address from each switch.

Cisco’s best practice in this situation is still to use the peer-switch command.

Load balancing with spanning tree uses different root bridges for different VLANs. This doesn’t balance traffic as evenly as vPC but is better than having wasted links.

Spanning-tree configuration on vPC peer switches needs to be identical. So how is load balancing achieved when a non-vPC switch is attached? The answer is with the spanning-tree pseudo-information command. This command modifies the bridge priority in BPDU’s sent to the regular switch. It will appear that one peer switch has a higher priority than another for a particular VLAN. This is set per-VLAN, allowing VLANs to be load balanced across the switches.

The most important thing to remember is that vPC does not replace spanning-tree. Don’t disable spanning-tree. Love it or hate it, you need it in your network. What happens if someone connects a rogue switch to your network and causes a loop? Or there’s a mistake in cabling? Or there’s a double peer link and keep alive link failure? This is where spanning-tree will be your friend.

The next thing is the spanning-tree flavour. The Nexus platform supports Rapid-PVST+ and MST. It’s best to use the same spanning-tree flavour across the entire network if possible. Also, the vPC switch pairs should be the root bridges in the spanning tree domain. What if you really want some other switches to be the root bridges? Then consider using routing to break the network into blocks or layer-2 domains.

If you want to use vPC across data centre DCI links, enable BPDU filter on these links. This disables spanning tree between the data centres. The reason for this is to limit the scope of the spanning-tree domain. This will create a spanning tree domain per data centre, rather than having one large domain. Imagine if you had one large domain. The root bridge may be in the data centre causing some traffic to cross the DCI links. Not quite optimal is it? Just remember that this topology is only suitable for connecting up to two data centres.