We've mentioned a few different times that things happen in a spanning tree top
ology
according to specific timers.
So for example, we talked about how we send BPDUs every two seconds.
Well that's because we have a hello timer that is configured as part of our
spanning
tree operation and the default value, as we look at all of these having default
values,
the default is two seconds.
So what exactly is the little timer?
Well once again, it's how often BPDUs get generated. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well once again, it's how often BPDUs get generated.
So the root switch is responsible for sending out BPDUs and it will send it out
not every
two seconds necessarily, but ultimately what really matters is whatever the
hello timer
is set to.
So if we set it to three seconds, then BPDUs will be sent out every three
seconds and
we could send it to one second if we desired as well.
There's also a timer known as the forwarding delay.
The forwarding delay defaults to 15 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The forwarding delay defaults to 15 seconds.
And this value might sound familiar, recall that when we are in the listening
state or
the learning state that it was going to sit in that state for 15 seconds.
Well again, these are default values, but each one of these states are going to
use
the forwarding delay, which effectively means that we're going to be in these
two states
for two times the forward delay. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for two times the forward delay.
So if I have the forwarding delay set to the default of 15 seconds, that means
we're going
to be in listening and learning for 30 seconds, which is exactly what we had
said when we
covered this earlier on.
However, if I change the forwarding delay to be say 10 seconds, well that doesn
't remove
five seconds from our final timer, it actually removes 10 seconds because it
removes it twice,
thanks to the fact that both of these states use the forwarding delay.
Now lastly, we have a really interesting timer known as the max age. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now lastly, we have a really interesting timer known as the max age.
And the max age is going to default to 20 seconds.
And we have yet to really explore a situation that requires max age.
Now one thing to consider before we jump into spanning tree protocol timers is
the fact
that these same timers are going to be used in rapid spanning tree.
And Cisco's version of rapid is rapid pbsd plus.
So let's talk about this just for a quick moment.
We're going to go into details on rapid spanning tree coming up. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're going to go into details on rapid spanning tree coming up.
But as we said at the start of the spanning tree conversation, rapid spanning
tree is
built on the same principles as basic spanning tree.
And when I say the same principles, that includes the same timers.
As the name implies, rapid spanning tree is going to speed things up,
especially around
convergence in the event that a link goes down.
Traditional 802 dot 1d spanning tree might take 30 or even 50 seconds for that
outage
to be resolved by spanning tree. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to be resolved by spanning tree.
Rapids Pervieland spanning tree tries to say, we don't want to wait 30 or 50
seconds.
We just want to come up immediately.
And it does that using new mechanisms.
So we might assume that a protocol that's supposed to be faster uses faster
timers.
And that would be a bad assumption in this case, because rapid pervieland
spanning tree
uses the same timers.
So this is one of these reasons why we don't just want to skip ahead and learn
rapid.
We need to learn traditional spanning tree because we need to understand what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We need to learn traditional spanning tree because we need to understand what
these timers
do because it does the same thing as it does in the rapid world.
So let's go ahead and go through these real quick.
So when we're talking about the hello timer, we're talking about BPDU
propagation.
So we recall that the root bridge in traditional spanning tree is responsible
for sending a
BPDU every hello timer.
So by default, that's two seconds.
And I'm going to therefore send a BPDU down to the next switch every two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And I'm going to therefore send a BPDU down to the next switch every two
seconds.
Now the thing to keep in mind is that this switch is going to receive this BPDU
and trigger
the next BPDU downstream.
So in theory, we have a steady stream of BPDUs going down.
I generate a BPDU at the top and it flows down and it very quickly results in
everybody
getting a BPDU update.
And so from everybody's perspective, it happens about every hello timer.
Just keep in mind that they have to come from the root, meaning if for some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Just keep in mind that they have to come from the root, meaning if for some
reason I don't
get this BPDU, I don't actually send one out either.
With forwarding delay, we already talked about this.
This is going to be when I bring up a new connection.
This is a new connection between switches or for that matter, it's a new
connection to
a laptop or a PC.
Either way, we're going to transition from the listening state to the learning
state.
And then ideally, we land in either the forwarding state or the blocking state. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then ideally, we land in either the forwarding state or the blocking state.
Depends on whether we're a designated port or a root port or possibly a non-
designated
port or a role is going to determine which state we end up in after all of this
.
But we start with the listening state.
And as we already said, with the listening state, I'm not doing anything to
insert anything
I learn in the cam table.
With learning state, I absolutely am inserting addresses into the cam table, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
With learning state, I absolutely am inserting addresses into the cam table,
which prevents
a little bit of flooding.
I suppose when I first come online, I will have learned some amount of MAC
addresses thanks
to the broadcasts and flooding that might be coming down the link.
Now in this situation, both switches are going to go through the listening and
learning.
And so there's not going to be any traffic really flowing there, so there's not
going
to be a whole lot of learning happening.
Another way, as we've said, this is going to require two times the forwarding
delay, which
by default would be 30 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
by default would be 30 seconds.
So now let's talk about MAC's age.
This is probably going to be the most interesting part of the conversation
because MAC's age
does some interesting things.
And specifically what it defines is how long a BPDU is valid.
Just kind of interesting.
For what I just said, there is a situation where maybe I didn't get a BPDU.
So what do I do in that scenario?
Well I already have a BPDU that I received before and I start this at MAC's age WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well I already have a BPDU that I received before and I start this at MAC's age
timer.
So I know that this stays fresh if we're going to think of it that way for 20
seconds.
So if I miss one BPDU and two seconds later I get a new one, not a big deal
because this
will take down to 18 seconds and I actually missed it so it kicks down to 16
seconds and
at that point I get one.
Well when I get it I refresh this back up to the full 20 seconds or whatever
MAC's age
timer is configured for. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
timer is configured for.
So the purpose of this is to detect indirect failures.
A direct failure is pretty well detected.
If I have a switch and a connection and this link goes down I don't have to
wait very long
to know that this port can be transitioned immediately into the disabled state.
Furthermore I know that there can't be a loop out that connection because again
it's a direct
failure.
The port being down means that I can make some pretty good deductions about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The port being down means that I can make some pretty good deductions about
what's going
on.
An indirect failure on the other hand is much more difficult to detect.
And also remember that spanning true was developed back when there were hubs.
So maybe there's a hub here and for whatever reason this link goes down between
these two
switches.
Well this link for better or worse stays online.
Even though we lost a connection to let's say this being the root bridge we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Even though we lost a connection to let's say this being the root bridge we
were sending
BPDUs and so from this switch's perspective the port stays online it's in an up
state and
yet I'm no longer receiving BPDUs.
So what's going to happen here?
Because maybe I have another path to the root that goes this way but it's in a
blocking
state.
Well what's going to happen is we're going to wait for max age time to go down.
So again I'm storing that BPDU that I had received last.
I'm going to tick down from 20 seconds to 5 seconds 4, 3, 2, 1, 0 and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I'm going to tick down from 20 seconds to 5 seconds 4, 3, 2, 1, 0 and
eventually I'm
going to say hang on a second I no longer have a valid BPDU.
If I no longer have a valid BPDU I need to start the whole spanning tree
protocol process
over again.
I'm going to assume I am the root.
I'm going to place all of my ports into the listening state and I'm going to
attempt to
send BPDUs out to try to figure out if I am the root or if there's another root WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
send BPDUs out to try to figure out if I am the root or if there's another root
out there.
Now remember how long it takes to go from listening to learning to forwarding.
Our focus right now at this point is this port right here.
We want to get this port into the forwarding state and therefore we are going
to rely on
the timers for this.
So we had to wait 20 seconds for us just to re-initialize things.
Then we had to go through listening and learning. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Then we had to go through listening and learning.
So how long did it take to transition this from blocking all the way up to
forwarding?
Well, it took max age plus 2 times forwarding delay.
So this actually takes 50 seconds by default.
This is a very long time to wait for the network to come back online.
But all of the users that are here connecting in to this switch they have no
choice but
to wait 50 seconds because we can't just pull this block port out of forwarding WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to wait 50 seconds because we can't just pull this block port out of forwarding
immediately
with traditional spanning tree.
Instead we have to wait for this whole process to resolve itself.
So again, if this would have been a direct failure, if this port had just gone
down, we
could have immediately said hey, I lost my root port, I lost this BPD who is no
longer
valid, I could skip max age and just go straight to listening and learning.
So it still takes 30 seconds to get into a transition into a forwarding state. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it still takes 30 seconds to get into a transition into a forwarding state.
But this is only possible if it's a direct failure, if it's an indirect failure
we see
that it's going to require the full 50 seconds.
So here's the question.
That's great, that's an error with hubs.
Does this still happen in an era without hubs?
If I just have switches.
And the answer is yes, this does indeed happen.
So let's go ahead and draw this real quick.
We've got a triangle of switches. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We've got a triangle of switches.
We'll say that switch one is the root.
Switch two is not, but switch three is the one that is blocking down here.
So what happens if there's an indirect failure from switch three's perspective?
That would be this link going down potentially.
So let's say this link goes down.
That's a direct failure for switch two.
It immediately recognizes that it's BPDU is invalid because that was its root
port.
And the root port is now down, therefore my path to the root is no longer valid WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the root port is now down, therefore my path to the root is no longer valid
.
So that's great.
It's going to place this port into the listening state.
And it's going to say that I am the root as it's supposed to be.
It's going to start its process over and try to figure things out.
What is switch three going to do?
Switch three has a blocking port here.
It had been receiving BPDUs that were the superior BPDUs.
And now it's getting inferior BPDUs because switch two is saying that it's the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now it's getting inferior BPDUs because switch two is saying that it's the
root even
though it doesn't have as good of a priority as switch one.
Switch three is going to ignore those BPDUs.
It has no choice.
The BPDU is valid for 20 seconds or whatever max age is.
And so it has to wait 20 seconds before it clears out the BPDU and then it can
transition
that port through listening and learning.
So even in this era of just having switches without having hubs, we can see WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So even in this era of just having switches without having hubs, we can see
that this
is still going to require a total of 50 seconds in order for switch two to come
back online.
Because switch two doesn't have a path to switch one and it's path to switch
three is
blocked.
Therefore, it's going to be isolated for quite a while.
So this is why reliance on timers isn't ideal because we'd really rather have
different
mechanisms and we'll see those mechanisms with rapid that speeds this process
up.
But even rapid is going to fall back on these timers if those mechanisms fail
for any reason. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
for any reason.
And these timers, even though they're slow, they do give us the best chance of
forming
a loop free topology because the worst case scenario in all of this is that we
rush through
the process of recovery and we end up creating loops in the network that
creates further disaster.