From: Scott Morris (swm@emanon.com)
Date: Sat Jul 05 2008 - 16:05:48 ART
Given your track record, I'm not so sure that would happen! The failing
part that is. They'll probably still sit there and make funny faces at you.
:)
Scott Morris, CCIE4 #4713, JNCIE-M #153, JNCIS-ER, CISSP, et al.
CCSI/JNCI-M/JNCI-ER
Senior CCIE Instructor
smorris@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
Knowledge is power.
Power corrupts.
Study hard and be Eeeeviiiil......
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Petr
Lapukhov
Sent: Saturday, July 05, 2008 2:40 PM
To: Joseph Brunner
Cc: Jason Madsen; Jonathan Greenwood II; Tim; ccielab@groupstudy.com
Subject: Re: UDLD
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