News: 1595235724

Anyone who wants to keep the locking tab on the end of the cable.

In a comms rack that shouldn’t be an issue.

I prefer non booted cables as trying to pull 48 booted ones when swapping a switch out is a nasty job, some of those boots appear to be made out of vulcanised rubber.

Out on the floor maybe, but once a cable is in then the only thing that causes the tag to break it when you replace the cable (at which point it is probably already broken).

Cisco, aren't they the crowd that makes webex?

'nuff said.

While it is perfectly obvious that the connector itself needs to be standardized, there should also be a standard for surrounding space which may or may not be taken up by accessories, e.g. protective hoods or wings.

Otherwise we end up with incompatible, compatible equippment.

The British BS1363 plug has an insulation safety zone around the pins as part of the specification. I'm surprised that this wasn't considered in Ethernet plug design.

With or without that hood, the reset button is too close to the port. I often have to change these things on the touch and the risk of pressing that button with your finger would be too big if you ask me. I understand why it's not recessed (as you some times need to press reset on the touch) but keeping it as far away from the ports as possible would make sense.

In the original advisory, Cisco said the problem was due to a 'problematic connector'. Nothing to do with the button being in a stupid place, no siree.

You're holding the cables wrong, obviously.

But as to why someone would want a locking tab protector... give it a few years and the patching and re-patching activity will have woven 24 of the 48 cables into a kind of rope. If you then need to withdraw a foot or so of one strand of this rope in order to reach a different port or socket, say a new bank of sockets has been added during renovation works or because the original space was under specified, then you have a choice of

1) putting in a new, longer patch cable and leaving the old patch cable in place as a free floating end (this seems to be the usual approach!)

2) unwinding a bit of the twist by pulling the ends back through the knotted, live, rest of the bunch - therein lies the risk to the locking tab as you pull it back through say a dozen pinch points.

3) removing the whole of the old patch cable, binning it and replacing it. Whilst this might be the tidiest and "gold standard" approach, you're bound to be asked why the job took an hour longer than the guesstimate and involved additional items on the bill of materials (new patch cable).

"You're holding the cables wrong, obviously."

Come now, this isn't Apple were talking about here...

In their (partial - it still is an inconvenient place) defense, it is a mode button for the blinkenlights. It only becomes a reset button when you keep it pressed.

They could have put it in-between the sockets below instead of directly above!

In a 48-port 1U switch with uplink ports, there isn't a lot of space above or below and Cisco's choice to use uplink modules to support 1Gbps/10Gbps uplinks limits removes the option of space at the right of the switch (looking from the front).

They could have moved the button further to the left but space is very tight if you take the case off and see where everything is located. But I would also speculate that Cisco never contemplated this being a design issue as the could have done a little more to give them the mm or so they needed.

Pressing the button while the switch is active doesn't cause a reset - it cycles through the different LED display modes.

The problem comes when the switch is restarted when holding the button for 15 (I think...) seconds causes it to enter recovery mode which then requires manual commands or a further power cycle to restart.

Customers generally discover this issue when they have a power outage and a problematic cable.

In terms of who is at fault, it's clearly a Cisco design fault but having said that the number of affected devices is relatively small because most customers don't use wiring closet cabling with problematic boots so I can understand it being missed in QA.

Out of the thousands (literally) of these switches I have been responsible for managing across international sites, I haven't seen this issue and we have almost no input into local cabling standards as it is usually part of a building fit out rather than ITs responsibility. The real design flaw in these switches is the stupid install/bundle firmware modes that catch out so many people and cause remote switches to either fail to upgrade automatically or just fail to boot into a stack or not boot at all.

Nah, we don't need to be able to plug things in there either.

I stayed up late last night to watch two episodes of "World's Most Evil Kittens" on Sky Crime. What a disappointment. World's Most Evil Killers.

On the plus side I now have a great programme idea. Plus the follow up, World's Most Evil Puppies.

This is the same issue with first generation of Nexus 7K and the "eject" lever -- the developers came up with a "nerd knob" to disable the eject levers.

Some of them are really damn difficult to unplug because you have to squeeze it just the right place, and with quite a lot of force, to get it to disengage. I'd much rather have to be careful about avoiding snags (or if I can't just tug really damn hard, break the flange, and replace the connector) than deal with the snagless boots.

"Or in other words, putting an ethernet cable into a router can put that router into and endless spiral of FAIL. Which given that the whole point of a router is to have cables plugged into it, is a less-than-optimal situation."

Its a sodding SWITCH for gods sake. It may have L3 abilities but its not a ROUTER & don't even think about calling it a HUB.