In this topic, we want to take a look at few features on Cisco Catalyst Switches that can help reduce the STP Convergences Time. We saw earlier that if we had a link failure, it might take 50 seconds to Convergences, to start sending traffic around that link failure, and 50 seconds can be a very long time into Production Networks, and we already talked about Rapid Spanning Tree Protocol, and saw how it could dramatically decrease this Convergence Time.
However, if we were not running Rapid STP, a couple of these features might help us out.
Here are those 3 features
UplinkFast: - this is not something you need with Rapid Spanning Tree Protocol, because Rapid Spanning Tree Protocol has a feature similar to this built into the Standard. What this does is, it’s going to allows the Switch to detect a Direct Link failure, if a link fails on a Switch, it’s going to be able to transition a previously Blocking Port into a Forwarding almost immediately and then Reeducate the Switch topology about how to get to the Mac-Addresses that resides of that Switch, we typically see this in Access Layer Switches.
Another feature we wanna talk about, and again this feature is not needed with Rapid STP because it has a similar more feature built into the Standard, but this feature is “Backbone Fast”.
And we going to see that “Backbone Fast is going to allow a Switch to reduce Convergence Time when it detect the Link Failure, but not a Direct Link Failure, an indirect Link Failure”.
Finally, a feature that is useful for Rapid Spanning Tree Protocol as well as other flavors of Spanning Tree Protocol, and it’s “Portfast”.
When we plugging an End Station into a Switchport, instead of waiting through the Listening and Learning States for that Port to go active, let’s go active almost immediately when we connect.
The first of these 3 features are “UplinkFast”
And UplinkFast is typically going to be configured on an Access Layer Switch, in fact we do not want to configure this on a Switch that is a Transit Switch, another word, it’s a Switch that’s sits in the path between the Root Bridge, and another Switch that can cause issue for use.
For example, on Picture, we would not want to enable UplinkFast on Sw2 because that was a Transit Switch for Sw4, to get to the Root Bridge but we can enable it on Sw4 that an Access Layer Switch connected to End User devices, and when we enable UplinkFast, we enable it, Globally on the Switch, it’s not a Port Configuration parameter, it’s a Global Switch parameter, and this feature is going to react to a Direct link failure, let me show you an example.
Consider Sw4 on Picture, notice it has a Root Port that goes directly up to Sw2, let’s imagine that, that link went down.
In response to that, Sw4 has a Blocking Port, and what is Spanning Tree Protocol do, it allows a Blocking Port to transition to a Forwarding State if we lost our Primary path to the Root Bridge like we just did, and we gonna transition almost immediately because we saw that link, that port on our Switch went down. We know that we can no longer get the Root via that port, and what we gonna do is unblock that port that gets us up to Sw3.
However, we still a challenge, and the challenge is the various Switches in our network have learned how to get to the Mac-Addresses that live of that Sw4. I am pretending that we got couple of Laptop’s with Mac-Addresses of All AAAA.AAAA.AAAA and all BBBB.BBBB.BBBB. Switch Sw2 for example, thinks to get to all AAAA.AAAA.AAAA mac-addresses, i am go straight down to this link to Sw4, and Sw3 has been thinking to get to the All AAAA.AAAA.AAAA mac-address, i am gonna go over this link to Sw2, and we would go down to Sw4 but that link between Sw2 and Sw4 it’s not there any longer, and of course over time the mac-address entry would age out and things would get OK.
We want to very quickly Reeducate to this topology about, how to get to these Mac-Addresses that live of that Sw4, here is what UplinkFast can do to speed that long. It’s gonna send a series of Dummy Multicast frames, i say Dummy because it doesn’t contain any meaningful data it’s just a frame that we can propagate through out to the network, and notice the Source Mac-Address on these frames.
Their Source Mac-Address are gonna be a Mac-addresses of the devices hanging of that Sw4, that’s the way we can quickly Reeducate the topology about how to get these mac-addresses.
Now let see, how to configure UplinkFast, we enable it Globally
That’s the first of our 3 features “UplinkFast” again it’s not needed, if you are using Rapid Spanning Tree Protocol, because Rapid Spanning Tree Protocol has covered, it has a similar feature that’s built into the Standard.
Our Second feature is “BackboneFast”, and we said that “UplinkFast” should be typically enabled on a Access Layer switches, if we gonna use “BackboneFast” we should enable it everywhere on all of our networks Switches, and when we enable it, we don’t enable it at the Port level, we Globally enable it for the entire Switch and what it can do is, allow a Switch to react to an indirect Link Failure.
For example, on Picture, Sw3 is about to react to a Link Failure between Sw1 and Sw2, let imagine that, the link between Sw1 and Sw2 goes down.
When Sw2 loses that link it’s going to assume that, it is now the Root Bridge, it lost its connection to the Root, it must be the Root. So, what Sw2 will do, it’s going to send out a BPDU to Switch Sw3 saying “i am the Root Bridge”, and this type of BPDU.
This type of Bridge Protocol Data Unit is being advertising from a Sw2, that’s known as “Inferior BPDU”.
It’s inferior because the Bridge ID that being advertised as the Root, Sw2 is the Bridge ID, is inferior to the Bridge ID is being advertised by Sw1, and Sw3, when it receives this inferior BPDU, it’s gonna notice that paradox and, if Sw3 is configured for BackboneFast, what’s its gonna do, its proactively go out and check if it still has a path to the Root Bridge.
And by the way, we did not have a “BackboneFast” enabled, Switch Sw3 would receive this inferior BPDU, what it’s gonna say “that’s inferior and i am going to ignore that”, and that Blocking Port on a Sw3 it would wait for a 20 Seconds Max Age timers before it started to transition to a Forwarding state, it would wait 20 seconds, and it would go out and to Listening and Learning.
What Backbone is going to allow us to do, is eliminate that 20 seconds delay, we getting read of that Max Age timers delay because Sw3 is going to try to determined does it have a path to the Root, and Sw3 is going to do is send a message out of all of its other Non-Designated ports, another word, any ports including the Root Ports that can get back to the Root Bridge and, in this case, we just have one of those ports, it’s the Root port on a Sw3 going directly back to the Root Bridge and it sends out what’s called “RLQ”, a “Root Link Query”.
And it’s asking “hey do i still have a path to the Root Bridge”, and that query goes into the Root Bridge, and Root Bridge says “Yes you do, yes i am the Path to the Root Bridge and it’s me, it’s Sw1”, this is a “RLQ Reply” or a “Root Link Query Reply”.
That goes back to Switch Sw3, and now the Switch Sw3 knows that Sw1 really is the Root it can let, Sw2 know about that, it’s gonna say “hey Sw1 is actually the Root Bridge”.
And when Sw2 gets that information, it’s says “ok i realize now, that i had an inferior BPDU, is a better Bridge ID than i have, and as a result “i stand down and i stop claiming to be the Root Bridge”.
How do we setup BackboneFast, almost identical to way we setup UplinkFast, with BackboneFast we enabling this globally, go into global configuration mode and say
And our third Switch feature in this topic, actually is useful for Rapid Spanning Tree Protocol, as well as other flavor of Spanning Tree Protocol, in fact we already demonstrated this in previous topic. This was how, we told Rapid Spanning Tree Protocol that a Port is an Edge Port, what we can do is, configure Portfast on Ports that connect out to network End points, Printer, PC’s, Laptops and Wireless AP, another word, we are not connecting to any device that might be sending us a BPDU’s, we are not connecting out to another Switch, and we can enable on Port by Port bases or we might want to just turned it on Globally.
However, when we turned it on globally, it’s only enabled for Non-Trunking Ports, if we got a Ports that doing Trunking Portfast is not going to be enabled for that, and the reasons we huge fans of Portfast is, it allows port to go almost immediately into the Forwarding State, when we connected to a device into a Switch Port.
For example, Laptop on Picture, if i plugged into this Switch Sw4 fastetherent 1/0/1
If Portfast not enabled, it might have to wait for 30 seconds before that Ports run active, that Port was not blocking before because it was even up, so we don’t have to wait through the 20 seconds of Blocking, we do after wait through the 15 Seconds of Listening and 15 seconds of Learning for grand total of 30 seconds before this port goes active.
And with the lots of PC’s and Laptop’s today, that have SSD, they can boot up very quickly, maybe quicker than 30 seconds and they might run into issue, if they boot up in 15 seconds and send out a DHCP Request to get their IP Address and hear no response, and the reason it could happen is, it’s taking 30 seconds for the Switchport to go active.
What we can do, enable a Portfast, “where we Promising to Switch, that we not going to connect this port to some other Switch or some other Device that might be sending BPDU”, something that might cause a loop. We promising to connect this to something like an End User Workstation and we already seen on the previous topic, how to Configure Portfast on a specific port, let’s do it
That’s how we can enable it, on a Port by Port bases but maybe you wanna turned this ON all your access ports, to do that in Global Configuration Mode.
And that’s going to enable Portfast on all of our Non-Trunking ports, all of our Access Ports on your Switch and if you want to verify that Portfast is running for a particular Port on Switch we can do
That’s the look at 3 features that might help us to reduce the Convergence Time for Spanning Tree Protocol, again no need to do the UplinkFast and BackboneFast, if we doing Rapid Spanning Tree Protocol it’s already got similar features built in.
If we were using for example PVST+, these can really help us to reduce Convergence Time and we said for all over flavors of Spanning Tree Protocol “Portfast” might be good option, when we configuring the Port that connect out to an End Station.
Join me on our Next session about
Ø BPDU Guard
Ø BPDU Filter
Ø Root Guard
Ø Loop Guard
If You Like the Post. Don’t forget
to “Subscribe/Share/Comment”. Thank You.