Well, next up, Rapid does make another change that we need to be aware of, and
this has
to do with our topology change notifications.
Let's recall how this worked in 802.1d.
We have our tree that forms, and there's a change on the network.
And so whatever this change is doesn't matter here, we're going to send a
notification up
to the root.
And the root is then going to turn around and send down to the entire network
that there
has been a topology change. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
has been a topology change.
And the idea here is that we're trying to prevent the black hole of our MAC
addresses.
So if, for example, let's say we had a path this way to a host, host A, and
this link
has been blocked here, and this link just went down.
So this link can get restored, let's say after the 50 seconds have passed, now
we're in a
forwarding state, but where does host A live? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
forwarding state, but where does host A live?
Well, host A lives this direction now.
It doesn't live this direction.
And so if a packet arrives at the root switch destined for MAC address A, the
root switch,
even though convergence has happened here and we're back online, the root
switch is going
to look at its MAC address table and think that it has to send that packet this
way.
And that's just going to be a dead end.
And so it effectively black holes the traffic.
And so the purpose of this process is for us to recognize that whether it's 30 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so the purpose of this process is for us to recognize that whether it's 30
seconds
or 50 seconds for us to get back online, either way, what we want to do is we
want to set that
MAC aging timer so that everything times out before this timer occurs.
So worst case scenario is 30 seconds.
If this link hard goes down, this is going to only take 30 seconds to come
online.
And so we set our MAC address aging to 15 seconds.
So this is our traditional 802.1d.
And so by the time MAC address A is back online, this root switch's MAC address WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so by the time MAC address A is back online, this root switch's MAC address
entry has already
timed out.
And therefore when that first packet arrives destined for MAC address A, it
will get sent
the right direction.
That's all well and good except rapid spanning tree now presents a problem for
us.
And that problem is that our recovery is no longer 30 to 50 seconds.
Instead, it can be as quick as maybe a few hundred milliseconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Instead, it can be as quick as maybe a few hundred milliseconds.
This is roughly zero seconds to recovery because in this situation that would
be an alternate
port.
And as we said, alternate ports have fast failover.
So as soon as this link goes down, the alternate port is brought online.
So now even waiting 15 seconds for our MAC addresses to converge is way too
long.
But we have another problem as well.
We're trying to be as fast as possible with rapid.
And the idea that we have to send our topology changes to the root to propagate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And the idea that we have to send our topology changes to the root to propagate
to the rest
of the network, this is perceived as being slow.
So we have another problem in that we need our BPDUs for the TCNs to propagate
faster.
And so these are the two problems that we have to resolve with rapid spanning
tree.
So what we're going to find is that we have two solutions for this.
So let's address the big one, the MAC address problem first. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's address the big one, the MAC address problem first.
So MAC timers still must be addressed or must be adjusted in rapid spanning
tree.
However, the way this works is that we're going to immediately flush the MAC
tables.
This means that all existing entries are immediately flushed out.
We're not going to age them out after 15 seconds.
So even valid MAC addresses will be impacted by this change. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So even valid MAC addresses will be impacted by this change.
It makes it actually more disruptive when that ends up happening.
Furthermore, it's going to last for two hello timers.
Now this is much less than the amount of time it lasted with traditional
spanning tree,
which lasted for the combination of forward and MAC's age.
So 35 seconds is how long it lasted with 802.1d.
Instead, by default, this is going to last four seconds.
And so fortunately, it doesn't last that long. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so fortunately, it doesn't last that long.
However, because MAC address tables are flushed and they continue to be flushed
during this
time, it's going to create a whole lot of flooded traffic.
And so we want to reduce this as much as possible and therefore configuring
edge ports is even
more important with rapid spanning tree.
Now the other problem we said was that TCNs should go faster.
We don't want to have to send to the root for that.
So our TCN BPDUs are instead not going to be sent all the way up to the root, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So our TCN BPDUs are instead not going to be sent all the way up to the root,
but they're
going to be directly sent from the switch from the topology change switch.
Furthermore, the definition of what it means for there to be a change is going
to change
as well.
For example, we no longer care if a port transitions from forwarding.
Instead, there's only going to be one situation where we recognize that changes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Instead, there's only going to be one situation where we recognize that changes
might black
whole traffic.
And that is if a port transitions to forwarding.
This is the only time we're going to send topology changes out and we're going
to send
it again from the originating switch.
So before we had to wait for this slow process to get up here.
And so this switch right here in the middle would actually ignore the fact that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so this switch right here in the middle would actually ignore the fact that
TCN BPDU
was sent out until the configuration BPDU came down with the flag set from the
root switch.
Now as soon as the topology change gets sent out from this switch, this switch
here doesn't
have to wait for the root.
It just immediately starts performing these actions.
So topology changes are a big deal in all spanning tree environments.
But with rapid, it's even more important that we reduce TCNs where possible. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But with rapid, it's even more important that we reduce TCNs where possible.
So configure our edge ports everywhere and be aware of how exactly topology
changes affect
our environment and look for opportunities to clean that up where we can.