Wednesday, January 14, 2009

STP: UplinkFast and BackBoneFast

This is I lab made to get familiar with the two STP features Uplinkfast and Backbonefast. RSTP (802.1w) includes these features but I don't seem to get the BackboneFast behavior when using "spanning-tree mode rapid-pvst+".

These features are similar but they are used to provide fast convergence in different scenarios depending on where the failure is in the STP toplogy.

Here is Topology #1 with SW1 configured as Root for VLAN13 where R1 and R4 reside. The Red Xes mark where STP is blocking:


Without Uplinkfast or Backbonefast enabled, lets see how long it takes STP to converge if port 13 on SW2 is shut:

R4 starts the ping while we shut the port on SW2

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!................!!!!!!

We missed about 16 pings and our topology has now converged. Let's enable UplinkFast on SW2, SW3 and SW4 and test again:

SW2(config)#spanning-tree uplinkfast
SW3(config)#spanning-tree uplinkfast
SW4(config)#spanning-tree uplinkfast


When you re-enable Port 13 on SW2, it takes awhile to come back up. It doesn't move through the LIS and LRN states according to the output but it will come up and you will see this message:

02:31:17: %SPANTREE_FAST-7-PORT_FWD_UPLINK: VLAN0013 FastEthernet0/13 moved to Forwarding (UplinkFast)

Now Let's ping from R4 again and the shut port 13 on SW2:

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!

One ping lost - WOW! Very fast. Let's build upon this failed scenario and look our new topology. Now we have SW2 forwarding through SW4 on it's way to the root SW1.

Let's see how long it takes to converge if we shut port 13 on SW4:

R4#ping 2001:13::1 re 1000000 Type escape sequence to abort. Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.........!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

We miss about 9 pings here. What happened? Well in short, when SW4 path to root went down, it started thinking that it was the new root. This caused a new STP election to occur and SW4 finally had to wait until it heard the new SW1 BPDUs from SW1 > SW3 > SW2 > SW4.

BackboneFast can speed up this process, when SW2 starts hearing this inferior BPDUS from SW4 (who is cliaming to be root when port 13 goes down") and special query process takes place to speed up convergence. Let's enable it and check the pings again. This goes on all switches.

SW1(config)#spann backbonefast
SW2(config)#spann backbonefast
SW3(config)#spann backbonefast
SW4(config)#spann backbonefast

R4#ping 2001:13::1 re 1000000

Type escape sequence to abort.
Sending 1000000, 100-byte ICMP Echos to 2001:13::1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!


Rapid Spanning Tree Protocol (802.1w) includes these features natively. In failover scenario #2 (shutting port 13 on SW4), only backbonefast provided quick convergence while Rapid-PVST+ did not. If have any ideas why, please let me know.

9 comments:

  1. Uplinkfast feature swaps failed root port to another Alternate port. Ports from SW4 towards SW2 and SW3 in your topology are just Designated ports.

    ReplyDelete
  2. Hello! Your site was super helpful but I found something relating to your question about BackboneFast. It is found here:
    http://dl.dropbox.com/u/744963/TEMP/cis187-4-PVST-RSTP.ppt
    see slide 20. It makes it clear that BackboneFast resolves the issue with bypassing the Max_Age timer. But it still has a listening timer of 20 seconds before going to forwarding. Maybe what you saw w/ RSTP was similar in that there was still 20 seconds before the port began forwarding.

    ReplyDelete
  3. The explanation is a SPOON FEEDING, Thank u Very Much

    ReplyDelete
  4. nice post..thanks.. very helpful!

    ReplyDelete
  5. Hey Deadhead, thanks for this info, good stuff.
    Backbone fast is disabled by default on Rapid-PVST+ and some switches I tested using 3750 and IOS 6509 seem to ignor enabling backbone fast whilst using Rapid-PVST+.

    ReplyDelete
  6. Hey.thanks alot for ur explanation...great work
    I have some doubt.when we shut port 13 of SW2....new route should be SW2-Sw3-Sw1..as per your scenario...as per my knowledge...please explain me if u can........

    Thanks

    ReplyDelete
  7. Eventhough, its an old article, It helped me a lot to get into the difference bw uplinkfast and backbonefast. I tried many articles, but nothing helped me except this one. I dont know how to express my gratitude for this explanation. Thanks a lot

    ReplyDelete
  8. Hi.. Thanks for the great tut..

    I am not sure how we can enable or disable backbone fast or uplink fast individually.

    Currently we are not enabling them individually but we are enabling 802.1w by issuing the command "spanning-tree mode rapid-pvst".

    ReplyDelete

Note: Only a member of this blog may post a comment.