Rapid Spanning Tree Configuration

In a previous lesson, I explained the differences between classic and rapid spanning tree and how rapid spanning tree works. If you haven’t seen it before, I would recommend looking at it first before diving into the configuration.

Having said that, let’s look at the configuration. This is the topology that I will use:

SW1 will be the root bridge in my example. I’m using three switches running Cisco IOS XE 17.18 (IOL). First, we have to enable rapid spanning tree:

SW1(config)#spanning-tree mode rapid-pvst
Warning: Changing STP mode can disrupt the traffic and make system unstable
Recommend to change STP mode only during maintenance window

SW2(config)#spanning-tree mode rapid-pvst
Warning: Changing STP mode can disrupt the traffic and make system unstable
Recommend to change STP mode only during maintenance window

SW3(config)#spanning-tree mode rapid-pvst
Warning: Changing STP mode can disrupt the traffic and make system unstable
Recommend to change STP mode only during maintenance window

That’s it…just one command will enable rapid spanning tree on our switches. The implementation of rapid spanning tree is rapid-pvst. We are calculating a rapid spanning tree for each VLAN. These IOL switches run rapid-pvst by default, so I started them in PVST mode to show this command.

Sync Mechanism

First, I want to show you the sync mechanism. Let’s shut the interfaces on SW1 and the interfaces on SW2 and SW3 that connect to SW1:

SW1(config)#interface Ethernet0/1
SW1(config-if)#shutdown
SW1(config-if)#interface Ethernet0/3
SW1(config-if)#shutdown

SW2(config)#interface Ethernet0/1
SW2(config-if)#shutdown

SW3(config)#interface Ethernet0/1
SW3(config-if)#shutdown

To see things in action, we’ll enable a debug:

SW1#debug spanning-tree events 
Spanning Tree event debugging is on

SW2#debug spanning-tree events 
Spanning Tree event debugging is on

SW3#debug spanning-tree events 
Spanning Tree event debugging is on

Now I will enable the link between SW1 and SW2, so on both ends:

SW1(config)#interface Ethernet0/1
SW1(config-if)#no shutdown

SW2(config)#interface Ethernet0/1
SW2(config-if)#no shutdown

Here’s what we see:

SW1#
setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.d800
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
RSTP(1): transmitting a proposal on Et0/1

The Et0/1 interface on SW1 will be blocked and it’ll send a proposal to SW2.

SW2#
RSTP(1): initializing port Et0/1
RSTP(1): Et0/1 is now designated
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): transmitting a proposal on Et0/1
RSTP(1): updt roles, received superior bpdu on Et0/1 
RSTP(1): Et0/1 is now root port

SW2 thought it was the root bridge, so it set its Et0/1 port as designated. However, it received a superior BPDU on this interface. Thus, it no longer considers itself as the root bridge and changes the role of Et0/1 to the root port. The Et0/2 interface on SW2 will now go into sync mode:

SW2#
RSTP(1): syncing port Et0/2

This is the interface that connects to SW3. SW2 will respond to SW1 by sending an agreement:

SW2#
RSTP(1): synced Et0/1
RSTP(1): starting topology change timer for 35 seconds
STP[1]: Generating TC trap for port Ethernet0/1
RSTP(1): transmitting an agreement on Et0/1 as a response to a proposal

We can see this on SW1 as well:

SW1#
RSTP(1): received an agreement on Et0/1
RSTP(1): starting topology change timer for 35 seconds
RSTP(1): starting topology change timer for 35 seconds
STP[1]: Generating TC trap for port Ethernet0/1
%LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up

SW1 receives the agreement from SW2 and interface Et0/1 will go into forwarding. SW2 will also send a proposal to SW3:

SW2#
RSTP(1): transmitting a proposal on Et0/2

When SW3 receives it, it will send an agreement:

SW3#
RSTP(1): updt roles, received superior bpdu on Et0/2 
RSTP(1): synced Et0/2
RSTP(1): starting topology change timer for 35 seconds
RSTP(1): transmitting an agreement on Et0/2 as a response to a proposal

SW2 receives the agreement from SW3:

