UDLD - Message Error

[wilsonsant]

Hi Guys,

My Customer had the problem with interface giga, was generated the message error. This interface has been use to trunk and appear the message error:

PM-SP-4-ERR_DISABLE: udld error detected on Gi4/1, putting Gi4/1 in err-disable state.

I found the link: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00806cd87b.shtml

But, not is clear what reason the problem. Any have idea?

Thanks,

Wilson

[Lucien Avramov]

UDLD-3-DISABLE: Unidirectional link detected on port 3/2. Port disabled. (CatOS)

or

PM-SP-4-ERR_DISABLE: udld error detected on Gi4/1, putting Gi4/1 in err-disable state. (Cisco IOS system software)

The port shutdown by UDLD remains disabled until it is manually re-enabled, or until the errdisable timeout expires (if configured). These are possible reasons for this message:

The link is up on both sides, but packets are only received by one side. This may be a hardware or a software issue.

Wiring mistakes occur when receive and transmit fibers are not connected to the same port on the remote side.

In this case, check to ensure wiring is set up properly.

In aggressive mode, if the link state of the port was 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 errdisable state.

This may indicate that a port is stuck (On one side, a port neither transmits nor receives, but the link is up on both sides).

Config guide for UDLD:

http://www.cisco.com/en/US/customer/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/udld.html#wp1021139

[Peter Paluch]

Lucien,

Can you please repost the URL you have suggested? That one requires a CCO login.

Additionally I suggest reading this document. It is a very concise and nice explanation of how the UDLD works in both normal and aggressive modes.

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a008009477b.shtml

Best regards,

Peter

[wilsonsant]

Hi Peter,

I used the file attached, but, It not answer my Question. Why the port generated the message error.

Thanks,

Wilson

[wilsonsant]

Hi Lavramov,

Thank a lot for you help. But, is not clear for me, what is cause of the problem. Why the port presented the message error: "PM-SP-4-ERR_DISABLE: udld error detected on Gi4/1, putting Gi4/1 in err-disable state". a on side is configured as udld port agressive (Switch 3560) and another side no (Switch 4507). Is this can be the cause problem or the problem is relationship with hardware (fiber)?

Thanks,

Wilson

[Lucien Avramov]

Most of the times, it's due to a cable failure or rarely to an IOS error.

You can have one side as aggressive and not the other, or both sides as aggressive.

If you disable aggressive mode, the link will not be brought down even if there is an error.

The link I posted does need you to login with your CCO. It's the configuration guide for UDLD.

[Peter Paluch]

Lucien,

That link does require logging in with a CCO. However, you may not see it as you are already logged in when replying to the NetPro. Clear your browser cache and cookies and give it a try again - I have confirmed it once more now.

Note that URLs generates by Cisco website are of two forms - a different URL pointing to the same document will be generated for anonymous (not logged in) user, and a different URL will be generated for a user that has logged in.

The same document without requirement to log in is here:

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/udld.html#wp1021139

Note that the '/customer/' component is not present in the "public" URL.

Regarding the UDLD normal mode - I agree that if an UDLD information times out, the UDLD takes no action. However, I have the feeling that if the UDLD detects a neigbhor mismatch (the Tx fiber is connected to a different switch than the Rx fiber) then it will disable the port even in the normal mode. I don't have optical interfaces available so I can't test this hypothesis but if somebody is able to test it and update this, I would be most grateful!

Best regards,

Peter

[Lucien Avramov · Accepted solution]

Peter, reed my posts before replying.

I said that the link does need a CCO login.

Also your request to post a link with no CCO login does not make sense. To post on forums, you do need a CCO anyways.

The port will get disabled but not as fast as with aggressive mode as I said earlier.

[Peter Paluch · Accepted solution]

Hello Lucien,

First of all, I do not want to argue with you. I have great respect for you and I appreciate all the guidance and help you are offering on the NetPro. But I also believe that if we have a different opinion about an issue we should discuss it in a friendly matter and possibly arrive to a correct conclusion.

Regarding that link, I am absolutely sure about what I have written. I have to note that also you should be reading my posts more carefully before responding to them as I have stressed that

[Lucien Avramov]

From the doc I suggested to read:

To prevent spanning tree loops, nonaggressive UDLD with the default interval of 15 seconds is fast enough to shut down a unidirectional link before a blocking port transitions to the forwarding state (with default spanning tree parameters).

In UDLD normal mode, when a unidirectional error is detected, the port is not disabled. In UDLD aggressive mode, when a unidirectional error is detected, the port is disabled

[Peter Paluch]

Lucien,

Yes, that is correct. You are right. What I had in my mind when I wrote about normal UDLD mode was that on fiber ports of a certain type, I believe that breaking a single fiber can be detected by Layer1 means and so the port will go down even without help of UDLD. On copper ports, a timeout of UDLD packets from the peer will not by itself cause the port to be disabled. It will simply stay in undefined state indefinitely. So I was looking for an explanation where a normal UDLD would be useful.

Best regards,

Peter