Aggressive Mode UDLD

[heatseeker]

We are preparing to incorporate UDLD and Loopguard into our infrastructure, and are wondering if anyone can give advise as to UDLD normal or UDLD Aggressive.

It seems that UDLD normal, barring any initial miswiring (misconnected ports), will do nothing to block a uni-directional link, and will only block should it be triggered by a L1 mechanism. While Loopguard will see and block uni-directional links on receive portion of links carrying BPDU's, it won't block on the send portion of the same links as they aren't carrying BPDU's.

It seems that UDLD aggressive will block all uni-directional links, even if Loopguard doesn't catch them (black holed traffic as well). We've seen many suggestions, even from Cisco, that recommends using UDLD normal mode. We have also seen advisements in these forums that recommend the same. What are the 'gotchas' with using UDLD in Aggressive mode? We are currently leaning towards UDLD Aggressive and Loopguard being implemented in a 802.1d environment. We also plan to implement errdisable recovery for UDLD and set at 300 seconds.

Any thoughts or advice would be appreciated.

[thomas.chen]

The most common case for an implementation of UDLD aggressive is to perform the connectivity check on a member of a bundle when autonegotiation or another Layer 1 fault detection mechanism is disabled or unusable. It is particularly useful with EtherChannel connections because PAgP and LACP, even if enabled, do not use very low hello timers at steady state. In this case, UDLD aggressive has the added benefit of preventing possible spanning-tree loops.

Aggressive UDLD was created in order to specifically address those few cases in which an ongoing test of bidirectional connectivity is necessary. As such, the aggressive mode feature provides enhanced protection against dangerous unidirectional link conditions in these situations:

1) When the loss of UDLD PDUs is symmetrical and both ends time out. In this case, neither port is errdisabled.

2) One side of a link has a port stuck (both Tx and Rx).

3) One side of a link remains up while the other side of the link has gone down.

4) Autonegotiation, or another Layer 1 fault detection mechanism, is disabled.

5) A reduction in the reliance on Layer 1 FEFI mechanisms is desirable.

6) You need maximum protection against unidirectional link failures on point-to-point FE/GE links. Specifically, where no failure between two neighbors is admissible, UDLD-aggressive probes can be considered as a heartbeat, the presence of which guarantees the health of the link.

[heatseeker]

Thanks for the reply.

It seems that UDLD aggressive is an appropriate setting, as failure between two neighbors, when a spanning tree loop could result, should never be admissible.

We have concerns that GBIC failure in our infrastructure will cause ports to stick or otherwise cause a unidirectional link. In the worst case, this could cause a spanning tree loop that loopguard MAY not catch.

Unless you know of a good reason NOT to use aggressive UDLD, it sounds like a good way to go.

Understandably, loss of pdu's for reasons other than unidirectional link i.e. load or software error could cause erroneous failure of an entire interface. I guess the risk of this occurring vs. risk of particular type of GBIC failure must be weighed.

Any other known drawbacks would be appreciated.

Thanks again.