Strange UDLD Issue

[aniklog01]

I am having a Network Infrastructure setup as following: 

One Server Switch HP 5120 is connected to two Cisco L3 switches Cisco Catalyst 3560 by two Gigabit Ethernet Ports. In my monitoring I am getting alert that one of the connected port from L3 switch (1) is down for UDLD Error detected in that port. In the switch after logging in I checked the port to be in err-disabled state.I shut the port down and do no shutdown and the port comes up and shows connected,but as soon as I do this the port from the other L3 switch (which connects HP 5120) gets into err-disabled state. When I perform the same in the second one the first one again goes back to err-disabled. Not finding any clue to what. exactly is the root cause of this issue and what would be the possible remedy.Your help would be highly appreciated.

[Leo Laohoo]

In the switch after logging in I checked the port to be in err-disabled state.

Not all switches "fully support" UDLD.  So I'd recommend disabling UDLD when dealing with non-Cisco appliance.

[Charles Hill]

I believe Leo is correct. 

I don't see the HP 5120 listed as a switch that supports UDLD.

UDLD interoperates with the following HP switches: 2600, 2800, 3400, 3500,
4200, 5300, 5400, 6200, 6400, 6600, 8212, and 9300. Consult the release notes
and current manuals for required software versions.

 If you want to verify if UDLS is supported on the HP switch, you can do the following.

UDLD is enabled on a per port basis. For example, to enable UDLD on port a1, enter

HP Switch(config)#interface al link-keepalive.

The info below is from the HP configuration guide:

When configuring UDLD, keep the following considerations in mind:
■ UDLD is configured on a per-port basis and must be enabled at both
ends of the link. See the note below for a list of HP switches that
support UDLD.
■ To configure UDLD on a trunk group, you must configure the feature
on each port of the group individually. Configuring UDLD on a trunk
group’s primary port enables the feature on that port only.
■ Dynamic trunking is not supported. If you want to configure a trunk
group that contains ports on which UDLD is enabled, you must
remove the UDLD configuration from the ports. After you create the
trunk group, you can re-add the UDLD configuration.

[Peter Paluch]

Hi,

I am not saying Leo is incorrect. Leo's knowledge about switched technologies is, in my opinion, second to none.

The strange thing is that for UDLD to claim a situation that requires err-disabling a port, a bi-directional UDLD session first needs to be negotiated with the neighboring switch. A switch that does not support UDLD would never be able to respond in such a way that would make UDLD believe that a bi-directional session has been negotiated. So enabling UDLD on links to non-UDLD switches by itself should not end up in UDLD disabling these ports, as there is no reason for UDLD to do so. The only exception to this rule is if an UDLD-enabled port receives back an UDLD message that was originated by the same switch and port - this would mean that a switching loop or a self-looped port exists - but these situations are equally handled by both STP and LOOP protocols which may react even sooner than UDLD.

So once again - UDLD could be the cause of this but ironically, if the HP switch does not support UDLD then it is unlikely it was exactly UDLD that brought the port down. That's why I vouched for determining the reason for the err-disable condition in the first place, instead of just blindly blaming UDLD.

Best regards,
Peter

[Charles Hill]

Good point!

aniklog01 try entering the following command:

show udld gix

and verify what device name and neighbor device name you see. 

Are the gigabit ethernet ports connected to media converters?

[Leo Laohoo]

Configuring automatic err-disable recovery may be a perfect way to shoot yourself in the leg... repeatedly.

I'd like to find out what's causing the ports to go into err-disable state.  

Could be a link flap, could be UDLD, could be anything.  

But I totally agree with Peter on this issue, why bothering enabling error-disable and then enabling error-disable RECOVERY?  Error-disable is, in my personal and professional opinion, a lifesaver.  If you enable error-disable recovery, then you're basically "asking for it".  FYI:  I've personally seen, more than once, how error-disable recover can bring a network to it's knees.   Error-disable recovery is like smoking in an oil refinery.  

There are only very extreme cases whereby you want to enable error-disable recovery and one of them is in a lab environment.  

[Alfredo Bosca Bataller]

Hi aniklog01,

The err-disanle issue is LAYER 1 and majority. 

Example:

%PM-4-ERR_DISABLE: link-flap error detected on GiX, putting GiX in err-disable state ()

Solution:

I would configure auto-recovery by the Cisco side, so will recovered automatically.

Cisco#errdisable recovery cause udld

show errdisable recovery

ErrDisable Reason            Timer Status

-----------------            --------------

arp-inspection               Disabled

bpduguard                    Disabled

channel-misconfig (STP)      Disabled

dhcp-rate-limit              Disabled

dtp-flap                     Disabled

gbic-invalid                 Disabled

inline-power                 Disabled

...

udld                         Enabled

[Peter Paluch]

Hi Alfredo,

With all due respect, I beg to differ. Configuring automatic err-disable recovery may be a perfect way to shoot yourself in the leg... repeatedly.

Also, there are several reasons for a port to become err-disabled. Many of them are beyond Layer1.

My recommendation is to find out why exactly was the port err-disabled - in other words, we need to know the precise cause. aniklog01 did not provide any logging message so out of tens of err-disable causes, any one of them could have occurred. Therefore, I suggest to aniklog01 that he attempts to cause the err-disable condition again if possible, and when that happens, capture the show interfaces status err-disable command output and post it here. We can follow from there. Without knowing anything more, it's just shooting blind, and quite possibly for the worse.

Best regards,
Peter