RSTP – Fundamentals, Port States and Link Types explained IN DEPTH, configured and verified on the lab!

RSTP_Base_Top3

The following will be used for labbing RSTP, with a lot going on there, so lets hit it!

 

Fundamentals of 802.1w RSTP, similarities and difference from 802.1d STP

 

RSTP is Rapid Spanning-Tree Protocol IEEE 802.1w, the evolution of 802.1 PVST STP that we have been labbing (default STP is PVST), RSTP is also referred to in Cisco documentation as PVRSTP or Per VLAN Rapid STP.

It uses the same BID criteria to elect a Root Bridge just like STP, the same rules apply to links that if one side is in FWD the other must be BLK unless it is a Root Port, and the default Hello / BPDU origination timer default is 2 seconds in both STP and RSTP.

This is about where similarities stop, as RSTP’s Root Bridge does not originate all BPDUs.

RSTP Bridges ALL originate BPDUs or Hellos out all non-Edge, non-Alternate (Blocking) Ports to neighboring switches, and if a switch interface detects 3 missed BPDUs / Hellos from its neighboring switch, that link is considered down and the TCN BPDU is sent out again all non-Edge / non-Altn ports.

RSTP does NOT use Max-Age, as the BPDUs exchanged every Hello interval include its Hello Timer, so each switch knows when to expect the next Hello (and how long it will take 3 missed Hellos to elapse) per STP neighbor.

Edge Ports are considered to be for end points like PC’s / Servers / Phones, so when they move into Forwarding there is no TCN BPDU created and sent through the network, because no other switches need to adjust their Topology because a PC joins the network.

Much more on Edge Ports below.

To configure a switch to use RSTP, simply use the following command in global config:

SW1(config)#
SW1(config)#span mode ?
mst Multiple spanning tree mode
pvst Per-Vlan spanning tree mode
rapid-pvst Per-Vlan rapid spanning tree mode

SW1(config)#span mode rapid

If issued on a switch that is STP Enabled, it will not drop or reset any connections, it will just change the STP mode from PVST to RSTP with no hiccups.

Non-Edge Ports that move into Forwarding do trigger a TCN BPDU, which is flooded out all non-Edge Designated ports, so Discarding Ports will not flood these TCN’s either.

  • The switched network doesn’t care about Hosts on joining it on Edge Ports, so it does not get TCN’s regarding the change
  • The Host doesn’t care about the switched network, as long as it has a Loop Free path through the network, so it does not get TCN’s regarding changes
  • Blocking / Discarding ONLY Learn BPDUs, they do not send them!

 

STP vs RSTP Port States:

STP = Disabled -> Blocking -> Listening -> Learning -> Forwarding

RSTP = Discarding -> Learning -> Forwarding

RSTP Discarding state encompasses STP states Disabled / Blocking / Listening STP states by initially going into Discarding while the network synchronizes via Proposal / Agreement frames between Bridges.

Once the network synchronization is complete, Alternate paths to the Root are put into Altn / BLK state known as Discarding in RSTP, able to jump into action upon link failure almost immediately on RSTP enabled switches.

One of the very Rapid parts of RSTP is that every Bridge monitors link failure independently, so whether it is Direct or Indirect the network begins to Synchronize in 6 seconds at most by default, which can be adjusted to be even faster:

SW3(config)#span vlan 1 hello-time ?
<1-10> number of seconds between generation of config BPDUs

This is configured globally and cannot be configured per interface, by default the Hello timer is again 2 second intervals, however if changed the Max-Age time will also change to be three times the Hello value.

 

RSTP also has one not so well known Port State “Backup” or Back

 

This Port State is specifically for a LAN segment connected to two switches with redundant cabling as shown here:

RSTP_Backup_Port

There are 3 physical links on 2 Non-Root Bridges connecting back to a shared LAN segment, which means logically there are 2 possible Alternate paths back to the Root Bridge through either SW2 or SW3, however SW2 has the secondary link that receives a Superior BPDU with its own Bridge as the source Bridge ID.

Given this secondary Path on SW2 cannot guarantee an Alternate Root Path, however it can guarantee a Root Path back to the shared LAN segment, it is placed into a different Blocking state called “Backup” which means the interface received a Superior BPDU from itself.

