Before we jump into the lab and configure UDLD, it's important to know that
there are two different modes of deploying this technology.
The first of which is known as normal mode, and the second is known as
aggressive mode.
And generally speaking in production networks, we are going to use aggressive
mode more often than not.
So what's the difference?
Well, when we configure UDLD on a link, we place the configuration on the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, when we configure UDLD on a link, we place the configuration on the
interface from one switch's perspective.
And in order for UDLD to work, we're going to have to configure it on both
sides as we might imagine.
Because remember, we're using the echo concept.
So if I send a keep alive to the other switch, if it doesn't know to loop it
back around, then it's not going to be very useful to me.
That doesn't just happen on its own. We need the UDLD running on both sides.
But what's going to happen is that the UDLD keep alive is going to get sent out
once every 15 seconds. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
once every 15 seconds.
And we're just making sure that that link stays up.
Now, if for any reason we don't get anything back, the question is which mode
are we running here as far as what our response is going to be.
Normal mode is just going to basically send an informational log message to say
, "Hey, something seems up on this link."
It's going to place the port into what's known as an undetermined state.
And effectively all we're really getting is a log message that says that again, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And effectively all we're really getting is a log message that says that again,
something appears to be wrong.
That's why usually in production networks, we're going to want to run
aggressive mode.
Aggressive mode is going to wait for there to be a miss on some of these keep
alive.
And so once it is determined that the link has gone down, it's going to
actually go into a second, let's call it another mini mode of operation here,
where it's going to aggressively try to reform that connection. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
where it's going to aggressively try to reform that connection.
How exactly does it try to reform the connection?
By sending eight keep alive in rapid succession, every second at this point.
So we've missed some keep alive, we're saying, "Hey, maybe this link is down."
We want to make sure that it is indeed down or it is indeed up one way or the
other.
Again, every 15 seconds doesn't tell us much. Let's go ahead and send a burst
of messages.
So we send eight of them every second.
And if we don't get anything back at the end of that, we're going to then place WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if we don't get anything back at the end of that, we're going to then place
the port into air disable.
As we mentioned, the goal of UDLD is to land an air disable to protect the
network from loops.
However, it's only aggressive mode that actually lands us in air disable.
And so that's why typically we want to configure it for air disable.
Now, there's a couple of things to consider with UDLD.
First of all is the copper versus fiber conversation.
As we might imagine, we're talking about unidirectional communications. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
As we might imagine, we're talking about unidirectional communications.
And the example we gave in the previous video of maybe fiber strands cracking
or one of these types of situations,
we probably would expect that fiber is going to have the most benefit from UDLD
.
After all, copper actually uses link pulses to determine whether or not all of
the pairs are connected.
However, we can deploy UDLD to both.
Just as sort of a fail safe to our fail safes, if we really want to run it WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Just as sort of a fail safe to our fail safes, if we really want to run it
across a copper connection,
this goal will allow us to do so.
Now, what's interesting about UDLD is how it's actually deployed.
I mentioned that we want to deploy it to these individual interfaces.
And so I can deploy it to an interface and I can deploy it to copper and fiber
interfaces.
But I can also configure it at a global level.
And if I configure it at a global level, it's going to apply to all fiber ports
.
Yeah, it's not going to apply to copper ports if I enable it globally. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Yeah, it's not going to apply to copper ports if I enable it globally.
So that's an important takeaway for us here, is for us to recognize if I wanted
on copper ports,
I have to manually deploy it to the interface.
But if I just wanted on fiber, which is pretty typical, even in production
networks,
to say I'm going to focus on fiber, then I would deploy it globally to make
sure that not only the fiber ports that are there today,
but also fiber ports in the future will automatically run UDLD.
Alright, let's go ahead and jump into the lab and in our lab, we've got a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Alright, let's go ahead and jump into the lab and in our lab, we've got a
similar topology to what we've used in the past,
where we have a triangle of switches, we have switch three,
and switch three happens to be the root. That's not going to come into play in
this conversation,
but it will when we look at loop guard.
So one thing we may have noticed by the way in all of this is that UDLD is
completely unrelated to spanning tree.
Yes, it does block loops from forming by putting a port into air disable,
but it doesn't actually tie into the STP process.
It doesn't care where the root is, for example. It doesn't care about the flow WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
It doesn't care where the root is, for example. It doesn't care about the flow
of BP to use.
Its job is simply to monitor a link and to shut it down if it goes into a unid
irectional mode of operation.
And so that's why it doesn't really matter as part of this video where the root
is,
but at the same time it might be helpful to know.
And so we're going to apply UDLD here to switches three and five, that link
between the two.
And so that's going to be gig two slash one and gig two slash one on both
switches.
So let's go ahead and configure this on switch three. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's go ahead and configure this on switch three.
I'm going to do a config T and from here I'll get on to interface gig two slash
one.
And then UDLD question mark, this is how we configure UDLD.
I'm going to require the port command, but when I run question mark one more
time,
I'm going to find that I can either hit enter to enable normal mode,
or I can type out aggressive here, and that's going to enable UDLD aggressive
mode,
which is again what we typically see.
So when I go back out to my configuration prompt here, global exec, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So when I go back out to my configuration prompt here, global exec,
I can just do a show UDLD on an interface like gig two slash one.
I can see a lot of information about how often messages are going out
and whether we're in aggressive mode, for example, right there.
So that's good information.
And then also show UDLD neighbors will tell me who's out the other side.
Now notice we haven't actually configured this on switch five yet, so we don't
see anybody.
And it's also important to know that at this point we've sent a bunch of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And it's also important to know that at this point we've sent a bunch of
messages
and we haven't gotten anything echoed back.
And if I do a show interface on gig two slash one, it's still in an up and up
status.
So why hasn't UDLD shut anything down yet?
Well, fortunately Cisco recognized that if we want to deploy UDLD under a
critical link,
we didn't want to have to go so fast so as to make sure that UDLD doesn't shut
a link
down just because we configured it on one end, or maybe a misconfiguration WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
down just because we configured it on one end, or maybe a misconfiguration
would do that as well.
Instead, switch three's UDLD process is going to wait to receive any other
message
from the other side before it will consider shutting it down.
So yeah, it's sending keep-alives right now, and yes, it's not getting anything
back,
but until we configure UDLD on the other side, switch three is not going to
think that
there's a need to shut the port down because it hasn't received a keep-alive of
its own.
So now I'll go to switch five.
Let's say config T, interface gig two slash one, and then I can do UDLD port WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Let's say config T, interface gig two slash one, and then I can do UDLD port
aggressive.
And at this point, let's just go back to switch three and run some of those
same commands.
So we did a show UDLD on this interface gig two slash one, and now we look at
this.
We actually see an entry listed here for the neighbor.
We're in a current bidirectional state, which is good.
We're sending messages every 15 seconds, also good.
And then when I do a show UDLD neighbor, we also see the device on the other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And then when I do a show UDLD neighbor, we also see the device on the other
side.
So these are very useful commands to validate that UDLD is working like we
think it is.
And again, we have to just configure this on an interface rather than globally.
So in our lab environment, this is all virtual.
There's no virtual fiber links.
It's all virtual copper links.
So we had to do it on the interface.
And I wanted to configure it globally in a production real physical type of
environment.
I can do a config T and then UDLD question mark shows me my options. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
I can do a config T and then UDLD question mark shows me my options.
I can change the well, first of all, I can set aggressive mode.
Interestingly, I'd say, oh, this should be UDLD port.
Now it's UDLD enabled in order to configure it in normal mode.
And then also I can change message time, like the amount of time that I send my
messages.
So I could just say UDLD aggressive here.
And then it will automatically enable that on fiber ports.
And actually it says that enable UDLD protocol in aggressive mode on fiber
ports except where locally configured. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
ports except where locally configured.
So local configuration will always override global configuration, but do notice
that this will only go to fiber ports when we configure it globally.