8th February 2012

UDLD – To Global or Per Port

I was discussing UDLD today, and thinking about merits of globally enable UDLD on all our switches or should we consider enabling UDLD per port ?

UDLD is the process of confirming that a bi-directional communication channel is available. The best example is an ethernet port that uses two fibres and data flows unidirectionally on each fibre.

The diagram shows the two ethernet ports connected and one of the fibres has broken e.g. connector, bend radius, backhoe attenuation etc. However, the Ethernet port will be UP when the receive line is receiving. The left side will show the physical port as UP, but the right side will show the port as DOWN.

udld20080124.png
This causes spanning-tree and routing protocol problem because they do not detect that the interface is down. (note: Bidirectional Forwarding Detection should also detect this type of failure). Troubleshooting can be tricky too.

So UDLD is a Layer 1/2 software protocol that establishes connectivity on the interface. It is not limited to ethernet or fibre optic, but that is the most common use. Both interfaces must support UDLD and have the same settings. Other vendors also support UDLD, Cisco has submitted it to the IETF in a Draft on April 2007, and other vendors also use it. I have personally used UDLD on Foundry quite successfully.

Global or not global

Cisco allows configuration of UDLD as a global default or on a port by port basis. When using global mode, copper ethernet are excepted, the assumption is that these will be computer ports. This means that copper connected switches will require UDLD to be explicitly configured. Copper cables have the same problem of failure if you lose the transmit, but this is uncommon. This negates the benefit of UDLD

If only one side is configured for UDLD, then the connection will not go active.It will also go into err-disable state So a switch with Global UDLD enabled will not interoperate will with a switch that has the default settings on the other side.

Autonegotiation

If you have enabled ethernet auto-negotiation on both ports, then the link pulse process will achieve a unidirectional detection at startup, however, if the link fails after negotiation the problem will reoccur

Conclusion

>
Because enabling UDLD would cause too much of deviation from ‘expected norm’ I recommend configuring UDLD on a per port basis. However, it is vital that you must audit the configuration on an ongoing basis to ensure that new switch-to-switch connections have been configured. Because UDLD is one of those ‘it just works’ technologies, people forget to implement the UDLD feature and this will cause problems in the future.

Postscript

If you miss enabling UDLD at first deployment, you can enable it later without causing service interruption, provided that you configure both sides within 30 seconds or so.

This post is copyright of Thropos Ltd ©2008-2011 at Etherealmind.com - contact | email: greg.ferro@packetpushers.net - twitter: @etherealmind | All rights reserved
About Greg Ferro

Greg Ferro is a Network Engineer/Architect, mostly focussed on Data Centre, Security Infrastructure, and recently Virtualization. He has over 20 years in IT, in wide range of employers working as a freelance consultant including Finance, Service Providers and Online Companies. He is CCIE#6920 and has a few ideas about the world, but not enough to really count.

He is a host on the Packet Pushers Podcast, blogger at EtherealMind.com and on Twitter @etherealmind and Google Plus

  • http://ccie-in-3-months.blogspot.com/ Tassos

    Hi,

    There shouldn’t be a problem with udld on only one side as long as you don’t configure aggressive udld.

    Tassos

    • http://nmsmonkey.com Rob

      Even if you enable aggressive the ports will still function as UDLD must first see the link as bidirectional before taking it down. It will flag the status as ‘unknown’. Although I would suggest this will cause you confusion and so should be avoided.

  • chris

    Even aggressive mode is okay on only one side, isn’t it?

    My understanding is that UDLD only reacts to LOSS of a peer. If a UDLD-supporting peer device is never detected in the first place, then no action will be taken. The UDLD neighbor info just stays in “undetermined” state (or somesuch).

    Also, regarding copper ports, there are a couple of other factors that contribute to it not making sense there:
    1) copper ports are kept alive by Ethernet Link Pulse signaling anyway, making UDLD unnecessary.
    2) copper ports might be connected to a hub where some devices support UDLD, and others don’t. Things could get ugly fast.