If SW2 was the Root Bridge all interfaces would of course be in Desg / FWD, and SW3 on the other side of the shared LAN would be a Root Port, so this Backup state is conditional to the “Blocking” rule that if an STP is not a Designated or Root Port it must be blocking.

How Backup looks in “sh span”

SW3#sh span

VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 20481
Address 1ce6.c7c1.c800
Cost 19
Port 5 (FastEthernet1/0/3)
Hello Time 10 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5897.1eab.ce00
Hello Time 1 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Altn BLK 19 128.4 P2p
Fa1/0/3 Root FWD 19 128.5 P2p
Fa1/0/4 Desg FWD 19 128.6 P2p
Fa1/0/12 Back BLK 19 128.14 P2p

This example doesn’t follow the above Topology, however if you plug both ends of an Ethernet cable into the same switch, one of those ends will become a Backup link!

 

Reviewing the full output of “sh span” on SW3

 

Since SW3 has a lot of links connected in the network, it makes a good candidate to review the “show span” output on an RSTP enabled switch, and yes the “half duplex” link is now removed from the equation as I move along:

SW3(config)#do sh span

VLAN0001
Spanning tree enabled protocol rstp    <— Hellooooo RSTP
Root ID Priority 24577
Address 1ce6.c7c1.c800
Cost 19
Port 5 (FastEthernet1/0/3)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec

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

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Altn BLK 19 128.4 P2p
Fa1/0/3 Root FWD 19 128.5 P2p
Fa1/0/4 Altn BLK 19 128.6 P2p Peer(STP)
Fa1/0/12 Desg FWD 19 128.14 P2p Edge

Highlighted in red going in ascending order is:

  • Verification Switch is STP Enabled RSTP
  • A couple ports show “Altn / BLK” or RSTP “Discarding” state
  • Link to SW4 also stayed in Discarding mode, indicating that Peer is running STP
  • Link to Fa1/0/12 shows it is an Edge interface, indicating a Host is connected

The Root Bridge / Root Path Election and Selection will be the exact same as STP, along with the timers, most of them not being used are just backwards compatible for understanding a neighbor switch running 802.1d running STP.

The timers are inconsequential to each other, they are basically there for backwards compatibility with 802.1d STP, to prove this I made the following Topology change:

RSTP_Hello_Top

I will spare all the output, however I thought maybe I could get a link to drop by setting one switch with a value higher than 3 x another switch and get the link to drop.

That was not the case, as RSTP does not use any timers except the Hello interval to send BPDUs to neighbors, then within that BPDU is timer information, so the remote switch knows when to expect the next Hello (or when its missed!).

I know that’s been covered but that is really important to know, links do not age out due to timers, they age out due to Hellos stopping at any frequency / interval they are set at.

 

An overview of the 3 different RSTP interface types

 

RSTP has 3 interface / Port types:

  • Point-to-Point – Any interface running at Full Duplex
  • Edge – All STP Portfast enabled interfaces
  • Shared – Interface running Half Duplex, or manually configured as Shared

A Point-to-Point or P2P interface type indicates any interface running in Full Duplex, an Edge port is an STP Portfast enabled interface, and a “Shared” interfaces are STP enabled interfaces running at Half Duplex or hard coded at the interface level.

 

An in depth look at “Shared” RSTP Interface type

 

Shared is a little different as you can hard code it in two different ways on the interface:

Shared Configured #1

SW2(config-if)#duplex half ?
<cr>

Shared Configuration #2

SW2(config-if)#span link-type ?
point-to-point Consider the interface as point-to-point
shared Consider the interface as shared

SW2(config-if)#span link-type shared ?
<cr>

This link type is used for interfaces that would be connected to “Shared” media (imagine that), such as a Hub or Repeater that would be running Half Duplex, which is why configuring the interface as Half Duplex automatically changes it to STP “Shared” type:

SW2 with “debug span events” running

