2 September 2010

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.

Please rate this post:

1 Star - It\\\'s Crud2 Stars - It\\\'s Tosh3 Stars - Something\\\'s missing4 Stars - Needs works5 Stars - Good Enough6 Stars - Good7 Stars - Excellent8 Stars - Brilliant9 Stars - Astonishing10 Stars - Awesomely Godlike? (No Ratings Yet)
Loading ... Loading ...

About Greg Ferro
Greg is a Network and Security Architect / Designer / Engineer working freelance in the UK and worked for Resellers, DotCom's, Large Corporate's and Service Providers across a variety of products & Vendors. He prefers to work for end users, believes in the life cycle, total cost of ownership and that near enough is often good enough. He likes talking about himself in the first person to feel "royal", even when hosting the Packet Pushers Podcast on Data Networking. More about Greg at http://etherealmind.com/who-am-i/ and you can follow him on Twitter.

Comments

  1. Tassos says:

    Hi,

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

    Tassos

  2. chris says:

    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.

Speak Your Mind

*