Hello @Nicholas Zerwig / @jont717
I hope you are doing great,
I would like to share some thoughst with you on this, usually a UDLD empty echo is presented due to:
- The UDLD bi-directional relationship has timed out on Switch-B because it does not receive the UDLD frames from Switch-A
- Switch-B received the UDLD frames from Switch-A but did not process them.
- Switch-A did not send the UDLD frames to Switch-B.
Now this dictates of course that the issue is the neighboring device, but I dont think so, but in order to discard this I would recommend you to connect fiber from the 2960X to the Nexus to any other port I would like this to be a port in other OIR Module or LC, and test the behavior (Allow a couple of test VLANs between them), if the UDLD is not impacted, it seems we are good from the 2960X, if it affects I would recommend testing to some other ports, replace SFPs, replace the fiber, or another uplink port in the 2960X. Well I would guess you have gone through most of that but I want to keep it as first step.
Then next I would power off and disinsert the OID module "poweroff module #", and then power on the module and test once again, because this could be due to a whole OIR module that needs to be RMAd. The cause is likely to be hardware related, either due to a bad port, a bad cable, or a misconfigured cable, so take this into account.
if one of the switches on either end of a UDLD aggressive link experience high CPU, the link will likely to have a high risk of dropping as UDLD messages will be missed. In this manner, it works almost like a heartbeat. This may or may not be desireable, you'll see this happen if a switch is not working properly and happens to introduces an STP loop, CPU's will spike, and UDLD will drop links in response.
STP dispute is triggered due to the unidirectional link failure that is happening, since STP checks the BPDU for the interface and sees the port role and so on, and in this case what it is likely detecting is an unidirectional link failure.
The following show commands will help to understand the issue:
- show tech-support lacp all (if the failed interface is a member of a Link Aggregation Control Protocol (LACP) portchannel)
- show tech-support module <x> (where x is the module where the UDLD error is detected)
- show tech-support ethpm
- show tech-support udld
- show udld internal event-history errors
- show udld internal event-history msgs | grep -a 3 -b 3 L2_RX_DATA
- show udld internal event-history ethernet <x/y>
- show log logfile | grep UDLD
- show log logfile | grep Ethernet<x/y>
- show processes cpu history
- show interface ethernet <x/y>
- show hardware internal errors module <x>
- show interface counters errors module <x>
I found 3 bugs but with different Nexus models but some of them indicate to move to another version, or an issue with the OIR module:
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCus77610/?rfs=iqvred
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCur61479
https://bst.cloudapps.cisco.com/bugsearch/bug/CSCtj29477/?rfs=iqvred
It all indicates to be a physical issue, anyways keep me posted,
Please rate all the helpful posts and marked as answered if the answer was provided to solve the issue!
David Castro,