SW2(config-if)#duplex half
SW2(config-if)#
*Mar 1 00:49:55.269: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to down
SW2(config-if)#
*Mar 1 00:49:56.033: RSTP(1): initializing port Fa1/0/2
*Mar 1 00:49:56.033: RSTP(1): Fa1/0/2 is now designated
*Mar 1 00:49:56.041: RSTP(1): transmitting a proposal on Fa1/0/2
*Mar 1 00:49:56.343: RSTP(1): transmitting a proposal on Fa1/0/2
SW2(config-if)#
*Mar 1 00:50:00.051: RSTP(1): initializing port Fa1/0/2
*Mar 1 00:50:00.051: RSTP(1): Fa1/0/2 is now designated
*Mar 1 00:50:00.059: RSTP(1): transmitting a proposal on Fa1/0/2
*Mar 1 00:50:00.370: RSTP(1): transmitting a proposal on Fa1/0/2
SW2(config-if)#
*Mar 1 00:50:01.057: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to up
SW2(config-if)#
*Mar 1 00:50:02.056: RSTP(1): transmitting a proposal on Fa1/0/2
*Mar 1 00:50:02.383: RSTP(1): transmitting a proposal on Fa1/0/2
SW2(config-if)#

What would normally be a near instant Port transition process went on for 30 seconds:

*Mar 1 00:50:26.550: RSTP(1): transmitting a proposal on Fa1/0/2
SW2(config-if)#
*Mar 1 00:50:28.564: RSTP(1): transmitting a proposal on Fa1/0/2
SW2(config-if)#
*Mar 1 00:50:30.065: RSTP(1): Fa1/0/2 fdwhile Expired
*Mar 1 00:50:30.065: STP[1]: Generating TC trap for port FastEthernet1/0/2

Verification

SW2(config-if)#do sh span

(Output redacted)

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/1 Root FWD 19 128.3 P2p
Fa1/0/2 Desg FWD 19 128.4 Shr

Given RSTP Debug output is a mess, it doesn’t show exact states like “Listening” or “Learning” in it, however from the debug output I did include, it is seen there is a 2 x Hello delay followed by a 2 x Forward Delay once the Line Protocol comes back up!

On SW3 (other side of the link) it actually dynamically changed the link type to Shared:

SW3#sh span

(Output redacted)

 

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Altn BLK 19 128.4 Shr
Fa1/0/3 Root FWD 19 128.5 P2p
Fa1/0/4 Altn BLK 19 128.6 P2p Peer(STP)
Fa1/0/12 Desg FWD 19 128.14 P2p Edge

The result being that one the link came back up, both ends of the link renegotiated their Duplex Speed, and interface Fa1/0/2 on SW3 downshifted to Half Duplex back to SW2:

SW3#sh int fa1/0/2
FastEthernet1/0/2 is up, line protocol is up (connected)
Hardware is Fast Ethernet, address is 5897.1eab.ce04 (bia 5897.1eab.ce04)
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 100Mb/s, media type is 10/100BaseTX

This resulted in the dynamic change to a Shared interface type in STP.

So the bottom line is Shared connections should run to Shared media, if a port is set to Half Duplex on an RSTP enabled switch it will use Forward Delay when transitioning to Forwarding, and it dynamically changes the remote end of the link to Half Duplex / Shared STP interface type.

 

The RSTP interface “Peer(STP)” discussed and debugged!

 

From SW3, it was seen it has the following interface up to SW4 from Topology:

Fa1/0/4 Altn BLK 19 128.6 P2p Peer(STP)

The Peer(STP) value for Fa1/0/4 indicates that the neighbor on the remote end of that link is running 802.1d STP, this is learned from the incoming BPDU Frame, which will have a Version # indicated the type of STP the neighbor is running, the values being:

  • STP = Version 0
  • RSTP = Version 2

Given that STP and RSTP play well together, the only consideration that needs to be given to an STP Peer is Forward Delay timers, as Link Failure on an RSTP enabled switch is detected and dynamically addressed almost immediately as seen below.

From the perspective of the STP Enabled switch, indirect link failure would take its 50 seconds for max-age / lis / ler until it forwards, 30 seconds for direct link failure for 2 x Forward Delay (lis / ler), however as shown below even Indirect Link failure through an upstream STP Enabled switch takes less than a second to address.

To demonstrate this I unplugged SW1 – SW3, started a “debug span events” on SW3, and pulled the Fa1/0/5 plug on SW1 causing Direct link failure to SW4 and Indirect to SW3:

