All right, so we are going to look at a topology here and apply what we've
learned, not only
about PBST+ but also as we see in the challenge, we're going to hit up some
timer conversations.
And the way the challenge was worded made it so we have to do a little bit of
math on
some of these timers as well as rely on a good understanding of what the timers
are
present in order to figure it all out.
So let's go and start with the PBST+ element.
This is a huge part of not just legacy PBST+ but even in the modern network WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This is a huge part of not just legacy PBST+ but even in the modern network
with rapid
PBST+.
Most of our Cisco networks in the real world still rely on rapid PBST+ and all
of the principles
are the same.
As we've said several times, we're learning the original PBST+ because for the
most part,
a lot of the same principles still apply to rapid.
And so at that point, we just need to understand what the differences are.
The splitting of the VLANs, the creating a topology per VLAN, that is all
exactly the
same in rapid PBST+ and so it still continues to apply in modern networks today WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
same in rapid PBST+ and so it still continues to apply in modern networks today
.
So we say in the challenge that the switches have been configured with PBST+
and we're
to optimize leak efficiency by assigning root priorities for each VLAN.
So we're given a list of active VLANs and we do some math there.
We say, okay, so there's seven VLANs.
So I might decide to split it up so that odds go on one side and the evens go
on the other.
In fact, let's go ahead and write that in a different color so we can kind of
track the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
track the
different topologies.
So the odds are going to be VLANs 11, 13, 15 and 17 and the evens are 12, 14
and 16.
Now right away, we might notice a little bit of a nuance here.
We see that we've got four VLANs for the odds and only three for the evens.
Does that mean that the odds are going to, that we've got more traffic across
the different
VLANs and if every VLAN has the exact same amount of traffic, that's what it
means. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
means.
And the reality is that we have to deal with the number of VLANs that we
actually have.
We can only build topologies based on VLANs, nothing else.
Now if we run a traffic analysis and we realize that all of these VLANs have
less traffic
on them than the evens, and maybe this is actually 80% of what's happening over
on the
even side relative to that.
So just because we're looking at it from the perspective of having a different
number
of VLANs doesn't necessarily mean that we actually have more traffic, although WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of VLANs doesn't necessarily mean that we actually have more traffic, although
certainly
it could mean that we have more traffic again if all of the VLANs have about
the same amount.
The reality is that in most of our modern networks, we're dealing with a whole
lot more
than seven VLANs.
We might have 50 or 60 something like that.
And at that point, if we're off by one or two, it's probably not that big of a
deal.
Furthermore, this conversation of odds versus evens, that is how a lot of
organizations
do it, but we should keep an eye on whether the traffic flows are about the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
do it, but we should keep an eye on whether the traffic flows are about the
same.
If they're within 20 or 30% of each other, that's probably fine.
I mean, we're trying to activate all of these links and not necessarily make it
so that
they have the exact same load on them.
But at the same time, if we find out that let's say there's two VLANs on the
even side that
are an enormous amount of traffic, well, maybe we should move one of those over
to the other
side and not just stick with even an odds.
Again, that's a little bit of a real world conversation.
In our example here, however, you chose to split these up is perfectly fine. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In our example here, however, you chose to split these up is perfectly fine.
And given that we don't know traffic flows, I would say that the right answer
would just
involve having four on one side and three on the other.
So let's just roll with that.
So the idea here is that we are splitting these up.
Now, what does that mean we're splitting them up?
What it means is that we're going to assign root priorities.
So I'm going to say let's just choose 40, 96, something lower than the default.
Remember the default is 32K for Cisco switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Remember the default is 32K for Cisco switches.
And we want to leave switch three sitting there at 32K.
So maybe I'm going to say 4096 as the priority, but keep in mind with Cisco,
everything's
a per VLAN configuration.
So I have to configure 4096 as the root priority for VLAN 11, but also VLAN 13
and 15 and 17.
And then over on the even side, I'd probably also do 40, 96, but this time it's
for VLANs
12 and 14 and 16. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
12 and 14 and 16.
So here's a question.
Even that VLAN 12, let's just say does exist here on switch one, what would the
priority
be for VLAN 12?
Well we might just say, well, let's leave it at the default of 32K.
But keep in mind that switch three is already defaulting the 32K for everything
.
Instead you state operation, it doesn't matter because switch two is going to
be the root.
But what happens if switch two is lost for some reason?
And what happens if switch three has a better MAC address? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And what happens if switch three has a better MAC address?
Then it would win the election and it would become the root for VLAN 12.
In a lot of our, again, real world topologies, we'd look at that and say, okay,
I've got
two distributions switches for a reason.
I really want switch one to take over as root, which means that rather than
leaving it as
32K here, I'd probably want to make it something like 8K, which is 8192.
So at that point, if switch two goes down, now switch one is going to win out
over switch WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
over switch
three even if the MAC address is worse.
And so that's usually how we do it again in a real world scenario is I would
look at
this and in general, just say that the evens are going to be 8K on switch one,
making it,
if you want to call it the backup root, that's fine.
That's not an official technical term.
But logically that would make sense because it will take over as root in the
event of
a failure.
And then same thing over here, the odds would also be 8K on switch two. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then same thing over here, the odds would also be 8K on switch two.
So that way switch one and switch two will back each other up.
And again, that's another real world conversation as far as how we configure
distribution layers
when we have two distinct logical switches.
Now lastly, this will result in blocked links that are different on a per VLAN
basis.
So 11, 13, 15 and 17, because the roots over on this side and with all links
being equal,
one of these sides will block probably switch three, especially if we have this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one of these sides will block probably switch three, especially if we have this
priority
here, that would be the case.
So we block here for our odds.
And then we're going to block this link over here for our evens.
And we'll get into calculation of which links get blocked or which ports get
blocked coming
up here real soon.
So for now, we can just sort of make an assumption.
One of these links is going to be blocked for each VLAN.
And because the evens are aggregated together, it should be the same port.
Same thing with the odds being all blocked on the same port as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Same thing with the odds being all blocked on the same port as well.
So now we see we have two topologies.
Again, the evens can fully use these two links.
The odds can still fully use this link between the switches, but it can also
use this link
over here.
And this is what allows us to make sure that none of these links is idle in the
environment.
But now things start to get a little bit more concerning or not concerning, but
something
we have to recognize is challenge question number two asks about the number of
spanning
true protocol instances. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
true protocol instances.
Well, we have seven total VLANs, which means we have seven total STP instances.
It is a one to one mapping with per VLAN spanning tree.
Again, it's right there in the name per VLAN.
Every single VLAN gets its own instance and therefore switch one has to send
out four
BPDUs every hello timer.
It's going to send one out for VLAN 11, 13, 15, and 17, and switch three is
going to replicate
that on its side with three different BPDUs every hello timer for VLANs 12, 14, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that on its side with three different BPDUs every hello timer for VLANs 12, 14,
and 16.
Now, again, you might have divided your VLANs up differently, but the reality
is that it's
seven total instances with seven total BPDUs getting sent out across the
switches every
hello timer.
Now lastly, we get into the timer conversation management.
Don't you love when management gets involved?
They are suggesting that 50 seconds is too long to wait for indirect failures.
Anytime I see this keyword indirect for indirect failure, we should be thinking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Anytime I see this keyword indirect for indirect failure, we should be thinking
about that
max age timer.
And by default, max age is 20 seconds.
So when they say that we really want to make it 40 seconds, that would be
better.
Okay, management, thanks for your input.
Now what timer can be adjusted?
Probably max age, but let's read the rest of it without affecting the failover
of direct
failures and what value should it be set at.
So again, indirect failures, that's what max age is for.
Direct failures are going to skip max age, and so we're going to rely totally WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Direct failures are going to skip max age, and so we're going to rely totally
on the
forward delay timer, which by default is 15 seconds.
So for example, if this link were to go down and switch through recognizes that
it would
start the forward delay timer here on this link, meaning it would progress
through listening
and learning.
And each one of those would take 15 seconds and therefore it would take 30
seconds.
So if we still want this to take 30 seconds, then we cannot change the forward WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if we still want this to take 30 seconds, then we cannot change the forward
delay, which
is where we eventually land back at changing max age.
So if we want to take this from 50 seconds down to 40 seconds, well, our 50
comes from
the max age of 20 plus two times the forward delay.
So this stays put at 30, which means this must become 10 if we want it to be a
total
of 40 seconds.
So that'd be the answer to number three, adjust max age to 10 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So that'd be the answer to number three, adjust max age to 10 seconds.
I will say this, be very careful about changing these timers in a real world
environment.
For the most part, that's not advised.
And there's very specific rules around doing it.
But this example is really not here for real world like advice, like this is
what we do.
Instead, it's here to help us to cement our understanding of the timers.
So just a little caveat there.
Now lastly, we're back to talking about another timer here.
Now management is getting involved again. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now management is getting involved again.
And they're saying that 30 seconds is too long to wait for a new device is to
come online.
So as we've said, if we have a laptop show up and plug in, it's going to have
to wait
that two times forward delay, which is a total of 30 seconds.
And we will learn pretty quickly that we have other ways of bypassing this.
But for right now, we're suggesting that's too long.
So how can we adjust the timer so that 24 seconds, they say would be better?
Well, we can't just say, oh, well, 30 minus 24 is six. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, we can't just say, oh, well, 30 minus 24 is six.
So let's just drop forward delay by six seconds.
If we did that, for delay would be nine seconds.
And then we multiply that by two and it's 18.
Well, we're trying to get this to 24.
So if we're trying to get it to 24, we actually need to drop this three seconds
because we
wait two times that delay.
So now this becomes 12 seconds and 12 times two gets us our 24.
So the answer to the last one is going to be adjust the forward delay timer and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So the answer to the last one is going to be adjust the forward delay timer and
shrink
it by three seconds in order to hit 24 seconds total.
So this example is series of challenges was intended to help us solidify our
understanding
of Pervieland spanning tree, the different topologies we can create as well as
how we
can adjust the timers, making sure we understand what the timers do and how to
adjust them
to achieve certain goals.
I hope this has been informative for you and I'd like to thank you for viewing.