Alright, let's go ahead and jump into a quiz.
As we usually do with these types of quizzes, we're just going to read the
question and
encourage you to hit the pause button and make sure you can answer it yourself
before
I go into the solution.
There's going to be seven questions total here where we go through these
together and
then we'll continue the challenge and other formats moving forward.
But let's just go ahead and again start with a quiz.
So question number one, which spanning tree protocol port roll?
Keep in mind our terminology here, but our port roll allows for sending BPDUs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Keep in mind our terminology here, but our port roll allows for sending BPDUs.
Well there's actually a lot packed into this question.
So this concept of sending BPDUs is important.
We have to remember that BPDUs are unidirectional, they only get sent one
direction and specifically
it's sent downstream from the root.
So if we have our root switch, we've got a bunch of switches hanging off of the
root switch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
root switch
or for that matter it could all loop back around.
But either way we send those BPDUs downstream and these are how we determine
what we're
doing, which boards are blocking and such.
And recall how exactly we broke this down.
So a switch is going to determine upstream ports by recognizing there's a
superior BPDU.
It's going to identify the downstream ports by recognizing that it has a
superior BPDU, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
superior BPDU,
meaning it's receiving inferior BPDUs.
And so we're talking about receiving not sending here by the way.
So I receive superior BPDUs upstream, that means it's towards the root.
I receive inferior BPDUs downstream, at which point I ignore those, I send my
own BPDU
and the other side is supposed to stop sending them.
And that's what turns into unidirectional because this switch down here might
start
by sending an inferior BPDU.
But as soon as I send my superior BPDU, if everything's working properly, this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But as soon as I send my superior BPDU, if everything's working properly, this
switch
will recognize, oh, I have an inferior BPDU, therefore I'm going to stop
sending the inferior
BPDUs and I will just continue to receive them.
So when we're talking about upstream ports, we have two different types.
We have the root port, of which there will always be exactly one, and then we
have non-designated
ports.
And that's going to make a lot more sense when we recognize the downstream
ports are
called designated ports.
So be careful, it doesn't stand for downstream port, although that is what it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So be careful, it doesn't stand for downstream port, although that is what it
is.
It's facing downstream, it's going away from the root.
So at this point, we see that I am going to have the root port here, the in a
forwarding
state.
The designated port gets to be in a forwarding state, but the non-designated
port becomes
a blocking port and enters into the blocking state.
And this is how we prevent loops.
So we're looking at this diagram I just drew here, and this switch down here WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we're looking at this diagram I just drew here, and this switch down here
needs to prevent
this loop that we see in the middle of the network.
So what it's going to do is recognize I've got one root port, let's say this
one on the
right, but it has two total upstream ports.
And so I'm going to have to throw this one into the category of being a non-
designated
port, which means it ends up getting blocked.
And at that point, we do prevent a loop from forming.
So let's go back to the question now, which SDP port role allows for sending BP
to use?
Well, we said we send BP to use downstream. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, we said we send BP to use downstream.
We said there's only one port role for downstream ports, and that would be
designated ports.
Our other two port types, our root port, our non-designated port, these would
be upstream
and we will never send our BP to use upstream towards the route, at least in
standard spanning
tree operation.
So B here would be the answer.
All right, question number two, switch ones for delay timer is set to 12 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
All right, question number two, switch ones for delay timer is set to 12
seconds there,
and the max age timer is set to 16 seconds.
How long does it take for a new port to come online?
So we've got our switch, we've got a device, let's say it's a laptop that plugs
in into
a switch, and now we have to bring this port online.
Now ideally, we have port fast enabled and it just comes online immediately,
but in traditional
spanning tree when this port comes online, whether it's connecting to a laptop
or connecting
to another switch, either way, we must progress through the listening and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to another switch, either way, we must progress through the listening and
learning states.
I'll draw it out a little better, there we go.
So listening and learning, each one of these is going to require the full
forward delay
timer.
So this is the trickiest part about the timer calculation, is just the fact
that we have
to double the forward delay.
So if it takes 12 seconds, or if we set it to 12 seconds, then it's going to
take 12
seconds for listening, 12 seconds for learning, and the answer is going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
seconds for listening, 12 seconds for learning, and the answer is going to be
24 seconds.
Now remember what Max Age implies.
So let's say that our root switch is over here, we're sending BP to use down,
it's flowing
this direction, and meanwhile I've got another path this way.
And so maybe this actually travels through several switches.
So we'll draw it out like this.
So this is two different upstream ports from this switch's perspective. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is two different upstream ports from this switch's perspective.
This is my root port facing the root, and this is my non-designated port up
here, and I'm
blocking.
So I'm expecting to continue to receive superior BP to use from both directions
.
But what happens when this link here goes down, and this switch decides, ah, I
am the
root, and therefore I'm going to send an inferior BP to you.
So this is now an inferior BP to you. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is now an inferior BP to you.
Well this switch here has to wait because the superior BP to you has a timeout
equal to
Max Age.
And so it's going to have to wait whatever is left of the 20 seconds from the
last time
I've received one of those superior BP to use.
We'll just say it's 20 seconds, actually in this example it's 16 seconds.
So let's stick with the example here.
So I'm going to wait 16 seconds to time that out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I'm going to wait 16 seconds to time that out.
Then I'm going to progress to listening and then learning.
So here's a bonus question.
Feel free to pause.
What is the total amount of time it will take for this switch here to bring
this port
into an online state if indeed this link goes down?
Well the answer here is simply my listening and my learning and my Max Age
because it'll
take the full 16 seconds, in our example again, 20 seconds by default, it'll WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
take the full 16 seconds, in our example again, 20 seconds by default, it'll
take 16 seconds
to time out.
Then it will place this port into listening and it will sit in listening for 12
seconds
according to our example and then learning for 12 seconds.
And so the total amount of time that these switches will both be down is
actually going
to be 40 seconds.
That's a really long time to be down and if we were using the default settings
it'd be
50 seconds because it would just be longer at that point. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
50 seconds because it would just be longer at that point.
So let's keep in mind what all of these timers are doing in steady state
operation with traditional
spanning tree.
Fortunately, rapid does speed this up quite a bit, which is what it's designed
to do.
But at the same time if for any reason, rapid can't figure things out, it will
still fall
back on these timers making these timers and these mechanisms relevant even in
rapid spanning
tree environments.
Alright question number three, a Cisco switch running PBST plus is configured
with 10 VLANs
and five interfaces are in a forwarding state per VLAN. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and five interfaces are in a forwarding state per VLAN.
How many STP instances are active?
Well even though we're throwing a lot of numbers, really what it comes down to
is how many VLANs
are there that are active on the device.
So our focus tends to be on, hey I've got 10 VLANs configured, VLANs one
through ten.
And therefore we're going to have 10 topologies because that's what per VLAN
spanning tree
means is every spanning tree or every VLAN gets its own spanning tree instance.
However do keep in mind in the real world that if I've got let's say just a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
However do keep in mind in the real world that if I've got let's say just a
single trunk
interface here, maybe we've got a bunch of access ports, all these access
points are
in VLAN five.
And on this trunk I'm carrying VLANs one through seven.
Well if there are no ports active for a VLAN then a spanning tree instance will
not run.
And so that's something that is just a little bit more call of advance I
suppose but it usually
goes beyond the scope of talking about some of these you know topology counts WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
goes beyond the scope of talking about some of these you know topology counts
and such.
In our case we'd really only have topologies for VLANs one through seven.
But as soon as a port comes online whether it's a trunk or access with VLAN
eight will
now all of a sudden we're going to need an eighth spanning tree topology.
So so long as we have active VLANs meaning they're enabled on at least one port
whether
access or trunk doesn't matter as long as that VLANs active there will be a
spanning
tree instance running for it and we need to make sure that we have enough
instances to
support all of the VLANs that are in our environments and for that we'll just WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
support all of the VLANs that are in our environments and for that we'll just
need to
check the spec sheets for the switches that we're deploying.
Alright next question what do switches do when a TCN the topology change
notification
is sent into the network.
So recall what happens here if there's a topology change let's say a port comes
online
it goes into the forwarding state or maybe this link goes down whatever the
situation
is we are going to alert the root to the fact that there's been a topology
change we're
going to send a BPDU it's the one time we send a BPDU upstream that is a TCN B WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to send a BPDU it's the one time we send a BPDU upstream that is a TCN B
PDU.
From there the root in its normal BPDU's so these are those config BPDU's will
now
have a flag set where our topology change bit is now equal to one.
This tells the network every time it receives a BPDU that there has been a top
ology change.
So what happens when this gets sent out?
Well what we're going to do is we are going to reduce the MAC address timeout. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well what we're going to do is we are going to reduce the MAC address timeout.
We went through several examples of this the idea is that because there was a
topology
change we run the risk of black holing traffic and so we don't want to make the
mistake of
sending MAC addresses or really packets and frames towards the wrong switch
based on the
destination MAC address which is now a stale entry.
So the timeout is going to be very important it goes down to the forward delay
timer and
so because it goes down to the forward delay timer if we're using default WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
so because it goes down to the forward delay timer if we're using default
settings that
will go down to a 15 second timeout which is way less than the 300 seconds that
we use
for by default.
As a result MAC addresses were more likely to timeout in this scenario and
there will
be a lot more flooding on the network and always remember that portfast will
prevent
this from happening if I have a laptop and I plug it in portfast will suppress
the TCN.
It's very important that we have portfast enabled otherwise we are going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It's very important that we have portfast enabled otherwise we are going to
more or less
constantly be sitting in a state where our MAC address timeouts are at 15
seconds.
Alright question number five what happens if a BPDU is received on an interface
configured
with portfast?
So something we have to worry about here is I might enable portfast on this
port and a
laptop is supposed to connect to it and maybe most of the time there is a
laptop connected
to it.
But all of a sudden maybe this is a college student and this is in a dorm or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But all of a sudden maybe this is a college student and this is in a dorm or
something
like that and they connect a switch and all of a sudden we're receiving a BPDU
's on our
portfast port.
Does this make a spanning tree loop are we now subject to potential loops on
every one
of our portfast ports.
And so fortunately we don't need to worry about that too much because portfast
is going
to transition us back into the listening state if this were to happen.
So A here is the correct answer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So A here is the correct answer.
We place ourselves into the listening state and ultimately we revert back to
standard
STP behavior.
That is what happens as a result we don't need to stress too much about port
fast creating
loops just do keep in mind that if I were to connect this to two different port
fast,
ports and we don't send out a BPDU for two, three, four seconds depending on
the hello
timer.
Well then we're not going to know that there's a loop and so it's going to loop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well then we're not going to know that there's a loop and so it's going to loop
traffic
until a BPDU is received.
So there is still a possibility of loops forming but they should be temporary
only until I
receive a BPDU from the downstream switch that just connected to that port.
We're almost there.
Two questions to go, a switch with bridge ID starting with 0.9, so I'd be the
start
of the MAC address, is configured with the root primary macro.
The current root has a priority of 4096 with a MAC address starting with 0A.
What priority does the switch change to? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What priority does the switch change to?
So this is really important.
We spent quite a bit of time talking about this here with the STP macros
conversation.
This root primary is a macro.
It's going to run additional commands on the back end but importantly it's
going to change
which commands it's running depending on the current situation.
Root primary remember what this does is it essentially says, hey, I'm going to
make myself
the highest, yes, highest numbered priority that makes me the root. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the highest, yes, highest numbered priority that makes me the root.
So if I win a MAC address battle with the current root then I can choose the
same priority level
because I'll win the tiebreaker.
If I don't win that tiebreaker I won't win it if I were to change it then I'll
have to
go lower.
So there's a few things in place here, a few forces that we have to kind of gel
together.
We also will not pick 0.
This is not an option to go down as low as 0. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is not an option to go down as low as 0.
And so we have a current root which has a priority of 4096.
So here's the question.
Can we go to 4096 or do we have to go to 0 and at that point we're not allowed
to go
to 0.
So this is kind of a little tricky.
So the current root has 4096 MAC address starting with 0a.
Here's me.
I just put this configuration onto this switch here so I'm running the macro WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I just put this configuration onto this switch here so I'm running the macro
here and it has
a MAC address of 0, 9.
So we have to compare these two MAC addresses.
What is the situation?
Well the situation is that 0a is actually a higher number and therefore the
priority
actually exists over here with our macro switch.
So in other words if it's the same priority value then we will win because 0, 9
is a
lower number than 0a which is effectively 0, 10 there.
A is hex for 10.
And 10 is higher and spanning tree that means worse than 9. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And 10 is higher and spanning tree that means worse than 9.
So all we're going to see is that this switch chooses a priority value of 4096.
So 4096 is going to win because now we compare our priorities and they're the
same and so
we compare our MAC addresses.
They're not the same, hopefully they're never the same and our macro switch
will win.
So remember how these priorities work and all the rules around how they work.
Remember that the secondary command will always choose a value of that 28k even WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Remember that the secondary command will always choose a value of that 28k even
if it won't
make it the secondary it doesn't matter because it doesn't know all the
priorities out there.
So we just have to use 28k.
Also remember that the highest priority that will be picked is 2k no 24k.
It won't choose 28k because of the secondary being or using that option already
and the
default priority for all of our Cisco switches are 32k. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
default priority for all of our Cisco switches are 32k.
So all these numbers do actually add up and they make a lot of sense for how
this deploys
and so we just need to make sure that we're being as intentional as possible
when we're
using these macros.
Alright last question.
Switch 5 has two possible paths to the root with BPDUs each arriving on 10 gig
ports.
Let's just draw this out real quick.
So switch 5 each one of these is 10 gig ports and the BPDUs arriving here are
two different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
two different
BPDUs.
I mean they're from the same root but they are advertised from two different
switches.
And we know that because the cost is different so we have one over here we'll
call this A
on the left and B on the right.
So we have a cost of 8,000 the bridge ID the bridge priority I should say is 16
k coming
from this other switch and the port priority is 80.
Over here path B cost of 6,000 then we have a priority of 32k and a port WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Over here path B cost of 6,000 then we have a priority of 32k and a port
priority of 128.
So what's interesting about this scenario is that these priority values the
bridge priority
and the port priority are much better than these values over here.
And so our eyes might be inclined to look here at the bridge priority and the
port priority.
The problem is that nothing matters more than the cost.
If switch B whatever that switch is upstream has a better path to the root than WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If switch B whatever that switch is upstream has a better path to the root than
switch
A on the left then I will always go out that path.
And so we don't need to even worry about the tiebreakers at that point.
Remember these tiebreakers are arbitrary.
It's really just a way for us to say hey I've got two great paths or at least
equal paths
and therefore I just need to pick one at random and that's essentially my way
of doing so.
Now if I'm configuring priority values then usually there's more intentionality
behind
it and I don't need to worry about it being random. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it and I don't need to worry about it being random.
But at the same time yeah we just understand that tiebreakers don't matter when
the costs
are not equal.
So which path is chosen?
The answer here is going to be B based on the path.
So how can switch V be tuned to prefer the other path?
Well importantly we say it's switch V that's being tuned.
We're not going to tune anything else in the network.
These are being brought in on 10 gig links each with a cost by default of 2000
if we're
using the long path costs otherwise it's a cost of two for short path costs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
using the long path costs otherwise it's a cost of two for short path costs.
Either way it's the same.
And so what we can do is one of two things I want to prefer this path so I can
either
lower the cost on this side or I can raise the cost on this side.
Now what we're trying to do here is overcome the difference in costs of 2000.
And so I can't really reduce this down.
But we don't want to use a cost of zero for example we can't decrease the two
at all WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
at all
if this happens to be configured with short.
And so we're going to have to increase the other side.
And so the idea here is that we will increase the side by at least 2001 meaning
I'm either
going to increase this to 4001 or I'll increase this to well I guess 2003 yeah
that would
be it.
2001 plus two.
So either way depending on whether we're running long or short we just need to
increase this
path cost by 2001. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
path cost by 2001.
At that point the total cost for path B will be 8001 instead of the 6000 that
was there.
And now we will prefer the lower path.
So that is how we can go about tuning the path.
And that's a big part of spanning tree and understanding it is looking at it
and saying
okay well how can I change it?
How can I change which ports are going to be blocked?
And now we've covered in great amount of detail how we can do that inbound
using cost,
outbound using port priorities if indeed it's connected to the same switch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
outbound using port priorities if indeed it's connected to the same switch.
So that is it brings us to the end of this quiz.
Now we're going to jump into a couple more challenges to really cement our
knowledge of
house spanning tree determines topologies and determines blocked ports.