Serial Console Servers

Simplify the setup of serial communications for console and configuration operations

On one less-than-enlightened occasion, I predicted that by the end of the 1990s, serial communications would no longer be the standard. I based my prediction primarily on wishful thinking: The number of variables involved with trying to get two serial devices to communicate with each other was frustrating. In my defense, my prediction was partly correct. Desktop computers rarely have anything plugged into one of the COM ports. Some vendors even provide legacy-free PCs that are free of the old-style serial or parallel ports. However, servers—particularly those designed to run UNIX—still firmly embrace serial communications as a conduit for console and configuration operations. Many other appliances and communication hardware components also rely on a serial connection for initial configuration.

In the Windows & .NET Magazine Lab, I test many devices in this category. When I need to attach to the serial interface on a new piece of equipment, I typically lug out the laptop that's configured with a terminal emulator program, then begin the bizarre serial-mating ritual. This ritual involves finding a null-modem or straight-through cable—sometimes both if the device doesn't clearly state whether it's Data Communications Equipment (DCE) or Data Terminal Equipment (DTE). The connectors at both ends of the cables must also have the appropriate gender and number of pins. After I attach what I hope is the right type of cable, I begin configuring the communication parameters. Although I like the geek factor of entering parameters such as handshake, parity, stop-bits, and flow-control, I don't think I've ever guessed those parameters correctly on the first try. I guess at least one parameter wrong, resulting in a string of garbage characters.

After I finally arrive at the correct combination of cable and software settings, I find a place to set the laptop so that I can type with more than one finger. Then I use the laptop for 5 or 10 minutes, and I'm finished. Because spending more time preparing for a task than actually completing the task annoys me, I became intrigued by a class of products that provide serial console emulation for multiple users through a network connection.

Some vendors of keyboard/video/mouse (KVM) switches—including Avocent, Lightwave Communications, and Raritan Computer—offer serial console servers that claim to simplify communication with serial devices in the data center. I tested an Avocent CPS1610, a 16-port serial console server containing one 100Base-T Ethernet port, and found that—after I got past the learning curve—the system also helped me more quickly set up serial communications between the servers and appliances with which I was working.

The approach that worked best in the Lab was to configure the different ports on the console server with a variety of common connection parameters and appropriately label the ports within the Avocent software. Now, when I want to use terminal emulation to attach to a Cisco Systems switch, I simply telnet the Avocent system from any PC on my network and specify the port that has been configured with serial parameters for Cisco. The supplied cables have an RJ45 connector on each end, and I can attach one of the modular adapters to accommodate DCE/DTE and gender requirements.

Although a serial console server doesn't solve all the difficulties associated with serial communications, it offers a much better connectivity approach for multiple devices and multiple users—which is the traditional application of console servers. The next time you're in your data center, however, take a look around and notice where you're using serial connections for communications and configurations. Perhaps you'll see how you can use a console server as a hybrid solution for various organizational needs.