UDLD problem

Answered Question
Mar 5th, 2009

Hi,

I have two switches, one 3550 and a 3750, wich are connected using single mode fiber. The link works well with a basic configuration:

switchport trunk encapsulation isl

switchport mode trunk

but when I activate a full trunk configuration as follows:

switchport trunk encapsulation dot1q

switchport trunk native vlan 999

switchport trunk allowed vlan 200-205,999

switchport mode trunk

logging event trunk-status

udld port aggressive

storm-control broadcast level 30.00

storm-control multicast level 30.00

spanning-tree guard loop

I got the following message:

020187: Mar 5 18:50:37: %UDLD-4-UDLD_PORT_DISABLED: UDLD disabled interface Gi1/0/3, unidirectional link detected

020188: Mar 5 18:50:37: %PM-4-ERR_DISABLE: udld error detected on Gi1/0/3, putting Gi1/0/3 in err-disable state

020189: Mar 5 18:50:38: %DTP-5-NONTRUNKPORTON: Port Gi1/0/3 has become non-trunk

I can see the message unidirectional link detected, but I resist myself to beleive it since the connection between the two swiches works well with just the basic. I have traffic between them with no problem.

Do you think it is a real UDL problem? How can I be sure?

Please help me

Thaks a lot in advance

HUGO

I have this problem too.
0 votes
Correct Answer by Edison Ortiz about 7 years 9 months ago

On the basic configuration you presented, you are forwarding all Vlans and the ISL has no concept of native vlan. All Vlans are encapsulated within the ISL header.

Remove the native vlan entry on both switches and see if your UDLD problem goes away.

__

Edison.

Correct Answer by xcz504d1114 about 7 years 9 months ago

If your VLAN's are not consistent on your trunks, UDLD will detect one way communication on that spanning-tree instance. If you tke UDLD off you will have inconsistent spanning-tree instances which can have undesireable effects as well (you no longer directly control which spanning-tree instances are blocked), that may be harder to detect until something catastrophic happens, and even then isolating the "real" issue is cumbersome.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.9 (9 ratings)
Loading.
Edison Ortiz Thu, 03/05/2009 - 19:56

Hugo,

You can still connect with a faulty connection. UDLD provides extra verification at Layer1 and it seems your fiber aren't connected properly or they are faulty.

Please see the following document for more information on UDLD:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_46_se/configuration/guide/swudld.html

I haven't seen yet a faulty report on UDLD, it's pretty much reliable.

__

Edison.

hugo.picado Fri, 03/06/2009 - 07:55

Thanks Edison.

Just to let you know more information, so you can make your mind better, this connection is across a city it is a little bit more than 6 kilometers. I am using GBIC for 10 Km.

Vlans 200-2005, and others, correspond to SVI interfaces what I call WAN vlans, I use them to carry traffic at layer 3. So the office has a gateway in one SVI, and I have a second SVI for wan connection. Maybe this really make it work because the spanning tree it is just used for the wan vlan which is actually a layer 3 svi interface.

Do you think I really need a udld in this evironment?

Nevertheless, I have already ask my provider to check the fiber quality, and I am afraid I will find more problems since I have a ring around the city where other switches are interconnected.

Thanks a lot for your help

Edison Ortiz Fri, 03/06/2009 - 09:47

Thanks for the additional info. Since they are not directly connected, I don't recommend placing UDLD on those optical ports.

HTH,

__

Edison.

hugo.picado Fri, 03/06/2009 - 10:03

Maybe I missguided you with my information. The two switches are actually directly connected, one GBIC(3550)-FO-(3750)GBIC.

Thanks a lot for you answer

HUGO

Edison Ortiz Fri, 03/06/2009 - 10:16

Are they on the same building or they are going via a provider network?

hugo.picado Fri, 03/06/2009 - 10:25

They are in different buildings, 6Km apart, but they are connected using dark fiber optic. The provider only gives me the dark fiber.

Thanks a lot

HUGO

xcz504d1114 Thu, 03/05/2009 - 21:09

UDLD can also be triggered on a port if your allowed VLAN's do not match in a PVST environment.

Try running debug spanning-tree events on both switches and make sure you are logging to buffer (or at least logged in to both to capture the data) to see if it's a spanning tree issue on a particular VLAN, or just poor fiber / GBIC.

3550's also "dynamically" remove VLAN's through static configurations, check your 3550's running config for "no spanning-tree vlan 200" etc for the VLAN's you are trying to pass.

the no spanning-tree vlan command will not stop the VLAN traffic, but it does cause the port to not participate in spanning tree, not a bad thing, you just need to be aware of it and make sure you are aware of the ramifications and design consideration needed to overcome those situations.

hugo.picado Fri, 03/06/2009 - 10:07

Hello,

Thaks a lot for your answer.

The vlan 999 it is not declare in any switch since I understood this a dummy vlan. Additionally vlan 203 it is not in the vlan database since it will be used in the future, but it is not being used now. Can be that the problem?

Thanks

HUGO

Edison Ortiz Fri, 03/06/2009 - 10:15

Well, that's not a proper configuration then.

You've decided to use Vlan 999 as your native Vlan and it must exist on both switches.

I'm surprised the only error you saw was regarding UDLD and I believe the previous poster was onto something.

You either need to change your native Vlan to a Vlan that exist on both switches or create Vlan 999 on the Vlan Database at either end.

Correct Answer
xcz504d1114 Fri, 03/06/2009 - 10:24

If your VLAN's are not consistent on your trunks, UDLD will detect one way communication on that spanning-tree instance. If you tke UDLD off you will have inconsistent spanning-tree instances which can have undesireable effects as well (you no longer directly control which spanning-tree instances are blocked), that may be harder to detect until something catastrophic happens, and even then isolating the "real" issue is cumbersome.

hugo.picado Fri, 03/06/2009 - 10:33

Ok thank you.

By mistake, now I must say that, I have used native vlan before which already is in my configuration.

Since I read about using a dummy vlan I decided to implement the change in this case. Since vlan 999 and 203 actually do not exist in any switch, they did not create a problem when I use the basic configuration, is that?

Thank you again.

HUGO

Correct Answer
Edison Ortiz Fri, 03/06/2009 - 10:39

On the basic configuration you presented, you are forwarding all Vlans and the ISL has no concept of native vlan. All Vlans are encapsulated within the ISL header.

Remove the native vlan entry on both switches and see if your UDLD problem goes away.

__

Edison.

hugo.picado Fri, 03/06/2009 - 11:33

Hello,

I just added vlan 999 in both switches. It is working nicely.

Thank you a lot.

HUGO

Actions

This Discussion