STP. Part 2. RSTP (802.1w)

STP. Part 1. STP (802.1D-1998)
STP. Part 2. RSTP (802.1w)
STP. Part 3. PVST+
STP. Part 4. MSTP
STP. Part 5. Bridge Assurance

Convergence of Legacy Spanning Tree Protocol (STP) 802.1D is timer based, which is not efficient.

Rapid Spanning Tree Protocol (RSTP) IEEE 802.1w is the next version of STP that was modified in order to achieve subsecond convergence. RSTP is compatible with legacy STP (802.1D-1998). RSTP was originally defined in the IEEE 802.1w and was later incorporated into the IEEE 802.1D-2004 specification.

RSTP calculates the final topology for the spanning tree using the same criteria as legacy STP (802.1D).

New in RSTP

First of all, there is no Listening state anymore:

RSTP (802.1w) Port State	Port is Included in Active Topology	Port is Learning MAC Addresses	Receive/Send BPDU	Frame Forwarding
Discarding	No	No	Yes/No	No
Learning	Yes	Yes	Yes/Yes*	No
Forwarding	Yes	Yes	Yes/Yes*	Yes

* – Port will process incoming BPDUs. Port also sends BPDUs until port receives superior BPDU

From Cisco’s documentation:
BPDU are sent every Hello-Time, and not simply relayed anymore. With 802.1D, a non-root bridge only generates BPDUs when it receives one on the root port. In fact, a bridge relays BPDUs more than it actually generates them. This is not the case with 802.1w. A bridge now sends a BPDU with its current information every Hello_Time seconds (2 by default), even if it does not receive any from the root bridge.

On a given port, if hellos are not received three consecutive times, protocol information can be immediately aged out (or if max_age expires). Because of the previously mentioned protocol modification, BPDUs are now used as a keep-alive mechanism between bridges. This made possible for RSTP to detect indirect failure in 6 seconds.

RSTP accepts Inferior BPDU on a Root port. When a bridge receives inferior information from its designated or root bridge (e.g. Root port), it immediately accepts it and replaces the one previously stored.

The Edge/Non-Edge Port concept was introduced in RSTP. Non-Edge ports are the ports for network devices. Edge ports are the ports for end devices (PC, printers, WiFi Access points, etc); By default, every port is a Non-Edge Port. Edge port is defined administratively (portfast feature). Edge ports do not participate in STP topology and do not trigger TC changes. An edge port that receives a BPDU immediately loses edge port status and becomes a Non-Edge Port until it goes down.

NOTE: An Edge port goes to forwarding immidiately, while a Non-Edge port that did not receive a BPDU takes 2xForward_Delay to go to forwarding state (Legacy STP fallback).

The Shared Port in RSTP is port operating in half-duplex mode. The half-duplex mode can not grantee that there are only two devices on a segment. Such links must wait for the timer to expire before transitioning to the forwarding state. Port operating in this mode can not be included in RSTP and works pretty much as regular STP port.

The major change in RSTP operation is a synchronization or proposal/agreement handshake. It provides the speed of convergence of RSTP. Synchronization takes place only on Point-to-point links (in terms of spanning tree) or Full-duplex links.

Synchronization

Sync is triggered by:
– the connect of a new switch that results in change of the Root port (better Bridge ID, new better path to the existing root bridge)
– a link failure on the Root port of a switch

Loop prevention during reelection of the Root Port is done by putting all Non-Edge Designated ports into Discarding state before the new Root Port is put into Forwarding state. Next, the sync process starts. It is also called Proposal/Agreement.

A switch that is in sync state “replies” to the new Root bridge by sending a BPDU with Agreement bit set. Once Agreement is received on a port, this port may be put in Forwarding state immediately. At the same time, the switch continues with sync process by sending BPDUs with the Proposal bit set out of every Designated Port in a Discarding or Learning state, declaring its willingness to put these ports in Forwarding state. Based on BPDUs received in return, a port either put in Designated Forwarding or Alternate Discarding. This process continues down to the rest of the topology.

RSTP Topology Changes

Facts about RSTP that differ from STP:
– there is no TCN BPDU in RSTP, only one BPDU type is used: RST BPDU
– RSTP does not require acknowledgment on TC bit set received in BPDU
– BPDUs with TC bit set propagated/flooded on hop-to-hop basis, not from the Root Bridge, like it is in STP
– only “Link Up” events of non-Edge ports trigger Topology Change
– on TC event a bridge flushes its MAC table

