ccie blog

RSTP Alternate and Backup Ports

This post identifies differences between the legacy spanning-tree (PVST+) non-designated port & the new RSTP replacement ports.

RSTP brought about a couple of new port roles compared to legacy spanning-tree, see below.

Legacy PVST+                      RSTP

Root                    ———->   Root
Designated          ———->   Designated
Non-Designated   ———->   Now uses Alternate and Backup ports

In PVST+ we said that anything that was in a blocking port state, was a spanning-tree a non-designated port.  RSTP has broken this blocking port down into two separate functions in order to provide faster convergence in a couple of difference scenarios.

Backup Port

Cisco has created this backup port for the function of supporting connectivity between switches that have some form of unsupported spanning-tree device between them.  In the diagram below, assume all switches have default configurations, and SW1 has been elected the root bridge.  So the Root Ports (RP) get elected on SW2 and SW3, and these are the ports with the least cost path to the root, which is via their directly connected links.  Now SW2 and SW3 need to decide who will be responsible for forwarding frames onto the network segment between them, i.e. who will become the designated switch for that segment.  In the event SW3 is the designated switch, it means that it has the least cost path to the root within the rules of STP port election process below:

  1. Least cost path to the root
  2. Lowest Bridge ID (Bridge priority + MAC address)
  3. Lowest Port-ID

So in spanning-tree terms, the shortest cost towards the root bridge from the segment between SW2 and SW3 is via SW3 assuming it has the lowest mac-address. Therefore, SW3 has the designated port (DP).  Now in legacy spanning-tree, all other ports on that segment would be non-designated blocking ports, and when SW3’s DP fails, there would be an election where SW2 and SW3 would decide who now becomes the designated port for the segment & eventually one DP port would be elected, and would transition through the listening, learning, and forwarding port states.  This would take 30 seconds (15 secs forward delay time for listening, plus 15 secs forward delay time for learning).  RSTP attempts to address this problem by pre-calculating who will become the new designated port if the current one fails.  In the network below, since SW3 already has the shortest cost to the root, then even if it’s DP dies, it would still have the shortest cost toward the root because it has the lowest bridge-id on that segment (see election process above). Now this is the purpose of the backup port.  Where, if SW3’s DP dies, then the backup port will take the DP role for that segment and instantly transition into forwarding state.  This is able to happen because STP just pre-calculates who would become the designated port on that segment in the event the current designated port fails. Note, that the backup port is hardly ever seen in real-life production networks because it’s only used where a switch has multiple links to the same layer 1 segment (i.e. multiple ports in the same collision domain), which can only really be apparent when using something like a hub.

RSTP-Backup Port

 

Alternate Port

Simply put, the alternate port is used as an alternate path up to the root bridge.  So in the diagram above, if the switch is neither a designated port or backup port for the segment, then it will become the alternate port.  I’m actually going to use a different diagram to explain this port role in more detail, see the topology below.


Alternate Port

The idea is that if SW4’s root port dies, then it can use the path via SW2 instead.  Now, lets first go through a failure of the root port when using legacy spanning-tree, and then afterwords go through what happens in RSTP.  SW4’s fa0/2 root port dies, and fa0/1 transitions through listening & learning, and eventually forwarding state, electing fa0/1 as the new root port.  This process took 2x the forward delay (2 x 15seconds) for fa0/1 to learn the new path to the root.  STP uplinkfast was then created to try and reduce this time.  By configuring SW4 with uplinkfast, when the root port dies, fa0/1 is able to instantly transition into forwarding state.  The details on how and why, requires us to take a few steps back.

Assuming we are not using uplinkfast, and SW4’s RP fails.  SW4 transitions fa0/1 through listening, learning, then forwarding in order to move the port role to “root port”.  At the same time a Topology Change Notification BPDU (TCN BPDU) is sent from Sw3 out the root port (because a port went from forwarding to down). SW4 also sends a TCN BPDU out its new root port Fa0/1 because a port went from blocking to forwarding, then SW2 relays this BPDU to the root.  The root then sends a TC Ack BPDU downstream to every switch telling them to age out their CAM tables.  The reason for this is because, say SW1 wants to send traffic to a computer on SW4.  Before the link failure, the CAM table on SW4 learned the MAC address as being reachable out the interface connected via SW3.  After the link failure, SW1 would still use this same path for a period of 300 seconds (5mins) until the MAC address is aged out in the CAM table & the result is that the traffic would be blackholed. The reason why it would be black holed is because the CAM table on SW3 still says the MAC address is via the broken link connected to SW4 until it’s aged out of the CAM table.  By flushing the CAM table out all the switches, they can re-learn where the actual mac address sits within the network from future broadcast ARP’s sent towards the computer on SW4.   Uplinkfast helps with the process of re-learning mac-addresses by sending a a bunch of dummy multicast frames out the new root port using a source mac-address for every entry it has in its CAM table.  This then allows all switches to re-learn the path to reach all hosts connected off SW4.

Now let’s go through this failure when using RSTP.  SW4 Fa0/2dies, and by default, RSTP moves the alternate port instantly into forwarding.  Only SW4 sends a BPDU with the TC-bit set towards SW2.  Notice that a bunch of other things haven’t happened:

  • Uplinkfast was not configured, as it has been depreciated & just built into the RSTP procotol with the ALTN port.
  • SW3 does not send any TCN BPDU’s. This is because the TCN BPDU has been depreciated, and the fact that RSTP only generates a BPDU with a TC-bit set when a port transitions into forwarding state now (i.e. a port moving from forwarding to down/discarding does not generate a topology change anymore).

Continuing with the failure, SW2, upon receipt of a BPDU with the TC-bit set will relay this message out of all ports except the port it received the BPDU on.  At the same time, it also flushes it’s CAM table on all ports except the port it received the BPDU on.  All other switches will follow this process.  Remember, the reason we want to flush out the CAM table on all ports except the one we received the BPDU on is because we don’t want the any switches in this topology to forward frames towards SW3 in order to reach hosts hanging off SW4 (because they are using old, stored information from the CAM table).

1 Comment

rollingJanuary 27th, 2016 at 8:35 am

Awesome post, very well explained… Keep up the good work!

Leave a comment

Your comment