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.

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.