UDLD problem

[hugo.picado]

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

[Edison Ortiz]

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]

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]

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]

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]

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

[hugo.picado]

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]

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]

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]

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.

[xcz504d1114 · Accepted solution]

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]

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

[Edison Ortiz · Accepted solution]

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]

Hello,

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

Thank you a lot.

HUGO

[AbrahamLincoln]

Hi Edison,

I tried to remove Native VLAN (no switchport trunk native vlan xxx) from the link that meaning untagged VLAN going through the link. If we remove native VLAN traffic can not go through the whole network. How about it?