The 802.1d spanning tree protocol was created with very few design flaws; however, as with most great things, there is always room for improvement. The biggest grievance the networking community had with spanning tree protocol was the slow convergence when a topology change occurred in the network.
Recall that it could take up to 30 seconds for the switched internetwork to converge and forward data frames again when a topology changed occurred. What’s more, it took roughly 30 seconds for an individual access port to become active when you plugged a device into it, because it had to transition from the listening and learning STP states before forwarding frames.
Cisco found several proprietary ways to improve the convergence lag of traditional spanning tree protocol. In addition, the IEEE adopted many of the ideas from cisco and created a much faster converging spanning tree protocol which is happily named Rapid spanning tree protocol (RSTP). As these switching technologies evolved and improved over the years, they became more and more adopted in switched internetworks. With this in mind, you too must evolve and improve your understanding of these enhanced switching technologies.
This article looks at the creative enhancements that were created over the years and demonstrates how they improve the speed limit of spanning tree protocol.
Cisco Enhancements to Spanning Tree Protocol
The steps to transition to a forwarding state in STP are critical to ensure that the switched network has enough time to propagate a change in the topology. However, in the networking world, 50 seconds is a lot of downtimes.
In some instances, these 50 seconds may be detrimental because of the disruption of data traffic and should be avoided if it is safe to do so. In light of these scenarios, Cisco has created some enhancements to normal STP operation that can decrease the time it takes for the switched network to converge (have to consistent perspective of the network).
Port Fast and BPDU Guard
Imagine you just plugged your server, IP phone, or just a normal PC into your switch. Because IP is running on all ports on the Catalyst switches by default, the interface into which you plug your server transitions from a blocking state to the listening state, followed by the learning, and finally the forwarding. In those 30 seconds, devices such as IP phones and computers cannot use those services that the server provides because no data transfer can occur until the spanning tree is in a forwarding state. To speed up the spanning tree process for end devices, you can configure your first STP enhancement, called Port First. If you configure this feature on an interface, it skips the listening and learning states and transitions immediately to the forwarding state to enable instant data transfer.
If you enable port fast on an interface, it is imperative that you never plug a switch or hub into it. This could easily cause a loop in your switched network. In fact, Cisco has added a function to Port Fast called BPDU Guard that acts as a loop-preventive detector for BPDUs on a Port Fast enabled the interface. When a BPDU is received on a Post fast configured interface with BPDU guard enabled, the port is disabled automatically and must be enabled by an administrator to ensure that a switching loop will not occur.
Uplink Fast
In an optimal redundant switching design, you would have redundant high-end distribution layer switches in your network, with your access layer switch having an uplink to both, as shown in the picture below. With this design, if your root port were to fail, it would still take at least 30 seconds to transition the backup link to a forwarding state. With a feature called Uplink Fast, you can bypass the listening and learning states for this redundant uplink to ensure a faster recovery.
Backbone Fast
Backbone fast is similar to Uplink fast, in which redundant link transitions faster than normal to a forwarding state. The difference is that the transition occurs without having direct knowledge of the link failure. Consider the scenario in the picture below. The failure actually occurs on the link between the two distribution layer switches. When that link fails, the distribution switch on the left begins to have delusions of grandeur and believe it is the root bridge, and it advertises that to the access layer switch. Because this access switch still has connectivity to the actual root bridge, it disregards the left distribution switch’s false BDPU (referred to as inferior BPDUs). By design, it must wait for the max-age (20 seconds) before transitioning to a learning state on its backup link and send a BPDU to the distribution switch, informing it of access to the actual root bridge.
With the backbone fast, the access layer switch bypasses the max-age time and immediately transitions from blocking to listening. After the distribution switch receives that BPDU from the access layer switch, it realizes it has a path to the root bridge through the access layer switch, and that corresponding interface becomes its root port.
Configuring Cisco STP Enhancements
To enable the Cisco enhancements on a catalyst switch, you can configure Port Fast with BPDU Guard on an interface-by-interface basis. Conversely, Uplink Fast and Backbone Fast are configured globally on the switch, as demonstrated in the following configuration:
Switch(config)#interface FastEthernet 0/3
Switch(config-if)#spanning-tree port fastWarning: PortFast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc… to this interface when Port Fast is enabled, can cause temporary bridging loops. Use with CAUTION
Switch(config-if)#spanning-tree bpduguard enable
Switch(config-if)#exit
Switch(config)#spanning-tree uplink fast
Switch(config)#spanning-tree backbone fastTo verify that Port Fast, Uplink Fast, and Backbone Fast are enabled on your switch, use the show spanning-tree summary command:
Switch#show spanning-tree summary
Root bridge for: none
Port Fast BPDU Guard is enabled Uplink Fast is enabled Backbone Fast is enabled
Spanning tree default path cost method used is short
Name Blocking Listening Learning forwarding STP Active
VLAN 0 0 0 1 1
Ether channel
Although it isn’t an actual enhancement to spanning tree protocol, Ether Channel proves to be a useful feature in Cisco switches to help overcome wasted bandwidth that might result from STP. For instance, consider the two switches illustrated in the picture below. Because these switches have multiple redundant links between them, spanning tree protocol ultimately blocks three of the links to avoid a loop. If these were Gigabit Ethernet interfaces, 3 gigabits of throughout would be wasted.
Ether channel solves this dilemma by bundling the individual links into a single virtual interface. In this manner, the switch does not block the other ports in the bundle and load-balances data across the individual links to aggregate the bandwidth. What’s more, if one of the individual links fails, Ether Channel detects the failure and redistributes the data traffic load over the remaining links in a matter of milliseconds.
Ether channel is a hardware feature present on most cisco catalyst switches today. Before configuring Ether channel, you must connect all the interfaces (up to eight), and they must be configured identically (speed, duplex, and so on). To assign them to an Ether Channel logical bundle, you have to navigate into each interface or use the interface range command and assign them to the same group number with the channel-group command.
Switch(config)#interface range FastEthernet 0/1-8
Switch(config-if-range)#speed 100
Switch(config-if-range)#channel-group 3 mode on
This configuration places the first eight Fast Ethernet interfaces in logical Ether channel bundle number 3. By adding these interfaces to the Ether Channel bundle, the Cisco IOS creates a logical interface called a port-channel interface. This logical interface simplifies configurations that need to affect the entire bundle (for instance, the duplex) because any configuration that is configured on this interface gets applied to all the individual interfaces in the bundle.
Switch(config)#interface port-channel 3
Switch(config-if)#duplex full
Switch(config)#show running-configuration
Building configuration…
!
Version 12.2
Service time stamps debug uptime
Service time stamps log uptime
No service password-encryption
!
Hostname switch
!
!!!output omitted
!
Interface port-channel 3
No ip address duplex full speed 100
!
Interface FastEthernet 0/1
No ip address duplex full
Speed 100
Channel-group 3 mode on
!
Interface FastEthernt 0/2
No ip address duplex full speed 100
Channel-group 3 mode on
!
Interface FastEthernet 0/3
No ip address duplex full speed 100
Channel-group 3 mode on
!
!!!output omittedRapid Spanning Tree Protocol
One of the greatest drawbacks of Port Fast, Uplink Fast, and backbone Fast is that they require an all-cisco network because they are Cisco-proprietary functions. Luckily, the IEEE made its own revised version of Spanning Tree Protocol to incorporate these functions while incorporating an updated algorithm for faster topology convergence. Enter Rapid Spanning Tree Protocol (RSTP), IEEE specification 802.1w.
Spanning Tree Similarities
Aside from the fact that 802.1w Rapid Spanning Tree Protocol and 802.1d Spanning Tree Protocol are both defined by an IEEE 802.1 specification, RSTP shares some core functional principles with STP, making them similar in several ways. Namely, RSTP adopts the same switch and port election process in determining the root bridge, root ports, and designated ports. In other words, the switch with the lowest Bridge ID advertised in its BPDUs becomes the root bridge, and every non-root switch chooses its root port back to that root bridge based on the lowest cumulative root path cost. In case of a tie in the root path cost, the Bridge ID is used, followed by the definitive tiebreaker, the port priority. And again, for each segment, a designated port is chosen for each segment to forward frames from one segment to the next.
Because RSTP and STP share these core elements, Rapid Spanning-tree Protocol is completely backward-compatible with Spanning Tree Protocol. The only caveat is that you will not be able to enjoy the radical improvements that are incorporated with Rapid Spanning Tree Protocol on switches that are running traditional 802.1d STP. And with that segue, we will now explore the differences between the two spanning tree algorithms and how these changes dramatically improved the convergence issues with spanning tree protocol.
RSTP Port States and Roles
RSTP adopted the 802.1d port states with a slight difference. Because the blocking and listening states were essentially non-operational in terms of actively discovering the network’s topology, RSTP has redefined these to be a discarding state. Discarding ports are similar to blocking ports in that they do not forward frames or learn MAC addresses but still can receive BPDUs from other switches. Learning and forwarding states are still active in spanning-tree transition states and maintain the same functionality in RSTP-enabled LANs.
As previously mentioned, RSTP still uses the concepts of root port and designated ports. To incorporate additional functionality that is specific to popular redundant LAN designs, RSTP created two more port roles, as illustrated in the picture below. Based on the principle of Uplink Fast, the following two new port roles were created.
- Alternate port: a blocking (or I should say discarding) port that becomes the root port if the active root port fails. In other words, this is a non-forwarding root port that has the second-best path back to the root switch.
- Backup Port: a discarding port that becomes the designated port if the active designated port fails. The backup port occurs when you have two or more ports connected to the same LAN segment and provides a redundant backup to the segment (but not necessarily back to the root).
Notice that the election has occurred this topology and the top switch has been elected the root switch based on its low bridge ID. Each non-root switch chose its root ports based on the fastest path back to the root switch. Similarly, the designated ports were chosen for each LAN segment based on the lowest root path cost. Where RSTP shines can be witnessed in the redundant links between switches B and C.
In traditional 802.1d, the parallel links between switches B and C would result in three of the four ports being blocked to avoid a possible loop. If a topology change occurred, one of the blocking ports would transition to the listening state, followed by the learning state, before forwarding again, which could take anywhere from 30 to 50 seconds. With Rapid Spanning Tree Protocol, the three ports are still technically discarding frames. However, switch B’s bottom link port has been given the RSTP alternate role because that port would become the root port if switch B’s root port went down. In addition, switch C’s top link port has been named the backup port for that specific segment because that port would be elected the designated port if its current link connected to the designated port went down. To solidify the function of these roles, let’s look at what happens in the event of link failure.
If the link between Switch B and the root switch fails, as shown in the picture below, the alternate port quickly becomes the new root port and begins forwarding frames.
In the picture below, the link connected to the designated port fails, causing the backup port to become the active designated port for that segment. Because the bottom link has gone down, switch B puts its alternate port into a discarding state and its previously discarding port transitions to a forwarding state.
If you see the picture below, you can see what happens when switch C loses its link back to the root switch. Because switch C has lost its root port, it now must find a new root port based on the fastest way back to the root switch (in this case the port connected to the bottom link). In the event that switches C’s new root port fails, the port connected to the top link becomes the new root port, so this interface is elected as an alternate port. Now the roles are reversed for switch B because its alternate port is now the designated port for that LAN segment because it has the fastest port back to the root. In addition, the port that was once in a discarding state for switch B is now transitioned to a backup state, because that will become the designated port if the currently designated port fails. It is important to keep in mind that although these roles have different names, they are still in a discarding state and are not forwarding frames or learning MAC addresses.
RSTP Link and Edge Types
Another interesting difference between Spanning Tree Protocol and Rapid Spanning Tree Protocol is RSTP’s distinction between the links between switches and connections to end devices. For instance, RSTP considers any connection between switches running in full-duplex (directly connected to each other) as link-type point-to-point. If the switch interface is running in half-duplex (connected to a hub), the link is called link-type shared because it is probably connected to a shared network. Finally, non-switch or hub end devices such as computers are edge-type connections according to RSTP.
Rapid Spanning Tree Protocol actually reacts to topology changes and converges faster depending on these distinctions. Specifically, link-type point-to-point and edge-type connections play a specific role in how fast RSTP adapts to network topology transitions. Because the use of hubs is rather insignificant these days, RSTP does not put any effort into increasing convergence speed for link-type shared connections.
BPDUs and Topology Changes
Rapid Spanning Tree Protocol uses BPDUs to communicate information throughout the topology with one major distinction: each switch generates its own BPDUs and advertises them to neighboring switches. This is significantly different from traditional STP, in which the root bridge generates the BPDUs (except when a topology change is detected), and each switch passes that information to the next switch. What’s more, RSTP takes a chapter out of our routing protocols book and uses these BPDUs as keeps alive to let neighboring switches know that the switches are still active in the topology. When a switch fails to hear three BPDU keeps alive from its neighbor, it considers that neighbor as dead and immediately reacts to the change. That is considerably more aggressive than traditional STP switches, which would wait for a max-age (20 seconds) before considering the switch dead. If an RSTP switch receives a BPDU from an 802.1d STP switch, it sends STP BPDUs only to that switch to allow for backward compatibility.
Recall that STP switches send a topology change notification (TCN) back to the root bridge if that change has occurred. This is followed by a notification broadcast from the root bridge to age out old MAC address entries. With RSTP, when a topology change occurs, the TCN still occurs. However, it is sent to all switches from the switch that detects the anomaly, and switches immediately start aging out their MAC address entries in the CAM table. This is similar to the flash flood of updates that occurs with link-state routing protocols such as OSPF. By not having to rely on the root bridge to alert the switched topology of the topology change, the switches can age out their old MAC entries and start adapting to the new topology considerably faster than 802.1d STP.
Rapid Transition
By now you should recognize that the most unique function of RSTP is its capability to converge in an expedient manner. The core ingredient of this feature is that it no longer reactively relies on conservative timers to transition to a forwarding state.
For instance, on edge ports that are connected to end devices, the interface takes on the same functionality as Port Fast with BPDU Guard in that it immediately transitions to a forwarding state. In fact, the way to configure the port as an edge port on a switch is to configure Port Fast on the interface. When an edge port receives a BPDU, however, it immediately transitions to a point-to-point link type.
Where the connection between two switches is a full-duplex point-to-point link, RSTP takes a rather unique approach to converge. When a point-to-point link comes up between two switches, a handshake occurs between the two switches using BPDUs to establish what role their local ports will play for that link. Because there is no reliance on conservative timers to transition the ports to a forwarding state, the exchange occurs rather quickly.
We’ve already established that switches use traditional STP algorithms to determine their root port and designated ports. However, the process used when ports transition to a forwarding state is a proposal/agreement handshake. Specifically, when a switch receives a BPDU and calculates that its local port will become the designated port for that segment after connecting to a switch, it immediately sends a proposal to its neighbor to begin forwarding. When RSTP switches receive proposals to forward and determine that the port that receives the proposal will become a root port, they put all non-edge ports in a discarding state (if they aren’t already) to avoid any possibility of a loop occurring. You can think of this as similar to getting a marriage proposal. You would want to discontinue any other relationships to avoid confusion before accepting the proposal. This process of blocking all non-edge point-to-point links before sending a proposal is called synchronization or sync for short. It is so named because the switch ensures that these new links to a root switch and the resulting topology will be accurately synchronized with all other ports.
When the RSTP switch has successfully synced all its ports, it sends an agreement back to the switch that sent the proposal to allow forwarding. It begins to forward out its root port and starts learning MAC addresses itself. When the original switch receives the agreement message on its designated port, it too immediately begins forwarding and learning MAC addresses.
Consider an example shown in the picture below. Suppose switch A was just added to the topology. After an initial exchange of BPDUs, switch A realizes that it will be the root switch because it has the lowest bridge ID, and its local interface will be the designated port for that new segment. Switch A sends a proposal to forward to Switch B. Switch B receives that proposal and knows its local port will be a root port. It begins syncing by blocking all non-edge ports (in this case they are all already discarding because no other switches are attached). Switch B replies to Switch A with an agreement BPDU and immediately begins learning MAC addresses and forwarding on that port. Likewise, Switch A receives the agreement back and transitions its designated port to a forwarding state and begins learning MAC addresses as well.
Let’s complete your understanding of RSTP’s rapid transition to forwarding states by looking at what happens when the switching topology changes and we add another switch and a redundant connection, as shown in the picture below.
The initial BPDUs are exchanged, and switch A recognizes that its port connected to switch C will be a designated port. Again, switch A sends a proposal to transition to a forwarding state to switch C. when switch C receives this proposal on its soon-to-be root port, it begins its syncing process. It puts the interface between switch C and switches B into a discarding state before sending an agreement back to switch A to avoid a possible loop. It does not put the port connected to the PC into a discarding state, though, because it is an edge port and does not participate in RSTP. After the agreement is sent, switch C begins forwarding on its root port. Likewise, Switch A begins forwarding on its designated port after it receives the agreement.
After all this handshaking occurs between switches C and A, switch B also realizes that its link will become a designated port for the link between switch B and C. one more time, a proposal is sent from switch B to switch C to begin forwarding. This time, however, switch C’s port is not the optimal port back to the root bridge, so it does not become a root port. Thus, no agreement is ever sent back to switch B, and that port stays in a discarding state (technically an alternate state, because that is an alternate route to the route switch). Switch B continues to send proposals until a forward-delay timer expires. At this point, it assumes that it is a designated port and starts forwarding.
Here is a summary of the steps involved in this synchronization process:
- After the switches are connected to a point-to-point link, they exchange BPDUs.
- If a switch determines that its port will become a designated port, it sends a proposal to start forwarding to its neighbor.
- The neighboring switch receives the proposal. If its port is a root port, it synchronizes the change by putting all non-edge ports into a discarding state and sends an agreement back to the original switch. If its port if discarding port, it does not respond to the proposal.
- The original switch immediately transitions to a forwarding state if it receives an agreement or eventually transitions to a forwarding state after a forward-delay occurs.
Although this sounds as if there are many steps, the process happens relatively quickly. Interestingly enough, the topology would end up in the same state (with the same ports blocking and forwarding) as traditional STP. The key difference is that it can take several seconds to have all switches converge (even in larger networks) as opposed to several minutes with 802.1d STP (because each switch would take 30 to 50 seconds to reach a forward state).