When switches are connected together, it’s important to keep traffic flowing in both directions over the links. In Scenario 3, we’ll need to leverage a switch feature to make sure that happens…
Three switches are connected to each other as shown in the network diagram. Switch A has nothing but links to other switches, while switches B and C have links to switch A, as well as links to end users. The links between switches are provided over fiber optic media; the end users connect via twisted pair copper cables.
All three switches support the same set of VLANs, and all three use the Spanning Tree Protocol to prevent bridging loops from forming. You will need to add a Cisco feature to make sure that the links between switches can always support bidirectional traffic. In the event of an odd link failure that prevents data from flowing in one direction, the link must be automatically disabled.
Stop here if you don’t want to see the solution! Otherwise, go on to page 2…
Get a PDF version of this scenario here: PDF
Pages: 1 2
July 4, 2010 at 5:27 am
I remember a few years back, before I was really up on these things a contractor had enabled this on one of out access switches.
IT kept putting the interface in to err -disabled status. Either had he bothered to enable the recovery feature. Took me ages to work out what was wrong, but a good way to learn a feature. What made it worse was the switch waas in a building that i did not have access to. took me about an hour to find a key.
My advice is to set access switches to auto recover from things like this after 5 to 10 min. but leave he core/distribution manual.
you can always disable the port manually on the distribution switch if when it comes back up after 5 min it causes issues across the network. But I have had issues where one switch has caused about 15 to go down and disable there ports back to the core. having them auto recover is so much nicer than running round site to get it all up and running again.
July 4, 2010 at 10:40 pm
Hi Dave,
I agree – I think the err-disable state is a tricky one to figure out when troubleshooting, mainly because I usually forget about it. I’ve finally committed the show interfaces status err-disabled command to memory so I can figure out if and why any interfaces have been automatically disabled.
I do like the auto-recovery feature, but have steered away from it in the healthcare environment I work in. If I can get problem interfaces shutdown before they cause real issues, then I don’t mind spending the time to repair and then manually bring them back up.
I recently had one bad uplink on an access layer switch take down an entire hospital network, simply because UDLD wasn’t enabled ahead of time. I’m hoping to post that as an example scenario soon, just as an exercise in painful lessons learned.
Good to hear from you,
Dave H
October 11, 2010 at 2:51 pm
Wouldn’t doing that defeat the purpose of enabling UDLD to protect yourself?
July 7, 2010 at 2:34 am
David
this is disgressing a bit ,but your new book on configuring Cisco routers has just come out.How useful could it be to somebody like me studying for the Route exam ?
(Yes I passed SWITCH !):)
Thanks
September 29, 2010 at 6:54 pm
David,
I believe this is something misunderstood previously, in that UDLD normal mode doesn’t do much other than alert (via syslog or snmptrap) and you need aggresive mode to actually errdisable the port.
Good blog. Already keen to resit my SWITCH exam.
October 11, 2010 at 2:47 pm
UDLD will need to be implemented in aggressive mode. This can be done with the udld agressive global config command. This can be safely enabled globally because it only affects fiber-optic links.