Console Access Server
Marcio Saito, Director of Technology-Revision 5.0- Mar/01

About this document
    The demand for console management equipment is on the rise as a consequence of the increasing use of clusters and server farms to reach the processing capacity required by Internet and corporate applications.
    This document discusses console port management (out-of-band management of servers and network equipment through their serial console ports) and provides information for intelligent product selection, solution design and implementation.
    The information herein is result of our own experience and the contribution from many customers (too many to list) and is being constantly revised. Any feedback or contribution is very welcome and should be sent to marcio@cyclades.com.

Console ports and out-of-band management
    Servers and networking equipment can be managed through the same channels used to carry data (usually the Ethernet LAN) using many available management tools. That is the most common form of management and is called in-band network management.
    In addition to in-band management, we sometimes need low-level control over our equipment. For example, we may be interested in monitoring the hardware self-test and BIOS information for a specific server. This information is generated before the operating system is loaded and we cannot rely on the network connection to retrieve the information. That is why out-of-band management (using dedicated management channels, independent of the channels used to carry data) is needed.
    If we are on location and there are a few servers, out-of-band management can be done individually at the server console using either a GUI or a text-based interface.
    Another important aspect of out-of-band management is that relying on the network to manage network boxes and servers is not always effective. How do we access and troubleshoot a node to fix a problem that is causing a network disruption? Again, out-of-band management is the answer.
    Most UNIX servers (Linux, FreeBSD, Solaris, HP/UX, AIX, System V, etc) can be monitored and managed through a serial console port. From the console, the system administrator can access diagnostic information (boot messages, error logs, alarms, monitor mode), change low-level system configuration and perform other administrative tasks (such as resetting/rebooting the system).
    In addition to the physical network interfaces, network equipment (routers, switches, and access servers) usually have an additional out-of-band management and configuration port (console or auxiliary port).
    Console ports in servers and network equipment use RS-232 interface. To connect to them you need serial cables and ASCII terminals (or a PCs running terminal emulation software such as HyperTerminal or Kermit).

What is a Console Access Server?
    When the number of servers and boxes in the network grows above a few nodes, it becomes unpractical to have one management console per box. We would like to access all the console ports without moving from one terminal to another. A Console Access Server (CAS) is the equipment that allows the system administrator to conveniently access all console ports in a computer network or server farm from one single station.

    Another reason to use a CAS is the need to access the console ports remotely. A console management solution should enable console access from anywhere, anytime, locally through the LAN or remotely through the Internet or dialup connections.
    A Console Access Server has multiple RS-232 serial lines for connection to the console ports and at least one Ethernet LAN port for connection to the network. It provides connectivity so that access is easy, fast and convenient and security so that intruders are kept out.
    With more mission critical applications being implemented on server farms rather than on a single large mainframe, Console Access Servers become indispensable elements in any large computer installation.

Selecting the right Console Access Server
    Here is a list of features to look for in a Console Access Server. More detailed discussion on some of these items are presented later in this document.
• Scalability and Port Density Because rack space in a data center is expensive, having the maximum number of ports in the minimum space is essential. Products in the market offer a maximum number of ports ranging from 16 or 64 ports per chassis. Some products allow stacking multiple boxes to create larger virtual boxes. Typical port densities range from 8 to 16 ports per 1U of rack space, with the highest densities being of 32 ports per 1U (1U equals 1.75 inches of height in a standard 17-inch rack).
• Mechanical Characteristics The console access server should integrate well with your rack and cable management systems. Built-in RJ-45 connectors, minimum external cabling, absence of moving parts, high-level of integration, front panel LED status indications, integrated power supply, are examples of desirable features. Some products offer clumsy external cables or wonÕt easily fit in a rack.
• Security and Connectivity  anyone who gains access to the console port of servers and routers can potentially take control of the entire network. Security features such as IP Packet and Service Filtering, RADIUS Socket Authentication, and Secure Shell (SSH) are essential. A CAS should allow easy, fast and convenient access for the system managers, but must be able to keep intruders out. It should have full support to Internet, LAN and dialup connectivity. Older products from the pre-Internet era lack the security or the Internet connectivity required by todayÕs networks.
• Functionality and Flexibility  Some generic terminal server products marketed as CAS lack the features for good console port management. A CAS should support direct telnet or SSH to a serial port and support multiple port addressing methods (IP address, TCP port number, or manual selection in a menu). It should allow local or server-based authentication. It should fully support RS-232 signaling, be able to send intentional break signals and not produce unintended breaks. It should allow logging of messages. Depending on the product selected, you may be able to customize the functionality to your own needs.
• Cost and Service  Depending on the vendorÕs focus and knowledge on console management, there may be significant variation on the cost of the equipment and the quality of service offered with the product. Before purchasing, make sure the vendor understands networking in general and console access in particular and that the product has a modern design, is cost-effective and can be updated though a software download.

