[OT] Labeling wires

[Jerry Feldman]

At HP we used color coding also.
But hwere, the situation is different. I have 2 24 slot Gbit stacked
switches in 1 rack section. We own the switches. The rack is shared with
all the other companies in the Regus office. I need to know what cable
goes to what wall slot. Our wall slots each have 2 CAT5E connections.
The patch panel is several rack frames away from the switches. I can
only control the cables that connect to the 2 offices we lease.
Currently nearly all the cables are yellow (ours and Regus). The cable
that goes from the switch to our rack is a different color. The new
office we are leasing has 10 (or so) wall slots. Initially, I'll
probably wire only 1 jack per slot. A while back when we got our rack we
did buy some cable and made sure it was a different color than the ones
Regus uses. So, it comes down to we need to know what cable goes with
what wall slot. And, from the wall slot patch panel, which cables go to
our switch.  The color code will help to identify what colors belong to
us. Every once in a while I might need to connect a wall slot to either
a cable modem or directly ro Regus' horrible network. If we had control
of what and who goes into the computer room, it would be easier, but
there is the Regus office staff, and sometimes IT guys working with
companies in here.

Actually, Regus has a worse problem because most everyone is connected
to their switches, and they have to control things by their switch port.

On 09/21/2010 01:03 PM, Rich Braun wrote:
> Inspired by the nature of the business where I was working (up until *v=
ery*
> recently), I came up with the concept of a "rainbow flag" cable-colorin=
g
> scheme to replace past failed cable-labeling strategies.
>
> What I did was assign a primary color to each Ethernet switch, and (oth=
er than
> the uplinks) *all* cables connected into each switch are all the same c=
olor.
>
> Most of the servers had 5 connections:  four on the motherboard (all th=
e
> latest servers from Dell/HP have 4 RJ45 jacks) plus a KVM for the out-o=
f-band
> management (DRAC, ILO, or whatever it is Super Micro calls theirs).
>
> One other major change about my latest design was that I discarded patc=
h
> panels.  Servers are directly connected to the switch, without going th=
rough a
> patch panel.
>
> By doing this, I eliminated practically all the labor costs of tracing =
cables.
>  You *know* which switch each server port is connected to, based on pro=
ximity
> and color coding.
>
> My color coding was this:  internal LAN was red and blue (red=3Dprimary=
,
> blue=3Dalternate -- Ethernet channel bonding), DMZ was orange and purpl=
e (again,
> a primary and backup), console current-generation out-of-band net was y=
ellow,
> old-fashioned (Raritan) out-of-band KVM network was green, and inter-sw=
itch
> connections were black and white.
>
> With 200 servers in a cluster you can easily have 1500 cables.  You'll =
wind up
> with twice that many if you use patch panels (vs. mounting the Ethernet=

> switches in racks near the servers).  My color-coding method reduced
> maintenance effort considerably, and eliminated all but one failure mod=
e:=20
> once in a while someone would cross-link two same-color switches on a p=
ort
> other than the designated uplinks.  If you don't lock down your spannin=
g-tree
> configuration, such cross-linking will create a nasty packet-storm loop=
=2E
>
> The nicest thing about this approach was the training.  It's really eas=
y to
> train a new tech how to rack a server by this color-coding strategy, wh=
ich can
> also be used on the power side (three colors for the 3 phases of utilit=
y
> power, and two other colors for A-side and B-side UPS power--alas the p=
ower
> cables all come in black, vs. Ethernet cables which come in about 10 di=
fferent
> colors, so you still have to use tape to do the power color-coding.)
>
> -rich
>
> _______________________________________________
> Discuss mailing list
> Discuss-mNDKBlG2WHs at public.gmane.org
> http://lists.blu.org/mailman/listinfo/discuss
>
>  =20


--=20
Jerry Feldman <gaf-mNDKBlG2WHs at public.gmane.org>
Boston Linux and Unix
PGP key id: 537C5846
PGP Key fingerprint: 3D1B 8377 A3C0 A5F2 ECBB  CA3B 4607 4319 537C 5846