How to configure Rapid PVST+ and Etherchannels

Rapid PVST+ tuning

Although Spanning Tree is enabled by default on Cisco switches, the default behavior isn’t always what you want in a real network. STP usually needs some tuning so the root bridge and forwarding paths line up with your design.

Here’s the scenario: three switches are connected to each other with trunk links - SW1, SW2, and SW3. SW1 and SW2 are distribution switches, and SW3 is the access switch.

(Image 107)

Image Title - 3 Switches connected to each other

In this design:

• SW1 should be the Primary Root Bridge for VLAN 2 and the Secondary (backup) Root Bridge for VLAN 3.
• SW2 should be the Primary Root Bridge for VLAN 3 and the Secondary Root Bridge for VLAN 2.

That way, SW1 and SW2 back each other up if one fails.

This makes SW3 the Non-Root Bridge. For VLAN 2, SW3’s:

• Root Port should be GigabitEthernet 0/1.
• GigabitEthernet 0/2 should be an Alternate Port.

Which port on SW3 should be the Root Port for VLAN 3 traffic and which port should be the Alternate Port?

If you leave all three switches at their default STP settings, they might not converge the way you intend. With the default bridge priority on all switches, the root bridge election comes down to the switch with the lowest base MAC address.

What is the default Bridge Priority value on all Switches running STP?

Now consider what happens if SW3 has the lowest base MAC address. SW3 could become the root bridge, which is usually not what you want in a hierarchical design.

Having an access switch as the root bridge for your LAN can create bottlenecks and suboptimal traffic paths.

To prevent that, you configure SW1 and SW2 so they reliably become the root bridges for their intended VLANs.

Verify and enable Rapid PVST+

Before tuning priorities, make sure the switches are running Rapid PVST+. Some switches may still be using the legacy STP version (802.1D / PVST+) by default.

To verify the current STP mode, use:

show spanning-tree

(Image 108)

Image Title - show spanning-tree output displaying 802.1D version running

This output also shows STP information per VLAN. With Cisco Per-VLAN Spanning Tree, each VLAN runs its own STP instance.

In the output, look for the line:

• Spanning tree enabled protocol

If you see ieee, the switch is running the legacy STP mode (802.1D / PVST+). In this scenario, you want to change all three switches to Rapid PVST+.

To enable Rapid PVST+, go to global configuration mode and enter:

spanning-tree mode rapid-pvst

(Image 109)

Image Title - Configuring Rapid PVST+

If you run {`show spanning-tree`} again, you should now see the protocol listed as rstp, which indicates Rapid PVST+.

(Image 110)

Image Title - show spanning-tree output displaying Rapid PVST+ version running

This should be configured on all 3 switches.

Set root bridge priorities per VLAN

Now you can tune SW1 and SW2 so they become the intended root bridges.

• Make SW1 the Primary Root Bridge for VLAN 2 and the Secondary Root Bridge for VLAN 3.
• Make SW2 the Primary Root Bridge for VLAN 3 and the Secondary Root Bridge for VLAN 2.

On SW1, in global configuration mode, set:

spanning-tree vlan 2 priority 4096 spanning-tree vlan 3 priority 8192

On SW2, do the opposite:

spanning-tree vlan 2 priority 8192 spanning-tree vlan 3 priority 4096

Verify the result on SW1 and SW2

To check the VLAN 2 STP instance on SW1 and SW2, use:

• show spanning-tree vlan 2

This filters the output so you only see the VLAN 2 STP instance.

(Image 110)

Image Title - show spanning-tree vlan 2 output on SW1 and SW2

In the output:

• The Root ID section shows which switch is the root bridge for that VLAN.
• The Bridge ID section shows the local switch’s STP identity.

On SW1, you’ll see it declare “This bridge is the root” for VLAN 2. You’ll also notice:

• The configured priority was 4096.
• The displayed priority becomes 4098 because the System-ID Extension adds the VLAN number (here, 4096 + 2).

Because SW1 is the root bridge for VLAN 2, its active ports for that VLAN take the Designated Port role (Desg) and are in the Forwarding state (FWD).

On SW2, the Root ID shows SW1’s base MAC address as the root for VLAN 2. SW2’s Bridge ID differs from the Root ID because SW2 is not the root bridge for VLAN 2.

If you run the same check for VLAN 3, you should see the opposite behavior:

(Image 111)

Image Title - show spanning-tree vlan 3 output on SW1 and SW2

Here, SW2 is the Root Bridge for the VLAN 3 STP instance, and SW2 will declare “This bridge is the root” for VLAN 3.

Verify the result from SW3