What types of CAS are available?
    Looking at existing products, we can identify three distinct categories:
Traditional Console Access Servers
    Console Port Management is not a new application. Besides using over-complex hardware and being expensive, traditional console access products have not been able to follow the changes required by the increase in size of the server farms and the need for Internet connectivity. They focus on hardware rather than software-based scalability and modularity and present poor connectivity and security features. The Lightwave Console Server 3200 is one example of traditional CAS.

Generic Terminal Servers
    Terminal Servers were used to connect serial terminals to Unix Systems. Some of those products have incorporated software features to adapt to the Console Access function. They usually come with strong Internet connectivity and security functions, but lack specific console features (convenient cabling, high port density, visual indication of the status of the ports, specific HW to prevent unintended breaks, etc.). The Cyclades-PR3000/TS, Lantronix, Portmaster 2, Xyplex, Cisco 2511 are examples of generic terminal servers that can be used as console access servers.

PC-based Terminal Servers
    With the availability of PC hardware and Open Source operating systems such as Linux and FreeBSD, building a terminal server by installing a multi-port serial board in a PC becomes a viable proposition for some users. These solutions are weak in port density and integration, but present potential advantages in scalability and flexibility to accommodate specific needs.
    Charts with objective comparison between products available in the market are available at our WEB site.

