Console Network Design

Tony Bourke

In today's modern data centers, we are presented with the problems of effective, efficient server management. One such problem is console administration, where access is needed to the console port on a Sun machine or other serial-administered device. Often the solution is one or more dumb terminals with long serial cables shared with the entire data center. This is not only sloppy management, but also extremely impractical in a crisis. A solution to this problem is the implementation of a console network. A console network is an efficient way to manage multiple console links from multiple workstations.

A console network consists of three parts (see Figure 1). First, there are the terminal servers -- the machines with a high concentration of serial ports to connect to the machines in the data center. An example is the Lucent (formerly known as Livingston) Portmaster 2e series of terminal servers. These were originally created to control modems for a dial-up pool, such as an ISP running PPP services. Models such as the Portmaster 2e30, have 30 serial ports in addition to an Ethernet interface. These are perfect terminal servers for a console network because they are relatively inexpensive, have a high port density, and a very robust operating system built for serial configuration. They also do not exhibit a characteristic of most other terminal servers -- sending “break” signals to all of their ports when either rebooted or power cycled. Break signals cause Sun machines to halt, which is obviously not acceptable in a live server environment.

The second component of a console network is the gateway. The gateway is a UNIX machine running some form of encrypted access, such as ssh or encrypted kerberos. This machine sits in front of the console network to authenticate users and provide security. The Lucent Portmaster, as well as most other terminal servers, do not offer any form of encrypted command-line interface. Because the gateway machine sits in front of the console network, it will provide encrypted access so that passwords and other sensitive information will not be sent as clear text over a public network.

The third component is the console network private LAN. This LAN will not have any access whatsoever to a public network, free from the prying ports of packet sniffers. The only machines plugged into this network will be the Portmasters and a separate NIC on the UNIX gateway machine.

Setting up Your Console Network

The UNIX gateway machine should be set up first. This machine will need two network interfaces -- one for the public network and one for the private console network LAN. Configure the public interface for your network as you would any machine. Give it the lowest address, .1, and the Portmasters will be configured with the next IP addresses. A full security audit should be performed on this machine. All non-essential services should be turned off; any routing function should be disabled; and all appropriate patches from the vendor should be applied.

The private LAN should be set up next. Any 10baseT hub will work to connect the gateway to the PortMasters. The PortMasters only have 10baseT interfaces, and there will be negligible traffic so there's no need for 100baseT or a switch. When you are ready for the PortMasters, follow these step-by-step instructions to configure the PortMaster as a terminal server.

1. Put the 4 and 5 dip switches into the “on” position. This enables the 10baseT interface.

2. Plug a console cable (you may need a null modem) into port S0 and power up the unit. After a few moments, you should be able to send a few carriage returns and get a command prompt. This is the PortMaster's ComOS software.

3. Choose and set the administration password by typing set password (your password).

4. Configure the interface with the set ether0 command. For instance, if the IP address you wanted to configure is 192.168.1.10, then type set ether0 address 192.168.1.10. Give the PortMaster a name for administration's sake, and add it to /etc/hosts on the UNIX gateway machine.

5. Once the Ethernet interface is set up, the rest of the administration can be done remotely. Simply plug the PortMaster into the console private LAN -- the rest can be done from the UNIX machine.

6. From the UNIX machine, telnet to the IP address of the PortMaster. The administration login is !root, and, after you enter the password, you should see the same command-line interface as when you consoled in.

7. To configure the serial ports, I will use port S1 as an example. To set it up for reverse telnet on port 6001, use the following commands:

   set s1 device network
         set s1 cd off
         set s1 service_device telnet 6001
         set s1 xon on
         save s4
         reset s4

8. From here, you should be able to telnet to port 6001 on the IP address of the PortMaster and get the console on whatever is plugged into S1. Configure the rest of the ports according to their port numbers (i.e., port 5 is on port 6005, port 12 is 6012, etc.).

Most machines, including Suns, will require a null modem cable when connecting to a PortMaster. For ease of management, I recommend using RS232 to RJ45 adapters and running the length of the cable with cat 5 cable. For null modem functionality, a male to female adapter can be added at one end.

For administration and use, you can set up a user called “console” and set its shell as a Perl script. The perl script will prompt the user for a specified machine, and a database will correlate that machine with its corresponding PortMaster and port number. It will then telnet the user to that port.

#!/usr/local/bin/perl
# Console Network Interface 
# Tony Bourke (tony@vegan.net) 
# Version 1.0 # # This simple perl script acts as the user interface 
# to the console network
print ("\nConsole Network Interface\n");
while (1) {
print ("\nEnter location/server: ");
$input = <STDIN>;
chomp ($input);
open (CONFIG,"/usr/local/etc/console.cfg") || die
"Cannot open 
config file";
    while (<CONFIG>) {
           ($server,$pm,$port) = split(/:/); 
if ($input eq "exit") {
                    exit 0;
                }
                if ($server eq $input) {
                        system("telnet $pm $port");
                }
        } 
}

servername:portmaster:port

An example of a config file is shown below:

web1.foo.com:pm1:6005 
stage1.foo.com:pm1:6006 
router1:pm3:6020

One issue I have seen is when a process running on a Sun machine writes a considerable amount to the console and it can hang a process because of the buffer on the portmaster. Logging into the port via the console network will clear the buffer, or leaving the console cable unplugged until the serial interface is needed will resolve this issue.

There are numerous resources for the Lucent Portmaster, and expanding the functionality and capability of the console network to suit your particular needs is very easy. Things like password protection on particular ports and setting up VPN links between geographically separated installations are all possible. The design can scale from just a few machines at a co-lo facility to the largest data center. Given all this and the low cost of implementation, the console network design would be a valued and essential part of a server network.

About the Author

Tony Bourke is a Senior Performance Engineer with Global Center, Inc., a division of Global Crossing. Tony specializes in the design and development of UNIX and networking infrastructures for Global Center clients. He can be reached at tonyb@globalcenter.net.