Slashdot Mirror


Plug In an Ethernet Cable, Take Your Datacenter Offline

New submitter jddj writes: The Next Web reports on a hilarious design failure built into Cisco's 3650 and 3850 Series switches, which TNW terms "A Network Engineer's Worst Nightmare". By plugging in a hooded Ethernet cable, you...well, you'll just have to see the picture and laugh. They write: "The cables, which are sometimes accidentally used in datacenters, feature a protective boot that sticks out over the top to ensure the release tab isn’t accidentally pressed or broken off, rendering the cable useless. That boot would hit the reset button which happened to be positioned directly above port one of the Cisco switch, which causes the device to quietly reset to factory settings."

19 of 150 comments (clear)

  1. Easy way.... by blackfeltfedora · · Score: 5, Insightful

    "There’s an easy way to prevent it happening at all, by disabling the button" Another easy way to prevent this from happening would be DON'T BUY THIS SWITCH

    1. Re:Easy way.... by Darinbob · · Score: 4, Insightful

      It's not just the hood on the cable that would do this, you could easily press that button with a finger while plugging it in. Or you could press it accidentally while working on a box above or below it. Don't know if you have to hold the button in for 10 seconds before it wipes to factory default, but even without the hood there it seems like a big goof.

      But hey, it's Cisco. They use the design principle that people will buy their stuff anyway so why bother trying.

    2. Re: Easy way.... by phaethon2k · · Score: 5, Funny

      Every cheeseburger I shove down my throat is stopping a child from eating it, saving that child from obesity. Won't you think of the children?

    3. Re:Easy way.... by Bert64 · · Score: 4, Insightful

      That's even worse, only qualified IT departments would be buying these switches so you have every reason to expect that they *should* research their purchase before buying.
      Normally a reset button needs to be pressed with a pin to prevent accidental pressing...

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  2. Bad in any case by Dan+East · · Score: 4, Insightful

    Regardless of the design of the connector, having the reset button directly above the port is a bad design. It's simply too easy to hit it with your thumb just plugging in or removing a cable. I suppose holding it down for several seconds resets to factory, which is what happens when using cables with the boot. Still, regardless of that more severe problem, it was a bad design in the first place.

    --
    Better known as 318230.
    1. Re:Bad in any case by Drishmung · · Score: 5, Insightful
      Why didn't they at least recess the switch? You really don't want to accidentally press a reset switch. Poor design.

      Not that Cisco hasn't made faux pas before. The 25xx as I recall had socket for a PCMCIA card, but no slot in the front panel to access it! You had to take the case off to do that.

      --
      Protoplasm. Quiet Protoplasm. I like quiet protoplasm.
    2. Re: Bad in any case by xous · · Score: 4, Interesting

      The mode button triggers "express setup" which is basically a lazy way to configure the shit for retard small business/enterprise admins so they don't have to console the device via rs232 to configure it.

      I've had similar issues with older gear not racked properly. The mode button a 3750 (and other models) can still be accidentally depressed in a messy cabinet.

    3. Re: Bad in any case by ArmoredDragon · · Score: 4, Informative

      The mode button triggers "express setup" which is basically a lazy way to configure the shit for retard small business/enterprise admins so they don't have to console the device via rs232 to configure it.

      For which model? In every Cisco device I've used (including the C3560 switches I own for CCIE training) the mode button only does anything at all if you have it held down while the switch is powering on. Doing so goes into ROMMON, which allows you to change the configuration register to ignore the startup-config.text file on the flash (the startup-config.text file is what contains all of the password information, so if it doesn't execute, then you effectively have a factory configuration switch, although your configuration files are still present if you need to use them.)

      By the way, you can also modify the configuration register so that if the mode button is held at bootup, then it simply wipes the configuration files entirely, that way you don't have to worry about somebody stealing your configuration data if you have a switch that's in a geographic location that you can't reasonably have physically secured.

    4. Re: Bad in any case by TWX · · Score: 4, Informative

      If I'm remembering correctly...

      If there's a TFTP server properly configured... If there's bootp on the LAN properly configured... If there's a switch configuration saved to that TFTP server and If it's named correctly such that there's a mechanism for associating it with a given request, some Cisco equipment can autoconfigure by pulling the config down off of TFTP without administrator intervention. I've seen some C2960S and C3560G do this; had to clear-out, IOS update, and put config templates on about 160 switches over a few days, watching it complain about not being able to find a TFTP server is just a little burned into my brain.

      No one that I've spoken with has ever used this feature in production, and honestly it would take so much advance-setup to make it work that no boss would choose that path out of laziness instead of getting out a console cable, but technically if the switch were reset with the mode button it might make the attempt.

      Again, if I'm remembering correctly.

      I wish that Cisco would make it harder to press that button. Some older switches were REALLY bad, the button was the whole left end of the panel. If the closet is racked incorrectly the component above or below the switch could press the button and hold it down. I've seen it happen a few times.

      --
      Do not look into laser with remaining eye.
  3. It's not a bug, it's a feature by __roo · · Score: 4, Funny

    Are 'config t' and 'write erase' too difficult to remember? Bothered by all those inconvenient keystrokes? Try the new EasyBoot(TM) from Cisco, the most convenient way to reset your router!

    1. Re:It's not a bug, it's a feature by CrankyFool · · Score: 3, Interesting

      You've got to log in as enabled in order to be able to use 'config' or 'write', which of course means you can't use either to recover from a lost enable password (of course, that's what starting up and interrupting the boot sequence and 0x2102 (which, BTW, I last used about 18 years ago and could still remember -- scary) are for.

  4. Wait, what? by Anonymous Coward · · Score: 5, Funny

    From the article:

    The cables, which are sometimes accidentally used in datacenters, feature a protective boot that sticks out over the top to ensure the release

    and then

    Such a situation could cause a problem in any size datacenter, where these switches and cables are commonly used

    So are they commonly used on accident? Accidentally used commonly? I was reading the article to figure out what type of cable was often used, but apparently it's these cables but only by accident all the time.

  5. i work in enterprise datacenter by cosm · · Score: 3, Interesting

    If a single device brings down your entire data center, you've got design problems and your architect should be fired or retrained. These days everything is redundant in triplicate at minimum and new devices spin up automatically based on automatic provisioning and chef/puppet type setups. Even if your core router (why would you have just one!?!?!?!) shits the bed and resets to factory defaults with VLAN 1 and basic STP with no routing interfaces configured, if your NOC folks did a good job, a proper MSTP / VRF / TRILL / SDN ( OpenFlow, etc) / etc like setup should route around that shit and QA will have already tested the "core clos spine device reboots to factory defaults" test case at which point you have just another device for a low paid lackey to swap out based on your network monitor going yellow.

    If you work in a Fortune 500 datacenter and you can't handle this sort of outage, get the fuck out. You're the reason shit's going downhill. Also if a Cisco 3650 or 3850 bring down your datacenter, see previous negative asshole sentiment or get a new job if your manager is responsible for the confines of such a clusterfuck. No participation trophy for such asshattery.

    --
    'We are trying to prove ourselves wrong as quickly as possible, because only in that way can we find progress.' RPF
    1. Re:i work in enterprise datacenter by iggymanz · · Score: 4, Insightful

      blah blah blah

      Reality is single device failures bring down large chunks of the net including valuable peers of your "enterprise datacenter"

      Of course, sometimes identical cisco models used in redundant tuples also cause outages together after upgrade by common bug that didn't show up in test

      so pontificate all you want, you're vulnerable to a lot of bad things

    2. Re:i work in enterprise datacenter by xous · · Score: 4, Interesting

      The problem is that 3650 and 3850 are not designed for a "Datacenter" deployment.

      They aren't even designed as top of rack switches.Their use case is access or distribution for end-users. They belong in a wiring closet.

      That, of course, doesn't stop morons or small companies deploying them as "Core" routers or switches in their datacenters....

    3. Re:i work in enterprise datacenter by Antique+Geekmeister · · Score: 4, Insightful

      > If a single device brings down your entire data center, you've got design problems and your architect should be fired or retrained.

      Please: if your data center has the time, and skill, and is willing to take the service interruptions to make the whole setup properly immune to single points of failure, that's great. But very, very few live business environments have that kind of resource, time, and willingness to enable critical switches with robust failover.

  6. Cisco's official response.. by hilather · · Score: 4, Funny

    You're plugging it in wrong.

    1. Re:Cisco's official response.. by 93+Escort+Wagon · · Score: 4, Funny

      You're plugging it in wrong.

      To be fair, it is running IOS.

      --
      #DeleteChrome
  7. Novel! by adolf · · Score: 5, Interesting

    While I like the auto-LART feature, I wonder what the switch is doing there at all: If the switch is working properly, it doesn't need a reset button.

    If the switch is not working properly, it needs to be burdensome to power-cycle it, to encourage people to complain loudly to the responsible vendor(s) until the product actually works.

    In these modern times, I think an accessible reset switch is like: "Yo dawg, I heard you like to 'fix' things by pushing buttons, so we put buttons on your Enterprise switches so you can reset one-handed while you [...]"

    ObTopic: I once helped take down an enterprise LAN with an Ethernet cable. It was 10-ish years ago, and we just installed a new-fangled VoIP phone system. Each VoIP deskset had a built-in unmanaged 10/100 switch. This was a very handy thing before our modern enlightened structured cabling roll-outs, because it could be trivially daisy-chained with a desktop computer and standardized PoE was not yet a thing.

    Anyhow, we started late on a Wednesday, and finished just before start of business Thursday: Record time for replacing an old Nortel with a few hundred extensions, I tell you. And I went home and died on my couch, having been awake and actually working (prep, etc) for about 40 hours.

    At 7:23AM, my phone rang. It was my manager. Their entire network had crashed, hard. They blamed us. They were livid. I read my manager the NSFW riot act, hung up, and went back to sleep.

    Turns out that after we left, some unknown person had plugged both external switched ports of a deskset into both ports on a wallplate connected to a then high-end HP Procurve switch, which itself connected to a factory and office tower full of other HP Procurve switches carefully set up in a redundant "mesh fabric" mode. This carefully-constructed, redundant network then died in a broadcast packet storm.

    Once they found the error and unplugged that one extraneous heads-will-roll wayward wire, things more-or-less instantly returned to normal.

    (STP would've instantly made this a complete non-issue, but at that time STP and HP's mesh conflicted with eachother and could not cohabitate. I understand that this was subsequently resolved, though I don't deal with HP switches often enough to verify.)