Cyclades solutions for console port management
    Some of the largest Internet and corporate server farms around the world are being managed using Cyclades console management products. We offer both stand-alone solutions and components for server-based solutions. Here are a few highlights of the products (more information can be found at http://www.cyclades.com).
    Cyclades-TS1000 (16 ports) and Cyclades-TS2000 (32 ports)
    The TS1000 and TS2000 are stand-alone console access and terminal servers. They offer the highest available port density (16 or 32 ports on 1U of rack space) and are totally integrated in a single self-contained unit. The RS-232 interfaces are provided on RJ-45 connectors and there are 3 LEDÕs per channel on the front panel for status indication.
    The TS1000 and TS2000 are designed with the console management application in mind. They combine the security and connectivity from generic terminal servers with the specific console access features of traditional console access servers in a product that is effective, secure and cost-effective.
    Cyclades-Z (16 to 64 RS-232 ports on a PCI adapter)
    The Cyclades-Z is a PCI multi-port serial card for PC servers that can be used to build server-based console access solutions. It can be installed in any standard computer running Linux, FreeBSD, or Windows operating systems and provides 16 to 64 RS-232 interfaces on RJ-45 connectors (16 ports per 1U external box).

How does a CAS work?
    As mentioned before, server or network equipment have management ports that can be monitored by a serial terminal (or PC running terminal emulation software) connected by RS-232 serial cabling.
    If the console port is connected to a CAS instead of being directly connected to a terminal, the system administrator gains much more flexible means to view that management interface.
    The console ports can be accessed through the network (either from the LAN or across the Internet). Even if the network is down, the CAS should allow you to get in through remote dialup access.
    Typically, the user will use a TELNET or SSH client to connect to a specific serial port over the network. The CAS should provide different ways to address the serial port to be monitored.
• Using individual IP addresses per serial port assigned by configuration. Users can simply telnet or ssh to that IP address and get connected to the serial port. This has the advantage of allowing the use of symbolic names rather than numeric addresses (via DNS server) and making multiple CAS look like one large virtual box. This method has the potential disadvantage of requiring the allocation of extra IP addresses in the network.
• Using individual TCP port numbers per serial port assigned by configuration. Users telnet or SSH to the single IP address assigned to the CAS, and specify the serial port using the special TCP port numbers (instead of the default TCP port number used by Telnet). This method saves IP addresses but requires the use of telnet/SSH clients supporting specification of TCP port numbers.
• Connecting to the CAS using telnet or SSH and them selecting the port manually through a menu or command interface.
• Using a console management application (such as Conserver). In this case, the CAS must support socket connections to the serial port. In this case, the application provides the specific user interface.
    Upon connection, the system administrator should be able to optionally require user authentication (based on local database or RADIUS server) before allowing access to the console ports.
    The TS1000 and TS2000 products support all methods of port addressing and socket authentication using either local or RADIUS database.

Cabling, rack space and physical location
    The CAS is attached to the LAN using standard cabling to an Ethernet hub or switch.
    The serial ports are connected to consoles with RS-232 cross-cables. Because console baud rates are usually low, the serial cables can be as long as a few hundred feet. Frequently the cabling run through patch panels and the rack cable management systems.
    For solutions based on the TS1000 or TS2000, the LAN connection can be either 10BT or 100BT (Fast Ethernet). The unit is all integrated in a single box with 1U of height and built-in power supply. Besides the network interfaces, the only external cables are the power cord and the CAS own console port.
    For server-based solution using the Cyclades-Z, besides the external PC connections (power, LAN, etc), there will be a 1U box per each 16 ports, with the boxes interconnected in a chain by SCSI-II type cabling.
    If you are also installing a modem to allow emergency remote dialup connections, the modem should be connected to one of the RS-232 ports in the CAS through an RS-232 straight-through cable.
    A cross-cable is connects two DTE devices (computers, terminals) crossing data lines and control signals between the two ports (Tx connected to Rx, DTR to DCD and DSR, RTS to CTS). A straight-through cable connects a DTE device to a DCE device (modem). It connects all RS-232 signals in a one-to-one basis.
    RS-232 serial interfaces on both the CAS and the console port sides can be provided on different connectors. Cables must be built accordingly.
    The most common connectors are RJ-45 (TS1000, TS2000, Cyclades-Z, most networking equipment, newest servers), DB-25 (modems and older equipment), and DB-9 (most servers and PCs). DB-25 and DB-9 connectors have standard pin-out assignments, so it is relatively easy to build or order pre-made cables from a computer store.
    RJ-45 is the connector type favored by CAS because they are compact and compatible with patch panels used in data centers. Unfortunately there is no standard pin-outs for RS-232 on RJ-45 connectors and each vendor uses a different pin assignment.
    If you look at a DB-25 or DB-9 male connector, there are two rows of pins. The one in the upper-left corner is pin 1. The one in the bottom-right corner is pin 25 (on a DB-25) or pin 9 (on a DB-9).If you look at a RJ-45 plug with the contact pins facing down, the 8 pins are numbered from left to right.
    DB-25 standard pin-outs are 1-chassis, 2-Tx, 3-Rx, 4-RTS, 5-CTS, 6-DSR, 7-Gnd, 8-DCD, 20-DTR.
    DB-9 standard pin-outs are 1-DCD, 2-RxD, 3-TxD, 4-DTR, 5-Gnd, 6-DSR, 7-RTS, 8-CTS.
    Cyclades RJ-45 pin-outs (there is no standard) are 1-RTS, 2-DTR, 3-TxD, 4-Gnd, 5-CTS, 6-RxD, 7-DCD, 8-DSR.
    More detailed information on cabling, including specific cable diagrams for console access applications can be found at the technical support and Techtalk sessions of the Cyclades WEB site.

Security and Connectivity
    Anyone who gains access to the console port of servers and routers can potentially take control of the entire network. A CAS should have all the connectivity features to allow the system administrator to access the console ports from the LAN, a dialup connection or over the Internet, but must also have the security features to keep intruders out.
    Packet and Service Filtering is a networking feature (frequently absent in older CAS designs) that allows the system administrator to set access policies and selectively allow or deny connections based on source address, destination address, port number, protocol type and other parameters.
    Socket Authentication is important to validate privileges of users trying to access a console port. The authentication requires passwords that can be checked against a local database or RADIUS server. Some terminal servers support RADIUS authentication on serial-to-network access but lack authentication support in the network-to-serial accesses.
    Secure Shell (SSH). In a regular telnet connection, the session screens and keystrokes (including the authentication process) travel the network in clear text form. When there is the risk of data interception in transit (as it is the case over the Internet), the user should give preference to SSH, which encrypts data before sending it through the network.
    Dialup Security. If the CAS is to be accessed remotely through dialup connections, the same security features mentioned above should be supported over dialup lines. Also, additional dialup-related security protocols such as PAP and CHAP should be supported.
    Not all security features are needed in every configuration. When setting a CAS, make sure it is not only functional, but also secure considering the profile of your environment.
    The TS1000/TS2000 products support all the features mentioned above, offering excellent level of security. In a server-based solution based on the Cyclades-Z, the OS should be configured properly so that it is equally secure.

Sending Break signals
    Some servers (Sun/Solaris, for example) switch to monitor upon the reception of a "Break" on the console port. This useful feature allows the system administrator to reset/reboot/reconfigure the server in the event of a system lockup.
What is a break?
    An RS-232 line has 2 states: "0" (-12V) and "1" (+12V). Sending a "break" means keeping the line in the "1" state for more than one character time (usually a couple hundred milliseconds).
What is the "break problem"?
    A potential undesirable side effect of this useful feature is the possibility of unintentionally stopping the operation of the server by generating false breaks on the serial line. This affects only servers that use the break signal to switch to monitor mode.
    When a system is powered off, it cannot control the state of its serial lines. Depending on the electrical characteristics of the circuit composed by cables and serial ports, there may be voltage fluctuations on the serial lines that could be interpreted by the other side as "break".
    The consequence is that, given the right conditions (or wrong conditions, for that matter), power cycling the CAS could cause servers connected to it to see a "break" on the console port (and you would have an entire server farm down). Notice that the CAS doesnÕt intentionally send breaks, but the console ports see them as a result of random electrical fluctuation.
    Because this phenomenon depends also on factors external to the CAS, nobody cannot absolutely guarantee that it wonÕt ever happen in your environment. But the electrical design of the box can make the break problem a certainty or a very rare event.
    The TS1000/TS2000 and Cyclades-Z products use low-noise line drivers and the serial interfaces are specifically designed to prevent this from happening. In addition, the TS1000/TS2000 have a special power circuitry that prevents random power fluctuation during power-on/off, virtually eliminating the possibility of unintentional breaks.
    What is the best way to avoid this problem?
    If you have a current Sun server (Solaris OS released after 11/99 or previous version with patch 107589-03, available in the Sun support site) and you use a unintentional break prone CAS, the problem can be avoided through configuration. Edit the file (/etc/default/kbd) to select a specific sequence of ASCII characters (less likely to be accidentally generated) to "switch to monitor mode" or simply disable the feature.
    What if I cannot avoid the problem by software?
    If you cannot or donÕt want to disable the reset on break feature in your server and the problem happens with your CAS and environment, the solution would be replacing the CAS with a break-safe product. Before that, you can try other solutions customers have reportedly used with some degree of success (but we at Cyclades have never tested ourselves):
• Change the electrical characteristics of the circuit by changing cable configuration or inserting inexpensive "RS-232 light-boxes" in the circuit.
• Insert "pull-down" resistors (4.7K Ohm) between the Rx line and Gnd (console port side) to prevent voltage fluctuations when the CAS is powered off. The resistors can be easily installed inside RJ-45 to DB-25 adapters in RJ-45 cabling systems.
    What if I want to send intentional breaks?
    If you want to be able to send break signals, you will need a CAS that supports telnet extensions (described in the RFC 2217, 854). In this case, make sure your telnet client is able to send break using the telnet extensions.
    The TS1000/TS2000 CAS are unlikely to allow the generation of unintentional break signals and can intentionally generate breaks through RFC 2217 commands.
    As mentioned above, if you want to be capable to remotely switch a Sun server to monitor mode, we recommend you to edit /etc/kbd and select a specific sequence of ASCII characters that are less likely to be generated by accident and easier to be generated intentionally.

Comments or suggestions to this document can be sent to Marcio Saito marcio@cyclades.com
The information in this document is the result of our own experience and the contribution of many Cyclades customers (too many to list). If you use this document and later find some information that would be useful to others, please let us know about it.