RSTP_STP_Indirect

Note Fa1/0/4 on SW3 is now a Root Port with the link gone to SW1, so this will be an Indirect link failure through SW4, and a Direct link failure on SW4 resulting in a 30 second Forward Delay while its only Alternate path is put into Forwarding state.

Play by Play of Indirect Link Failure via SW3’s debug!

Debug output:

*Mar 1 01:44:34.796: RSTP(1): updt roles, received superior bpdu on Fa1/0/4

1. SW4 detects link failure to SW1, floods TCN BPDU to SW3

*Mar 1 01:44:34.796: RSTP(1): Fa1/0/2 is now root port
*Mar 1 01:44:34.796: RSTP(1): Fa1/0/4 blocked by re-root
*Mar 1 01:44:34.796: RSTP(1): Fa1/0/4 is now designated
*Mar 1 01:44:34.804: STP[1]: Generating TC trap for port FastEthernet1/0/2

 

2. Within 1 second a new Root Port is elected, Fa1/0/4 goes into Discarding state

*Mar 1 01:44:49.803: RSTP(1): Fa1/0/4 fdwhile Expired
SW3#

3. SW4 transitions its end of the link to Learning state

*Mar 1 01:45:04.810: RSTP(1): Fa1/0/4 fdwhile Expired
*Mar 1 01:45:04.810: STP[1]: Generating TC trap for port FastEthernet1/0/4
SW3#

4. SW4 transitions its end of the link to Forwarding state

The “fdwhile Expired” message has something to do with the Synchronization process failing, its exact meaning is a good read and beyond the scope of needed CCNP SWITCH information.

However it does show locally the remote bridges transition stage timers, as highlighted in red demonstrating the 2 x Forward Delay between the “fdwhile Expired” messages, due to it running 802.1d STP.

 

The RSTP “Edge” interface type AND DISCARDING MODE CAUGHT IN ACTION!

 

Any STP Portfast enabled interface is designated by RSTP as an “Edge” port, as in the outer edge / access layer, however if a BPDU is detected on the interface it backs off FWD mode and is “demoted” to a regular RSTP mode.

Here be the difference in FWD transition, Host B vs SW4, via “span debug events”

Host A get plugged into Edge Fa1/0/12

SW3#
*Mar 1 03:57:32.437: RSTP(1): initializing port Fa1/0/12
*Mar 1 03:57:32.437: RSTP(1): Fa1/0/12 is now designated
SW3#
*Mar 1 03:57:34.434: %LINK-3-UPDOWN: Interface FastEthernet1/0/12, changed state to up
*Mar 1 03:57:35.440: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/12, changed state to up
SW3#sh span

VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 20481
Address 1ce6.c7c1.c800
Cost 19
Port 5 (FastEthernet1/0/3)
Hello Time 10 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5897.1eab.ce00
Hello Time 1 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Altn BLK 19 128.4 P2p
Fa1/0/3 Root FWD 19 128.5 P2p
Fa1/0/12 Desg FWD 19 128.14 P2p Edge

So it doesn’t give that explicit “HEY I’M MOVING IMMEDIATELY INTO FORWARDING FROM BLOCKING” output we get from normal STP Portfast, so its important to know that RSTP doesn’t yell that in your face 🙂

SW4 (Solo) plugged into Edge Fa1/0/12

*Mar 1 03:58:13.910: RSTP(1): initializing port Fa1/0/12
*Mar 1 03:58:13.910: RSTP(1): Fa1/0/12 is now designated
SW3#
*Mar 1 03:58:15.907: %LINK-3-UPDOWN: Interface FastEthernet1/0/12, changed state to up
SW3#
*Mar 1 03:58:16.989: RSTP(1): initializing port Fa1/0/12
*Mar 1 03:58:16.989: RSTP(1): Fa1/0/12 is now designated
*Mar 1 03:58:16.997: RSTP(1): transmitting a proposal on Fa1/0/12
SW3#
*Mar 1 03:58:17.987: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/12, changed state to up
SW3#sh span

VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 20481
Address 1ce6.c7c1.c800
Cost 19
Port 5 (FastEthernet1/0/3)
Hello Time 10 sec Max Age 20 sec Forward Delay 15 sec

Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5897.1eab.ce00
Hello Time 1 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Altn BLK 19 128.4 P2p
Fa1/0/3 Root FWD 19 128.5 P2p
Fa1/0/12 Desg BLK 19 128.14 P2p Peer(STP)  <— DISCARDING MODE!!!!!

 

SW3#
*Mar 1 03:58:31.996: RSTP(1): Fa1/0/12 fdwhile Expired
SW3#
*Mar 1 03:58:47.003: RSTP(1): Fa1/0/12 fdwhile Expired
*Mar 1 03:58:47.003: STP[1]: Generating TC trap for port FastEthernet1/0/12
SW3#

Here is the elusive Desg / BLK state highlighted in blue, Discarding Mode!

I didn’t realize when trying all sorts of debugs and scenarios to see Discarding in action, it would be plugging in an STP Enabled Bridge into an Edge Port, it is not easy to catch an RSTP interface in Desg / BLK state!

However once all the excitement is over, if that is a rogue switch being plugged into an Edge switch port, RSTP will not STOP it from becoming part of the RSTP network:

Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/2 Altn BLK 19 128.4 P2p
Fa1/0/3 Root FWD 19 128.5 P2p
Fa1/0/12 Desg FWD 19 128.14 P2p Peer(STP)

So the Edge Port is “demoted” to a slower convergence time, especially with an STP Enabled switch, but it does not disable the interface or prevent the switch from joining the network – That is where a BPDU Guard or BPDU Filter type command would come in.

 

To end this – The ultimate Spanning-Tree Per VLAN / Per Interface command!

 

I have been using this throughout the lab, but to reduce the clutter have not shown it, however this command can be used (hopefully) to get the full view of the STP Network:

Per VLAN information

SW3#sh span det

VLAN0001 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 32768, sysid 1, address 5897.1eab.ce00
Configured hello time 1, max age 20, forward delay 15, transmit hold-count 6
Current root has priority 20481, address 1ce6.c7c1.c800
Root port is 5 (FastEthernet1/0/3), cost of root path is 19
Topology change flag not set, detected flag not set
Number of topology changes 219 last change occurred 00:14:58 ago
from FastEthernet1/0/12
Times: hold 1, topology change 35, notification 10
hello 10, max age 20, forward delay 15
Timers: hello 0, topology change 0, notification 0, aging 300

I started to highlight the important information that has been reviewed, and after half the output was red I just set it back, that is excellent information regarding VLAN 1!

  • VLAN is RSTP Compatible
  • Root Port is interface X, Root Path Cost #
  • # of Topology changes, TIME SINCE LAST TOPOLOGY CHANGE!
  • Timers galore (even the Aging / MAC Table timer!)
  • And on and on

If you need to know ANYTHING STP related in detail for VLAN 1, there is a command!

Per Port (Interface) information

Port 4 (FastEthernet1/0/2) of VLAN0001 is alternate blocking
Port path cost 19, Port priority 128, Port Identifier 128.4.
Designated root has priority 20481, address 1ce6.c7c1.c800
Designated bridge has priority 32769, address 5897.1eab.c800
Designated port id is 128.4, designated path cost 19
Timers: message age 10, forward delay 0, hold 0
Number of transitions to forwarding state: 37
Link type is point-to-point by default
BPDU: sent 327, received 4462

This again has a ton of useful information at the interface level, I had to do a double take on the Root / Bridge Priority, I didn’t realize they had the same ending hectet until now!

You can shave this command down a bit using:

“sh span detail | s VLAN0001” this is can sensitive so VLAN 158 would be VLAN0158

“sh span detail | s Port 14” also case sensitive with the P on Port, and I always figure the STP Port # to be the interface # + 2, which the theory has held up in my switched lab so I just go with it.

That is a wrap

I was going to add Synchronization into the mix, but I need to stop before my eyeballs dry out, Merry Xmas and Happy Holidays to all Cisco geeks around the world! 🙂

 

 

One thought on “RSTP – Fundamentals, Port States and Link Types explained IN DEPTH, configured and verified on the lab!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s