Network Operators List Their Peeves

The ears of a few well known networking companies must have been burning this week, as subscribers to the mailing list of the North American Network Operators' Group (NANOG) made their choices for the world's worst design decisions in networking gear.

These folk have plenty to complain about. After all, many of them are the guys'n'gals who get called out at night to fix your ISP connection. Their beefs (beeves?) center on features of networking gear that interfere with the efficient completion of their appointed rounds.

Examples include modules that can't be slotted into or out of routers easily; cable adapters that don't fit the equipment; sharp edges that cut engineers' hands; handles that don't work...

Here's a sampling of the choicer bits:

  • "Why did Cisco not include side handles on the 12000 chassis? It's a heavy chassis, and I can imagine how many techs have thrown out their back moving that chassis around." (NOTE: Subsequently, the thread moved on to how the scissors-jack included with the product could lift a house, or double as an office coffee-table.)
  • "Personally my issues are console-cable related: is there a benefit to the HUGE variety of console pinouts used by the various hardware vendors?"
  • "Could people just pick ONE pinout and connector and stick with it? Please!"
  • "I can't stand it when I sit down and find the keyboard in front of me has moved the 'backslash' key. It drives me crazy and prompts me to find a real keyboard right away to work with."
  • "RJ45 connecters that have a rubber hood over the release. Grrrrr!"
  • "The little clippy widgets (looks kind of like @) on some oldschool racks, that hold the nut in place for the hex-head bolt. Why these were considered desirable is beyond me."
  • "The slimline DS3 patch panels. God help you should you need to do something with the two innermost wires on the back end of that -- there's barely room for pliers, much less fingers."
  • "Any device whose physical characteristics make it a likely candidate to be shelf-mounted, yet which has side ventilation ports which will be blocked by the sides of a rack shelf."
  • "Routers that will accomodate high density of OCx ports but only have the bus capacity to support a fraction of hem."

Vendors, take heed. Messages like the above insert a healthy dose of reality. Have a thought for the poor fellow who has to confront this gear in the middle of the night.

— Mary Jander, Senior Editor, Light Reading

<<   <   Page 2 / 2
mcasaes 12/4/2012 | 11:24:03 PM
re: Network Operators List Their Peeves No, you are wrong, the master/slave your refer is for CPU only, not for switch fabric/forwarding (if you are doing PCAP, the 2nd CPU will even be used to packet capture without impact in the control plane, if doing HA, the 1st and 2nd CPU will be in sync for control plane info)
The current hardware/software in the 8600 is wirespeed for 64 Giga interfaces, no doubts about that. Has been since day one. No "upgrade" was required for that.
Both TAP are active in a dual CPU/SSF configuration.
AFAIK, the full duplex argument come from what is called today Cisco Math..
BlueFox 12/4/2012 | 11:24:00 PM
re: Network Operators List Their Peeves Rubber booties on RJ45's as a problem????

I hate those damn things. If you work in a lab and are constantly rewiring your network they are an evil creation. Especially, if you have cables in the slots beside, above, and below the cable you are attempting to remove. Give me the wire cutters and off with the booties!!
vrparente 12/4/2012 | 11:23:59 PM
re: Network Operators List Their Peeves I kind of agree with justapeon. But I will add that one can build a packet switched (in this case referred to as a stat muxed) network and get cost savings from opex alone, without accounting for any differences in capital equipment cost or that portion of the opex tied to transmission capacity. In other words, packet switched networks can be easier to operate even for fixed bandwidth.

In reality it is much more complex than that. So the kinds of "stat muxing" we can and do see/use on IP networks, for example, do include things like time of day "muxing." An example is the opreation of a web service for global customers run out of a single geography. So the total transmission capacity (while fixed) is used along different paths at different times of day as people wake up, go to work, come home, go to sleep, etc. In a case like that one could engineer to the max. capacity for a given time of day and traffic load, but then use "stat" geographical multiplexing to save cost, in a way that would be difficult to configure with TDM networks. (Although arguably just as easy with other packet technologies like FR, etc.).

vrparente 12/4/2012 | 11:23:58 PM
re: Network Operators List Their Peeves Not to comment on RJ45's specifically, but for anyone with operational experience (and more important responsibilities) this is no laughing matter.

Managing cable systems has become a massively complex problem. In the data centers I have worked in (and later the ones I designed with my colleagues) we put significant effort and finances into the management of overhead, underfloor, rack, and equipment cable management. With the increasing density of equipment, sensitivity (meant in BOTH ways) of fiber, and growing size of data centers, it is costly issue.

I've dealt with everything from connectors falling out (call it the gravity effect because some equipment designers love to point the conenctors down/aka south); to issues of alignment, connector types, etc.

In some of the largest data centers we ran we dealt with tens of thousands of RG cables, tens to hundreds of thousands of CAT5/110 pannel connections (that by the way is a tiny operation), hundreds of thousands of CAT5/RJ45, and hundreds of thousands of MMF and SMF tips. And of course a variety of connectors (ST, SC, MT-RJ, MIC, etc....). If that weren't enough managing test equipment for this gets complex as various kinds of test equipment have or don't have appropriate leads/tails. I could go on endlessly. Ribbon connectors, bend radius issues, etc.

In summary a big problem. I hope that wireless technologies will begin to provide some relief. In particular I see wireless taking on a role with out of band network management to replace endless quantities of low-tech crash carts, terminal servers, and fix that serial/tty port pin-out challenge. But wireless has a long way to go to scale from basic p-to-p and p-to-multi-p to supporting large scale hiearchical networks (aka data centers and transport networks). Still though -- how long will it be before folks try to use WLANs to bypass interconnection fees and politics in co-lo facilities ? I'm sure its been done already. One problem replaced by another ...

st0 12/4/2012 | 11:23:49 PM
re: Network Operators List Their Peeves vrparente,
like time of day "muxing." is not really a good idea. Many things transmitted at night (low peak time). backup update, consumer goods, banking and even education using the low peak time to transmit the pre-recorded classes. for example, it is really peeves when direct trading bank tells you their computer upgrade everyday between 5-7 am and you can not place a trade....just back on line when you step out of door heading to work...(24 hr trande is really a 22 hr one... )...

The off peak time is more important on speed than daytime...just think about if the bank can shorten their upgrade to one hour.... ha, I might be a millioniar now...May be not!

vrparente 12/4/2012 | 11:23:48 PM
re: Network Operators List Their Peeves St,

Interactive services are clearly time of day specific as the systems rotate through servicing folks in various timezones. For example, primetime online service for residential tv, email, reading news, etc. matches local time of day.

So this is the big driver for residential/home web services, streaming video, etc.

So I disagree strongly. Time of day muxing is a very good idea. And my point was that it is easier to do with packet networks -- especially geographically open ones -- like the Internet.

<<   <   Page 2 / 2
Sign In