So now we're going to take a look at Spanning Tree Protocol convergence,
configuration, as well as manipulation to get ourselves ready for the certification exam.
So these are the four different states that we find with Purveyland Spanning Tree Plus.
Rapid Purveyland Spanning Tree Plus is just slightly different but not a whole lot different
and we'll explore that when we get to it. But with Purveyland Spanning Tree Plus of
Cisco's proprietary modified version of 802.1d, remember, we have the blocking state,
the listening state, the learning state, and the forwarding state. So the blocking state you've
seen it is when our ports are blocked. The forwarding state you've seen it's when our
ports are root port or designated ports. So in the blocking state we're not going to allow any
traffic to flow through it. We are blocking that user traffic so that way there we can ultimately
prevent our loops when it's all said and done. So this is a stable state. This is a good state
to be in. There's nothing wrong with being in the blocking state. Forwarding is when we learn MAC
addresses, populate our MAC address table, forward our frames, all of that fun stuff, root ports.
Again, a stable state is what we're dealing with here. So listening and learning are
transitionary states. They are transitionary states, meaning that we have a port that is
transitioning from being, for example, like a block port to a forwarding port. So when you are
a block port, you will remain a block port until something changes in the topology. So when
something changes in the topology, you will ultimately receive a BPDU in that environment
that is different than the one you have been receiving. Why? Because something has changed.
And when something changes, then BPDUs will change slightly. Why? The information in them
slightly changes. And as a result of that, that BPDU arrives to you, and you look at it,
and then you do your calculation. So remember, BPDUs are being sent every two seconds. Our hello
time is every two seconds. So what we have is we have our BPDUs constantly being sent,
and if they're always the same, then we're stable. But if something changes at all, and we have a
change, like in our environment, a link goes down, a link goes up, a device disappears,
a device comes in, whatever it is, then our switches can generate what is called a topology
change BPDU. And that topology change BPDU will help us transition from what? From blocking to
listening to learning to ultimately forwarding when it's all said and done. So if, for example,
you receive a BPDU in a block port that is different than what you've been receiving,
then you are going to take that information, and you are going to run with it,
meaning that you are going to look at it and say, oh, look at that. This is different,
and it looks like I should no longer be blocking. So you are then going to move to the listening
state. However, what if you simply stop receiving BPDUs on your interface? If you stop receiving
BPDUs on your interface, it typically means that the upstream device from you doesn't exist
anymore. So if you stop receiving BPDUs on your interface, or you don't receive any BPDUs at all,
then what happens is you've got about 20 seconds. This is what we call our max age timer.
And that max age timer, every time you receive a BPDU, goes to 20 and starts counting down.
So if you're receiving BPDUs every two seconds, then essentially your max age timer goes 20,
19, 18, 20, 19, 18, 20, 19, 18, 20, 19, 18. And then let's say you stop receiving BPDUs. Well,
then what happens? 17, 16, 15, 14, 13, right? Eventually, it hits zero. At that point in time,
the max age expires. And what do you do? You've got to transition to the listening phase at that
point in time. So a couple of different ways from the blocking phase in order to get to the
listening phase. But regardless of whether it's the max age timer expiring because you stopped
receiving BPDUs or you received the topology change notification BPDU that ultimately says,
hey, it's time for you to change. Well, then eventually you end up in the listening phase.
So when you're in the listening phase, this is a transitionary phase. You never stay in the
listening phase, right? And when you're in the listening phase, you are listening and processing
BPDUs. So what does that mean? You're listening, you're waiting for, hey, if I keep receiving BPDUs
on this port, then what I'm going to do is I'm going to keep seeing if they're the exact same
over and over and over again. So I received a BPDU that when I was in the blocking phase that
essentially informed me that I should go to the listening phase based on the calculation I did
on it. So now that I'm in the listening phase, I want to keep double checking, triple checking,
quadruple checking, right? And just making sure, is that the right decision? Is that the right
decision? And so I just keep receiving the BPDUs. So if the BPDUs that keep coming in are the exact
same over and over and over again, then I know I've made the right decision. If another BPDU
comes in that changes my mind, well, then we're going to change our mind at that point in time.
But the idea here is that the topology around us should be the way it needs to be at this point in
time. And as a result, I'm just double checking, double checking, triple checking, triple checking,
right? And that's all I'm doing in the listening phase. And we're going to do this for 15 seconds.
We call this the forward delay time. Make sure you know that. 15 seconds is the forward delay
time. That's how long we spend in the listening phase, right? That's for a different position.
No, that is for something else. We're going to talk about PortFast later, right? So PortFast
would not apply here right now as part of this discussion. So we have our forward delay time.
And so now my port. So for example, the ports would be these ports here we were talking about
earlier. So if we go back to like, for example, this page here, right? As this is deciding whether
it should be designated port, as this is deciding whether it should be root port, whatever that is,
we are spending 15 seconds hanging out in the listening phase, double checking, double checking,
triple checking. So, all right, I've decided to be a designated port. Am I going to keep that?
And then you just keep double check every two seconds when a BPDU comes in. So you do that
for 15 seconds. And then after 15 seconds is over, then you move to the learning phase.
So when you're in the learning phase, what does that mean? It means you're doing basically the
same thing as the listening phase, still receiving those BPDUs and double checking,
triple checking, quadruple checking. But you're also going to start pre-populating
your MAC address table. And so you're going to do this for 15 seconds, which is forward delay.
Again, so you do forward delay twice, one for the listening phase, one for the learning phase.
And then if no BPDU comes in, that changes your mind. Whatever decision you made,
if you decided to become a designated port in the listening phase, or you decided to become a
root port in the listening phase, well, then nothing has changed your mind for 30 seconds.
Now you're forwarding. So best case scenario takes 30 seconds for you to
confirm that you should be a designated port or a root port. Worst case scenario, it's 50 seconds.
Because 50 seconds in total from here to here, or best case scenario, only 30 seconds. So for
example, if a port comes up for the very first time, it's going to receive a BPDU or not receive
a BPDU depending on the scenario and situation. But if it's a port that just comes up, then it
immediately goes to the listening phase. And if it's not receiving BPDUs, it'll go listening,
learning, then it becomes a designated port if it doesn't receive any BPDUs.
But if it receives a BPDU right away in the listening phase, then it's going to have to make
a decision. Based on this, should I be blocking? If I should be blocking, I'm going to block right
away. I'm not even going to wait. I'm just going to block. But if I decide I should be a root port
and designated port in the listening phase, then I got to wait. Then I got to wait. Then I got to
go. So 30 seconds, worst case scenario in that situation. But if you're currently a blocking
port and you stop receiving BPDUs, then it could take up to 50 seconds to fully go to the forwarding
state in that particular scenario. So remember that your hello time is two seconds and you can
tune that. For example, you can go to your global configuration mode and type in the
spanning tree VLAN10 and set your hello timer. You can set your forward delay timer. You can
set your max age timer. But always remember, if you start manipulating your timers,
then that is going to put more pressure on your device to process more and more and more and more
BPDUs and possibly make decisions prematurely. And as a result of that, you could end up in
flip-flapping situations until it sorts itself out. So typically, the default timers are the
best way to go. And if you want to speed yourself up and you don't want to spend all that time,
then switch protocols, okay? Don't manipulate your timers for these two. That's silly, right?
Instead, you might as well go with these. And what makes these faster? Is it faster timers? No.
The same timers are used if and only if they are needed with, I should say, all three of these.
Why is that? Because the timers are only needed if the device you're talking to
doesn't speak the same version of spanning tree protocol. So for example, if I have a switch here
and I have another switch here and we're both running rapid per VLAN spanning tree plus,
rapid per VLAN spanning tree plus, we don't need timers anymore. We're still going to have the
timers just in case something goes wrong. But because we're both rapid per VLAN spanning tree
plus, we have a handshaking mechanism. It's called a proposal and agreement process.
So essentially, we have the ability to talk to each other whenever changes are happening.
And so because we have the ability to talk to each other when changes are happening,
we have the ability to make sure that we can make changes very, very, very fast without causing a
loop and having to worry about timers to confirm that we've made the right decision. So with these
two protocols, we're relying on simply timers timing out to determine if we made the right
decision. Whereas with these ones, we're using the proposal and agreement process to determine if we
made the right decision. And if for some reason the proposal and agreement process doesn't work
or it fails, then we'll just use our timers. And so worst case scenario with rapid per VLAN spanning
tree plus, it is going to be like 30 seconds as an example if an interface comes up. Best case
scenario, it can be instantaneous, two seconds or less based on the proposal and agreement process.
Here is two charts just showing us the port rules, port states, and operational effect of
spanning tree protocol versus rapid spanning tree protocol. So for example,
it doesn't matter whether this is 802.1D or PV or PVST plus. We're talking about the same thing
or 802.1W or multiple spanning tree protocol or rapid per VLAN spanning tree plus or 802.1S.
Okay. So all of those would apply to the chart on the right. 802.1D, PVST plus applies to the chart
on the right, left. So as you can see here, root port, designated port, forwarding, forwarding,
they're all the same. That doesn't change at all. That's all the same. The only difference here is
that we can be more rapid, faster at figuring out the root ports and designated ports based on the
proposal and agreement process over here, where here we have to rely on those timers timing out
before we can actually go to the forwarding state. Notice over here in our spanning tree protocol
ports, we've got non-designated ports that are the blocking ports. So that's like the traditional
spanning tree protocol, 802.1D, without any additional features added that were invented
after the fact. It is like if you're blocking, you're blocking, that's it, that's all. And if
any changes happens, you're going to have to go through the whole process with timers and everything
else. Eventually, there were some additional features added like backbone fast, uplink fast,
and stuff like that. So you could speed up the process, speed it up to what, like maybe bypass
the forward delay timers with something like uplink fast. So you could immediately transition
a blocking port to a root port. That was something that was added after the fact, backbone fast,
making just, making the changes faster. So instead of having to wait for the 22nd max
age timer to expire, you could just immediately change right away. So a lot of those features,
though, don't matter anymore because they're baked in the rapid spanning tree protocol.
They're baked in the rapid spanning tree protocol. So instead of just having like
non-designated ports in the blocking state, we now, as you can see, have two different types
of ports called alternative and backup. And they're listed as discarding. I mean, it's still blocking
when it's all said and done. But what I want to point out to you is that we have these ports so
we can transition faster. So not only do we have the proposal and agreement process, but we have
the alternative ports and we have the backup ports. So here's an example of an alternative port on a
switch. An alternative port can become the root port immediately if the root port on that switch
fails. So basically, your switch has determined, if I go this way and this is discarding, I have a
loop-free path. If this fails, then this can immediately become the root port. Why? Because
I know it's an alternative loop-free path as long as this link doesn't exist. So if anything ever
happens to the communication or connection between these two switches, this immediately
becomes the root port, like right away, instantaneously, within milliseconds.
And therefore, traffic is probably not going to be affected when it's all said and done.
Right? That's just alternative port. The backup port, most of you are probably never going to see.
The backup port exists because – or the backup port is a port that can become the designated port
if the designated port fails. The only way that works is if you have two ports connected to the
same link, connected to the same subnet – sorry, segment, not subnet. You have two ports on that
You have two ports on that switch connected to the same link, the same segment, the same
collision domain. So to make sure you understand this fully, you see this designated port here.
Do we have another port on this same switch that is connected to the exact same link,
the exact same segment, or the exact same collision domain?
No, we don't. No, we don't. Right? This is a totally different one.
So in this case, you would never see a backup port for here or a backup port for here.
A designated – a backup port happens when you see your own BPDU. That's right. When you see
your own BPDU. So if I send a BPDU at this port, am I ever going to see that BPDU again? No,
you are not. Because that BPDU gets gobbled up by this switch. This switch generates its own BPDUs
and sends them out, gets gobbled up by this switch. This switch generates its own BPDUs,
sends it out, gets gobbled up by this switch. So no, this switch will not see its own BPDUs.
So therefore, no backup ports in those scenarios. So I'm going to see a backup port when? When I
have two ports on the switch in the same segment, link, or collision domain, and I receive my own
BPDUs on that link, collision domain, or segment. So here's an example of this. This is a hub.
This is a link. This is a link. Although it's two different physical links,
what you need to remember is that a hub is a layer one device. Meaning it's a bit spitter.
Bits come in an interface, bits get spit out all the other interfaces. So when I send a BPDU this
way, it gets sent, sent, sent, sent, sent, sent, sent, and then sent back up here. Now I just saw
my own BPDU. You see that? So even though it's two different physical links, we are in the same
collision domain. We are on the same segment. We are technically one link according to what?
According to Spanishy protocol in this case. So we do have a loop here. When you think about it,
when it's all said and done now. Because the hub does not understand BPDUs. So I send my BPDU,
it arrives back in this side. I send a BPDU at this port, it arrives back in on this side.
So what happens? Cost is tied. Upstream bridge ID is tied. Therefore the sending port ID is the
winner. When it goes out this way, it's 128.1. When it goes out this way, it's 128.2. Therefore
128.1 is lower. Therefore it becomes a designated port and this becomes the block port. In this
case, discarded backup port because it's a port that could immediately become the designated port
if this port fails. That's what's happening in that scenario. So you're only going to see
a backup port in this type of a scenario or let me show you another type of scenario.
I mean, we all do this, right? There you go. Now, you would see one of these is a designated
port and the other one's a backup port. I mean, because this does a lot for us. I mean,
but there you go. If you ever want to see a backup port, if you want to see it,
just do that on your switch and look, you'll see you'll have a backup port.
All right. So, be able to pick these terms and items out of a lineup on the certification exam,
folks. Now, what you're going to see here also is that when we are transitioning,
we talked about listening and learning. Well, with Rapid Spanning Tree Protocol,
we don't have listening and learning. We only have learning. So, we have 15 seconds here,
which is our forward delay timer. We have 15 seconds here, which is our forward delay timer.
15 seconds here, which is our forward delay timer. But over here, we have 15 seconds times
two. We go through learning twice. So, we go through learning twice. So,
that way there, we can be backwards compatible. Backwards compatible.
So, let's go ahead and show you how to switch over to Rapid Spanning Tree Protocol because right now,
we are running Per-VLAN Spanning Tree Plus on our device. And how do I know that? Because it
says IEEE. That means Per-VLAN Spanning Tree Plus. Per-VLAN Spanning Tree Plus.
So, let's go over right now and type in, configure terminal, Spanning Tree Mode,
and you'll see that this device supports Per-VLAN Spanning Tree Plus,
Multiple Spanning Tree Protocol, and Rapid Per-VLAN Spanning Tree Plus. So,
PVST and Rapid PVST are Cisco proprietary. They don't work with non-Cisco devices. Keep that in
mind. All right. So, let's switch over to Rapid. Okay. Now that I'm Rapid, type in show span
Per-VLAN 10. You'll see now it says Rapid Spanning Tree Protocol for us.
Okay. Let me just refresh this because everything should be good now so far. All right. Still not
good enough in my opinion. There you go. That's looking perfect now. So, you'll see here that
because DSW1 is Rapid Spanning Tree Protocol and the rest of my switches are not Rapid Spanning
Tree Protocol yet, it even tells me that over here. Your peer out these interfaces are running
Spanning Tree Protocol, Per-VLAN Spanning Tree Plus. So, what does that tell DSW1? It tells DSW1
that whenever it wants to communicate with any of the switches out of these ports, it cannot use the
proposal and agreement process. Why? Because they're not running Rapid Spanning Tree Protocol.
Now, do the other switches know that this is Rapid? No, they don't. Okay. So, only the Rapid
device knows about the non-Rapid devices. The non-Rapid devices will not know that the Rapid
devices are actually Rapid. So, we can verify it here. If I go to, for example, like ASW1,
it doesn't have any information about whether your neighbor is Rapid or non-Rapid. Why? Because it
doesn't matter, right? Because Per-VLAN Spanning Tree Plus is always going to run as Per-VLAN
Spanning Tree Plus. It's the Rapid side that has the ability to operate as one or the other.
So, in this case, even though this is Rapid, everybody else is non-Rapid, there really is
no benefit because we're still going to be behaving like regular Per-VLAN Spanning Tree Plus.
So, let's go over to DSW2 as an example now and change that over here.
So, Spanning Tree Mode Rapid. So, we'll let that cook just for a moment and we'll see that
we now don't have that information there. So, if you're ever looking at this output
and you see something like Rapid Spanning Tree Protocol, just by looking at this output,
you know that whoever's out 17, 18, 19, and 20 is also a Rapid-speaking device,
whereas 21, 22, 23, 24 is a non-Rapid-speaking device.
All right. So, let's go ahead and adjust this on all our devices.
I'm going to change my cost back.
So, that way, there we have consistent cost. There we go. All right. So, go back to DSW1
and we'll see that we shouldn't have pure STP anymore. So, we're Rapid for all of our devices
now. So, now we want to start talking about how we manipulate this. So, we're going to go back to
DSW1. So, now we want to start talking about how we manipulate Spanning Tree Protocol.
So, let's look at this environment here. Right now, the environment looks like this. This was
the diagram that was produced based on this information here. So, all of this information
here, folks, ultimately, with our default port costs, was able to produce this diagram for us
here. Now, my equipment that I'm using today does not equal what we see here. So, for example,
if we go to ASW1 right now and we look at the output of Spanning Tree VLAN10, we'll see here
that the root port, it's listed here, the root port, as well as down here,
is gigabit one size zero size 47. So, it's actually this port going this way.
And if we look and we follow that path, we follow that path. Let me write that in here.
This is going to be the root port here right now in my diagram.
And if we follow that path up to DSW2 and we type in show Spanning Tree VLAN,
we're going to see here that I am the root bridge right now. So, I am actually the root bridge.
So, the topology that we have right now does not equal what we have seen here. So, let's go ahead
and show you how you can manipulate Spanning Tree and change the entire architecture, change who the
block ports are, who the root ports are, who the designated ports are. And we're going to show you
a couple of different ways that we can do that. But before we do that, let's make sure that we
have the ability to verify the changes after. So, right now, take a look at this. This is DSW1
compared to what you see here. That's a big, significant difference. It really is. You look at ASW2.
We have our root port as 47. This is what we have right now.
And blocked everything else. And then DSW2 is our root port.
And then DSW2 is our root bridge. Right? So, what is one way that we can manipulate this entire tree
in one shot? Change who the root bridge is. That's how we can do that.
Yeah. So, how do we do that? Well, we can't manipulate the MAC address of the root bridge,
but we can manipulate the what? We can manipulate the priority that the root bridge is using.
Right now, everybody's using 32,768 by default in my environment.
In my environment. And as a result of that,
DSW2 has elected the root bridge, in my case, in our live environment.
So, if we start manipulating priorities, we could ultimately manipulate who the root bridge is,
because we're manipulating what? The bridge ID. So, if we go back to this diagram here,
recall that we're manipulating these upper four bits. So, we're manipulating the upper four bits.
It means we're allowed to do what? We're allowed to increment in 4,096.
As it showed right here.
Because there's other values for the VLAN. And right now, we're just manipulating VLAN10 as an
example. So, who do I want to become the root bridge in this case? I want
DSW1 to become the root bridge in our case. So, right now, DSW2 is,
but I want DSW1 to be the root bridge. So, how would we do that? Let's type in configure terminal,
type in spanning tree. And this is something you can do on a VLAN by VLAN basis.
That's why we have the ability to manipulate our trees
individually on a VLAN by VLAN basis. And that's why we have the ability to manipulate
we have the ability to manipulate our trees individually on a VLAN by VLAN basis on Cisco
devices. So, let's focus on just VLAN10. You'll see here that I have the opportunity to specify
the priority of this device in increments of 4,096. So, let me put in 5,000 so I can get this
error. And those are the 16 different possible values. The default value is 32,768.
And since we're dealing with VLAN10, your values are these plus 10. You just put in these values,
and it automatically adds 10 to it. So, if we're 32,768 right now for all of our devices,
what number could we pick folks to force DSW1 to become the root bridge?
Well, anything lower than 32,768, that's on the list. Absolutely, any one of them.
So, we could choose any one of these top values here and accomplish our objective.
Now, let me ask you this. What would be the best value to use in your opinion?
Zero, right? Because remember, we always said lower is better with spanning tree protocol.
So, if lower is better, zero would be the best number to pick if you want this device to be the
root bridge because you can't get any lower than zero. So, that's the recommended best practice is
best practice is your root bridge for that VLAN, just set it to zero.
That is the recommended best practice. Now, if you don't follow that,
that's fine. That is your choice. Whatever works for you, works for you.
But in this case, I ensure that down the road, if anybody accidentally runs this command on another
switch, the chances of them becoming the root bridge are far less. Why? Because I am already
zero. The only way they would be able to become the root bridge if they're also set to zero
is if they have a lower MAC address. That would be the only way.
So, I give myself the best chance of being the root bridge by using zero. It doesn't guarantee
it because if somebody else comes along, they get a priority zero, they have a lower MAC address,
then they're the root bridge. All right. So, now that this is done, let's take a look at
show spanning tree VLAN 10.
And what we're going to see is that now my priority is zero plus 10 for a grand total of 10.
And everybody else is still at 32,768. So, because of that,
I am the root bridge. It's also recommended. And so, my topology would look like this. So,
let's verify the topology before we do anything else.
Now, is every single port designated like we have up here? Yes, it is.
Let's go to DSW2 for VLAN 10. Is 17 the root bridge, 18, 19, 20 blocking? Yep. The rest
designated ports? Yep. All right. Let's go to ASW1. Is gigabit 1.0 size 45 the root port? Yes,
it is. 46, 47, 48. What? Yes, it is. Look, gig 1 and 2 designated ports. Perfect.
What about ASW2? Show a span for VLAN 10. We've got 45 root port. Perfect. And the rest are
blocking. So, as you can see, by manipulating who the root bridge is, you change the entire
topology. Now, do we ever want these devices to become the root bridge? Do we ever want them to
become the root bridge? And the answer is no, because if they're the root bridge,
that could change the path of the flow of traffic. So, for example, let's say this is
the root bridge. If this is the root bridge, and right now this is the default gateway,
it is possible, right? It is possible that your traffic flow could do this. I am not joking about
that. And you would not want that at all, right? It is possible that could happen.
So, the moral of the story is this. Always, always have your root bridge as close to your
distribution layer switches as possible, meaning on those distribution layer switches,
at the entry and exit point to the layer 2 environment. That is the best practice,
so you typically get the best results. But you could still mess up. For example, even if this
is the root bridge, is it possible that traffic could end up doing this if I'm not careful?
Absolutely. Absolutely. So, you got to be mindful of your environment and know how to
look at the results of Spanning Sheet Protocol and determine, is this the right traffic flow we want
under normal operating conditions? The answer is yes, then you're good. If not, then you want to
manipulate it to get what you need. So, one of the things we want to do is make sure if we ever
have a failure of this device, we don't want that device. We don't want that device. Sorry,
if we ever have a failure of that device, we don't want these devices to ever become the root bridge.
So, if this is my primary root bridge, I want this to be my secondary root bridge
because I want to maintain this right here. So, we can set this one to the next best priority.
So, when we looked at our priority numbers, what did we have? We had zero, 4,096. So, we could do,
for example, on DSW-2, set the priority for VLAN 10 to 4,096. So, Spanning Tree, VLAN 10,
priority, 4,096, and that will ensure that if something happens to DSW-1,
I will become the root bridge because you're zero, I am 4,096, you're 32,768,
and you're 32,768. So, that's a recommended best practice at a minimum, at a minimum.
All right. So, there is another command I want to talk about,
which doesn't do what you think it does.
All right. So, I'm going to show the command, and it does not do
what people are misled to thinking that it does.
On DSW-1 as an example, oh, I'll just do it on DSW-2 right now. Okay. So, if I type in Spanning
Tree, VLAN 10, you notice down here there's a thing that says root. If I type that in, notice
I got primary and I got secondary. I got primary and I got secondary.
Okay. These are commands that run an embedded script on your switch. They are commands that run
an in-embedded script on your switch. Let me type this in again. Why? Because I want these numbers,
so we can talk about it. All right. So, let's say we typed in root primary.
Okay. Let's say we use that command. What does that do?
Okay. What it does is it runs a script that says, what is the current priority of the root bridge?
If the current priority of the current root bridge is 32,768, then I will set my primary
priority to 24,576. All right. So, if the current root bridge is using the default priority,
then the value you choose is 24,576. That's it. It will drop itself to 24,576. That's all
it'll do. Why? Because that is better than the current root bridge. All right. But wait,
there's more to this craziness. If, if, why that number? Because it's a script
that Cisco wrote on the device. It's a script. That's it. That's what they chose. That's how
it works. It is actually not a really good command to use. It's not. And we're going to get to that.
All right. So, we've got 32,768. If the current root bridge, the current root bridge is 32,768,
and I run this command, it drops this device to 24,576. All right. There. That one's out of the
way. Okay. But wait, if, if the current root bridge is not using the default. Okay. So,
let's say the current root bridge is using this value right here. If I run this command on this
device, what it does is it says, what is the current value of the root bridge? Oh, it's 20,480.
Well, that is not the default. Okay. So, what are you going to do? You, Switch, are going to
determine if you use the same priority, is your MAC address lower? If the MAC address is lower,
that means you can use the same priority and you become the root bridge. So, go ahead and do that.
But if your MAC address is higher, then that means you can't use the same priority. So,
use the next priority lower than that.
What does that mean? What does that mean? It guarantees nothing. It guarantees nothing
because once I do this on this switch, if I go to another switch and I run the command,
it'll do the same thing. Let's do it. Let's have some fun. Let's do spanning tree VLAN 20. Let's
do VLAN 20, root primary. Let's take this out. Let's check this out.
That's all it does. Okay. Now, let's go over to somebody like ASW1.
It's the wrong VLAN. VLAN 20 we want. It guarantees nothing. It's just a script. That's
all it does. That's all it does. Yep. Why was it invented? Okay. Let's go way back in the day.
Remember when DTP was created? Remember when VTP was created, right? Well, these commands were to
make your life easier. Just go to the device, type in primary, type in secondary on another device,
move on, forget it, it's over, right? And just hope for the best. That's it, right? They were
trying to make everybody's life easier. But in the end, in modern day networking, it's a command
that I tell people, just avoid it. It's not even worth it. Why? Because who's your root bridge?
You want this to be your root bridge? Go to it, set the priority to zero. You want this to be
secondary? 4,096 for the VLAN. You want this to be the root bridge for VLAN 20? Set the priority
to zero. You want this to be secondary for VLAN 20? Set it to 4,096. Done. Call it a day. Forget
this script stuff. It guarantees nothing. Guarantees nothing. Yeah. I know. When I first
learned about this too, I was misled, misled way back in the day. Primary guarantees it. No,
it doesn't. And I had to learn the hard way that it didn't. Yeah. All right. So,
it may or may not come up on the exam, but now you know that that's how it works.
And it's better to set you in the real world production environment, set it to zero
on your root bridge. Oh, also watch this now. If I set it to zero in my root bridge,
watch what happens if somebody tries to use this script. You ready?
So, right now, ASW1, somebody's trying to use the script. DSW1 is our current root bridge
with a priority of zero. Remember, I set the priority to zero for VLAN 10. It says,
no, sorry, denied, because they are zero.
So, if you set someone to zero, the script is useless on everybody else.
All right. So, that is setting your primary. That is doing your secondary.
But that is not all when it comes to manipulating spanning tree protocol.
We can also adjust our cost. All right. So, this is what our VLAN 10 looks like now in our
environment. We know that this decision is made how in this topology, the root port decision.
We know it was made based on, one, cost being tied,
and then upstream bridge ID being tied still, and then the port ID, 128.21 and 128.22,
breaking the tie ultimately for this to be the root port.
What if I don't like that decision, right? I like this decision. I want that to be my root bridge,
but I don't want this to be the root port. How could I override that? So, for example,
let's say we want instead this one to be the root port instead. How could we do that? Well,
let's manipulate cost, right? What if we inflate the cost of this one? Right now,
it is a cost of four. What if we make it a cost of five?
Then that means ASW1, when it compares it, we would have eight, eight, five, and four.
Which would win then? It would be simply the cost of four that wins, and none of the rest of those
decisions matter anymore. But if that's what you need to do, and that's how you want to manipulate,
you could totally do that. So, for example, on ASW1 right now, let's look at the spanning tree
for VLAN10. And we'll see the spanning tree for VLAN10 says 45 is the root port, and it has a
cost of four, this port. Let's just change that to five, and we'll see how this becomes our root
port after that. Now, the only reason why I know that's going to happen is because I know how the
decision was made. You see, if they ask you on the exam to do something like this, you have to
understand how the original decision was made, so you can then manipulate what you need to.
And you have to understand how the cost is cumulative. I'll show you an example after by
using one of the other ports, for example. So, let's go to interface, gigabit ethernet 1.0.0.0.0.45,
and we'll say spanning tree cost is now going to be five for my interface. So, instead of it being
four, it's now five. So, look at the output for VLAN10, you'll see that we're now five.
We are now a blocked port, and the root port is now 46. We made that change.
So, just by manipulating the cost of interfaces, you have the opportunity to change who your
root ports are, and possibly even your designated ports. The thing here is, is to realize that if
this is five now, and this is four, and this is eight, and this is eight, we have to remember that
we have to remember that this is based on four plus four, right? The four is coming from over
here. That's where this four is, and this is the one of the interface.
We know that this is five plus zero, four plus zero. So,
knowing how the decisions are made can ultimately help you deciding where you make adjustments,
because I don't necessarily have to manipulate costs here. I could manipulate costs elsewhere,
right? Because if this cumulative cost is based on information up here, could we drop this down
to two? Could we drop that down to two and get a value of four, or drop this down to one,
and have that as two? Manipulate that to two. Now you got three. Would that give us a lower
cumulative cost? Absolutely. So, realize that it could be multiple interfaces that get adjusted
to make that change. It could be just one interface that gets adjusted to make that change.
But let's go ahead and change both of these interfaces now to, let's say, nine, and we'll
see that because they end up being nine, then it's one of these ports that have to become the root
port. So, now eight is lower. And so, eight is tied. Upstream bridge ID is tied. Sending port ID
is going to be 21. So, it should be 47 on ASW1. That becomes the root port if both of those get
increased. So, let's say interface range, gigabit ethernet, one size zero, size 45 and 46. Let's say
your spanning tree cost is now going to be nine. And we'll take a look at that output.
And because we're using rapid spanning tree protocol, it fails over really, really fast,
as you can see. But there's just another example. We manipulated cost on both those interfaces,
and now we're actually going this way.
Oh, root bridge is still the same. We haven't changed that, right? Root bridge is there,
and now we're just showing you how to manipulate cost to change the direction of traffic.
So, just keep that in mind for the certification exam.
All right. So, you might be asked, you know, manipulate the environment so such and such an
interface is blocked. Well, how might you do that? Well, you might be able to do it by changing the
root bridge. But the question is, do they want you to change the root bridge? If you can't change
the root bridge, what's your next option? Can I do it with cost? And if you can do it with cost,
then you do it with cost. But we're not done yet with that. Why are we not done with that?
Why are we not done with that? Because there's another way that we can manipulate,
and that is going to be by adjusting the port ID. But before we get to that,
I want to revert this all back to our default values.
So, now we're back to our default values.
Root port is 45, like we see here. Let's recall how all of this, again, this decision was made
in this case. This decision was made because cost was tied, upstream, bridge ID,
bridge ID was tied, and then the port ID was 128.21 and 128.22.
And so, it was the port IDs of this device that was used by this device to determine what their
root port should be. That implies, folks, that we could manipulate these values to make a decision
on ASW1. That's right. We could manipulate these to manipulate ASW1. But that only works
in scenarios like this, where you get to the deciding factor of the port ID.
Remember, cost is always first, upstream bridge ID next, and then port ID.
So, port ID is only going to happen if it's two links, or three links, or four links,
or five links, or six, right, going between the same two devices.
And you're using that upstream port ID to break that tie when it's all said and done.
So, in this particular case, we could go ahead and manipulate it. And what value do we manipulate
it? Well, earlier, can't remember who asked the question, but they were asking about,
what does the 128 mean? I'm going back through my chat to find who said, no, I'm too far. It's
somewhere in there. Conrad, Conrad said, what does the 128 mean? Well, that is a value that
you can manipulate to manipulate the decision-making factor in this case. That's all it is.
So, the value is from zero to 255, but it has to be in increments of 16, as we're going to see here.
So, let's go to DSW1 right now, and look at the output of show VLAN10. We can see that we have
21 and 22 listed as such for our ports. So, whenever DSW1's sending its BPDUs,
those are the values, 128.21 and 128.22 that are in there. And right now, if we go to ASW1,
its decision is based on the fact that 128.21 is lower than 128.22. Meaning,
128.21 is lower than 128.22. Notice, it's not these numbers here that matter, it's the DSW1
numbers that matter. So, on DSW1, I could change DSW1's port numbers in this scenario, and that'll
change ASW1's. So, let's force gigabit one slash zero slash 46 to become the root port by changing
the values on DSW1. So, right now, this is lower than this. So, all I have to do is make this one
lower. So, we'll go to interface gigabit ethernet one slash zero slash 22, and I'm going to say
spanning tree, and it is listed as your port priority. And you'll see that it says you have
to be increments of 16. So, zero through 16. So, let's pick, what, it was 96, increment of 16. So,
96. And that's it. All I can do is manipulate that first number, that first number. That's
what I'm doing. So, done. So, now if we look at DSW1, we'll see that value has changed here. It's
now 96.22. And I've overused my time in the lab environment. Got to connect back in.
Had nothing to do with what I just configured, folks. All right. There we go. So, 96.22.
So, now, that is what's being sent in the BPDU at that port. And then the gigabit one
slash zero slash 21 is sending 128.21. So, 96 is lower. So, remember, this is what ASW1 looked
like before, right? We should see that that is now flipped. And there you go. So, yes,
something I want you to know for the exam. Absolutely, if there's any scenario on the exam,
and they're talking about manipulating something between these two switches,
manipulating something between these two switches, but the rule of thumb is that you are not allowed
to make changes on this switch or this switch, as an example. You can only make the changes
on the upstream switch. Then you immediately have to think, I have to adjust the port ID.
Because if you're allowed to touch this device or this device, for example,
then you could just manipulate the cost. You could just manipulate the cost of the interface.
But if you're not allowed to touch those devices, then you have to manipulate the port ID
going down to them. So, can you give an example or two of why you might choose? Yeah,
I just gave the example. Can you give an example or two of why you might choose to
change a port priority on an upstream switch as opposed to using another option?
Because you are being forced to do it that way. Being forced. Yeah. Because we all know,
based on today's discussion, I could just go to this device, manipulate the cost. If I tell you
you're not allowed to touch that device, then what's your next best option in this scenario?
Port ID. That's how you'd have to do it.
Isn't this fun and exciting, folks?
Right. One more thing, though, to keep in mind.
No, it doesn't have to be on the root bridge, for example. So, let's say I told you that
let's say right now the scenario was that this was the root port, this was blocked, okay? It could
be this as an example, right? Let's say this was the topology instead. And I told you I wanted
this port to be the root port instead, but you weren't allowed to log into ASW1. Then that means
you have to go over here and manipulate the port ID so that this port ID is lower. So,
no, it does not have to be the root bridge. Yeah. Yeah. So, that's why it's important for
you to be able to decipher based on the algorithm. What? Who's the root bridge? What are the designated
ports? What are the root ports? What are the blocked ports? How was it determined so that
way there you have the ability to do the manipulation? That's why the algorithm is so
important. If you don't know the algorithm, you can't walk through it. It's tough to determine,
hey, could I use the port ID here? Or do I use cost? Or do I use this? Think about this scenario
as well. Upstream bridge ID. Okay, we gave an example earlier that when we were trying to
figure out the root port as an example, we said that what if this was an Ether channel bundle?
This was an Ether channel bundle. And this had a cost of eight and this had a cost of eight.
Well, then what is going to break that tie? What is going to break that tie? Well, the upstream
bridge ID. So, right now, we know that this has the lower upstream bridge ID, right?
So, could you technically, if this is the root port right now, could you technically
change the bridge ID of this and all of this becomes the root port? Yes. But then you're
actually changing who the root bridge is too, aren't you? Yeah, in that scenario, you would be.
But just showing you how manipulating things like bridge priority, changing who the root bridge is
can manipulate the path that is taken, manipulating cost, manipulating port IDs,
all of those come into play when you're manipulating your Spanish root protocol.
And so, all things you really need to be aware for the exam, because you are in Encore, you are in
CCNP. The odds of them testing you on the simpler things are very low. The odds of you
testing you on strange things like changing port ID or cost are a lot higher. Also, let's not forget
the power of per VLAN spanning tree plus and rapid per VLAN spanning tree plus
comes in the fact that you can create a different tree for each and every single VLAN you have.
So, let's say right now, this is the tree we have for every one of our VLAN. So, VLAN 10,
VLAN 20, VLAN 50, VLAN 200. Let's say by default, this is what the tree looks like. And that's what
happens on Cisco devices, just so you know. Every single VLAN you create will automatically have
this same looking tree. So, if I look at my device, and I look at DSW1, and I log into it,
I will type in show span. By default, it would be the root bridge for VLAN 1, VLAN 10, VLAN 20,
VLAN 50, VLAN 200, etc., etc., etc. Why? Because you think about it, the numbers by default are
all the same. So, unless you start manipulating it, they will all have the same tree. Now,
they're different trees, but each tree will look the same. So, the power though of per VLAN spanning
tree plus and rapid per VLAN on Cisco devices is that we can change all of that. And we already
know that just by simply changing the root bridge, you can change a tree. So, right now,
for example, VLAN 50 is also using this exact same looking tree. But what if, for example,
we make this instead the root bridge for VLAN 50? If we do that, it now means that traffic flow
is going to be totally different for VLAN 50 than it is for VLAN 10. So, right now, right,
VLAN 10 traffic does this, right? VLAN 50 would be down here, and VLAN 50 traffic would be doing
this because why? Same tree, same looking tree. So, this, all traffic is flowing through that device,
all of it. So, what if we make this the root bridge? Does that mean the traffic can now flow
like this for VLAN 50 while it flows like this for VLAN 10? Yeah, that's a type of
balancing of traffic. It's not true load balancing because VLAN 50, right, who's in that,
right? If they're not doing, if they're not consuming a lot of bandwidth or resources,
right, it's not a low perfect load balancing. But if you can change the way that traffic flows
and start using more links, start using more distribution devices,
you're going to get better performance overall in your environment. So, I'm just going to show it
here. Right now, DSW1 is the root bridge for VLAN 50 as well as VLAN 10 and all the other ones.
Hey, let's just go ahead and go to DSW2, type in Spanish, VLAN 50 priority zero.
That now makes me the root bridge. So, like I said earlier, on Cisco devices,
we're not blocking physical ports, we're blocking logically our ports on a VLAN by VLAN basis. So,
notice here that all of these are now designated ports, every single one of them for VLAN 50,
but for VLAN 10, those are blocked and that's a root port. That's right, two different trees now.
One for VLAN 10, one for VLAN 50, they're different. Instead of looking the same,
they're now looking different. So, what does that mean now for somebody like ASW2? Take a
peek at that. Based on the algorithm, based on going through the motions, 47 would be the root
port in this case. So, that means traffic is going to flow this way for VLAN 50.
Look at ASW1. If somebody down here was added for VLAN 50, their traffic would flow this way.
How cool is that now? How cool is that? And if somebody for VLAN 10 is here, their traffic is
going to flow that way. How cool is that? Look at that. You are starting to use more of your
links by manipulating. Like, and then that would be your DSW1.
So, there you go. That's the power of Cisco's proprietary versions of Per-VLAN Spanning Tree
Plus and Rapid Per-VLAN Spanning Tree Plus. So, question, for all of you,
how many of you have taken advantage of this in your environment with Cisco switches? Anybody?
Yes, you can do something like this with multiple Spanning Tree Protocol as well,
and we'll talk about that when we get there.
So, a lot of important things there. Little nuggets of information too. What did we talk
about? We talked about timers. So, know your hello time, know your max age time,
know your forward delay time. Make sure you know those. Make sure you know the different states,
blocking, listening, learning, forwarding, and how the timers apply to that. Make sure you know
about alternative ports and backup ports for the certification exam. Know the command to change
the Rapid Spanning Tree Protocol. Understand that Rapid Spanning Tree Protocol can be backwards
compatible with Per-VLAN Spanning Tree Plus, right? Why? Because it's going to use timers
in order to be backwards compatible with Per-VLAN Spanning Tree Plus. But we have our proposal and
agreement process for Rapid. So, if two Rapid devices are communicating, they're going to use
proposal and agreement process. If that fails, then they're going to use timers as a backup
mechanism for themselves. And then manipulation, manipulation, manipulation, know that.
There's a really high probability you'll be tested on that on the certification exam,
and it might actually be a lab, a simulation, as opposed to just multiple choice questions.
So, keep that in mind. Make sure you are well aware of how to manipulate Spanning Tree Protocol.