10-03-2014 09:49 AM - edited 03-07-2019 08:58 PM
So I have an interesting issue and somewhat of a dispute with a colleague. Here we go, hopefully this makes sense. The scenario is below:
A colleague has enabled udld in aggressive mode on a fast ethernet interface on a Cisco 3750 me switch. This switch is facing another fast ethernet port on a switch of a different vendor (NSN). The port has been up for some time and working (we didn't know it was enabled). For some reason, UDLD detected a TX/RX loop and error disabled the port. The question is - why would UDLD have detected anything if it was facing a device that does not support it. I have tried duplicating this in the lab to no avail. Below are the logs:
.Sep 27 14:18:11.689 UTC: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Fa1/0/6, transmit/receive loop detected .Sep 27 14:18:11.689 UTC: %PM-4-ERR_DISABLE: udld error detected on Fa1/0/6, putting Fa1/0/6 in err-disable state .Sep 27 14:18:12.721 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/6, changed state to down
From everything I've searched, I cannot find anything related to UDLD disabled due to a TX/RX loop. Can anyone shed some light? Thanks!
10-03-2014 12:06 PM
It looks to me that UDLD didn't detect a unidirectional link, but instead shut down due to a loop being discovered. I would surmise that a loop could be observed without the opposite end of the link knowing how to speak UDLD. It's primary purpose is to prevent loops anyhow.
Please rate if helpful.
10-04-2014 12:19 AM
Not all vendors support UDLD (and subsequent flavours). So be careful about it.
Next, do NOT enable UDLD on copper ports. NEVER. UDLD will significantly benefit if used on fibre optic link.
10-04-2014 09:10 AM
Hi,
I agree with Antonio's assessment: It appears that the port on the Catalyst 3750 received back its own UDLD message. This will indeed cause UDLD to err-disable the port. In fact, UDLD err-disables a port when one of the following four conditions occurs:
This list is compiled from three primary sources - the U.S. Patent # 7,480,251 where UDLD mechanism is patented, the RFC 5171 where an overview (albeit a little vague) is provided, and from the following Cisco website article:
http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10591-77.html
Following the log message you have received, UDLD clearly complains about a looped port. How the port could become looped is a matter of discussion - perhaps a topology change event occurred in the network that temporarily caused the NSN switch to reflect frames to unknown destinations back to their sender through the same port (although that should NEVER, EVER happen with any decent switch), or there may indeed have been a transient loop caused somewhere at or behind the NSN switch. In general, UDLD messages are ordinary 802 SNAP-formatted frames destined to 0100.0ccc.cccc multicast MAC address and flooded accordingly by non-UDLD switches.
In any case, UDLD can, and will, deactivate a port upon discovering it is looped.
Best regards,
Peter
10-04-2014 04:36 PM
You don't need "all" UDLD experts. You got the best expert (Peter) answering your question and that is all you need.
How have you been Peter?
Thanks,
Reza
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide