Nexus port down in a port-channel with UDLD mismatch

[junhong]

Hello, Experts,

My Customer has port down problem with UDLD mismatch which was caused by peer nexus switch.

The peer nexus switch is sending UDLD packet with its own Chassis ID (S/N)

But the switch which has the issue is shutting down the port when it receives the packet with the peer's Chassis ID.

If it is a normal process, what can I do to resolve this issue? or if it is not, is it a bug or something?

In summary,

Nexus 5548UP(CSW1) ==Po==(CSW2)Nexus 5548UP

and if it receives UDLD packet from CSW2 with its own Chassis ID, one of the port is going down with the message "UDLD Mismatch"

Below is the log frome the nexus.

7) Event:E_DEBUG, length:159, at 411296 usecs after Tue Nov 24 06:23:47 2015
    [102] udldCheckBidirDetect(1734): Chassis ID & str in pair [1] from Ethernet1/26 mismatched, Exp:  SSI162907J8, Rec: Ethernet1/26CSW2(SSI172000FL).

SSI162907J8 is CSW1's own Chassis ID and SSI172000FL is for CSW2

Best Regards,

Jungwo

[alaarrud]

I would suspect a missing/incorrect configuration, or a layer 1 problem. Have you verified configs and swapped cables and transceivers?  Also ensure STP is functioning as desired.   The UDLD protocol per design will respond (echo) device/port IDs.  UDLD functionality is similar across IOS and NXOS .  This link describes the expected behavior

http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/10591-77.html

"Each switch port configured for UDLD sends UDLD protocol packets that contain the port's own device/port ID, and the neighbor's device/port IDs seen by UDLD on that port. Neighboring ports should see their own device/port ID (echo) in the packets received from the other side."

Other considerations:

Are you using copper or fiber?  Are the ports autonegotiate (this is recommended).  Are you using standard LACP ?

Is UDLD enabled globally and configured the same on each individual port on both sides of the link?

Additionally,  Are you running standard Rapid-PVST+ or MST?  Have you modified STP any values or default timers?  

What do the outputs of "show udld global", "show udld" and "show udld neighbors" look like from both sides of the link?  Also "show port" from the affected interfaces does this show errdisable? if so then run show errdisable-timeout to see reason.  See https://supportforums.cisco.com/document/22536/port-status-errdisable-due-unidirectional-link-detection-condition ;

[junhong]

Thank you for your fast reply and it was late that I could receive the logs from my customer.

When I lookup the log, I could find that there is no udld configuration but "feature udld" on the switch.

Could it be a clue for this case? and also I could find the additional log like below.

I think that my customer is connecting the cables incorrectly, is it right?

(ex. CSW1 1/25 to 1/26 on CSW2 and  CSW1 1/26 to 1/25 on CSW2)

2015 Nov 24 06:23:43.534 CSW1-P05-BD-EUL %UDLD-4-UDLD_NEIGHBOR_MISMATCH: UDLD neighbor mismatch detected, exp: Ethernet1/26, rec Ethernet1/25
2015 Nov 24 06:23:48.563 CSW1-P05-BD-EUL last message repeated 5 times
2015 Nov 24 06:23:48.563 CSW1-P05-BD-EUL %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Ethernet1/26, neighbor mismatch detected
2015 Nov 24 06:23:48.566 CSW1-P05-BD-EUL %ETH_PORT_CHANNEL-5-PORT_DOWN: port-channel200: Ethernet1/26 is down
2015 Nov 24 06:23:48.584 CSW1-P05-BD-EUL %ETHPORT-5-IF_DOWN_ERROR_DISABLED: Interface Ethernet1/26 is down (Error disabled. Reason:UDLD Neighbor mismatc

[InayathUlla Sharieff]

"feature udld" ==> This is just enabling the feature on the switch.

Now when you see the interafce is down du to UDLD disabled then you need to look out for configuration both the end. (UDLD configure mode aggressive/normal) then udld enabled on the ports between the ends.

ref:

http://www.cisco.com/c/en/us/support/docs/ios-nx-os-software/nx-os-software/118908-technote-udld-00.html

Also check the cable first if it is good enough before connecting.

woraround:

disable udld both the ends and see ports are coming up?

HTH

Regards

Inayath

[junhong]

Thank you for your support, Inayath.

Customer is trying to find cable mismatch but it should spent more time since their DataCenter is not manned site.

Customer has no UDLD config but feature config on both ends. I think I should investigate the document you sent further. 

[alaarrud]

It sounds like there is a disparity in the configuration on both ends of the link, on the interface and switches at global level as well.    It will be interesting to hear the results. 

[junhong]

Thank you for your help.

CSE has been tested in their lab with the configuration disparity but it was not reproduced.

So, my customer will test the config in their maintanence domain.