From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Sat Jul 05 2008 - 15:38:01 ART
Historically, Normal (informative) mode was the first one introduced on the
Catalyst switches. While it's much less useful, it does not add risk of
losing connection to a critical switch in your network. Imagine your switch
having and upstream connection running UDLD aggressive. Say for some reason
(e.g. temporary connectivity issues, noise, duplex mismatch) UDLD may
declare a link to be unidirectional. If if didnt have errdisable recovery
set up, you would need to look for another way of accessing your switch :)
It may look similar to the situation with keepalive frames and loopback
conditional errdisable issue. You certainly do not want loops in you
network, but at the same time you cant risk losing a whole segment due to
some temporal issue.
HTH
-- Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com
2008/7/5 Tim <ccie2be@nyc.rr.com>:
> Thanks Petr. > > That helps but when would it be better to use UDLD in Normal mode? It > seems > like aggressive mode would always be better because UDLD doesn't shut the > port which could maybe allow STP loops to occur. > > Tim > -----Original Message----- > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of > Petr > Lapukhov > Sent: Saturday, July 05, 2008 2:08 PM > To: Jason Madsen > Cc: Jonathan Greenwood II; Tim; ccielab@groupstudy.com > Subject: Re: UDLD > > UDLD is Cisco proprietary extension for detection of mis-configured > (basically unidirectional) links. The idea is pretty simple - to allow two > switches verify they can both send and receive data on a point-to-point > connection. It's plain to see that an unidirectional link may end up in STP > loop, which is highly undesirable. Note that problems with unidirectional > links usually occur on fiber-optical connections and are not common on > twisted-pair connections, where link pulses are used to monitor the > connection integrity. > The confusion about UDLD is that Cisco provides quite unclear description > of > it's operations be it on CatOS or IOS platform. So here is a short overview > of how UDLD works. > > 1) Both UDLD peers discover each other by exchanging special packets sent > to > well-known MAC address 01:00:0C:CC:CC:CC. (Naturally, those frames are only > understood by Cisco switches). Each switch sends it's own device ID, the > originator port ID and timeout value to it's peer. Additionally, a switch > echoes back the ID of it's neighbor (if the switch does see the neighbor). > Since some versions of CatOS and IOS you can change UDLD timers globally. > > 2) If no echo with our ID has been seen from the peer for a certain amount > of time, the port is suspected to be unidirectional. What happens next > depends on UDLD mode of operations. > > 3) In "Normal" mode, if the physical state of port (as reported by Layer 1) > is still up, UDLD marks this port as "Undetermined", but does NOT shut down > or disable the port, which continues to operate under it's current STP > status. This mode is iformational, and you can review the "undetermined" > ports using CLI show commands when troubleshooting. > > 3) If UDLD is set to "Agressive" mode, once the switch loses it's neighbor, > it actively tries to re-establish the relationship by sending a UDLD frame > 8 > times every 1 second (surpisingly this coincides with TCP keepalives retry > values used by FCIP on Cisco MDS storage switches :). If the neighbor does > not respond after that, port is considered to be unidirectional and brought > to "Errdisable" state. (Note that you can configure "errdisable recovery" > to > make switch automatically recover from such issues) > > To finish the overview, recall that UDLD is designed to be a STP helper. > Therefore UDLD should be able to detect a unidirectional link before STP > would unblock it due to missed BPDU. Thus, when you configure UDLD timer, > make sure your UDLD timer is set so that unidirectional link is detected > before MaxAge + 2xForwardDelay expires (by default it's 20+2x15 seconds, > though who uses the STP defaults nowdays?!) > > HTH > > -- > Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) > petr@internetworkexpert.com > > Internetwork Expert, Inc. > http://www.InternetworkExpert.com > > 2008/7/5 Jason Madsen <madsen.jason@gmail.com>: > > > Yep, here it is per the Command Ref' Uasge Guideline section: > > > > UDLD supports two modes of operation: normal (the default) and > aggressive. > > In normal mode, UDLD detects unidirectional links due to misconnected > > interfaces on fiber-optic connections. In aggressive mode, UDLD also > > detects > > unidirectional links due to one-way traffic on fiber-optic and > twisted-pair > > links and due to misconnected interfaces on fiber-optic links. > > > > Jason > > > > On Sat, Jul 5, 2008 at 10:00 AM, Jonathan Greenwood II < > gwood83@gmail.com> > > wrote: > > > > > Aggressive mode is used for twisted pair/copper connected interfaces, > > udld > > > command by its self is used for all fiber connected interfaces. > > > > > > HTH > > > > > > Jonathan > > > > > > On Sat, Jul 5, 2008 at 10:36 AM, Tim <ccie2be@nyc.rr.com> wrote: > > > > > > > Hi Guys, > > > > > > > > > > > > > > > > Can someone help me understand the difference between regular mode > and > > > > aggressive mode with respect to UDLD? > > > > > > > > > > > > > > > > I've read the Cisco doc's but they're about as clear as mud. > > > > > > > > > > > > > > > > Thanks, Tim > > > > > > > > > > > > > _______________________________________________________________________ > > > > Subscription information may be found at: > > > > http://www.groupstudy.com/list/CCIELab.html > > > > > > > > > _______________________________________________________________________ > > > Subscription information may be found at: > > > http://www.groupstudy.com/list/CCIELab.html > > > > > > _______________________________________________________________________ > > Subscription information may be found at: > > http://www.groupstudy.com/list/CCIELab.html > > > > > > > > > > > > > -- > Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) > petr@internetworkexpert.com > > Internetwork Expert, Inc. > http://www.InternetworkExpert.com > > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html > > > _______________________________________________________________________ > Subscription information may be found at: > http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Mon Aug 04 2008 - 06:11:53 ART