Everything we're going to talk about in this skill has to do with one
fundamental flaw
of spanning tree protocol.
And it has to do with the fact that spanning tree protocol must support hubs.
We look at this and say, well, okay, that's great, but we don't want to support
hubs
anymore.
And that's cool and all except spanning tree still has to be able to support
them even
today.
We need this backwards compatibility.
And so here's the situation that's going to drive most of our conversations.
Let's say we have a stable spanning tree topology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's say we have a stable spanning tree topology.
And we know that somewhere up here is the root of the network and we're sending
our
BP to use downstream.
Those BP to use land on some switch like this.
We'll call this switch three and downstream of switch three is switch four.
And let's say that switch four has another path to the root.
In fact, this is switch four's root port.
And here we have a connection to switch three, so we've decided, you know, that
's another
upstream port, but we're going to place this into the non designated port or WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
upstream port, but we're going to place this into the non designated port or
blocking status.
And so this prevents our loop.
We see that there's kind of a loop all the way around like this, but the fact
that we're
blocking that port means that there is no loop and life is good.
But notice the BP to you flow here.
We're receiving BP to use this way.
And we're receiving BP to use this way.
The BP to use are sort of like the lifeblood of the spanning tree topology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
The BP to use are sort of like the lifeblood of the spanning tree topology.
Those BP to use must be maintained because they're maintaining the topology
switch four
knows to continue to block that port because it continues to receive superior
BP to use.
And remember, a superior BP to you tells us that that is an upstream port
because that
is a better path to the root than anything that I would claim to have myself.
And so therefore, if I send packets that direction, it'll get to the root. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so therefore, if I send packets that direction, it'll get to the root.
But remember, I can only have one upstream port, which is why I have to block
one of those.
So the best upstream port becomes my root port.
As soon as I'm receiving superior BP to use on other ports, and it's not as
good as that
one, they're going to be blocked.
Meanwhile, inferior BP to use or for that matter, no BP to use.
This means that it's downstream.
And while I block all of my upstream ports besides one, downstream ports are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And while I block all of my upstream ports besides one, downstream ports are
always going
to be forwarding because there's no risk of a loop in theory when I'm
forwarding packets
downstream.
So what happens here is that life is good until what happens, and this is the
big scenario
that we need to address, what happens if the superior BP to you stops?
Specifically in our diagram here, these BP to use stop showing up for some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Specifically in our diagram here, these BP to use stop showing up for some
reason.
Now if this link is down, that's not a problem because now that link is no
longer a part
of our topology.
But what if the link is up?
The link remains up and the BP to you stops.
Well this is a problem because now this gets classified here was saying that
there's no
BP to use, which means it's now considered to be a downstream port, which means
we're
going to transition into the forwarding state. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going to transition into the forwarding state.
So this is the problem.
This non-designated port actually gets changed over to being considered a
designated port
and it goes into the forwarding state.
Now yeah, we're going to have to go through our timers or have to wait for max
age.
That's 20 seconds by default.
And then we're going to have to wait for listening and learning, which is 15
seconds
each.
But after 50 seconds, we have transitioned that port into the forwarding state.
And now we have this large loop, which is a problem. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now we have this large loop, which is a problem.
Now we might look at this scenario and say, okay, that's interesting.
Why did those BP to you stop?
Well the why is going to drive a couple of our conversations because there are
a couple
of different reasons why this might happen.
And the solution is either going to involve a technology known as UDLD, unid
irectional
link detection.
And that's what we're going to talk about here.
Or we could possibly prevent this using another technique that we call loop WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Or we could possibly prevent this using another technique that we call loop
guard.
And so depending on the scenario, we're going to address that scenario with one
of these
techniques.
Now we're going to go into those details, but we do have to pause for a moment
and make
sure we understand that this is problematic.
Now real quick, we might say, okay, so if this is our scenario and the link
stays up and
yet I stop receiving BP to use, why wouldn't we just recognize this and put WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
yet I stop receiving BP to use, why wouldn't we just recognize this and put
this into the
blocking state from a spanning tree perspective?
Well the reason for that is because again, there could be a hub in here.
And so if there's a hub in the middle and there's all kinds of hosts hanging
off that
hub and all of a sudden this link goes down upstream of the hub, well now this
link down
here stays online and I stopped receiving BP to use.
If I immediately block that port using standard spanning tree, well then all of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
If I immediately block that port using standard spanning tree, well then all of
these hosts
are going to lose their network connectivity.
There goes the redundancy of having a link to two different switches.
And so this is why spanning tree can't do anything about this.
It's going to require us to be proactive with one of these two techniques to
say, okay,
yeah, it's great that spanning tree can't do anything about it because of the
whole
hub situation but I in the modern network, I can do something about it and I
can recognize
that, okay, assuming there's no hubs here and it doesn't have to be an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that, okay, assuming there's no hubs here and it doesn't have to be an
assumption and
we'd confirm that there's no hubs there which again in the modern network is a
given in
most cases hopefully.
But once we confirm there's no hubs in the network then we can go and deploy
these different
techniques and that will make sure that we don't cause a loop in that scenario.
So let's talk about this why and specifically this conversation around UDLD.
So one of the why's the ways that this could actually create a situation where WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So one of the why's the ways that this could actually create a situation where
we stop
BP views is known as a unidirectional link.
A unidirectional link means that we can only speak in one direction.
Hence una which means one there and directional is saying one direction.
So the idea here is that we have two devices and let's say that this is the
upstream switch
and this is the downstream switch and we always are going to have two streams
of communication. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of communication.
I need to be able to send to the switch this way and the switch needs to be
able to send
back to me this way.
Now usually this happens on a single connection.
If that's a copper connection, we use different pairs in the copper in order to
transmit and
receive.
However, what if this is fiber?
Well fiber works with two strands in most cases.
We've got a strand here, a strand here and one of those is going to support one
direction
and the other one is going to support the other direction. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and the other one is going to support the other direction.
So if this is the upstream switch and I need to send a BP DU, it's going to go
out here
out the one fiber strand that I transmit on.
And so the BP DU's get carried here on the top strand.
So you can probably tell where we're going with this what happens if this top
strand goes
down but the bottom strand is A-OK.
Well at this point we have a problem because this switch is trying to send BP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well at this point we have a problem because this switch is trying to send BP
DU's but
the downstream switch has stopped receiving them.
Furthermore, this link is considered to be up simply because it can continue to
send traffic
if it so desires.
This will indeed result in a loop.
And so what could cause a unidirectional link?
Well a lot of things.
Certainly crimping fiber could actually cause that if we pull our fiber around
a corner too
hard or we're up in the ceiling and we tug on it too hard. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
hard or we're up in the ceiling and we tug on it too hard.
Maybe one of them gets crimped, maybe one of them actually gets snapped.
And so there's lots of different options here.
And so the concern is that these two switches have no awareness of the fact
that this strand
broke.
And because all we did was we stopped receiving traffic but for all we know the
upstream
switch just stopped sending any traffic.
So we need the ability to detect a unidirectional link. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we need the ability to detect a unidirectional link.
And that is going to lead us to unidirectional link detection which is a very
appropriate
name for what we're trying to do.
We're trying to detect unidirectional links.
And this is usually abbreviated as UDLD.
Now by the way, this is a Cisco technique, a Cisco technology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now by the way, this is a Cisco technique, a Cisco technology.
We're not going to find this on non-Cisco devices.
So we're talking about UDLD as well as LoopGuard down here.
Just like with BPU Guard and RootGuard, these are Cisco technologies.
And so we're really focusing on this from the perspective that we are working
on all
Cisco devices.
So what exactly does UDLD do?
Well UDLD forces communication across a link by using KeepaLives.
So now if we draw this back out and we've got our two different strands, yeah WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So now if we draw this back out and we've got our two different strands, yeah
we're trying
to send BPDUs out this way, but we're also sending KeepaLives.
And so even if the BPDUs were to stop, let's say this whole thing breaks again,
well yeah
I stopped receiving BPDUs but that doesn't mean the link is down, but hey, I
stopped receiving
KeepaLives.
If I stopped receiving KeepaLives then I know the link is down.
We're forcing a constant stream of communication that tells us if that stream WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're forcing a constant stream of communication that tells us if that stream
of communication
stops, that means that the link is unidirectional.
Now here's a question, how does this switch on the left know that this one
strand is down?
Because if we're just sending KeepaLives on this link then we're going to think
everything
is fine.
Well the reason why we can detect that the other strand is down is because we
actually
use the concept of echoing.
Meaning that when I send a KeepaLive, this switch is responsible for bringing
it in and
looping it back around.
And so this KeepaLive actually shows back up, thereby it allows each individual WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so this KeepaLive actually shows back up, thereby it allows each individual
switch
to test both strands at the same time.
So if this strand is down, these KeepaLives won't be showing up and therefore
this switch
also recognizes that there's a problem.
So here's the question, what do these switches do when there's a problem?
Well they are going to place the port into AirDisable.
Just like with our BP-DU guard, it's going to shut these ports down and it's
going to
either require manual intervention or we're going to rely on automatic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
either require manual intervention or we're going to rely on automatic
attempted recovery
at least using AirDisable Recovery.
But we can tell that this is treated very seriously because we are shutting the
link
down.
Now one last interesting point here is that these Echoes, these KeepaLives,
they're going
to use a specific MAC address.
And that MAC address is 0100 and then lots of Cs.
C, C, C, C, C, C, C.
Now why am I spelling out the MAC address here? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Now why am I spelling out the MAC address here?
It's not so much that we want to memorize it.
I don't expect this goes wanting us to be able to recognize the MAC address
that's used
by UDLD.
However, the reason why I pointed out is because we can actually filter this
MAC address using
a MAC address access control list and that will allow us to test UDLD.
It can be difficult to test something like UDLD because I don't really have a
great
way of going out even if I have physical devices and try to shut down one of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
way of going out even if I have physical devices and try to shut down one of
the strands.
Maybe literally cut a fiber cable or something like that.
I certainly know of people who have done that in the past to test UDLD.
Well we don't actually have to do that.
We can simply filter out the MAC address for the testing and that will allow us
to see
the unidirectional link's failure detection in action.
But at the end of this whole conversation, again, let's make sure we understand
the scenario
that causes loops specifically are superior BPDUs stop coming in and therefore WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that causes loops specifically are superior BPDUs stop coming in and therefore
we need
to go against the native spanning tree behavior of saying, "Hey, let's just put
that into
forwarding state."
Instead, we want to shut that link down to prevent a loop from occurring.
[BLANK_AUDIO]