For When You Can't Have The Real Thing
[ start | index | login ]
start > Cable Labeling

Cable Labeling

Created by dave. Last edited by dave, 5 years and 300 days ago. Viewed 2,905 times. #2
[diff] [history] [edit] [rdf]
labels
attachments
(13 February 2013)

An incomplete thought.

The Internet Says:

Tom Limoncelli (who knows more than a few things) comments on the labeling of cables. >>He says:

I believe the purpose of cable labels is to accelerate tracing. That is, when you need to know "where the other end" having labels means you can read the label instead of physically tracing the cable. If a cable has the same tag on both ends, if you find one end, you can find the other end.

While this is a fine theory, I think we can do better.

The Problem

A lot of people look at cable labeling and see only the problems. Mr. Limoncelli himself notes a few, for example:

  • labeling with the port or system of the far end is a problem because the cable labelled "host123" will get plugged into "host456" but not relabeled and everyone will just live with it;
  • if you have a database, even if it is easy to keep updated, it will fall out of date
The thing of it is, none of these objections are the actual problem.

The actual problem usually is: what computer or switch port is at the other end of this cable?

Cable labels are a means to an end, that is, to identify the other end of some wire that you happen to transfer your interest to.

A Digression

We have a database.

We have a sharepoint site where computers and switches and ports are identified, then we link those objects together with a cable object. The cable object also has a (mostly) integer identifier, which is applied to both ends of the cable. So you have a table which should tell you what is plugged into where and what the connective media is.

And every six months or so, we audit it. Which in practice means that I grab one of the helpdesk guys and we go into the server room with a print-out of the database and compare what is in the database to, as I refer to it, reality, and fix the database accordingly. It takes a couple of hours because our installation is relatively small. If it gets much bigger then I'll probably break it up and audit half of it every two months or something.

A database like this is no different from any other piece of documentation. It is only as right and as useful as you make the effort to make it.

It is like backups. Backups are not backups until you prove you can restore from them. Similarly, a database tracking network connectivity is only useful if you can demonstrate that it closely approximates what is actually in your server room.

Solving The Real Problem

Here's the thing: even though numbering cables is a good idea, and tracking those cables is a good thing, both should be considered a fall-back position. At the end of the day, you almost never care about a cable. You care about what is plugged in to either end of the cable.

And this is my copious-spare-time-project for the last million years. See, switches know what is plugged into them. (Or at least what is plugged into the other end of the wire that is plugged into it. Try to stay with me here.) And through SNMP, we can ask switches what is plugged into them. So live equipment should be findable in the network through some scripting work.

Say, for example:

[dave@store01 ~]$ time switchwalk 00:02:A5:EF:7C:7F
Core
sa4-38: port 549(ge-0/0/36.0)
Edge
sa2-40: port 560(ge-0/0/47.0)
sa3-41: port 558(ge-0/0/45.0)
sa4-42: port 27(Slot0/27)
sa5-41: port 560(ge-0/0/47.0)

real 0m47.856s user 0m13.963s sys 0m0.731s

Which tells me that right now the computer with that MAC address in row A rack 3 because:

  • 0/0/47 is always an uplink port
  • Slot0/27 is an uplink port
  • this computer isn't important enough to be directly connected to the core switch
  • sa3-41 is showing the MAC on port 0/0/45
  • sa3-41 is row A, rack 3.
There's still room for improvement. Because most of the time I don't know I care about that MAC address. I generally care about an IP, or a DNS name. The script can and should be extended to translate names into IPs, and to query router ARP tables to translate IPs into MACs. And the whole thing generalized so that others can share in using this tool without having to deal with my ugly, ugly perl code.

And recently I've learned about LLDP which most of my switches support. I'm hoping that with some research, I can use LLDP (hopefully extracted via SNMP) to draw connectivity maps between my switches in real time.

All that aside, THIS is how I think one should go about solving the problem: Solve the problem. Don't worry about solving problems of the symptoms.

no comments | post comment
This is a collection of techical information, much of it learned the hard way. Consider it a lab book or a /info directory. I doubt much of it will be of use to anyone else.

Useful:


snipsnap.org | Copyright 2000-2002 Matthias L. Jugel and Stephan J. Schmidt