All right, same deal here.
We are going to go through a quiz of six questions once again, and we're going
to talk
about rapid spanning tree and understand how it changes from traditional
spanning tree,
and also talk about multiple spanning tree MST and how it differs from rapid PV
ST plus.
So first question here, what is the primary mechanism used for faster
convergence in 802.1w
rapid spanning tree?
Well, rapid spanning tree, there's one takeaway we have from all of these WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, rapid spanning tree, there's one takeaway we have from all of these
conversations is
that it's going to rely on switch negotiation rather than something like faster
timers or
even requiring better bandwidth.
The idea here is that in traditional spanning tree, we're going to connect
these two switches
and they're going to send BPDUs back and forth, and the switch with the
inferior BPDU is just
going to stop sending them, leaving this switch to just sort of hope that the
other side places
it's poured into blocking or otherwise figures out another port to block.
In our situation with a rapid spanning tree, instead of simply stopping to send WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In our situation with a rapid spanning tree, instead of simply stopping to send
the inferior
BPDUs, I'm going to still send an upstream message that says, hey, guess what,
I'm going
to block my port or I'm going to be, or this is going to be my root port, one
of the two,
and as a result, we can just bring this connection online immediately.
We don't have to wait for 30 seconds.
And so even though the timers are the exact same and they are, by default, with
rapid
spanning tree, all three timers have the same values, we are still a whole lot
faster because WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
faster because
of these negotiations and messages that we can send essentially agreeing that
we are going
to establish these ports in a specific state.
Question two, what two port states were eliminated by rapid STP?
And technically there was another state that was in this, I just couldn't
really include
it for the sake of the fact that it has the same three letters, but the
disabled state
as well was removed.
So let's go and dive into this. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's go and dive into this.
Remember, what we recognize at some point is that if we're blocking, if we're
in the
listening state, and if we're in the disabled state here, that would be a port
is shut down
or not running spanning tree in either any of these cases, we're doing the
exact same
thing.
We are discarding the traffic that comes in.
As a result, this state replaces all three of these states.
So yeah, we could call it DIS.
We just have to be careful because DIS stood for disabled and the traditional WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We just have to be careful because DIS stood for disabled and the traditional
spanning
tree.
And so that's why I couldn't include it in the question.
But either way, we only have three states.
We have forwarding.
We have learning and we have discarding.
Just keep in mind a couple of things.
First of all, even though listening doesn't actually show up in the command
line, it's
pretty rare that we actually see states in rapid spanning tree.
We don't typically progress through listening and learning, so to speak.
But if we do see it happening, we will see it go through the discarding state WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But if we do see it happening, we will see it go through the discarding state
and then
directly into the learning state still for 15 seconds at a time by default.
So we do still wait for 30 seconds if we don't get those negotiations to work
for whatever
reason.
But also we don't see this happen very often because again, rapid spanning tree
brings
ports online immediately in most situations.
The other thing to consider is that Cisco still uses BLK at the command line.
So we do show spanning tree.
We're going to see BLK representing a discarding link.
And so the terminology can get a little bit, get our wires crossed, I suppose, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so the terminology can get a little bit, get our wires crossed, I suppose,
a couple
of times when we're running Cisco commands between traditional and rapid
spanning tree.
But do be aware that there are only three states in rapid spanning tree.
So that was a question on port states.
Let's talk about port roles.
Now we want to identify the rapid spanning tree port role used for each of the
following
topology locations.
So when we're looking at a connection here, we're going to have the concept of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So when we're looking at a connection here, we're going to have the concept of
let's
say this is the root port, we're going to have downstream ports, we're going to
have
upstream ports, we're going to have potentially other upstream ports that could
go a different
way.
And then we might have two different types of downstream ports, one where we're
blocking
and one where we're not.
So same thing here, we might have one that we're blocking on the left and one
where we're
not going straight up.
So these are the four situations where we need to figure out what port role is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So these are the four situations where we need to figure out what port role is
used for each
one.
So as we go through these upstream blocking, if I'm blocking this, this is
going to be
serving as an alternate port.
Remember we got rid of the blocking or the non designated, we're just saying,
Hey, this
is an alternate port.
If this link goes down, my my upstream forwarding port goes down, I can
immediately transition
this into the forwarding state, that makes it an alternate port.
My upstream forwarding is simply my root port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
My upstream forwarding is simply my root port.
This doesn't change from traditional spanning tree.
The one that faces the route that's my best path to the route is going to be my
root port.
Now downstream is interesting because usually we are forwarding downstream.
At this point, we call this a designated port.
And this again doesn't change from traditional spanning tree.
But what is that downstream blocking situation?
Well, again, we have a situation where we might have a hub in the network.
And if we have two connections going into a hub, these BPDUs are going to cross WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we have two connections going into a hub, these BPDUs are going to cross
through
the hub and we're going to see essentially our, we're connecting to ourselves.
And technically, if we have a switch and we loop a cable between two ports,
then we'd
see this as well.
So whichever one of these is in a forwarding state, that's going to be my
designated port,
whichever one is in a blocking state, that is going to be a backup port.
It's essentially saying that, hey, if for any reason this other link goes down,
I can
bring this online. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
bring this online.
It's just not going to come online quickly and that's fine.
We can't really use rapid spanning tree mechanisms where there's hubs or other
wacky things
like this happening in the network.
For the most part, we're not going to see a whole lot of backup ports in our
modern
networks.
We should see one root port as many alternate ports as we can have.
And paths to the root, those would be all of our blocking ports.
And then as many designated ports as we have facing downstream.
Question four, how does an RSTP or rapid spanning tree device respond to a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Question four, how does an RSTP or rapid spanning tree device respond to a
change in the STP
topology?
This is a big conversation in traditional spanning tree and rapid.
It's the topology change notifications.
The goal is to convert spanning tree, but in a way where we're not black hole
in traffic,
where maybe because of the topology change now, I should send a packet that I
get in.
I should send it this way instead.
But before the change, I should have sent it this way.
So I still think that I should send it that way, even though spanning tree is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I still think that I should send it that way, even though spanning tree is
converged,
even though maybe there's a switch down here that used to connect upstream and
it's no
longer there.
And therefore, this is going to black hole the traffic just going to send it
off and
let it get dropped.
So we want to update this as fast as possible.
The problem is that rapid spanning tree is so fast that we just have to do what
B suggests,
which is to flush our Macaductress tables and set the aging timer to zero.
Now the amount of time we do that is for three hello timers, which might be six
seconds
if we're using the default value. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
if we're using the default value.
So it's not for a very long time, but it's all the more reason to reduce TCNs
in the environment.
One of the ways we can do that is by putting port faster, port type edge ports
everywhere
where we have end devices connecting.
Because every time I exist in this topology change status of having an aging
timer set
to zero and flushing my Macadress table, I'm going to be flooding a lot of
traffic because
I'm not learning any Macadresses.
So it's going to turn my network into a massive flooding domain. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it's going to turn my network into a massive flooding domain.
And again, for six seconds, that's fine.
But if it continues to happen constantly, then we have a big problem,
especially in a
rapid spanning tree environment.
All right, question five, what does multiple STP or MST accomplish that Cisco's
rapid
PVST plus is unable to do?
Well, this is a big factor with MST.
MST looked at rapid per VLAN spanning tree and said, hey, what you guys are
doing is
great. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
great.
However, it's inefficient.
If I have 100 VLANs, then that's going to be 100 topologies.
And that's no good.
We would rather say, hey, you define however many topologies you want in most
modern networks,
we can get away with two topologies.
And then we map the VLANs into the two different topologies.
And so that's exactly what MST is going to be able to do.
It's going to be able to deploy an efficient number of topologies, not making
it so that
we have to send BPDUs for every single VLAN, not making it so we run the risk
of enabling WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of enabling
so many VLANs that we run out of spanning tree topologies as we demonstrated.
All right, last question here.
And this is a big one.
What are the three MST attributes, there's three of these that must match among
switches
in the same layer two region?
I left this as an open ended question because I wanted us to pause this video
and make sure
that I can bring these to mind myself without having to go and look it up.
If you do have to look it up, that's perfectly fine.
But again, we should know what these three attributes are because we have to
configure
them every time in an MST environment. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
them every time in an MST environment.
So these three attributes don't exist in PVST plus or rapid spanning tree alone
.
It's an MST specific concept.
So it starts with the region name.
I have to name this region and we all have to agree on what that name is.
It's just going to be a string.
It could be CBT and or something along those lines or it could be your company
name, whatever
we want to use.
Next we have that revision number. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Next we have that revision number.
And even though it's great that we have the concept of being able to say, hey,
I'm making
a change, I'm going to increment this for maybe revision number one to two in
the real
world.
We may or may not use that, but just understand that we do have to match on
that revision
number, whether we use it or not.
And lastly, this is a big one as well.
We need to make sure that the VLAN to instance mapping is the same.
These are going to hash perform a hash of the VLANs and instances to share them WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
These are going to hash perform a hash of the VLANs and instances to share them
with
one another, compare the hashes and make sure that they're identical.
And so again, if we have two topologies here, maybe I'd throw VLANs 10 through
15 into this
instance, VLAN 16 through 20 into this instance.
But either way, we have to agree on this as well as the instance number, by the
way, maybe
instance zero here and instance three over here for whatever reason.
But if we don't agree on all three of these, then we are going to act like we
're completely
different topologies.
And that's going to change the rules for how we end up blocking between the two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that's going to change the rules for how we end up blocking between the two
different
domains that we or however many domains we end up creating.
So this was again, a, a an opportunity for us to identify areas of weakness to
say, hey,
maybe I should go back and review MST or rapid per VLANs, bandage, plus or
whatever the
situation is.
If not, hey, then we're good to go and we can move on.
It's time to jump into the lab and make sure we remember how to configure these
protocols.