All right, we want to configure timers on our network.
Now in the real world, we don't do a whole lot of timer tuning.
In fact, we want to be very careful about tuning timers,
and we'll talk about that here coming up.
But ultimately, if we do want to change our timers,
keep in mind that it's only the root that really matters.
From the perspective that it pushes those timer values down.
So we're on switch one here.
We've made switch one the root.
It's got this priority value of 20k still.
We see that it has no root port, and so we
know that it is indeed the root. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
know that it is indeed the root.
If it doesn't have an upstream port,
it must be the most upstream switch.
And so what we're going to do is configure timers on this.
We'll validate that those timers get pushed down.
Just keep in mind that if we do change timers
in the real world situation, we probably
have a backup root as well.
So do I need to configure these timers only on the root?
Well, if the root is online, then that would be correct.
But what happens if that root goes down
and the secondary takes over at that point?
It will determine what the timers are.
So we usually at least want our timers configured WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we usually at least want our timers configured
on primary and secondary routes.
If we have a catastrophic failure
and we've lost both of those routes,
we probably have more issues to worry about than what
the SDP timers are.
So either way, let's go ahead and do a show spanning tree
for our VLAN 1 here.
Separate the 1 from the VLAN.
And we will see the timers as configured.
So our hello time is two seconds.
Our max age is 20.
Our forwarding delay is 15 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Our forwarding delay is 15 seconds.
Here is my local configuration as well.
Now this will match because I am the root.
But just keep in mind that this is what is going to matter.
Whereas this is just a local configuration
and all the other switches.
Incidentally, if we're messing around with studying
topology change notifications, we'll
notice the aging time is listed here.
That would be our MAC address aging timer.
And if we're in a topology change status,
then we'll see that aging timer change.
So let's go ahead and run some debug.
In order to confirm that everything's working like we think. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
In order to confirm that everything's working like we think.
We've got a hello time of two seconds.
So I'm going to say debug spanning tree.
And I can do a BPdu transmit.
Now we'll see transmit happening.
In fact, I'm just going to go ahead and very quickly
undebug this.
So I'll say undebug all and hit Enter.
And let's go ahead and evaluate what just happened.
So if I scroll up a little bit, we'll
see that this all started at 31 seconds.
Now notice how many BPUs are getting transmitted.
We've got one for VLAN 10, VLAN 20, VLAN 30, and VLAN 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got one for VLAN 10, VLAN 20, VLAN 30, and VLAN 1.
And then we also have another one on VLAN 1.
Why do we have another one on VLAN 1?
Well, this has to do with the fact
that I need to send one for my STP,
pure VLAN spanning tree instance.
But I'm also sending one for the sake of aligning
with any non-Cisco devices out there.
So that would be my backward compatibility version.
Either way, we do see that we're sending
BPdu on a per VLAN basis, which is why if we have 300 VLANs,
we're sending 300 BPUs within a hello timer. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we're sending 300 BPUs within a hello timer.
Now again, we sent this all at 31 seconds after the minute.
So if I go down to the next batch of BPdu's,
we see it happened at 33 seconds.
So 31 to 33 is two seconds.
33 to 35 is another two seconds.
35 to 37.
OK, so we are sending our BPdu's every two seconds.
So that's good to know.
And that's the way we can validate that.
So if I wanted to, I could say config T, spanning tree VLAN 1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So if I wanted to, I could say config T, spanning tree VLAN 1.
And I had a question mark.
I see I can configure my timers here.
So I can change the hello time to, let's say, four seconds.
So let's come down here.
We'll do our debug command again.
Now this is going to be interesting,
because I only changed the hello time on VLAN 1.
So let's see what ends up happening here.
I'm just going to go ahead and cancel the debug's.
And then we'll go and evaluate it.
So let's scroll up and see what happened here.
So we happen to catch. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we happen to catch.
It looks like right here.
OK, so we've got our VLAN 1 BPdu sent out.
It looks like 1 got sent out at 01, 1 got sent out at 02.
So that's kind of interesting.
03 here is when we sent VLANs 10, 20, and 30.
And then 05, we're also sending 10, 20, and 30.
But notice here, we've got VLAN 1 now
sending on the 06.
We did not send one here in 03.
So 02 looks like this is about where we actually are talking
about this 01 was probably off by a few milliseconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about this 01 was probably off by a few milliseconds.
It's basically 02.
So 02 to 06 is where we actually--
we send it every four seconds.
We shouldn't see another one now at 7, see it VLAN 10, 20,
30, 10, 20, 30, and then 10 down here.
So notice that it did change it to every four seconds.
So that's pretty cool.
It's good to know that changing the Hello timer
actually does work.
So now what I can do is test the forwarding delay.
So I can say debug spanning tree events. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I can say debug spanning tree events.
And let's get onto an interface here.
I'm just going to get onto interface gig 00.
This goes to switch 2.
I'm going to do a shutdown.
Now notice what just happened here.
At 26 seconds afterwards, we generated a TC trap
that topology change trap like we said.
And we-- yeah, just other information about this.
So we are the spanning tree root,
sending topology change notifications
on the different VLANs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
on the different VLANs.
And let's go ahead and say no shut.
So when I do the no shut, what's interesting here
is we're going to see that we progress through the listening
learning states.
And notice this is happening on every VLAN, VLAN 1, VLAN 10,
VLAN 20, VLAN 30.
It also started at 50 seconds after the minute.
So we'd expect to transition to the learning 15 seconds later,
which would be five seconds after the next minute.
So now we're in learning.
And then at about 20 seconds here after the minute, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then at about 20 seconds here after the minute,
that is when we should be back into a forwarding state.
So this is a great way that we can use this debug command
to verify that the timer is already working.
And so there we go.
We're at the 20 second mark.
And remember, when we transition to forwarding,
that's going to trigger another TC trap.
So if I do a show spanning tree VLAN 1, VLAN 1, there we go.
We do notice that the aging timer at 15 seconds, which again,
reflects the fact that we're in a topology change,
like we talked about. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
like we talked about.
Notice our hello time is at four seconds.
Let's go ahead and go over to switch to show spanning tree
VLAN 1, see what it thinks is happening.
So it sees that our root is suggesting a hello time of four
seconds, but locally I'm configured at two seconds.
So the question here is how often am I actually
sending my VPDUs?
I've got my local configuration at two.
Hello time is at four.
So once again, I can use that same debug command.
So debug spanning tree, VPDU transmit. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So debug spanning tree, VPDU transmit.
How often are we sending it for VLAN 1?
Well, here's one.
Oh, you know what?
Always make sure your service time stamps are on.
If you're going to be tracking with time stamps,
that's going to be important.
All right, so it looks like at 10 seconds,
we sent a BPDU for VLAN 1, 14 seconds.
All right.
And we're not sending BPDUs for the other VLANs. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're not sending BPDUs for the other VLANs.
Might not be actually configured on this switch.
So every four seconds, we see that we are sending our BPDUs.
So it's not the local configuration,
but it is indeed the root configuration
that drives our timers.
So the hello timer especially is going to be relevant
because I don't actually send BPDUs on my own.
I wait for a BPDU to be received from the upstream root. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I wait for a BPDU to be received from the upstream root.
So lastly, let's test max age.
And in order to do that, let's take a look
at our diagram again.
Things have changed a little bit here.
We no longer see switch three as the root,
but instead switch one is the root
because switch one is the root,
switch four is probably blocking a port.
And I don't remember what values
all of our priorities are at.
It's going to be one of these interfaces.
Let's go ahead and take a look at switch four.
Show spanning tree blocked ports. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Show spanning tree blocked ports.
VLAN 1, it is blocking a couple of ports.
So we do have actually another switch in this topology.
We'll see this later on in the,
in when we get to the lab here towards the end of the skill,
but this would be our gig three slash one.
So that's apparently blocking as well.
We don't need to worry about that for right now.
What we do need to know is that we're blocking gig zero two.
Gig zero two is this connection here.
So this is our blocked port. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is our blocked port.
So if that's our blocked port, how do we test max age?
I want to see how long it takes for this port
to come back online in the event of an indirect outage.
If I just shut down this link,
we'll pick this back up in 30 seconds
'cause we'll immediately transition it over to learning
because it's my next best upstream connection.
However, what if this link over here goes down?
What if switch three, this is switch three's gig zero two port?
And so if I were to take that down,
switch three all of a sudden has no path to the root WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
switch three all of a sudden has no path to the root
and it's going to try to come this way.
But we can't come this way 'cause switch four
is trying to go this way to get to the root.
And so we're all going to be kind of stuck for a little while.
And so we want to again see how long it takes
switch four to realize that there's a problem here.
And so what we're going to do is we're going to enable
our debug's on switch four.
I'm going to again do debug spanning tree events.
And I'm going to get on here and make sure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I'm going to get on here and make sure
that service timestamps are configured.
(keyboard clicking)
All right, and again, we're expecting something to happen
here with gig zero two coming out of block.
So let's go ahead and get on to switch three,
interface gig zero two, and we're going to actually,
let's just do real quick, do show spanning tree root.
All right, so indeed that is my root port for VLAN one.
So I'm going to go ahead and shut this down.
And let's come over to switch four WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And let's come over to switch four
and see what ends up happening.
So look, right away we're actually hearing new BP to use.
So this is really cool, actually.
So switch three is like, hey, I lost my root port.
So I am the root.
I must be the root.
And it's sending BP to use out everywhere technically,
but out here and switch four saying, wait,
now I'm receiving these BP to use
that suggest that there's a new root downstream.
So that's exactly why we're saying
we're hearing this root down here.
And we're actually ignoring it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we're actually ignoring it
because it's an inferior BP to you.
We have to wait for Max H to be done
before we can pay attention to it.
So let's take a look here.
So we see that we started hearing these at 47.
Max H lasts 20 seconds.
So we would expect this to be about seven seconds after,
and indeed about seven seconds after, hold up.
(laughs)
We're waiting for all of this to settle out.
Let's go ahead and undi-bug all of this.
So somewhere right around here, let's see here. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So somewhere right around here, let's see here.
All right, so right here.
So this is when we transitioned over to listening.
So we have four seconds and then this is 47.
So we do the math there, we say it's about 17 seconds.
Well, wait a second.
We said we were gonna wait 20 seconds.
Why only 17?
Max H is based on the last BP to you that was received.
So if I received a BP to you and then a second or two
later pass and then the link goes down,
well, the 20 seconds is relative to the last BP to you WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
well, the 20 seconds is relative to the last BP to you
I received.
So it'll actually be a little bit less
than the full Max H timer because of that.
So once we really think through how all these timers work,
you know, that makes a whole lot of sense
how that ends up happening.
So at this point, where were we?
Oh, at three.
So we transitioned to learning 20 seconds
after we received the last BP to you,
which was 17 seconds after the port went down,
or after we started hearing new BP to use.
And so 15 seconds later from 03, so about 018 here, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so 15 seconds later from 03, so about 018 here,
we should see that we transitioned to learning.
Now we're off by a second because there's milliseconds
involved here and we're rounding the seconds.
So no problem, we're not too worried about that.
And then about 15 seconds later,
we should transition to forwarding and from 19 to 34,
indeed we do.
So that validates for us not only how these timers work,
but also makes us think a little bit about how,
exactly Max Age did works with indirect failures and the like. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
exactly Max Age did works with indirect failures and the like.
And so one of our primary takeaways here,
besides just knowing how to test this
and seeing the results ourselves,
is knowing how to configure these.
So remember, it's everything with Cisco's
on a pervieland basis.
Spanning tree vlan one question mark,
I can change the forward time,
I can change the hello time,
I can change the Max Age all here,
and I can do so again on a pervieland basis.