udld aggressive mode

So, i discovered something new today.

I disable auto-neg on both ends of a fibre link.
I enable udld aggressive mode on each port, pull the tx fibre, when the port detects a unidirectional link it goes error disabled. All good so far, next i config udld recovery using errdisable timeout of 30 seconds.After 30 seconds the port comes up, the tx is still disconnected and the port is up and forwarding in stp.
I expected the port to either not come up or come up and go errdisabled after udld kicked in again.
I've tried this on a 3550 with two ios versions and a catos 6500, result was the same.
After some digging i read an old email which mentions this is a limitation of udld, since the tx is down no udld is sent so no udld frame is echo'ed back to initate the protocol.
Just to be sure as i cant trust the email 100%, any chance someone else can try reproduce this? preferably on an old image.
Cheers...

Find more posts tagged with

Free for TechExams community: Cybersecurity salary guide

Compare cert salaries and plan your next career move

Button

Comments

GT-Rob

I have not tried that but it seems silly of the protocol. Basically saying if it can't start up in the first place correctly, its not going to run I guess. Maybe it is a way to protect the link from going into errdisabled by mistake.

Maybe look through some Cisco docs. Again like you said though, a newer image might be different.

ixg123

Hi Ed,

By disabling autonegotiation you're effectively removing udld's ability to determine the L1 status aren't you? I don't have a switch to test on but am prepared to bet that restoring autonegotiation will allow udld to function as you expect!

EdTheLad

Yes, i was testing udld's at L2.At L1 udld will shutdown a port that is connected to the wrong neighbor, in my test case if auto-neg was enabled, autoneg would bring the port down rather than udld.

ixg123

At L1 udld will shutdown a port that is connected to the wrong neighbor, in my test case if auto-neg was enabled, autoneg would bring the port down rather than udld.

Really? auto-negotiation has no concept of a neighbour-id and so surely bringing down an incorrectly wired port would also be a result of udld ....

EdTheLad

Yes auto-neg has no concept of neigh-id, it negotiates physical layer attributes speed,duplex.In my initial post i mentioned i disconnected tx, if auto-neg was enabled this would cause the port to drop.You replied saying by not enabling auto-neg udld will lose its ability to determine the L1 status, i try to explain how udld works at layer 1 i.e. detects an incorrectly wired port.
Since i'm not interested in verifying incorrectly wired ports, why should i care about udld at layer 1?

Now i will repeat myself and say i am only interested in udld at l2 as i know my switch is physically connected to the correct port.To test udld at l2, auto-neg needs to be disabled otherwise when i disconnect tx, auto-neg being a layer 1 protocol will drop the link.

nullrouter

Is your UDLD config the same for both end ports on either switch?

Also UDLD likes to be in sync, prehaps doing the recovery time command after the fact the port has been brought down may be impacting this.

dtlokee

Ed, I found the same thing you are saying when I tested UDLD, until UDLD could establish a neighbor relationship it had no effect on the link. I guess this also counts when the link comes out of the err-disabled state. It probably needs to reestablish some form of bi-directional communications before UDLD actually starts again.

EdTheLad

Yep thanks, i've tried on afew different images and platforms with the same result.
Nice way to get a loop if you have a remote switch with two uplinks,auto-neg disabled and udld aggressive recovery enabled.

cisco_trooper

To your initial post, from what I remember from my BCMSN book UDLD doesn't become active until it verifies it has a bi-directional link. After a bi-directional link has been established, any further detection of unidirectional conditions causes UDLD to react.

If you think about the way you would initially enable UDLD on a link, it kind of makes sense. You cannot configure both ends at the exact same time, you will configure one, and then the other. After configuring the first link there is not a UDLD link on the other end to echo UDLD back, so it would fail pretty quickly if it did not wait for a bidirectional state to begin taking action when UDLD packets are missing.

We should run debug on this to see what the actual messages are....