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.

 

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

 

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

 

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

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.

 

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:

 

 

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.

 

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

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

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

 

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.

 

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

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:

 

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

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).