Well, here we finally are.
We are ready to talk about rapid spanning tree and find out what exactly it is
that makes
it so much better than traditional spanning tree.
So traditional spanning tree we often refer to as 802.1d, it's the IEEE's
standard specification
for how exactly spanning tree should be deployed into environments.
Well, they updated this to this rapid spanning tree via a specification which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, they updated this to this rapid spanning tree via a specification which
is 802.1w, the
w is lowercase there.
And yes, as the name implies, it is going to greatly speed up our convergence.
The challenge is understanding how exactly it accomplishes this goal.
Because we might make the bad assumption that this has something to do with
timers.
We have these long timers in traditional spanning tree.
We have forward delay and we have to wait two of those to bring a port online
so it takes
30 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
30 seconds.
And so maybe we're going to drastically decrease the timers or something along
those lines.
But that's not how it works.
In fact, it uses the exact same timers as our traditional spanning tree.
Instead, we're going to accomplish this by allowing our switches to perform
negotiations.
We're going to allow our switches to talk to one another.
So that if one side decides it's blocking, the other side becomes aware of that
.
And at that point, they understand what the other side is doing and they can
make decisions WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
make decisions
faster.
Now before we get into the differences between traditional and rapid spanning
tree, what
exactly is the same as our 802.1d traditional spanning tree?
There's a reason why we spent so much time on 802.1d.
Just because rapid spanning tree uses a lot of the same principles as
traditional spanning
tree.
For example, as we already mentioned, the timers are going to be the same.
Our root election is going to be the same.
Our decision making around who has the best priority or ultimately the best WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Our decision making around who has the best priority or ultimately the best
bridge ID
because it's always going to go by lower MAC address if priorities are tied,
that all
remains the same.
We're going to see that our BPDU flow is mostly the same.
But at least is going to continue to flow downstream from the root.
But at the same time, when we say from the root, we just mean directionally.
There is a difference with how BPDUs are generated and we'll talk about that
later.
So put a little, maybe more of an asterisk on the BPDU flow for now. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So put a little, maybe more of an asterisk on the BPDU flow for now.
But again, the focus here being that it flows away from the root remains the
same.
We also have concepts like our priorities.
I suppose we just mentioned as part of root election, but we also look at
spanning tree
costs, our port priorities, all of these decisions that are made around these
concepts, they
are going to be made the exact same way.
And then for that matter, when we look at our iOS XE commands, once rapid is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then for that matter, when we look at our iOS XE commands, once rapid is
enabled,
which takes its own command, well, then all of our iOS XE commands are going to
feel very
similar.
And identical, we're using the same show commands, the same debug commands
regardless.
And finally, those protection mechanisms that we just got done talking about,
if you're
working way through this course sequentially, we talked about Cisco creating
mechanisms
such as BPDU guard and root guard. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
such as BPDU guard and root guard.
And then we have UDLD and such.
So we'll just say it said right here because all of those loop guard included
are going
to remain the same and yes, we should absolutely be deploying these into
production as we emphasize
when we covered the topics.
That doesn't change when we talk about rapid spanning tree.
Finally, this is a big one.
Per VLAN spanning tree is back.
When we talk about rapid spanning tree on a Cisco switch, it's going to use WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
When we talk about rapid spanning tree on a Cisco switch, it's going to use
rapid PVST
plus.
This just means that we're doing the exact same thing that Cisco does with
traditional
spanning tree in that we get a topology per VLAN, whether we want that or not,
doesn't
matter because we cannot disable the per VLAN nature of rapid PVST plus.
So we're either running our traditional PVST plus or running rapid PVST plus.
Those are only two choices outside of MST, which we'll be talking about coming
up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
up.
So then we have to say, if we know what is the same, we have to ask the
question of what's
new.
And this, the negotiation concept is the biggest concept here.
We are going to see that our switches, again, are going to send messages to one
another that
allow them to make faster decisions.
This happens out of band relative to the timers.
The timers will still run in the background.
I mentioned that it's the same, right?
But they are going to be more of a fail safe when we can't use rapid mechanisms WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But they are going to be more of a fail safe when we can't use rapid mechanisms
.
But it's important to understand when we can use rapid mechanisms.
Rapid mechanisms is going to require an underlying assumption to be proven true
, which is that
we have point to point links between switches.
In other words, no hubs.
Always remember that spanning tree was designed to handle hubs.
We had the capability of having a hub here in the middle and our two switches WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We had the capability of having a hub here in the middle and our two switches
could connect
into the hub and then we could have a bunch of hosts hanging off of this hub.
And we've talked about how some of these Cisco mechanisms, these protection
mechanisms,
work around some of the problems that that can cause especially in modern
networks.
Well, rapid is going to say we're no longer going to support hubs, at least on
links where
rapid mechanisms exist.
So we're going to define two link types.
We're going to call one point to point spelled like this on Cisco iOS XE. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to call one point to point spelled like this on Cisco iOS XE.
So capital P number two lowercase P, which again simply means point to point,
which has
a couple other implications.
First of all, it means we're connecting switch to switch directly.
And second of all, it must be running full duplex.
Because if we're running half duplex, that means there might be a hub between
the switches.
So then we have another link type that we call shared.
Shared is simply saying that it's half duplex. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Shared is simply saying that it's half duplex.
It's not necessarily saying that there's a hub there.
It's saying, or what it is saying is that we don't know whether there's a hub
there.
Now we can configure a link to run in either one of these modes.
However, by default, it's going to rely on the half and full duplex
configuration to
decide which mode it's running on.
And as we might imagine in modern networks running gigabit and 10 gigabit
speeds, most
if not all of our ports will default to point to point, which means that rapid
mechanisms WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
mechanisms
are going to work on all of those.
But it is worth noting that the speed of rapid spanning tree can only be
achieved on
these point to point full duplex connections.
So the question then is, do we need timers?
Are they required at this point?
And the answer is still yes.
However, the primary purpose of timers is going to serve as a backup to our
rapid mechanisms.
In other words, if one of two situations is true, either we have no BPDUs WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In other words, if one of two situations is true, either we have no BPDUs
coming in,
meaning I can't negotiate with the switch on the other side because I don't
sense that
there's a switch on the other side.
And maybe there's not one, or if it's running in half duplex and either one of
these scenarios,
we are going to have to use timers.
And as I mentioned, all the timer values share the default settings from
previous the traditional
802.1d values.
However, there is one caveat to that, which has to do with max age. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However, there is one caveat to that, which has to do with max age.
Now max age still has the same value of 20 seconds.
That part doesn't change.
But the question has to do not with our backup mechanisms, but actually how
exactly does
rapid PBS D plus in our case?
How does rapid handle timing out of BPDUs?
Because the BPDU timeout concept is that I haven't received a BPDU in a while,
and therefore
we need to time it out.
And so we normally use max age for that, but 20 seconds is a very long time in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so we normally use max age for that, but 20 seconds is a very long time in
the rapid
spanning tree world.
So when we're running with rapid mechanisms, we don't actually use max age
anymore.
Instead, we simply use a calculation based on hello timer.
We say it's three hello timers.
Now if hello time is set to two seconds, that would be six seconds by default.
And so if we change hello timer, then that value would change as well.
So just understand max age still is set to 20 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So just understand max age still is set to 20 seconds.
It's still used as a backup mechanism, but the BPDU timeout element of max age
when we're
running rapid spanning tree is not going to actually be based on the max age
timer.
It's going to be based on the hello timer and specifically three of the hello
timers.
So once again, rapid spanning tree achieves its speed when possible, requiring
these point
to point links.
And it does that using these negotiations between switches rather than relying
on faster
timers or any other mechanism.