Tuesday, September 2, 2014

RSTP synchronization

  No comments    
categories: 
#Cisco #Routers
#CCNA R&S, CCNP and CCIE Students

#Cisco Systems Engineer
#Specially Routing Students
# Network Engineers
#Cisco TAC Engineers
#Cisco CCIE Students

Introduction

In 2001, the IEEE introduced Rapid Spanning Tree Protocol (RSTP) as 802.1w. RSTP provides significantly faster spanning tree convergence after a topology change, introducing new convergence behaviors and bridge port roles to do this. RSTP was designed to be backwards-compatible with standard STP.


While STP can take 30 to 50 seconds to respond to a topology change, RSTP is typically able to respond to changes within 3 × Hello times (default: 3 times 2 seconds) or within a few milliseconds of a physical link failure. The so-called Hello time is an important and configurable time interval that is used by RSTP for several purposes; its default value is 2 seconds.
Standard IEEE 802.1D-2004 incorporates RSTP and obsoletes the original STP standard.




  • Detection of root switch failure is done in 3 hello times, which is 6 seconds if the default hello times have not been changed.
  • Ports may be configured as edge ports if they are attached to a LAN that has no other bridges attached. These edge ports transition directly to the forwarding state. RSTP still continues to monitor the port for BPDUs in case a bridge is connected. RSTP can also be configured to automatically detect edge ports. As soon as the bridge detects a BPDU coming to an edge port, the port becomes a non-edge port.
  • RSTP calls the connection between two or more switches as a "link-type" connection. A port that operates in full-duplex mode is assumed to be point-to-point link, whereas a half-duplex port (through a hub) is considered a shared port by default. This automatic link type setting can be overridden by explicit configuration. RSTP improves convergence on point-to-point links by reducing the Max-Age time to 3 times Hello interval, removing the STP listening state, and exchanging a handshake between two switches to quickly transition the port to forwarding state. RSTP does not do anything differently from STP on shared links.
  • Unlike in STP, RSTP will respond to BPDUs sent from the direction of the root bridge. An RSTP bridge will "propose" its spanning tree information to its designated ports. If another RSTP bridge receives this information and determines this is the superior root information, it sets all its other ports to discarding. The bridge may send an "agreement" to the first bridge confirming its superior spanning tree information. The first bridge, upon receiving this agreement, knows it can rapidly transition that port to the forwarding state bypassing the traditional listening/learning state transition. This essentially creates a cascading effect away from the root bridge where each designated bridge proposes to its neighbors to determine if it can make a rapid transition. This is one of the major elements that allows RSTP to achieve faster convergence times than STP.
  • As discussed in the port role details above, RSTP maintains backup details regarding the discarding status of ports. This avoids timeouts if the current forwarding ports were to fail or BPDUs were not received on the root port in a certain interval.
  • RSTP will revert to legacy STP on an interface if a legacy version of an STP BPDU is detected on that port.


  • RSTP bridge port roles:
    • Root - A forwarding port that is the best port from non-root bridge to root bridge
    • Designated - A forwarding port for every LAN segment
    • Alternate - An alternate path to the root bridge. This path is different from using the root port
    • Backup - A backup/redundant path to a segment where another bridge port already connects
    • Disabled - Not strictly part of STP, a network administrator can manually disable a port
    It is well known that RSTP uses synchronization to speed up convergence in
    switched networks. Not many articles or books give the full picture how this
    process really works. The synchronization process is often oversimplified
    and readers are left with the IEEE standard if they want to understand all
    of the details. This post will give you a better understanding of how the
    RSTP synchronization really works.
    Initial synchronization
    In regular 802.1D when switches first boot up ports are brought online
    the switch claims to be root because it has not yet heard any better BPDUs.
    This is no different in RSTP or RPVST+ which is Ciscos implementation.
    Take a look at the following topology.
    RSTP-synch-1
    The goal here is to make SW1 the root bridge. But until better BPDUs have
    been heard all switches will claim root. That is how STP works, it stores
    the best BPDU received in on a port. To emulate a network coming online
    to begin we will have all ports shutdown and then try to bring them up
    at the same time. Debugs and captures will be run to show how the synchronization
    process works. The following debugs have been enabled.
    SW1#sh debug
    Spanning Tree:
      Spanning Tree event debugging is on
      Spanning Tree state sync support debugging is on
    
    So we start at looking at the debugs from each switch in order.
    SW1
    setting bridge id (which=3) prio 16385 prio cfg 16384 sysid 1 (on) id 4001.aabb.cc00.0100
    RSTP(1): initializing port Et0/0
    RSTP(1): Et0/0 is now designated
    %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
    RSTP(1): transmitting a proposal on Et0/0
    RSTP(1): received an agreement on Et0/0
    STP[1]: Generating TC trap for port Ethernet0/0
    
    SW1 assumes its port is designated and sends out a proposal. SW2 will agree to this
    proposal.
    SW2
    %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
    %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
    setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0200
    RSTP(1): initializing port Et0/0
    RSTP(1): Et0/0 is now designated
    RSTP(1): initializing port Et0/1
    RSTP(1): Et0/1 is now designated
    %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
    RSTP(1): transmitting a proposal on Et0/0
    RSTP(1): transmitting a proposal on Et0/1
    %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
    RSTP(1): transmitting a proposal on Et0/0
    RSTP(1): transmitting a proposal on Et0/1
    RSTP(1): received an agreement on Et0/1
    STP[1]: Generating TC trap for port Ethernet0/1
    RSTP(1): transmitting a proposal on Et0/0
    RSTP(1): transmitting a proposal on Et0/0
    RSTP(1): updt roles, received superior bpdu on Et0/0 
    RSTP(1): Et0/0 is now root port
    RSTP(1): syncing port Et0/1
    RSTP(1): synced Et0/0
    STP[1]: Generating TC trap for port Ethernet0/0
    RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
    RSTP(1): transmitting a proposal on Et0/1
    RSTP(1): received an agreement on Et0/1
    
    SW2 initializes all ports as designated and starts sending out proposals. It
    then receives a better BPDU from SW1 so it has to sync its downstream ports (Et0/1).
    SW3
    %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
    %LINK-3-UPDOWN: Interface Ethernet0/1, changed state to up
    %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
    %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
    setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0300
    RSTP(1): initializing port Et0/0
    RSTP(1): Et0/0 is now designated
    RSTP(1): initializing port Et0/1
    RSTP(1): Et0/1 is now designated
    RSTP(1): transmitting a proposal on Et0/0
    RSTP(1): transmitting a proposal on Et0/1
    RSTP(1): updt roles, received superior bpdu on Et0/0 
    RSTP(1): Et0/0 is now root port
    RSTP(1): syncing port Et0/1
    RSTP(1): synced Et0/0
    STP[1]: Generating TC trap for port Ethernet0/0
    RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
    RSTP(1): transmitting a proposal on Et0/1
    RSTP(1): transmitting a proposal on Et0/1
    RSTP(1): received an agreement on Et0/1
    STP[1]: Generating TC trap for port Ethernet0/1
    RSTP(1): updt roles, received superior bpdu on Et0/0 
    RSTP(1): syncing port Et0/1
    RSTP(1): synced Et0/0
    RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
    RSTP(1): transmitting a proposal on Et0/1
    RSTP(1): received an agreement on Et0/1
    
    SW3 goes through the same process. Claims root at first, then hears a better BPDU
    and must sync its downstream port.
    SW4
    %LINK-3-UPDOWN: Interface Ethernet0/0, changed state to up
    setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.aabb.cc00.0400
    RSTP(1): initializing port Et0/0
    RSTP(1): Et0/0 is now designated
    %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/0, changed state to up
    RSTP(1): transmitting a proposal on Et0/0
    RSTP(1): updt roles, received superior bpdu on Et0/0 
    RSTP(1): Et0/0 is now root port
    RSTP(1): synced Et0/0
    STP[1]: Generating TC trap for port Ethernet0/0
    RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
    RSTP(1): updt roles, received superior bpdu on Et0/0 
    RSTP(1): synced Et0/0
    RSTP(1): transmitting an agreement on Et0/0 as a response to a proposal
    
    SW4 also claims root, hears a better BPDU. It has not downstream ports to
    synchronize so the process ends there.
    To visualize the process this is what happens at time 0.
    RSTP-synch-2
    This can be seen in the BPDUs as well. This is the BPDU that SW1 sends out.
    BPDU-SW1-1
    The BPDU is a proposal and the designated bit is set. It’s not yet trying to learn or
    forward on the port.
    SW2 sends out the following BPDU.
    BPDU-SW2-1
    When SW1 has received agreement BPDU it can start forwarding on its designated port.
    SW2 can forward on its root port as soon as it decides that it is root. When SW2
    has learned better root information it must synchronize downstream ports so the port
    to SW3 is still blocking.
    RSTP-synch-3
    This is the agreement BPDU that SW2 sends to SW1.
    BPDU-SW2-2
    The learning and forwarding bits are set and the role is root. The agreement
    bit is also set as well as TC so that MAC address tables can be updated. The
    TC bit is set for 2x the hello time and is called TcWhile.
    The next segment to be synchronized is the one between SW2 and SW3.
    At first SW3 claims to be root.
    BPDU-SW3-1
    Then SW2 sends out a better BPDU.
    BPDU-SW2-3
    SW2 sends a BPDU with TC set because for a brief period of time SW2 was believed to
    be root before SW2 heard a better BPDU from SW1. Then SW3 sends agreement BPDU.
    BPDU-SW3-2
    After SW2 has received the agreement BPDU it can bring its downstream port (Et0/1)
    to forwarding making the topology look like this.
    RSTP-synch-4
    Finally the segment between SW3 and SW4 is synchronized. SW3 sends out the BPDU
    and then SW4 agrees to it. TC is set because for a brief period SW3 as believed
    to be root.
    BPDU-SW3-3
    BPDU-SW4-1
    The final topology is then that all links are forwarding because we have no physical
    loop in this topology.
    RSTP-synch-5
    Receiving better root information
    So far we had no physical loop in the topology. This is not a very realistic
    scenario and to see how RSTP works when receiving better root information we
    will add a link between SW1 and SW4 meaning that SW4 has a direct path to the
    root like this.
    RSTP-synch-6
    Before we look at what happens when bringing up the port between SW1 and SW4
    let us assign port roles to all the ports on the drawing. This is good practice
    to understand how STP works and you should be able to do this manually if you
    fully understand STP. We are expecting the topology to converge like this.
    RSTP-synch-7
    After SW4 receives better root information, which ports do we need to synchronize
    to converge the topology? SW1 does not receive better information, it is the root.
    SW4 has a designated port towards SW3 so it needs to synchronize that segment.
    SW3 has no designated ports so we except the synchronization process to stop
    there. Lets look at debugs and I’ll do a play by play with the drawings.
    SW1
    %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
    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): received an agreement on Et0/1
    STP[1]: Generating TC trap for port Ethernet0/1
    
    SW1 initializes the port and waits for agreement BPDU from SW4 before it can
    bring the port into forwarding.
    SW4
    %LINEPROTO-5-UPDOWN: Line protocol on Interface Ethernet0/1, changed state to up
    RSTP(1): initializing port Et0/1
    RSTP(1): Et0/1 is now designated
    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
    RSTP(1): Et0/0 blocked by re-root
    RSTP(1): synced Et0/1
    RSTP(1): Et0/0 is now designated
    STP[1]: Generating TC trap for port Ethernet0/1
    RSTP(1): transmitting an agreement on Et0/1 as a response to a proposal
    RSTP(1): transmitting a proposal on Et0/0
    RSTP(1): received an agreement on Et0/0
    STP[1]: Generating TC trap for port Ethernet0/0
    
    SW4 initializes the port but then receives a better BPDU. Et0/0 is then blocked by
    reroot because Et0/1 is now the root port. Et0/0 must be synchronized because it
    is now a designated (downstream) port. SW3 then sends an agreement. So looking at
    the topology this is what has happened so far.
    RSTP-synch-8
    Then SW3 sends agreement so that SW4 can bring Et0/0 into forwarding.
    RSTP-synch-9
    So now the question is, what happens at SW3?
    RSTP(1): updt roles, received superior bpdu on Et0/1
    RSTP(1): Et0/1 is now alternate
    
    SW3 did not receive any better root information and it has no designated ports.
    This means that the synchronization process can stop. Making the final topology
    look like this.
    RSTP-synch-10
    What happens when synchronization fails?
    RSTP synchronization is dependant on that all links in the topology are
    point to point. This is decided by if the link is running in full duplex or not.
    It is possible to force a link to point to point but if you are running your
    interfaces in half duplex STP is not your biggest problem!
    In the case that the proposal and agreement process fails RSTP has to fall
    back on relying on the old timers used in regular STP. There is a timer called
    FdWhile which is the same as the forward delay, defaulting to 15s. After trying to
    send proposals for 15s it will start to bring the port through discarding, learning
    and then to forwarding. I simulated this scenario below by blocking BPDUs between
    SW3 and SW4.


    20:02:23.338: RSTP(1): Et0/1 is now root port
    20:02:23.338: RSTP(1): Et0/0 blocked by re-root
    20:02:23.338: RSTP(1): Et0/0 is now designated
    20:02:23.338: STP[1]: Generating TC trap for port Ethernet0/1
    20:02:23.339: RSTP(1): transmitting a proposal on Et0/0
    20:02:23.509: RSTP(1): transmitting a proposal on Et0/0
    20:02:25.509: RSTP(1): transmitting a proposal on Et0/0
    20:02:27.509: RSTP(1): transmitting a proposal on Et0/0
    20:02:29.517: RSTP(1): transmitting a proposal on Et0/0
    20:02:31.517: RSTP(1): transmitting a proposal on Et0/0
    20:02:33.517: RSTP(1): transmitting a proposal on Et0/0
    20:02:35.517: RSTP(1): transmitting a proposal on Et0/0
    20:02:37.521: RSTP(1): transmitting a proposal on Et0/0
    20:02:38.338: RSTP(1): Et0/0 fdwhile Expired
    
    Every 2 seconds it tries to send a proposal but gets no agreement back.
    After 15 seconds the timer expires and RSTP has to go through the regular
    phases instead of immediately bringing the port online.


    Conclusion
    RSTP is a rapid protocol that works by synchronizing the topology. This process
    is often overlooked in books on switching and spanning tree. This post describes
    in detail how the synchronization process actually works. RSTP is a distance vector
    protocol since the cost is learned by listening to BPDUs from other switches. In
    some cases this can lead to issues like counting to infinity.

    0 comments:

    Post a Comment

    Popular Posts