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.
0 comments:
Post a Comment