Coloured UTP cables considered harmful

The rainbow hurts my eyes

One colour for links to client computers, another colour for links to servers, another colour for phones. Sounds like a wonderfully organised network.

Don't do it.

The reason is stocking. You want a good stock of UTP cables. Ten or twenty in lengths from 0.5m to 3m in every increment available (typically 0.5m), then 5m, 10m, 15m.

It is much more important to use the correct length cable than it is to have some colour scheme. The more colours you have, the less stock of each colour in all the lengths you will carry.

Why is it important? Cable control. If you stock every length the average slack you need to dispose of in a cabinet is 25cm, the worst case is 49cm. If you are missing just one size the average becomes 75cm and the worst case becomes 149cm, both of which are a significant amount of cable to route out of the way. You do that more than one or twice then your cabinet is a cabling disaster zone. You'll never be able to remove a cable easily, which means you won't, which will snowball over the years.

Consider one exception: cross-over cables. Make these some non-red noticeable colour (red has a special meaning and you shouldn't be using it in patch cabinets). I use pink. You need one length: 0.5m. You need one type: the "gigabit ethernet four-pair crossover". To use the cable plug it into the interface of the equipment, attach a Cat6 through-connector, and then cable using your typical patch leads. Why as long as 0.5m? Because that is enough to clear the equipment and place the through-connector outside of the equipment's own cable control.

Coloured patch leads indicate that you lack sufficient records of your cabling plant and sufficient labelling to audit those records against the plant. If you feel the need for coloured cabling "to prevent error" then I suggest you look to improving your record-keeping.

RS-232 over a RJ-45 connector

Cisco 2500-series RJ45

There used to be a variety of specifications for presenting a RS-232 signal on a RJ-45 socket. There is one predominant survivor: the pinout of the Aux socket of the cisco Systems 2500-series routers (from back when Cisco had no leading capital letter, being short for San Francisco).

The pinout of the socket is:

Pin	Name	Description (direction)
1	CTS	Clear to send (output)
2	DTR	Data terminal ready (output)
3	TxD	Transmit data (output)
4	Gnd	Signal ground
5	Gnd	Signal ground
6	RxD	Receive data (input)
7	DSR	Data set ready (input)
8	RTS	Request to send (input)

RTS and TxD are not valid until DTR is asserted: the device might be off and they may be floating. RTS indicates that there is enough buffer to receive more data. TxD is used to transmit data. Data is not sent until CTS is asserted. RxD and CTS are not valid until DSR is asserted.

The cabling is straightforward:

1 CTS ---- RTS 8
2 DTR ---- DSR 7
3 TxD ---- RxD 6
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 4
6 RxD ---- TxD 3
7 DSR ---- DTR 2
8 RTS ---- CTS 1

You can see that the presentation of signals to pins has been carefully thought out. By flipping over the RJ-45 plug at one end when crimping the RJ-45 patch lead we can connect one Aux interface to another Aux interface. Cisco call this transposition a "rolled" UTP cable.

This trick has one downside. You'll recall that a 568B UTP cable twists the wires 1,2; 3,6; 4,5; 7,8 and a 568A UTP cable twists the wires 1,2; 3,6; 4,5; 7,8. That is, the TxD and RxD signals are not carried on the same pair as the Gnd. That is going to affect performance. I think that is acceptable: if you want performance on unshielded twisted pair then that is why RS-422 exists.

The 2500-series of devices used a speed of 9600 bits per second. Each ASCII character used 1 start bit-time, 8 data bits, no parity bit, and 2 stop bit-times. Later devices used only 1 stop bit-times for greater compatibility with common settings.

The command line of early devices would clear the top bit of received ASCII characters, allowing 7 data bits and either odd or even parity to be understood by the command processor (the screen would show gibberish, but from a 7E1 terminal you could blindly type the commands to set 7E1 for the terminal setting and the display would then work. Although a useful hack at the time, today it means that international characters are best avoided when using the Cisco IOS command line.

Console ports do not do handshaking. They connect CTS to RTS. They pull up DTR to asserted as long as the chassis is powered. They ignore DSR.

IBM PC/AT DB-9

There is of course another popular presentation of RS-232 signals: the D-9 plug of a IBM PC/AT. The usual RS-232 connector is a D-25 socket, unfortunately the IBM PC used that for the Centronics parallel connector for a printer (the usual Centronics connector was too side for the IBM PC interface slots). So the IBM PC used a D-25 plug for the RS-232 connector to avoid cabling errors. The IBM PC/AT updated that to use a D-9 plug, allowing the serial and parallel interfaces to be presented using one slot (the "Super I/O" cards).

The pinout of the IBM PC/AT D-9 connector is:

Pin	Name	Description (direction)
1	DCD	Data carrier detect (input)
2	RxD	Receive data (input)
3	TxD	Transmit data (output)
4	DTR	Data terminal ready (output)
5	Gnd	Signal ground
6	DSR	Data set ready (input)
7	RTS	Request to send (output)
8	CTS	Clear to send (input)
9	RI	Ring indicator (input)

IBM PC to Cisco console

So how do we interface these two? There are obviously two choices: allowing for a standard patch lead and allowing for a rolled patch lead. Cisco chose to allow for a rolled patch lead. Thus a RB-9/RJ-45 backshell, a rolled cable, and another RB-9/RJ-45 backshell could be used to interconnect two IBM PC/AT.

1 CTS ---- CTS 8 ---- RTS 7
2 DTR ---- DSR 7 ---- DSR 4
3 TxD ---- RxD 6 ---- RxD 3
4 Gnd ---- Gnd 5 ---- Gnd 5
5 Gnd ---- Gnd 4 ---- Gnd 5
6 RxD ---- TxD 3 ---- TxD 2
7 DSR ---- DTR 2 ---- DTR 6
8 RTS ---- RTS 1 ---- CTS 8
                 nc-- DCD 1
                 nc-- RI  9

You can see that for this cable to work the application has to be configured to ignore Data Carrier Detect. If you make your own RJ45/DB9 backshells then you may wish to crimp DCD(1) and DSR(4) on the DB9 connector to DSR(7) on the RJ45 connector.

Avoiding the rolled cable

The rolled cable is key to a flexible system for interconnecting RS-232 devices. However the importance of RS-232 has faded. About the only thing it is used for these days is for the console of networking and embedded devices. Flexibility for other applications doesn't have the attraction it once did.

For connecting a computer to a console the rolled cable is painful: using a standard patch lead would be far superior. If you needed a longer cable you could simply use one from the stock of standard UTP cables.

This is the approach taken by Juniper Networks. They provide a backshell and a standard UTP cable. The pinout of the backshell is:

1 CTS ---- RTS 7
2 DTR ---- DSR 4
3 TxD ---- RxD 3
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 5
6 RxD ---- TxD 2
7 DSR ---- DTR 6
8 RTS ---- CTS 8
      nc-- DCD 1
      nc-- RI  9

Again, if I was constructing this myself I would pull up DCD if the far end is available. That would allow lines to clear down properly if the far end powers down.

1 CTS ---- RTS 7
2 DTR --+- DSR 4
        +- DCD 1
3 TxD ---- RxD 3
4 Gnd ---- Gnd 5
5 Gnd ---- Gnd 5
6 RxD ---- TxD 2
7 DSR ---- DTR 6
8 RTS ---- CTS 8
      nc-- RI  9

The USB console

Computers no longer come with RS-232 ports. Network engineers carry a RS-232/USB dongle. So why not provide a USB B connector which carries a Data Class Interface USB profile. Cisco Systems use a Mini B connector. This will appear as a /dev/ttyUSB… if connected to a Linux system.

I have yet to try it, but there shouldn't be anything preventing plugging a whole switch stack of USB consoles into a single USB hub. A small embedded computer like a Raspberry Pi can then used as a basic console server.

RS-232 will be with us in the embedded space for a long time. It is very easy to initialise a RS-232 UART and so it is an ideal way to output messages from very early in the boot process. For this application there is little justification for the high voltage levels of RS-232 and many boards present 5V or 3.3V levels (that is, they have the UART but not the MAX232 chip). Those signals can be run directly into the RS-232 inputs of a Prolific or similar RS-232/USB UART (again, lacking a MAX232 ship).