From SW3’s perspective, the root and alternate ports should match the intended design, and SW3 should not be the root bridge for either VLAN.

(Image 111)

Image Title - show spanning-tree vlan 2 output on SW3

(Image 112)

Image Title - show spanning-tree vlan 3 output on SW3

A simpler root bridge configuration method

There’s also a simpler way to configure primary and secondary root bridges. Cisco provides commands that automatically lower the bridge priority.

On the switch you want as the Primary Root Bridge, enter in global configuration mode:

spanning-tree vlan [VLAN ID] root primary

This automatically lowers the bridge priority to 24576, which is lower than the default (32768), making it preferred.

On the switch you want as the Secondary Root Bridge, enter in global configuration mode:

spanning-tree vlan [VLAN ID] root secondary

This automatically lowers the bridge priority to 28672, which is 4096 higher than the primary value. That makes it less preferred than the primary, but still preferred over a default-priority switch.

Configuring Etherchannels

Now consider a scenario where two switches have redundant links between them, and you need to configure an LACP EtherChannel. In this setup:

• SW1 will be the active LACP neighbor.
• SW2 will be the passive LACP neighbor (it waits for LACP packets from SW1 to negotiate the channel).

For this example, you’ll manually create the Port-Channel interface first, then add the physical interfaces as members.

Create the Port-Channel interface

First, create the logical Port-Channel interface that will bundle the physical links. In global configuration mode:

interface port-channel 1

(Image 113)

Image Title - Creating the logical Port-Channel interface

Add member interfaces on SW1

Next, configure each member port (GigabitEthernet 0/1 and GigabitEthernet 0/2) so they join the EtherChannel.

Remember that each member of an Etherchannel must have idendical configurations, therefore, it is best to make sure that the interfaces have their default configurations.

On SW1, under both GigabitEthernet 0/1 and GigabitEthernet 0/2, add:

channel-group 1 mode active

(Image 114)

Image Title - Adding GigabitEthernet 0/1 and GigabitEthernet 0/2 as members of Po1

It is important to note that the channel-group number must match the Port-Channel interface number that we used when we created it. Otherwise, another Port-Channel interface would be created using the channel-group number that was referenced under the physical interface.

Verify EtherChannel status on SW1

To verify membership and status, run:

show etherchannel summary

(Image 115)

Image Title - Output of the show etherchannel summary command on SW1

In the output:

• The Group number matches the Port-Channel number (1).
• The Port-Channel interface appears as Po1.
• The flags show the current state.

For example, SD means:

• S: Layer 2 EtherChannel
• D: Down

At this point, it’s down because SW2 hasn’t been configured yet, so LACP hasn’t formed. Once everything is correct, you typically want to see SU.

Configure the Port-Channel as a trunk

If you want the EtherChannel to carry multiple VLANs, configure it as a trunk. After an EtherChannel is created, make configuration changes under the Port-Channel interface, and the switch replicates them to the member ports.

(Image 116)

Image Title - Configuring the Etherchannel as a Trunk on SW1

If you check the running configuration, you’ll see the trunk configuration applied to the member ports as well:

(Image 117)

Image Title - Running-Config showing member ports with the Trunk configuration

Configure SW2 (passive side)

Now configure SW2 with the same overall setup, with one key difference: the member ports use passive mode.

configure terminal

interface port-channel 1 exit

interface gigabitethernet 0/1 channel-group 1 mode passive exit

interface gigabitethernet 0/2 channel-group 1 mode passive exit

interface port-channel 1 switchport mode trunk end

Now check the EtherChannel status on SW2:

(Image 118)

Image Title - Output of the show etherchannel summary command on SW2

When the EtherChannel is up, you should see SU, and the member ports should show the P flag (in port-channel). At this point, the EtherChannel between SW1 and SW2 is successfully formed.

Troubleshooting LACP

If the LACP EtherChannel isn’t coming up, verify that LACP negotiation is working. In privileged EXEC mode, run:

show lacp neighbor

(Image 119)

Image Title - show lacp neighbor command on SW1

This command (show lacp neighbor) may not be available in the Cisco Packet Tracer software, so if you are not able to enter this command in Packet Tracer, do not worry as some commands are not available in Packet Tracer. It is available however, in real Cisco IOS images, which are used in the Cisco CML application.

If you run this on “SW1”, the output shows LACP information learned from the neighbor (SW2). One key detail is the P flag under the partner information, which indicates the neighbor is operating in passive mode. Seeing partner information at all is a strong sign that LACP packets are being exchanged and the neighborship has formed.

Also note the mode dependency:

• If both sides are passive, they won’t form an LACP EtherChannel.
• At least one side must be active (in this case, SW1).