Terminal Server versus Console Server

Historically, there were terminal servers designed to allow serial devices such as modems and CRT terminals to connect to network resources (typically mainframe computers), with the terminal server handling all of the network protocol tasks. Later, the "Reverse-TCP" feature was added, allowing users on the network to gain access to a specific serial port on the terminal server, typically to allow many users to share the limited number of outbound modem devices and to allow the mainframe to directly access a serial printer.

Because the original core features set for terminal servers was to connect to modems, these devices often sent serial BREAK to the modem at the end of a session, as a way to reset a modem to its non-volatile RAM settings. One side effect of those early hardware designs was that these devices also usually sent the BREAK signal to all of the serial ports when the power to the terminal server was turned off. If you are using older Sun Microsystems hardware or some SGI servers, you know that this signal will cause these computers to halt, causing Sun computers to go to the "ok>" prompt. More information about serial BREAK can be found online at:

http://www.conserver.com/consoles/BREAK-off/breakoff.html

Console servers are the new generation of hardware, designed with remote access to serial consoles as a primary task. They often come with default settings already configured for such service, and most come with SSL and/ or SSH security features built-in. (Note: I did write "most" come with security features built-in. You still need to read the specs to see whether a device has these features, and to see how current their SSL/SSH versions are. Ask how quickly they update their versions when an SSH hole is found, if that's an important issue for your shop.) Most console servers are also advertising that they are "Sun Safe", meaning that they should only send serial BREAK to a serial port when a user invokes it, so that Sun computers are not unexpectedly halted.

It can take a fair bit of configuration effort to make an older terminal server work properly for remote access to serial consoles. You may be able to find user documentation on the Web, but you may have trouble finding the software for the terminal server on the Web. Most older devices are no longer supported by their manufacturers (if the maker is still in business). If you can get software, it's probably going to be an old version. If the software has any security features, they will be old versions, and they may well have some old, well-known bugs.

If you are buying a used terminal server, you may not get the manuals or firmware to make it work. You might be able to find these resources online and make the unit boot using TFTP or BOOTP, but there is a significant "soft cost" of the time to find the resources and set up the infrastructure to make them useful.

In my opinion, older terminal server hardware should be confined to deployments where there is no need for security and where the connected devices do not care about serial BREAK.