Process in detail, described by Petr Lapukhov on blog.ine.com:
The bridge detecting a topology change sets the TC (Topology Change) bit in all outgoing BPDUs and starts sending BPDUs with the TC bit set upstream through the root port as well. This marking lasts for TCWhile = 2 x Hello_Time seconds and allows the detecting bridge the start the flooding process.

Every bridge that receives a BPDU with TC bit set, should receive it on either root port (coming from upstream) or designated port (coming from downstream). The receiving bridge performs the following:
– Flushes all MAC addresses associated with all ports with except to the port where the TC BPDU was received and Edge ports
– Repeats the flooding procedure by starting TCWhile timer and setting the TC bit for all BPDUs sent upstream or downstream. The receiving port is excluded from flooding, in order to ensure flooding procedure termination.

There is no need to flush MAC addresses on the port receiving the TC BPDUs as the downstream section will only originate a TC BPDU if a “Link Up” event was detected. Thus, the downstream section could only potentially learn additional MAC addresses, but not lose any of the existing.

Links going down do not result in any changes, as loss of connectivity does not provide new paths in the topology. Indeed, if a bridge loses the link to its downstream bridge, the latter either has an alternate path to the root or not. If the downstream has no alternate path, no action will to be taken to improve convergence. If there is an alternate path, the downstream will unblock it and generate its own topology change event.

Edge links do not create any topology changes, even if they become forwarding. This allows for greatly reducing the amount of topology change events in a topology. Furthermore, edge ports do not have associated MAC addresses flushed when a topology change message is received, thus further reducing flooding. Lastly, no TCN BPDUs are ever flooded out of the edge ports, as there is assumed to be no bridges connected downstream.

BPDU Guard and BPDU Filter
Cisco provides you to define every access port as Edge port:

Switch(config)# spanning-tree portfast edge default 
    %Warning: this command enables portfast by default on all interfaces.
     You should now disable portfast explicitly on switched ports leading to hubs, switches and bridges as they may create temporary bridging loops.

By default, once an Edge port receives a BPDU, this port becomes a non-Edge (regular STP) port. Another option is to disable an an Edge port if a BPDU arrives on it:

spanning-tree portfast edge bpduguard default

disable-timeout option allows the interface to return to service automatically after the timer expires:

errdisable recovery cause bpduguard
errdisable recovery interval 600

If you need to unblock and re-enable the interface manually, then shutdown and no shutdown the interface.

BPDUs on a port can be dropped/filtered. The configuration for it:

interface Ethernet0/0
 spanning-tree bpdufilter enable

The same features (portfast, BPDUGuard and BPDUFilter) can be configured on a port basis.

BPDUFilter has higher preference than BPDUGuard, so if both feature are configured for a port, only BPDUFilter will be applied.

Root protection

Root protection is intended to protect STP topology from rogue BDPU or human error. Root protection is enabled on interfaces that should not receive superior BPDUs and should not be elected as the root port.

Root protection is enabled on downstream links on non-root bridges.

If the bridge receives a superior BPDU on a port that has root protection enabled, that port transitions to an inconsistency state, blocking the interface. After the switch stops receiving superior BPDUs on the interface with root protection, the interface returns to a forwarding state.

Configuration is made on a port basis:

interface Ethernet0/1
     
 spanning-tree guard root

Loop protection

Loop protection performs a specified action when BPDUs are not received on a Alternate port.

If a loop-protection-enabled interface stops receiving BPDUs, it reacts as it would react to a problem with the physical connection on this interface. It does not transition the interface to a forwarding state, but instead transitions it to a loop-inconsistent state. The interface recovers and then it transitions back to the spanning-tree blocking state as soon as it receives a BPDU.

By default, a spanning-tree protocol interface that stops receiving bridge protocol data unit (BPDU) data frames will transition to the designated port (forwarding) state, creating a potential loop.

interface Ethernet0/1
 spanning-tree guard loop

NOTE: An interface can be configured for either loop protection or root protection.

By the way
RSTP has some problems, like “Counting to infinity“. In detail, this effect is described in blog post “Understanding STP and RSTP Convergence” by blog.ine.com. There is a paper on this topic – “Understanding and Mitigating the Effect of Counting to Infinity in Ethernet Network”