Recently in Category Network Automation > Philosophy

Managing patch cables

| | Comments (4)

A colleague recently asked if I had any recommendations for software to manage lists of patch cables and ports, and I think my answer might have surprised him...

There are a variety of Visio add-ons and standalone tools available, and while I've often found tools like that useful for planning initial installations, they haven't been so useful for ongoing maintenance. The problem is, whatever documentation you create gets out date pretty quickly, unless you're very disciplined about it, which almost nobody is...

Instead, I've found it most useful to simply follow good cable management practices:

  • Labelling both ends of all cables with a unique identifier, but not what it's currently used for (because that will inevitably change, and the only thing worse than no label is an incorrect one)
  • Always taking the time to dress cables in neatly, rather than draping them haphazardly.
  • Removing cables when you disconnect one end, rather than just leaving them hanging.
  • Using easy-to-change physical cable management systems, like clips and velcro, rather than hard-to-change systems like cable ties, so that it's easy to "do it right" (see the above 2 points).
  • Using cables of just the right length, rather than too-long cables that you then somehow have to manage the excess for (or too-short cables with a patch hidden somewhere inaccessible in the middle of the run). This means keeping a selection of cables available in various lengths, so that the right one is available when you need it.
  • Having and religiously following a color coding scheme.

As usual, Limoncelli and Hogan offer good advice on this topic in their indispensable book The Practice of System and Network Administration (chapter 17, especially sections 17.1.7 and 17.1.8).


| | Comments (1)

Steve Traugott at Infrastructures.ORG says:

Most IT organizations still install and maintain computers the same way the automotive industry built cars in the early 1900's: An individual craftsman manually manipulates a machine into being, and manually maintains it afterward. This is expensive. The automotive industry discovered first mass production, then mass customization using standard tooling.

Indeed... Most network devices are still configured by hand and manually maintained, with all of the attendant problems (typos, inconsistency of configuration, difficulty making common changes to many systems in parallel, etc.). I'm very interested in taking the same principles that Steve has been codifying and espousing for systems, and applying them to networks.

For the last several years, Steve has been driving this effort, including creating and hosting the Infrastructures mailing list. Their goal is to develop and discuss the

... standards and practices [that] are the standarized tooling needed for mass customization within IT. This tooling enables:
  • Scalable, flexible, and rapid deployments and changes
  • Cost effective, timely return on IT investment
  • Low labor headcount
  • Secure, trustworthy computing environments
  • Reliable enterprise infrastructures

From a discussion today with someone who wishes to remain anonymous (emphasis mine):

I think you'll find most of these [network management tools] are sort of a RANCID outgrowth - config monitoring systems + other functions which differ between all the vendors, although there is growth towards an approach of establishing a baseline and then creating and enforcing compliance rules/templates across the network. I think we're a bit cautious of using software written by someone else that writes to a device (all of the [network management tools we were discussing] do, but those functions aren't widely used), opting instead for tell me what's different and I'll change it myself. As more of these tools become well known and stable, and with more people using automated provisioning tools which do network device writes, that attitude will gradually ease off. But I believe many people are a bit scared of auto-enforcing features when it comes to routers/switches/etc., and maybe that explains a bit of what's lacking in comparison to sysadmin tools.

I agree with this assessment, but personally, I'm more worried about somebody fat-fingering a manual configuration. Another concern is that the configurations just getting too complex to maintain manually, particularly things like packet filtering ACLs, BGP policy statements, and so forth. In a lot of ways, it's like the old arguments about programming in assembly language versus higher-level languages.

October 2006: Monthly Archives


About this Archive Archives

This page is a archive of recent entries in the Philosophy category.

Information is the previous category.

Products is the next category.

Find recent content on the main index or look in the archives to find all content.

Mailing List

Creative Commons License
This weblog is licensed under a Creative Commons License.
Powered by Movable Type 4.12