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!
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.
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:
UDLD messages received by a switch S on its port P do not advertise the particular <S,P> combination in the list of detected neighbors carried in the message. This can either mean that the originator of this UDLD message (a neighboring switch) does not hear the switch S at all, or that the connection is miswired - the Tx fiber is possibly plugged into a different port than the Rx fiber.
UDLD messages received by a switch S on its port P are originated by the same switch and port. This suggests a looped port. This condition appears to apply to your situation.
The switch detects only a single neighbor speaking UDLD but its UDLD messages contain more than one <Switch,Port> pair in their list of detected neighbors. This suggests a shared media with impaired reachability between attached switches.
If and only if the agressive mode is activated, UDLD messages that have been arriving from a neighbor in bi-directional UDLD state suddenly cease to be received. This suggests a medium whose connectivity has become impaired during its operation, and at the same time, the port's hardware is unable to bring the port down automatically.
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:
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.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...