A friend of mine recently posted this image of a hideous network-cable tangle:
I have invented an algorithm for fixing this kind of mess. Probably other people have developed the same technique before, but it wasn’t taught to me and I’ve never seen it written down. Here it is…
First, start by assembling your equipment. You will need a labeling gun (the kind that can put lettering on a short length of sticky-backed plastic tape), a bunch of cable ties (a couple dozen for this mess), a pad of paper (ideally, blue-lined graph paper), a clipboard, and a pencil. Finally, a bunch of patch cables in 12-inch and 6-inch lengths.
For some jobs, like this one, you’ll want a nice sturdy stepladder, something you can use to put the bulk of the cable tangle at or below shoulder height. If you need to reach above shoulder height to get at the connectors, the job is going to fatigue you faster than you realize – and that can easily lead to mistakes that are quite difficult to recover from. Hard work is not a virtue here; make the job easy on yourself so you’ll get it right.
The tangle pictured is about a three-hour job using this method, maybe four; scale appropriately for your mess . Allocate time so you can do it all in one go, otherwise you may have trouble fully recovering intermediate state.
Your first step (and the longest part of the job) is the crucial one. Trace each individual cable through the mess without removing it. Now label both ends of the cable, right near each connector, with a unique code. Same code for both ends.
Second step: Make a sketch of the patch panels. The reason graph paper helps is that usually the equipment racks will be laid out so the cable connectors fit on a rectangular grid. Sketch in each connector as a little box, and each rack unit as a surrounding frame. Leave enough room in the boxes to write inside; if there are unused connectors on the units, X them out in your diagram. When you are done, your sketch should resemble a crude plan of the racks.
Third step: Pick a cable. Note the code at one end in the corresponding box on your sketch. Unplug that end. Work the cable end through the rest of the mess until it is fully untangled and you can see the entire length. Identify the end still attached and add its code to your sketch. Unplug the other end and lay the cable aside. Repeat this procedure until all cables are removed. If you can recruit someone to help you, the single most useful thing that person can do is eyeball-check each code pair on your diagram as you pencil it in.
Step Four: At the end of this step, you should have a filled-in diagram that will tell you exactly how to rebuild your patch network. Do that. But this time, you’re going to do three things differently. First, you’re going to use shorty cables wherever you can to avoid hanging loops that can get tangled. Second, you’re going to use cable ties to bundle together parallel runs.
Thirdly, and most importantly, each new cable gets a label at both ends. Once you’ve done this, your patch network will no longer be a nightmare to manage. And the next poor sod who has to cope with it (quite possibly yourself in six months) will bless your foresight.
Could you post image how cables should be laid out?
>Could you post image how cables should be laid out?
Not without actually fixing the mess. Which I could do, but somebody would have to fly me to England first. :-)
The first rule for a setup like this where the cabling seems to change seldom is: use the shortest cable you can for each link. This reduces cable tangling, which is the main reason the connections become difficult to trace.
More great photos of cable messes (including scary mains ones), and even some good examples: http://www.darkroastedblend.com/2011/09/crazy-wiring-drb-series.html
Couldn’t you just label each cable end with what it plugs into without tracing them?
>Couldn’t you just label each cable end with what it plugs into without tracing them?
Er…how are you going to know unless you trace them? Do not try just following by eyeball – in a tangle that large you will make mistakes and they will bite you in the ass.
That network is desperately in need of some WIFI
You mean to tell me that people are still using Ethernet?
I meant you label every _cable end_ with a label which does not match any other cable end, but rather matches the _port_ that this cable end plugs into. Then when you remove a cable you can note what the two [different] labels on the ends of it are. Seems easier than tracing them while they’re still tangled, and I don’t see an obvious downside.
Random832:
>”Couldn’t you just label each cable end with what it plugs into without tracing them?”
ESR:
“Er…how are you going to know unless you trace them?”
I suspect that Random meant that you could create a grid for what I’ll call the left and the right panels. On the left, we see that a cable is plugged into the 3rd row, 4th column down, so we label attach a label to the left end of that cable that says “34”. Repeat for all other cables on the left end. Then on the right end, we see that a cable is plugged into the 2nd row, 6th column; label that end of that cable “BF” (on the cable itself). Repeat. Then disconnect everything and untangle it.
Now look at the pile of disconnected cables that you have on the ground. You’ll see that one of the cables has a “34” on one end and a “BF” on the other. Go back to your diagrams and write “34” in the BF box and “BF” in the 34 box, showing that these connect. Repeat for all other cables.
Now rebuild as you described in your final step, using shorty cables and tying cables into bundles.
Cathy
> On the left, we see that a cable is plugged into the 3rd row, 4th column down
Ah, right. That’ll work, all right, but only if you can pre-compose a set of coordinate codes that are meaningful for the whole setup. Maybe you can – but if you get halfway into the job and find a flaw or gap in the system life is going to get really complicated really fast.
Having done this sort of thing professionally, I have a couple of improvements to offer:
1) While zip ties are nice, even better are Velcro ties — hooks on one side, loops on the other, with a hole at one end big enough to make a loop. All you have to do is wrap it around a set of cables, unwrapping is simple and reusable, and they can’t be pulled so tight that they damage the cables. You can get these in multiple lengths; I usually buy them at Lowes or Home Depot.
2) If you’ve got the money, color-code your cables. Ideally, each network gets the same color, and save red or orange for networks with potentially damaging traffic (eg: Internet feeds, DMZs, etc.)
>If you’ve got the money, color-code your cables.
I actually think it’s better to mix colors at random in such a way that cables near each other don’t have the same color. Makes visual tracing easier.
That’s fairly frightening, but not too much worse than what I’ve seen in wiring closets and data centers at various companies.
> Thirdly, and most importantly, each new cable gets a label at both ends.
Sadly, I’ve seen this willfully disregarded at companies I’ve worked at, policy be damned. To take the time to correctly label a patch cable would be considered too much work when the cable layout changes infrequently and it can be somebody else’s problem later.
Cable ties are good, but I dare say double-sided velcro strips are even better. Rather than having to cut the cable tie whenever you want to make a change to the bundle, you can undo the velcro, make your change, and redo it again. Cut the velcro long enough, and you can leave room for expansion in the future.
As for routing the bundles, if the bundles aren’t too large and are to be routed along the edge of a desk, cabinet or similar, large binder clips are handy. Clip to the edge of the desk or cabinet, and the cable bundle fits in the space between the edge of the desk and the back of the binder clip.
In a situation like the one shown in the picture, I’d be tempted to grab a spool of cable, some ends, and a crimper. Yes, making your own cables would take more time, but you can cut your patch cables to exactly the needed length, thus avoiding all the extra slack that becomes tangled. Plus, 1000′ spools seem easier to find than patch cables < 3' for some reason.
I second what Random wrote.
Labeling cables while tangled without caring where it goes to should also reduce problems with following a tangled cable from one end to the other – you might just mix them up while following them…
Sometimes its necessary to step back and decide if the problem originates because two or more hubs should be stacked together but aren’t – thereby requiring more longer cables with the attendant mess.
Now I will confess, when I had to straighten out something like this and there was enough slack in the tangle, I just attacked it by tracing a cable, and immediately replacing it – while running the new shorter cable under the mess. There are obviously messes that can’t be done this way due to too large or too tight a tangle.
ESR: “Thirdly, and most importantly, each new cable gets a label at both ends.”
Jeremy:
“Sadly, I’ve seen this willfully disregarded at companies I’ve worked at, policy be damned. To take the time to correctly label a patch cable would be considered too much work when the cable layout changes infrequently and it can be somebody else’s problem later.”
Presumably these are the same companies that are in such a hurry to make code changes they can’t be bothered to budget time to update the documentation (and in some cases, even the comments in the code). Always time tomorrow (or so they think), never time today.
“Ah, right. That’ll work, all right, but only if you can pre-compose a set of coordinate codes that are meaningful for the whole setup.”
Actually you don’t even need a coordinate system. You just need an unambiguous diagram of the panel at each end. You label the cable and the diagram with a unique code, any code, but don’t trace the cable to the other end. Then go to the other end and use a new set of unique codes on the cables, and write in those code on the second panel diagram. Now unplug everything and untangle the cables. Match the unique codes at both ends of each cables, and copy the left panel’s unique code into the correspondong diagram for the right panel, and vice versa.
This is simpler if you have a nice grid layout, but it works either way. The point is that it’s worth some effort to eliminate the cable-tracing step, which is by far the most tedious, time-consuming, and error-prone.
@cathy
>@esr
>>Ah, right. That’ll work, all right, but only if you can pre-compose a set of coordinate codes that are meaningful for the whole setup.
>Actually you don’t even need a coordinate system. You just need an unambiguous diagram of the panel at each end.
Mix these ideas for the win. Make your diagram – 2 copies. Label the devices in the 1st copy numerically, and label the ports sequentially (upper left to lower right) per device. Label the devices in the 2nd copy alphabetically, and the ports the same way as the first diagram. Now label the two ends of each cable with the codes you just created. Unplug, and rationalize the routing according to the two codes per cable as described above. This is one way to “pre-compose” the coordinate codes with no fear of running out or ending up in a contradiction. (If you have more than (scalar(@ALPHABETIC_LETTERS)) number of devices, start over at “AA”, “AB”, “AC”, etc.)
@esr
>I actually think it’s better to mix colors at random in such a way that cables near each other don’t have the same color. Makes visual tracing easier.
No, NO, please! Any large site will color code according to function – particular subnets, KVM over cat5, SAN private network, whatever. Anything much bigger than the pictured setup will be way too big to trace wires end-to-end – correct and complete labeling is manditory.
Ask me how I know…. :-O
The picture has a package of gummy bears in the background. I was mildly disappointed to find out your algorithm did not include the gummy bears.
You color-code your cables so you don’t accidentally mix networks.
For complicated setups, instead of graph paper, either (a) take a photograph of the back panel of each piece of equipment, (b) go online to the vendor’s site and download the back panel diagram, or (c) draw it up in Visio, Inkscape, etc.
Patch cables shorter than 3′ are hard to get because Ethernet is spec’d for cables that are a minimum of 1 meter between pieces of equipment.
By the way, I’ve posted this to reddit in http://www.reddit.com/r/cablefail, which includes many pictures of similar situations and occasional discussion like this.
A few notes:
@esr
>I actually think it’s better to mix colors at random in such a way that cables near each other don’t have the same color. Makes visual tracing easier.
This will bite you later when stuff has to move and somehow you end up with all of one color next to each other. This has happened to me in _every_ case where this policy was used. Visual tracing is a source of errors. I use tactile tracing if at all possible (run your finger along the cable).
My favorite cable management accessory:
http://www.neatpatch.com/
It’s a really simple idea, but if you have the vertical space available, using these is more useful than you can imagine (until you actually use them). And the cost is about the same as an equivalent number of short cables, which are included, so…win!
Also, for the first set of labels (which are in theory temporary and only need to last until you are done cleaning up the mess) you can use plain masking tape and a Sharpie. Saves on tape for the labeller. You really should invest in a labeller for the permanent labels, though.
>I use tactile tracing if at all possible (run your finger along the cable).
Well, so do I if I’m rearranging anything large. My point is the combination of random colors and short cables increases the percentage of situations in which your eyes can correctly grok what’s going on.
I agree with Craig — velcro, not zip-tie.
Seeing things like this makes me glad my employer has a draconian cabling policy. The end result of that algorithm is the expected cabling procedure from the beginning.
I like the idea of assigning a unique code to each individual Ethernet port, but why is it necessary to have two separate sets of codes? It doesn’t matter which end of the cable comes “first,” and it’s impossible to plug a cable in “backwards,” so this is information you don’t need to encode in your namespace; that is, 3rd switch, 4th port –> 5th switch, 1st port is the same as 5th switch, 1st port –> 3rd switch, 4th port. Or am I missing something?
+1 for color coding en velcro
What’s the rationale behind a policy of labeling cable ends ?
I prefer to have the patch panel ports labeled, and document how they’re connected – if it actually matters; uplinks and such.
And I’ve found that SPQR’s approach of trace and replace immediatly often works well, and keeps most of your network up most of the time during the whole exercise.
As a building engineer I see this all the time in the Comm Closets, the cause of the problem tends to be outside contractors who could care less, as by the time you find the mess they’ve been paid and are long gone. Glad all I have to do is cleanup all the trash they leave around.
@Max E – the point of having separate codes for each port is that you can label the cable ends before you untangle anything. You can redo it with a code per cable after you’re done, but this way you wouldn’t have to trace through the middle of a tangled mess.
When my former company laid this problem at my feet, I pretty much used the method you described with the additional step of PRE-labeling all of my replacement cables (already sorted into color and lengths). And, since the prior person had just them all spaghetti’d between the rack modules, we also had pre-estimated the lengths we needed with just a tab to spare, we pre-affixed the replacement cables to the vertical rack supports in bundles. Then as we removed each cable we immediately plugged in the replacement cabling and the job resulted in a quick, clean switch out. I had a pic of the before-and-after on my old phone; sadly, it was lost to a swim.
Oh what a tangled web we weave when first we practice to wireless leave.
What we did at the TV network:
Cables get *the same* number at both ends. Preprinted cable markers are available commercially. They are white cloth tapes with black lettering that you peel off a card and wrap around the cable end. For added security and protection from grunge, wrap the installed markers with a layer of transparent tape.
>Cables get *the same* number at both ends.
Hm, I see I didn’t specify that, though I meant to. Added.
Someone in this thread was advocating a variation where you have different codes on either end, as a way to avoid tracing. The trouble with that is that those unmatched labels are zero help in reading the cables after you’ve rebuilt.
I guess this method must be well-established craft practice in places I don’t personally know about. Otherwise there wouldn’t be a market for the preprinted cable tags.
@Random832 — yeah, that’s what I meant. I thought people were suggesting assigning each Ethernet port two different unique IDs, which seemed unnecessary.
@Jakub Narebski: I don’t know how standard it is, but there are a handful of rules I’ve been taught. Divide the gear in half vertically and horizontally. For example, if you have a 24 port switch it’ll usually be in a 2 by 12 port array, and you’ll have 12 ports to the left, 12 to the right, 12 above, and 12 below. Cables to the left half are always routed towards the left, similarly to the right; ports on top go into any raceway above, ports on the bottom go into the raceway below. (In other words, don’t try to shorten up the cable run by, for example, routing a bottom port to the raceway above.) If feasible, leave a little slack on each end to facilitate future cable tracing, especially for custom-made cables–the most common example I can think of is 110 block cross-connects (loop the wire around your finger pointing at over/under the target 110 block position). For things like servers, try to judge if the port is more to the right or left and route the cable towards the closest side of its rack.
Another vote for velcro, not zip ties. I deal with more of these in a given year than most people ever deal with, and the guy I’m cursing the most is the guy who used zipties, especially when they use diagonal cutters and not flush-cuts on the ends of the ties (they quite often get razor sharp).
@esr:
I could have misunderstood, but I assumed the different numbering was merely an attempt to quickly document what was already there. Especially since one of the points of the exercise is shorter, thus presumably different, cables, there is no mandate to use the same numbering scheme on the replacements.
>there is no mandate to use the same numbering scheme on the replacements.
You’re right, but who wants to re-tag cables they’ve already labeled? There’s a difference between “intelligent risk minimization” and “annoyingly fiddly”; for me (and I suspect for many others), a second labeling pass would cross it. OK, there’s some escape from this by using new (shorter) cables, but I developed my technique on smaller and zero-budget jobs where buying a box of shorty cables wasn’t really an option – in fact, I’ve never done a solo rewiring job where it was.
I was thinking more of a red sauce and garlic bread. Served on a big platter. With some extra Parmigiano-Reggiano.
Screw ’em. Patent the technique and sue ’em.
What sort of modifications does this procedure require if I find any bird’s eggs? ;)
“how are you going to know unless you trace them”
Presuming that you can map each port on the patch panel to a port on a switch (a big assumption sometimes) you then find out what mac address is on the other end of each switch port. Then you do something that gives you a host to mac mapping (there’s a couple ways) and bob’s your uncle.
At my last gig I had a switch with over 250 network cables coming into it (Memory says a Cisco 6500 series). This was the core switch for my lab. I had to migrate off the switch, power it down and blow it up…I mean get rid of it.
About 1/5th of the cables were unlabeled. About 1/2 of the rest were either labeled wrong, or had labels that were inadequate.
Because of the nature of the facility I had to minimize downtime.
I wrote a script in python using the expect module to scrape the switch’s mac address table and match it up with the entries in DHCP and DNS. This got me all but a very few.
Oh, and did I mention that this was all under-the-floor cabling?
We had a cable label system that assigned each cable a serial number, put the location (x/y), rack number, rack elevation and socket/jack/port of each end in such a way that “this” end was the top line, and the matching label for the other end was on the bottom. Of course this was for a building with multiple datacenters that interconnected in byzantine ways.
The one downfall of your algorithm AS WRITTEN is that it assumes you can pull all the cables at once. This is frequently not an option.
Oh, and that is not a mess, that’s just a bit untidy. Heck, I might not even bother to clean it up unless we were redoing it. In one former data center down near Al Basra *EVERY* cable (think a bundle you MIGHT be able to get your arms around) came out of a hole in the ceiling and into a big circle on the floor, and then into switches, racks and servers. All the same color, and the contractors that put it in used some sort of thin black type on clear plastic labels that was hard to read if you unplugged it. Impossible to read while it was in the switch.
Good thing TCP tolerates a bit of latency.
“””Patch cables shorter than 3? are hard to get because Ethernet is spec’d for cables that are a “””
No, they aren’t.
http://www.blackbox.com/Store/Results.aspx/Cables/Copper-Patch-Cables/n-4294838115-4294953702
“””I’m cursing the most is the guy who used zipties, especially when they use diagonal cutters and not flush-cuts on the ends of the ties (they quite often get razor sharp).”””
Anyone who uses zipties cinched up tight does not know what they are doing and should be educated. Preferably by having a ziptie cinched up tight on his willy and made to drink a gallon of strong tea.
Then hand him a pair of diks and let him cut the cable.
Meant to say “cable tie”, but I couldn’t edit it.
My suggestions for dressing the cables: Lead them directly away from the equipment, then make a right angle bend about 6″ out. This redirects the mess to either side of the rack, and makes it easy to read the numbers you put on the cable ends.
----[U]---[U]---[U]---[U]---[U]---[U]---[U]---[U]---[U]---[U]---[U]---[U]---- | | | | | | | | | | | | <- cable numbers here | | | | | | | | | | | | ___ / | | | | | | | | | | \_______ ________/ | | | | | | | | \___________ ___________ / | | | | | | \_______________ Bundle these together ________________/ | | | | \___________________ ____________________/ | | \_______________________ ________________________/ \___________________________ ^ ^ ^ ^ ^ ^ Use cable ties hereSorry folks…I used the magic incantation, yet my ascii masterpiece still got screwed up.
Cable ties aren’t that bad, so long as you use the smaller sizes, and don’t use that stupid gun to tighten them. As for removal, the best tool to use is a little green screwdriver, Xcelite R3322 or R3323. Slip the blade under the tie, use the handle as a lever to twist the tie loop (like a tourniquet), and the tie will pop right off.
Do this for every cable when you install it: Label both ends of every cable with locations for both ends. This isn’t complicated… Number your cable racks, then number your panels / hardware by their height from the floor, number your ports so they coincide with what the vendor already painted on the hardware. Every end labelled with it’s own location and the location of the other end = no more tracing cables. (If you have both ends labelled as I describe and you plug something into the wrong location it’s because you don’t read.)
Oh, and put all that in a full-size 19″ rack with some cable trough / strain relief / etc. You’ve spent enough on the rest of the hardware to make it worth moving it out of the employee break room / broom closet / mom’s basement.
Then document / track your equipment locations with something like RackTables http://racktables.org/ so you and your coworkers can find it later.
I’d use the reference designator system. It’s what is used in the military flight simulators I’ve worked on for the last 18 years.
Each rack is labeled with an “A” number. So the top left rack on the wall could be “A1”, with the next one to the right being “A2” and so on. Each unit in the rack is also given an “A” number. The top unit in each rack is “A1”, the next one down is “A2”, etc. The connections on each unit are given “P” numbers. These are usually conveniently supplied and labeled by the manufacturer. The patch panels are referred to differently, given “TB” numbers instead of “A” numbers, the ports also prelabeled by the manufacturer.
So port 18 in the third switch from the top in the rack on the right would have a reference designator of A2A3P18. It may have a cable going to port 12 in the second patch panel from the top (A2TB2P12).
Once you have your reference designators established, then you pick a cable end, label it with its reference designator, write it down on a sheet of paper, and unplug it. Find the other end. Since you’ve already unplugged one end, you don’t have to trace it through the tangle, just remove it. This is much easier and far less error prone. Label the second end with the reference designator it plugs into, and write that down on your paper. The example above would be “A2A3P18-A2TB2P12”. Now, if you are a belt-and-suspenders sort, what you do is add another label to each end of the cable with the reference designator of the opposite end, making sure to keep the label nearest the end the reference designator of that end. This is a great help in troubleshooting later on. If you somehow lose your piece of paper, you can still rebuild the system even if you have to disconnect all cables at once, say if you have to move a rack from one place to another, or if you have to replace a bad switch. You’ve made the documentation part of the system itself. As a bonus, anybody who understands reference designators can work on it. They don’t even have to know the function of a particular piece of equipment. This is probably why the military adopted it.
I use a similar method for the data center. Using a Brady IDXpert lable maker, I create 3-line lables that have the following:
Customer ID
Location of customer end
Location of Carrier end
I use rack, unit/machine name, port threeples for the locations whenever possible (I’m rarely given this info for customer’s stuff). This makes it extremely easy to work on stuff, as if I have a problem, I look at the cable and I know who’s it is and where it goes. If I find a cable hanging loose, I know where it SHOULD go on either end.
Label both ends identically (print 2 labels at a time).
For inner-rack wiring, we use Machine Name, then location (to the port) on both ends.
If you deal with LOTS of cables and are doing this kind of work on a regular basis (e.g. work in a data center), invest in an IDXpert label printer and 1.5″ self-laminating cable labels. They are work every cent you will spend on them (about $350 for the printer and $50 for a cartridge of labels).
Dozens of racks, hundreds of machines, thousands or ports gives one a completely new appreciation for labeling and methodology :^).
My two cents taken from decades of experience…
Assumptions for Human Activity in Data Centers and Closets
1) Always assume that some uncaring human will come into your data center and totally disregards your patching and cabling identification system.
2) Always assume that there are a thousand different ways to create a cabling identification system and that your choice will be therefore opposed by a thousand other people.
3) Always assume that an emergency will come along that will cancel all of your carefully crafted rules for patching and cable identification. Always assume that no one will go back and clean up after the emergency has passed. Emergencies happen several times a year.
4) Always assume that staff turnover will nullify all of your carefully thought out rules and standards for patching and cable identification.
5) Always assume that other staff will take an already labeled cable and reuse it without removing the existing labels. Always assume that re-patching one end of a cable will result in a cable with one end correctly labelled and the other end not.
6) Always assume that someone with a pair of side cutters trying to snip a cable tie will result in damaged patch cables (especially fiber).
7) The longer a cable run is, the less likely it will be labelled correctly at both ends.
Pragmatic Rules for Data Closets
1) No side cutters or other sharp implements are permitted in the data center and data closets.
2) Cable ties are forbidden in the data center. Velcro wrap only.
3) Patching cables shall be any color. No functional significance shall be attached to the color of any patch cable. Mix and match cable colors randomly so that physical tracing is easier.
4) No cable shall ever be labelled. If you encounter a cable that is labelled, assume that the label is wrong. Never remove a label on a cable. It may be useful to someone else.
5) Always maintain accurate descriptions in the switch and router port configurations. Develop scripts to do the job for you. Develop scripts that audit the descriptions.
6) Use network management tools to audit switch and router ports that map MAC address to IP and to reverse DNS lookups.
7) Always use automated scripts to maintain an accurate and up to date reverse lookup DNS for all interfaces with IP addresses (layer 3/router interfaces).
8) Maintain your own accurate network diagrams.
9) All patching racks (including switches or patches) shall be 24″ wide. No 19″ racks are permitted for patch panels!
10) For catalyst switches, cable shall enter the switch modules from the side that does NOT have the fan tray. The fan tray side must remain clear at all times.
11) Use overhead cable tray/ladder for all inter cabinet cabling.
12) Fiber runs and copper runs shall be segregated. Preferably a slotted duct should be installed in overhead cable tray. The slotted duct will be used for fiber runs only.
13) Always try to make the cabling look good but do not make it look good at the expense of troubleshooting problems or at the expense of maintaining functional integrity.
Oops and finally, ensure that all patch panels are properly labelled when they are first installed. This requires that a scalable patch panel numbering system is used at the outset.
> >Couldn’t you just label each cable end with what it plugs into without tracing them?
> Er…how are you going to know unless you trace them?
I have a wonderful Ethernet cable tester I bought at Micro Center for $5. It has two parts, each of which has 8P8C (commonly referred to as “RJ-45”) jacks. Plug one end of the cable into each of the two parts, and it lights up each of 8 LEDs in sequence indicating that wire connects to the other end. To test whether you have the correct other end of the cable, try plugging in two ends. If none of the LEDs light, they aren’t connected. As an added bonus, you can identify defective cables as you go.
>I have a wonderful Ethernet cable tester I bought at Micro Center for $5.
Excellent. I’m gonna get me one of those.
I have not actually tried this on data cables, but I’ll just throw this out there in case it might help someone. They make wire tracers for use on telephone wiring problems. Like the tester that The Monster described, there are two parts. One is a signal generator you attach to one end of the cable. (You would have to make an adapter to feed an RJ-45 jack.) The other is a probe that you run along the cables. When the probe is near the cable you are tracing, it makes a distinctive sound. You just follow the sound until you reach the other end. Saves lots of time in large installations.
Craig Trader said: Patch cables shorter than 3? are hard to get because Ethernet is spec’d for cables that are a minimum of 1 meter between pieces of equipment.
Monoprice (no affiliation, but damn do I love their stuff) will sell you 6″, 1′, 2′ lengths, in a large variety of colors, for pocket change – and in my experience they seem to work fine at gigabit speeds.
I know nothing of a minimum length spec for Ethernet, but I sure have used a lot of shorter-than-1-meter cables with no obvious problem, and seen a lot of them in pictures of Real Networks, too.
(Discovering them is what made me finally get decent cabling for my home network – at prices like that there’s just no excuse for using “the wrong cable” because “it’s what you’ve got”.
Also, the other helpful policy that made easily enforced for my personal network is “if a cable is at all dodgy, throw it out“.)
patrioticduo on Tuesday, January 22 2013 at 10:02 am said:
>My two cents taken from decades of experience…
>Assumptions for Human Activity in Data Centers and Closets
> […]
> Pragmatic Rules for Data Closets
>[…]
After hardly one decade and already having cleaned up more spaghetti cabling than I care for, I can confirm your assumptions and the MO I developed along the way is converging pretty well with your ‘pragmatic rules’ – the main exception is that I do tend to use colors to identify between VLANs (visual clue in addition to switch port documentation) and to easily identify “important” links – a distinctive color for an unusual solution, or for temporary patches and such.
This is off-topic. I just happened to see this comment made on this blog in July 2010 by “J. Jay”:
“Even so, the ‘year of Android’ is as far away as the year of the linux desktop. For approximately similar reasons.”
That makes for a bit of claim chowder, I think. The blog post is titled “FroYo, yum yum!”, from 3 July 2010.
The other day I flashed CyanogenMod 10 (4.1 Jelly Bean) on a low-end Sony phone that originally came with 4.0 ICS, and that was not going to get a Jelly Bean update from Sony according to their announcement last month. This is a non-carrier phone bought in Finland, so it only had Sony’s stuff on it, which is actually not that far from a vanilla ICS experience. I flashed a potentially unstable early version of CM10 on it anyway, and I’ve been very impressed, both with Jelly Bean and CM. Everything, starting from the contacts app, is just nicer and better-looking than in Sony’s version of ICS.
I couple of things struck me. The fact that Sony announced the list of 2012 models that are going to get Jelly Bean (in a few months time), but excluded my phone, actually made me go get Jelly Bean via CM sooner. I wasn’t even particularly unhappy with the Sony firmware or ICS, but just the knowledge that there isn’t going to be a manufacturer update made me think that I might as well go for CM right away.
I hadn’t been following the independent Android development community at all before this, and I was somewhat amazed at the number of people supporting the number of handsets that they do. I guess it shouldn’t be that surprising for an OS that’s on hundreds of millions of handsets, but still. Also, Jelly Bean runs quite nicely on the low-end phone hardware of the moment (a single-core 800 MHz processor, 500 MB or even less of RAM). There are a zillion Gingerbread handsets in use that could benefit in a big way from an update, but will probably never get one.
Mikko notes J. Jay’s old quote from 2010:
“Even so, the ‘year of Android’ is as far away as the year of the linux desktop. For approximately similar reasons.”
Quite hilarious given that Android has somewhere north of 52% of the smartphone market in the U.S. today, and smartphones have 50% of the cell phone market.
Eric, are you planning to update your comscore numbers at http://www.catb.org/esr/comscore? I know you had some doubts about their validity, but they’re still the best measure readily available. You have no data posted past June 2012.
@Cathy
Android has more than 70% global market share in smartphones.
Linux world domination indeed.
http://m.linuxjournal.com/article/3676
I have seen the original article that presented Linus’ talk ( or one of them). I have never been able to find the link again. Can anyone help us to that link?
@LS:
That’s called “Toning” the line.
It works ok if you’ve got a few cables. It works for bugger all when you’ve got 100 cables. It’s f*ing useless if you’re in a raised floor environment with power and network all mixed in.
@patrioticduo:
> My two cents taken from decades of experience…
> Assumptions for Human Activity in Data Centers and Closets
> 1) Always assume that some uncaring human will come into your data center and totally disregards your patching and cabling identification system.
Under stress this will be you.
> 3) Always assume that an emergency will come along that will cancel all of your
> carefully crafted rules for patching and cable identification. Always assume that
> no one will go back and clean up after the emergency has passed. Emergencies
> happen several times a year.
Somewhere between 50 and 300 times a year, depending on scale, scope and who you support.
> 4) Always assume that staff turnover will nullify all of your carefully thought out rules
> and standards for patching and cable identification.
Once I’m gone, it’s their network and their job. If I’m still there.
> 6) Always assume that someone with a pair of side cutters trying to snip a cable tie
> will result in damaged patch cables (especially fiber).
That is someone who needs a career change, as is the nitwit that used the cable tie to begin with.
> 7) The longer a cable run is, the less likely it will be labelled correctly at both ends.
IME the opposite is true. The longer the cable is the less likely it is to get moved/re-used.
> Pragmatic Rules for Data Closets
> 1) No side cutters or other sharp implements are permitted in the data center and data closets.
Bugger that mate. No one who can’t *use* dikes or other sharp implements (second most dangerous thing in the world is a programmer with a screwdriver) is allowed anywhere near a data cable.
> 3) Patching cables shall be any color. No functional significance shall be attached to the color of any patch cable. Mix and match cable colors randomly so that physical tracing is easier.
I think this largely depends on the size and complexity of your network. If it’s relatively simple–inside, outside, management, each attaching to a different switch/router set–then attaching functional significance to them is manageable and can reduce errors.
If you’ve got dozens of vlans all on the same set of switches, then you’re in a management nightmare, and you’re better off not making assumptions about the colors.
> 4) No cable shall ever be labelled. If you encounter a cable that is labelled, assume that the label is wrong. Never remove a label on a cable. It may be useful to someone else.
The last job I worked had an insane number of interconnected systems. Massive, multiple networks stretching across an area probably 3/4s of a mile long and 1/2 that wide. Systems installed, run and maintained by folks on multiple continents, and often the first line responders for problems were, well, the kinds of folks you’d expect to find working the midnight shift at such a place.
Many of the cables in this place weren’t traditional networking cables. Some were “10bT” cables running entirely different signals (in some case analog) max length Ethernet runs were not uncommon, often under the floor and into different data centers.
Some of these systems had been up and running in one place or another for decades. In 2010 there was still a Sun Sparc 5 in the rack. No, not an Ultra 5. A *5*. The are still running and using VMS.
The only option in cases like this is to rigorously enforce labeling. The scheme doesn’t *really* matter as long as it contains the location of both ends and a serial number.
> 5) Always maintain accurate descriptions in the switch and router port configurations. Develop scripts to do the job for you. Develop scripts that audit the descriptions.
Yes. Python + Expect is *awesome* for this.
I wish I could have brought that code out with me.
> 6) Use network management tools to audit switch and router ports that map MAC address to IP and to reverse DNS lookups.
Handing out IP addresses via DHCP is a good way to solve this.
> 7) Always use automated scripts to maintain an accurate and up to date reverse
> lookup DNS for all interfaces with IP addresses (layer 3/router interfaces).
> 8) Maintain your own accurate network diagrams.
Should be a way to generate automated diagrams and diff them day to day.
> 9) All patching racks (including switches or patches) shall be 24? wide.
> No 19? racks are permitted for patch panels!
Not always doable. Sometimes regulations from up above prevent this. In that case vertical mounting of switches can help.
> 11) Use overhead cable tray/ladder for all inter cabinet cabling.
Amen. Only power should be run under the floor. And it SHOULD be run under the floor if possible.
@ Sigivald:
> Also, the other helpful policy that made easily enforced for my personal network is
> “if a cable is at all dodgy, throw it out“.)
About a decade ago I was involved in moving a .com site from one datacenter to another. In the first datacenter someone had pulled a couple of suspect FC cables off a cheap SAN they had, and set them to the side.
When they moved it, the suspect cables back in and put them on the SAN at the new site.
I told them over and over, but no, they got the SAN vendor out there, broke a motherboard on one of the heads and spent almost a month troubleshooting the problem.
Bad cables.
Do not “throw it out”. Cut it up and throw it out.
>each new cable gets a label at both ends.
…as I was saying, I once became a system administrator at a site with about 20 feet of racks of hubs, routers, and Digiboard ports with wiring like that.
After spending a weekend straightening up the wiring, I started cutting off the ends of any alien wires that showed up without a proper tag on each end. The inter-departmental whining and raging was impressive, particularly after I tossed a handful of cut-off ends onto the conference table at a high-level blamestorming session…
When an organization is small and connectivity is a convenience, you can get away with haphazard stuff on the network, but when it’s a >4,500 employee business, downtime costs money, and tracing mystery wires is an absolute waste of time.
Simpler method, via cable removal. Requires a spreadsheet as well as a diagram, the diagram has the port ID assignments, the spreasheet has the port matching
1. Create thorough diagram of rack, assign ID to each port on each device
2. Remove 1 cable end, enter port ID on new row on spreadsheet
3. remove other end of cable, enter Port ID in second cell of spreadsheet
4. Repeat steps 2-3 for all other cables.
5. Sanity check diagram and spreadsheet for network loops.
6. label new cable with port ID’s, starting with first row on spreadsheet. Preferably with both ports labelled at each end.
7. Plug cable into assigned ports
8. repeat steps 6 & 7 until all cables plugged in.
9. Zip-tie/velcro-tie bundles as appropriate
@Adam Maas that’s probably better than my idea using labels for the ‘removal trace’ phase, simply because having the labels tempts you to reuse them as your permanent labeling scheme – and to reuse the same cables for each connection even if they are inappropriate color or length.
One downside is that you have less ability to switch what cable you are working on removing in the middle (say, if you identify one that is the “linchpin” of the tangle), and you’re not able to do things like unplugging the whole mess and untangling it on the table.
But many more iPhones sold in Q4 2012, and they still have a much more vibrant app ecosystem. Sure, there’s a bigger open source scene on Android — but what does that mean to end users, really? Tethering apps — and using those is probably a felony.
Most of the schemes here are workable, if you assume a sane work environment. That does not describe any production network I have worked in, in twenty years of network maintenance.
If you try to be systematic, management (sometimes, that has been me) starts using words like “responsive”. If you scramble around, it looks like you are doing something.
My home network is, if I do say so myself, gorgeous. But I only have 12 wired devices, and even having a patch closet in a personal residence is a bit exotic, I think.
You want to see a real mess, look at any analogue phone system. I’m currently dealing with one, and every time I think about it, H. P. Lovecraft comes to mind.
> But many more iPhones sold in Q4 2012
… in the US. It’s actually interesting to see how the different platforms fare in different markets. For some reason, Windows Phone seems to be doing significantly better in Italy than anywhere else at the moment.
> Tethering apps — and using those is probably a felony.
Funny you should mention that. I’m installing Fedora on a family member’s laptop and pulling all the updates and packages that weren’t on the live USB in through my phone over wifi. I’ll probably have used over 1 GB before I’m done. Tethering is generally not disabled on phones sold in Finland, not even carrier ones. My phone was a non-carrier one in the first place and it now runs CyanogenMod, so Android’s built-in tethering always worked on it. The data plan is 9.90 euro per month for unlimited 2 Mbit/s, and unlimited means unlimited (13.90 euro for up to 21 Mbit/s). The nominal speed is a maximum, not a guarantee, and I don’t seem to get up to 2 Mbit very often at my home, which is in the center of a city and probably in the middle of a busy network. Here at said relative’s house in a smaller town and late at night, the speed is consistently between 2 and 2.5 Mbit/s. It actually exceeds the advertised speed for long periods. The contract has some kind of a clause about tethering, but it seems that nobody knows it’s there and the carrier doesn’t care. On the contrary, they seem to advertise tethering, to some extent.
@Mikko “they seem to advertise tethering, to some extent” – they may actually be advertising a more expensive plan you can buy that allows it.
Mikko, I don’t know what it’s like in Finland, but European telecoms carriers tend to be on the sane side.
In the USA, tethering is often an expensive add-on to an existing data plan. You use the carrier’s Authorized Tethering App, and the carrier automatically tacks on a surcharge. There are ways around this like the WiFi Tether or AziLink apps on Android (the latter of which doesn’t even require rooting), but since you are getting for free what the carrier wants you to pay for, there’s a fat probability that using these apps to avoid carrier surcharges count as unauthorized access to protected computers, and hence wire fraud, under the Computer Fraud and Abuse Act.
Think that reading of the law is silly and extreme? Yeah, so did Aaron Swartz.
> they may actually be advertising a more expensive plan you can buy that allows it.
No, I actually checked the terms of the contracts, and they’re all the same. They do have a clause forbidding tethering of “multiple devices”, and there’s no extra service that allows it. The ad copy regarding additional data plans for telephony contracts is worded ambiguously. They say e.g. “use your phone to connect to the internet”, without mentioning that a laptop should not be involved. The contract is the same for a 3G USB modem (I have one), i.e. no tethering. Yet the retail outlets of the carrier actually sell wireless routers where you can plug in the USB modem to the router for internet access, and they sell the router and modem as a package with the same contract as the USB modem alone.
As far as I can tell, the tethering clause is a dead letter. Everybody does it and the carrier doesn’t care. There’s not much point anyway, as e.g. watching videos online on the phone can consume pretty much any amount of data capacity.
I found a discussion thread from 2011 on tethering on the website of my carrier (they have a forum). Apparently the Finnish carriers (three major ones and a bunch of niche operators) collectively changed the standard part of their contract text in 2011 to include the clause forbidding tethering. This is more about forbidding what they call excessive load on the network and using more than one IPv4 address per SIM card. I guess in some cases DHCP requests from a home network could possibly be routed to the carrier and someone might theoretically get more than their share of public addresses. None of the carriers try to charge extra for tethering or disable it on their phones, and at least two sell wireless routers with USB modems with the standard contract. There was a comment in the thread from a company rep, saying only that the carrier reserves the right to shape and prioritize traffic. He didn’t answer several direct and colorful questions about whether tethering a handful of devices at home is forbidden. Another carrier’s rep has explicitly confirmed that it’s allowed on their network (they sell a product that does exactly that), even though they, too, have the clause in the contract.
Then there’s the law, which in Finland says that a carrier is not allowed to deny connecting compliant devices to the network. So forbidding tethering might actually be illegal here, never mind that there’s no reliable way for the carrier to enforce the prohibition anyway.
Some interesting smartphone wars material brewing.
For the folks talking about tethering:
http://bgr.com/2013/01/23/verizon-shared-data-plans-analysis-303240/?utm_source=featuredposts-widget-main&utm_medium=home
Seems people are starting to notice that, even though the cost to move bits is going down, the price people are being charged to have their bits moved is going up. Hmmmm.
http://phandroid.com/2013/01/25/htc-mini-video/
In case it wasn’t obvious to everyone yet, the ‘smartphone’ form factor no longer needs to be constrained to be a ‘phone’, it’s really just a little computing pod with interface components somehow connected.
Some misc interesting links:
http://bgr.com/2013/01/26/mobile-industry-analysis-306634/?utm_source=trending-widget&utm_medium=home
http://bgr.com/2013/01/24/apple-google-rivalry-analysis-304928/?utm_source=trending-widget&utm_medium=home
http://bgr.com/2013/01/24/smartphone-unlocking-illegal-303627/?utm_source=trending-widget&utm_medium=home
Question #22 demonstrates that randomly intersecting lines can create a triangular number of intertwined areas, and cabling extends to 3D.
@JustSaying – but cables don’t intersect, they’re not lines, and AIUI the 3D extension of the principle would require planes.
@Random832 agreed, but if we conceptualize from the 2D projection, the orthogonality of the additional degree-of-freedom of the 3rd dimension is mitigated because the ends of the cables of two intersection projections often do not lie on non-intersecting planes in 3D. This provides entanglement opportunities. The curving of a pair of lines allows more than one intersection, increasing the potential for entanglement. A probabilistic model model for the minimum number of 3D cables to create the maximum probable number of entanglements would have to consider the flexibility of the cables. My comment was intending some intuitive (and deterministic) sense of exponential rate of growth of entanglement w.r.t. to the number of cables.
One more link on the smartphone wars:
http://ben-evans.com/benedictevans/2013/1/17/samsungs-china-problem
That one suggest that the largest and most rapidly growing part of the Android user base in China is cheap no-name phones that likely have no Google apps on them. The data is apparently from the server logs of the Baidu search engine. Western analysts seem to be concluding that this is spells some sort of a disaster for Google or Samsung. I don’t see why it should. Isn’t lots and lots of cheap, generic phones exactly what one would expect to happen with a freely-licensed, de facto standard OS? I wouldn’t expect the majority of cheap PCs in China to have the logo of a western or Korean company on them either, and since Google’s apps can be left out, of course they will be.
@William O. B’Livion –
> 9) All patching racks (including switches or patches) shall be 24? wide.
> No 19? racks are permitted for patch panels!
>> Not always doable. Sometimes regulations from up above prevent this. In that case vertical mounting of switches can help.
I have a book full of photos that I use to convince senior management that 24″ wide cabinets are an absolute must for patching. It can be a real challenge to convince SM that they should do it. But it’s worth fighting for.
> 11) Use overhead cable tray/ladder for all inter cabinet cabling.
>> Amen. Only power should be run under the floor. And it SHOULD be run under the floor if possible.
I advocate for power in overhead cable ladders for two reasons.
1) A flood (from above or below) won’t jeopardize your power. I’ve seen water raining down from above and not cause problems to correctly installed water proofed twistlocks. Yes, most overhead installations will use standard indoor fixtures. For “my” data centers, they use water proofed. It is truly amazing how much water can come out of a broken 2 inch sprinkler feed. Better to have the electrical wiring up in the air rather than sitting in pools of water.
2) The risk of electrical fire is too high when placing your electrical under raised floors. What is seen is usually maintained to a far superior standard than those things that are hidden from easy eyeballing. The ability to visually inspect all power sitting above your head beats the heck out of lifting tiles.
What is your rationale for “SHOULD” run power under the floor?
>Better to have the electrical wiring up in the air rather than sitting in pools of water.
I concur. Though possibly my opinion should only weigh lightly, because I’ve never been responsible for a cabling job as large as you describe.
@JustSaying “The curving of a pair of lines allows more than one intersection, increasing the potential for entanglement. ”
You’ve missed the point of “and they don’t intersect”. Cables are solid objects, so they _cannot_ intersect, so clearly intersections are a poor model for tangled-up cables.
Anyway, I suspect it’s linear past a certain point, since each “tangle” takes up a minimum amount of volume, and the volume of the whole mess grows linearly with the number of cables of the same length.
…the other reason your line intersections are a poor model being because they can be arbitrarily close together.
Still trying desperately to get this thread as far off-topic as a few of the others are: CyanogenMod seems to be growing at a very healthy pace. It passed one million installs a year ago in January 2012, two million in late May 2012, and stands currently at 3.6 million. That’s about 2.6 million added over the past 12 months, whereas the first million took several years. They have an opt-in counting based on hashed IMEI numbers, so the counted installs are genuinely unique, and they remove those that don’t send in a ping for 90 days. See
http://www.androidpolice.com/2012/05/28/cyanogenmod-has-been-installed-over-2-million-times-doubles-install-numbers-since-january/
http://stats.cyanogenmod.com/
@Random832
> You’ve missed the point of “and they don’t intersect”
How do you know I missed your point? Did I write everything that was in my mind?
> so clearly intersections are a poor model for tangled-up cables
I specifically wrote that intersection is not a model for entanglement.
> the volume of the whole mess grows linearly with the number of cables of the same length
The less slow the volume grows, the more potential for entanglement.
I wrote about giving an “intuitive sense” for exponential blow-up of entanglement opportunities w.r.t. to the number of cables. Your point about volume is missing the point of what causes entanglement. Intersection on the 2D projection with limited volume leads to entanglement opportunities.
Correction. The less slow the volume grows, the more potential for _density_ of entanglement. Longer cables and more volume may provide more potential for entanglements, but this misses the point of why entanglement becomes a dense untraceable mess.
What you need is wire managers and new patch cords of 2 different lengths. You can use a ptouch to label one side of the patch cord and unplug it and let it hang. Once all the cords are tagged you install the wire managers in the rack. Then one by one unplug the old and put the new in it’s place. Very simple. Of course this needs to be done after hours. We do jobs like this all the time.
http://www.networkcabingworld.com
I agree that it’s so frustrating when the cable wires get messed up. You have invented a great algorithm to reduce such kind of mess. Well done!