Re: UDLD recommendations

From: Nick Matthews <matthn_at_gmail.com>
Date: Sun, 11 Sep 2011 20:56:11 -0400

I've also seen environments face outages due to links not being shut
down when they should have, because the links were still up.

Example: Downstream switch has two uplinks to two switches. The one
STP chose experiences an ASIC error where the upstream card no longer
forwards or sends traffic but the card is still up (copper or fiber).
If UDLD had been turned on this would have been detected and STP would
have re-converged.

I'm curious what types of problems people have seen, because I've seen
more of the port-not-forwarding-but-is-up/up rather than UDLD
problems. UDLD doesn't play nice with 3rd party seems to be one,
anything else?

-nick

On Sun, Sep 11, 2011 at 6:22 PM, Chris Proctor <chris_at_cwproctor.net> wrote:
> I would comment that for some vendors UDLD can become unreliable in the face of other types of CPU intensive events.
>
> I have personally had to deal with one where the interaction between OSPF, rapid spanning tree and UDLD prevented covergence from being reached. OSPF would start SPF calculations, UDLD would miss a heartbeat, the port would shut down, etc...
>
> Personally I feel it was the non-realtime OS but many vendors run these. Reliability of UDLD is nailed to the ability of the hardware to always send and accept the heartbeats on time. If the hardware can not do this reliably then relaxing of the UDLD timers is the only way to protect against unidirectional links without the elevated risk.
>
> YMMV
>
>
>
> -----Original Message-----
> From: Martin Schumacher <martin1.schumacher_at_googlemail.com>
> Sent: September 11, 2011 3:51 PM
> To: Carlos G Mendioroz <tron_at_huapi.ba.ar>
> Cc: Joseph L. Brunner <joe_at_affirmedsystems.com>; Atle Xrn Hardarson <atle.hardarson_at_gmail.com>; Ccielab_at_groupstudy.com <ccielab_at_groupstudy.com>
> Subject: Re: UDLD recommendations
>
> Hi...
>
> I work for 2 Company with two Datacenters. On all LWL Ports UDLD mode
> Agressive is enabled and never experienced Problems.
>
> Greetings
>
> Martin
>
>
> 2011/9/11 Carlos G Mendioroz <tron_at_huapi.ba.ar>
>
>> Joseph,
>> I don't think the physician metaphor applies, or else, you'd rather do the
>> IP routing on all the networks by hand ???
>> The time it takes for a human to react to an event is HUGE compared to
>> an automatic procedure. I guess we all agree on that.
>>
>> What IMHO is important in your argument is that UDLD is not dependable.
>> I have no direct experience to such faults, anyone else care to comment?
>>
>> -Carlos
>>
>>
>> Joseph L. Brunner @ 11/09/2011 06:01 -0300 dixit:
>>
>> Surely, in a critical, redundant environment one would configure
>>>> aggressive mode instead of normal mode?
>>>>
>>>
>>> No because taking a whole link down is a major event in a production
>>> network. Your network should get the alerts to peoples smartphones/screens
>>> who can fix the issue and determine if further action is required before
>>> taking a link down and re-routing traffic to a different layer 2 path.
>>>
>>> Also, UDLD is not always very accurate - so you may not want to trust
>>> it... I have had it fail on copper many times and think the link was
>>> unidirectional, simply because of poor copper links, etc.
>>>
>>> You're missing the fact the UDLD feature is not as good at detecting an
>>> issue as a qualified person responding to an alert...
>>>
>>> "Would you want UDLD to perform brain surgery on your child or a skilled
>>> physician?
>>>
>>> -Joe
>>>
>>>
>>> -----Original Message-----
>>> From: nobody_at_groupstudy.com [mailto:nobody_at_groupstudy.com] On Behalf Of
>>> Atle Xrn Hardarson
>>> Sent: Saturday, September 10, 2011 9:22 AM
>>> To: Ccielab_at_groupstudy.com
>>> Subject: UDLD recommendations
>>>
>>> Hi guys
>>>
>>> I was reading up on UDLD, and I have always wondered why Cisco recommends
>>> normal mode for UDLD, and not aggressive mode?
>>> Surely, in a critical, redundant environment one wo
>
> [The entire original message is not included]
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html

Blogs and organic groups at http://www.ccie.net
Received on Sun Sep 11 2011 - 20:56:11 ART

This archive was generated by hypermail 2.2.0 : Sat Oct 01 2011 - 07:26:25 ART