Hello Jonathon
This is an interesting point that you bring up and it has given me (and I hope other readers) an opportunity to dig deeper and appreciate the intricate details that engineers have gone into in order to develop and implement these features.
I’d like to point out that according to Peter’s explanation (and the patent), there are two methods of detecting a unidirectional link: explicitly and implicitly. Explicit detection will result in the disabling of the port regardless of the mode of operation. Although Cisco documentation does not explicitly state this (pun intended), it seems to indicate this in this document:
Specifically it says:
If the port does not see its own device/port ID in the incoming UDLD packets for a specific duration of time, the link is considered unidirectional.
This echo-algorithm allows detection of these issues:
- Link is up on both sides, however, packets are only received by one side.
- Wiring mistakes when receive and transmit fibers are not connected to the same port on the remote side.
Once the unidirectional link is detected by UDLD, the respective port is disabled and this message is printed on the console:
UDLD-3-DISABLE: Unidirectional link detected on port 1/2. Port disabledPort shutdown by UDLD remains disabled until it is manually reenabled, or until errdisable timeout expires (if configured).
All of the above is regardless of the mode of operation. This corresponds to the explicit method of detection.
In the following section of the same document, it describes implicit detection, which is where the mode of operation kicks in:
Here it states:
UDLD can operate in two modes: normal and aggressive.
In normal mode, if the link state of the port was determined to be bi-directional and the UDLD information times out, no action is taken by UDLD. The port state for UDLD is marked as undetermined. The port behaves according to its STP state.
In aggressive mode, if the link state of the port is determined to be bi-directional and the UDLD information times out while the link on the port is still up, UDLD tries to re-establish the state of the port. If not successful, the port is put into the errdisable state.
Aging of UDLD information happens when the port that runs UDLD does not receive UDLD packets from the neighbor port for duration of hold time. The hold time for the port is dictated by the remote port and depends on the message interval at the remote side. The shorter the message interval, the shorter the hold time and the faster the detection. Recent implementations of UDLD allow configuration of message interval.
The above statement only refers to a case where there is a timeout and UDLD info is not received. This describes the implicit detection, and this is where the mode of operation has meaning.
The documentation does not clearly state that the mode of operation plays no role when explicit detection is observed. However, in the document you shared above (Troubleshoot Uni-Directional Link Detection Errors on Nexus Switches), the examples stated correspond exactly with the patent.
Short of actually performing these tests in a lab, I believe that the Cisco documentation for both IOS and Nexus does agree with the patent, although I do believe that it could have been written more clearly.
I hope this has been helpful!
Laz