as a corollary to this, i label home theater and audio cables differently because the primary driver is different. the normal issue in audio is someone (or something) pulls a cable out and you want to restore the connection. so i label each end with the port it plugs into. that way the high frequency case is optimised.
On Feb 7, 2013, at 11:36 AM, Tom Limoncelli wrote: > Fundamentally you are asking "What is the purpose of a cable label?" > If you can answer this question then the labeling scheme becomes > self-evident. > > 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. The minimum solution is to start numbering cables 1, > 2, 3, 4, 5, and so on. Label each end with the same number. > > There are other things that COULD be the purpose of the cable labels. > I'll list the 2 that come to mind. I think these are POTENTIAL > purposes but that they solve problems that are solved better using > other methods. > > 1. What is the length, type, and so on. (i.e. Cat6 vs Cat5; 1m vs 6m vs > 10m). > 2. What is connected to each end? (i.e. label each end with "router > port 5 to host123") > > I would argue that (1) is best done via cable color. > > I would argue that (2) is an inventory nightmare: it creates more work > than saves. It also solves a problem that doesn't exist. How often > have you walked to a computer room to see what is connected to what? > Generally you FIRST check the router "cam" table to see the ground > truth. That answers your question 99% of the time. You only > physically go to the computer room the remaining 1% of the time, and > in this case you want to verify what you think you already know, which > having a cable number on each end is all you need. In the 1% of the > time that THAT is not successful, you end up tracing the cable or just > trying a different cable. > > On the other hand, this 1% of 1% can be solved by having each end > labeled with "routerX port abc:23 connected to host123:eth1". > However, maintaining such labels is a huge amount of labor for > something that is extremely rare. Without such detailed labels you'd > trace the cable (or more likely try a different cable to see if that > solves the problem). With such detailed labels you create an > inventory nightmare. > > Early in my career I tried labeling cables with the name of the two > ports on each end. Within a few months the cable labeled "host123" > was re-used to connect host "host456" and rather than updating the > label we just "lived with it". It was a mess. We eventually just > started labeling each end with a unique number. Cables could be > reused easily. > > If you agree that the only purpose of a label is "to accelerate > tracing" then it also means you do not need to keep a database of what > each cable is for. You only need to store a single integer: What is > the highest number used so far? > > If you do choose to keep a database, it will be out of date within > days. Even if you make it extremely easy to update, mistakes will > happen. Then you'll be tempted to do a yearly database audit, which > is a lot of work. Why would you create more work for yourself? > Instead, a database that doesn't exist has no errors. > > As a side note, this issue seems to be magnified because of the choice > to have every machine connected all the way to a single central > switch. That is a best practice from years ago that is no longer > very popular. The current best practice is to have a switch in each > rack (a "TOR" or "Top Of Rack" switch) and then have all the TORs > connect to a main switch (the "core" switch). That way you have very > short cable runs from the machines to the TORs; so short you might not > even need to label them. The only long cable runs are from the TORs > to the core switch. These are static and a simple integer-based > labeling scheme is fine. I'm sure you have reasons for not going with > a flat network instead, but this is one of the trade-offs to be > considered. > > Tom > -- > http://EverythingSysadmin.com -- my blog > http://www.TomOnTime.com -- my videos > _______________________________________________ > Tech mailing list > Tech@lists.lopsa.org > https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech > This list provided by the League of Professional System Administrators > http://lopsa.org/ ----------------------- Andrew Hume 623-551-2845 (VO and best) 973-236-2014 (NJ) and...@research.att.com
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