SW2#
RSTP(1): received an agreement on Et0/2
%LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up

SW2 receives the agreement from SW3, and the interface will go into forwarding. That’s all there is to it…a quick number of handshakes, and the interfaces will move to forwarding without the use of any timers.

Port States

Let’s continue. I’m going to enable the link between SW1 and SW3 so that connectivity is fully restored:

SW1(config)#interface Ethernet0/3
SW1(config-if)#no shutdown

SW3(config)#interface Ethernet0/1
SW3(config-if)#no shutdown

Let’s look at an overview:

SW1#show spanning-tree

VLAN0001
  Spanning tree enabled protocol rstp
  Root ID    Priority    32769
             Address     aabb.cc00.d800
             This bridge is the root
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     aabb.cc00.d800
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Desg FWD 100       128.2    P2p 
Et0/3               Desg FWD 100       128.4    P2p

We can verify that SW1 is the root bridge. This show command also reveals that we are running rapid spanning tree. Note that the link type is p2p. This is because my Ethernet interfaces are in full duplex. Let’s run the same command on the other two switches:

SW2#show spanning-tree

VLAN0001
  Spanning tree enabled protocol rstp
  Root ID    Priority    32769
             Address     aabb.cc00.d800
             Cost        100
             Port        2 (Ethernet0/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     aabb.cc00.d900
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Root FWD 100       128.2    P2p 
Et0/2               Desg FWD 100       128.3    P2p

SW3#show spanning-tree

VLAN0001
  Spanning tree enabled protocol rstp
  Root ID    Priority    32769
             Address     aabb.cc00.d800
             Cost        100
             Port        2 (Ethernet0/1)
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec

  Bridge ID  Priority    32769  (priority 32768 sys-id-ext 1)
             Address     aabb.cc00.da00
             Hello Time   2 sec  Max Age 20 sec  Forward Delay 15 sec
             Aging Time  300 sec

Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Root FWD 100       128.2    P2p 
Et0/2               Altn BLK 100       128.3    P2p

Here are SW2 and SW3. Nothing new here. It’s the same information as classic spanning tree. Here’s what the topology looks like now:

Let’s add another link between SW2 and SW3 to see if this influences our topology:

SW2#show spanning-tree | begin Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Root FWD 100       128.2    P2p 
Et0/2               Desg FWD 100       128.3    P2p 
Et0/3               Desg FWD 100       128.4    P2p

SW3#show spanning-tree | begin Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Root FWD 100       128.2    P2p 
Et0/2               Altn BLK 100       128.3    P2p 
Et0/3               Altn BLK 100       128.4    P2p

Nothing spectacular, we just have another designated port on SW2 and another alternate port on SW3. Let me add that alternate port to the topology:

So far, the topology with rapid spanning tree looks the same as with classic spanning tree. Now let me show you something you haven’t seen before. I will add a hub between SW2 and SW3:

In my lab, the hub is an unmanaged switch in hub mode, which floods every frame out of all its other interfaces. A real hub also forces the switch interfaces into half duplex, and the switch then treats the link as shared. My virtual interfaces stay in full duplex, so I’ll set the link type myself:

SW2(config)#interface range Ethernet0/2 - 3
SW2(config-if-range)#spanning-tree link-type shared

SW3(config)#interface range Ethernet0/2 - 3
SW3(config-if-range)#spanning-tree link-type shared

Now take a look again at the interfaces:

SW2#show spanning-tree | begin Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Root FWD 100       128.2    P2p 
Et0/2               Desg FWD 100       128.3    Shr 
Et0/3               Back BLK 100       128.4    Shr

SW3#show spanning-tree | begin Interface
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Et0/1               Root FWD 100       128.2    P2p 
Et0/2               Altn BLK 100       128.3    Shr 
Et0/3               Altn BLK 100       128.4    Shr

Here’s something new. SW2 has a backup port. Because of the hub in the middle, SW2 hears its own BPDUs: the BPDU it sends on Et0/2 comes back in on Et0/3. SW3 doesn’t send any BPDUs on this segment, but it hears the BPDUs from SW2, and that’s what makes its ports alternate.

You can also see that the link type is shr (shared). On real hardware, that’s because the hub causes these switches to switch their interfaces to half duplex. In my lab, it’s because of the command I just used. Here’s the topology picture again:

You probably won’t ever see the backup port on a production network since hubs are scarce now, but if you see it, you’ll know why…

BPDU

BPDUs are sent every two seconds (hello time), and if you want to prove this, you can take a look at a debug:

SW2#debug spanning-tree bpdu
Spanning Tree BPDU debugging is on

You can use the debug spanning-tree bpdu command to view BPDUs that are sent or received.

SW2#
STP: VLAN0001 rx BPDU: config protocol = rstp, packet from Ethernet0/1  , linktype IEEE_SPANNING , enctype 2, encsize 17 
STP: enc  1 80 C2  0  0  0 AA BB CC  0 D8 10  0 27 42 42  3 
STP: Data      0 0 2 23C80 1AABBCC 0D8 0 0 0 0 080 1AABBCC 0D8 080 2 0 014 0 2 0 F 0
STP: VLAN0001 Et0/1: 0 0  2  2 3C 80 1AABBCC 0D8 0  0 0 0 0 80 1AABBCC 0D8 0 80 2  0 0 14 0  2 0  F 0
RSTP(1): Et0/1 repeated msg
RSTP(1): Et0/1 rcvd info remaining 6
RSTP(1): sending BPDU out Et0/2STP: pak->vlan_id: 1 

STP: VLAN0001 rx BPDU: config protocol = rstp, packet from Ethernet0/3  , linktype IEEE_SPANNING , enctype 2, encsize 17 
STP: enc  1 80 C2  0  0  0 AA BB CC  0 D9 20  0 27 42 42  3 
STP: Data      0 0 2 23C80 1AABBCC 0D8 0 0 0 06480 1AABBCC 0D9 080 3 1 014 0 2 0 F 0
STP: VLAN0001 Et0/3: 0 0  2  2 3C 80 1AABBCC 0D8 0  0 0 064 80 1AABBCC 0D9 0 80 3  1 0 14 0  2 0  F 0
RSTP(1): Et0/3 repeated msg
RSTP(1): Et0/3 rcvd info remaining 6STP: pak->vlan_id: 1 

You will see the contents of the BPDU above. It’s not very useful if you want to know the content of the BPDU, but it does show us that SW2 is receiving BPDUs on Et0/1 and sending them on Et0/2, its designated port. Because of the hub, the same BPDU comes back in on Et0/3, with the MAC address of SW2 as the source.

Packet Capture: Spanning Tree BPDU

Link Failures

Let’s get rid of the hub and the second link between SW2 and SW3:

SW2(config)#interface range Ethernet0/2 - 3
SW2(config-if-range)#no spanning-tree link-type shared
SW2(config-if-range)#interface Ethernet0/3
SW2(config-if)#shutdown

SW3(config)#interface range Ethernet0/2 - 3
SW3(config-if-range)#no spanning-tree link-type shared
SW3(config-if-range)#interface Ethernet0/3
SW3(config-if)#shutdown

Now let’s do something else…I will simulate a link failure between SW1 and SW3 to see how rapid spanning tree deals with this.

First, I’m going to shut both ends of this link, the Et0/3 interface on SW1 and the Et0/1 interface on SW3:

SW1(config)#interface Ethernet0/3
SW1(config-if)#shutdown

SW3(config)#interface Ethernet0/1
SW3(config-if)#shutdown

You’ll see this on SW3:

SW3#
RSTP(1): updt roles, root port Et0/1 going down
RSTP(1): Et0/2 is now root port
RSTP(1): starting topology change timer for 35 seconds
STP[1]: Generating TC trap for port Ethernet0/2
%LINK-5-CHANGED: Interface Ethernet0/1, changed state to administratively down
%LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to down

SW3 realized something is wrong with the root port almost immediately and will change the Et0/2 interface from alternate port to root port. This is the equivalent of UplinkFast for classic spanning tree but it’s enabled by default for rapid spanning tree.