From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Sat Jul 05 2008 - 15:39:58 ART
Hehe,
Yeah, so you guys can stand by the door, making funny faces and helping me
fail the storage lab ;)
-- Petr Lapukhov, CCIE #16379 (R&S/Security/SP/Voice) petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com
2008/7/5 Joseph Brunner <joe@affirmedsystems.com>:
> >(surpisingly this coincides with TCP keepalives retry values used by FCIP > >on Cisco MDS storage switches :) > > I take it Petr we'll see one more star on your uniform by the end of > 2008??? > Maybe we'll meet in RTP... I'll be there a lot too. And as you know the SAN > rack is by the door where we can all see you ;) > > > > -----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