Strategies I've seen include:
- A seemingly endless loop of AUX->Console rollover cables
- High density serial port cards in servers
- Commercial terminal server products
- The now defunct BlueConsole dongles hanging out of every device, and a server with a bluetooth module (It's a neat dongle, but deploying these things in a data center is wacky)
- Mapping serial ports to TCP/IP ports for telnet or SSH access
- Mapping serial ports to IP addresses for telnet or SSH access
- Running terminal server management software on a central console host for convenience, logging and access management
The Lantronix SLC product is widely deployed for this purpose, and will get the job done. Don't mistake that for a ringing endorsement.
Here's what I usually do when deploying a Lantronix SLC terminal server:
- Set defaults using front panel controls. The password is probably 999999.
- Set IP/Mask/Gateway via front panel controls or console interface.
- Upgrade to latest OS version (5.4). Http is the easiest way to do this. Default login is sysadmin/PASS.
- Login via SSH, set admin password with 'passwd'
- The rest of the configuration follows.
set network host mylantronix domain mydomain
set network dns 1 ipaddr 126.96.36.199
set network dns 2 ipaddr 188.8.131.52
set datetime timezone UTC
set ntp localserver1 clock1.mydomain.com
set ntp localserver2 clock2.mydomain.com
set ntp localserver3 clock3.mydomain.com
set services location building suchandsuch rack suchandsuch
set services snmp enable
set services rocommunity BigSeekr1t
set services rwcommunity BiggerSeekr1t
set services telnet disable
I like to give an IP address to each serial port. This way I can SSH directly to a device console, by name. At 3 AM, it's useful to have little details like remembering how to get to the console server taken care of, so I create a DNS record ending with '-console' for each piece of gear. It points
myswitch IN A 192.168.255.1 # This is the loopback address of a piece of network gear
IN A 192.168.50.10 mylantronix-port1 IN A 192.168.50.11
mylantronix-port2 IN A 192.168.50.12
mylantronix-port3 IN A 192.168.50.13
mylantronix-port4 IN A 192.168.50.14
mylantronix-port5 IN A 192.168.50.15
mylantronix-port6 IN A 192.168.50.16
mylantronix-port7 IN A 192.168.50.17
mylantronix-port8 IN A 192.168.50.18
myswitch-console-slot3 IN CNAME mylantronix-port1
myswitch-console-slot4 IN CNAME mylantronix-port2
myswitch-console IN CNAME myswitch-console-slot3
Note that there's a CNAME pointing to another CNAME here. It works, but the RFC says it should be avoided. In this case, it's never going to loop, and it's handy.
192.168.50 set deviceport port 1-8 sshin enable
set deviceport port 1 ipaddr
set deviceport port 2 ipaddr
set deviceport port 3 ipaddr
set deviceport port 4 ipaddr
set deviceport port 5 ipaddr
set deviceport port 6 ipaddr
set deviceport port 7 ipaddr
set deviceport port 8 ipaddr
Label the ports:
set deviceport port 1 name myswitch-console-slot3 myswitch-console-slot4
set deviceport port 2 name
edge-router-B set deviceport port 3 name core-router-A
set deviceport port 4 name core-router-B
set deviceport port 5 name firewall-A
set deviceport port 6 name firewall-B
set deviceport port 7 name edge-router-A
set deviceport port 8 name
syslogserver2 syslog2.mydomain.com set services syslogserver1 syslog1.mydomain.com
I can't remember what these do, and the lackluster documentation provides syntax, but no clue as to the meaning of these commands. I knew once, and decided they were a good idea. I think I figured out that they were helpful through the GUI.
server2 tacacs2.mydomain.com set tacacs+ server1 tacacs1.mydomain.com
server3 tacacs3.mydomain.com set tacacs+
set tacacs+ secret BigSeekr1t
set tacacs+ permissions ad,nt,sv,dt,lu,ra,um,dp,rs,fc,dr,sn,wb,sk,do
set tacacs+ group admin
set tacacs+ state enable
set services authlog info
set services devlog info
set services clicommands enable
set services includesyslog enable
I like to have the SLC spool every byte that crosses my serial port off to an NFS filesystem. It's pretty easy if you own the fileserver, somewhat trickier if you have to interface with the storage dudes. You'll need a share setup for you, with write access for UID 0 from all of the Lantronix IP addresses.
The box is kinda flaky this way.
This is one of the ways the box is flaky. Traffic originated by the SLC might come from any of its IP addresses. Even those assigned to serial ports. Ugh.
Make a directory for each SLC that will be writing to the share. Ensure that UID 0 can write within those directories.
set nfs mount 1 remdir myfileserver:/path/to/share/mylantronix locdir /nfs1 rw enable mount enableThe share is at myfileserver:/path/to/share and it contains a directory called mylantronix. Presumably you'll have lots of SLCs, so it's nice to have a directory for each one.
set deviceport port 1-8 nfsdir /nfs1
set deviceport port 1-8 nfslogging enable
set deviceport port 1-8 nfsmaxsize 250000
set deviceport port 1-8 nfsmaxfiles 4
Within the mylantronix directory, the SLC will create a file for each serial port. As each file reaches 250KB, a second file will be created, and so on, with a maximum of 4 files (1MB) per port. 1MB is a lot of console data at 9600 baud!
Broken: Interface Bonding
The SLC has two NICs, but until recently, there wasn't much you could do with the second NIC. Redundancy boiled down to:
- Assign the secondary NIC an IP on a different subnet than the primary NIC
- Configure an alternate default gateway secondary subnet
- Configure a healthcheck-IP, to be pinged through the primary NIC/gateway
- If the healthcheck IP fails to ping, the SLC will swap to its alternate default gateway
- You better remember how to get to the box via its alternate NIC
- per-port addressing is impossible
set network bonding active-backup
Don't do it! Per-port addressing and interface bonding are a deadly combination. It doesn't matter which you set first. When you enable the second of those features, the box goes completely offline. You can't even get any output from the SLC's own console port! The only option is a front-panel reset. Lantronix support hasn't shown much interest in fixing the issue. I suspect they're too busy dealing with their PCMCIA supplier crisis. They have told me that they might enhance the documentation, CLI and GUI to warn the administrator who dares such a a configuation <eyeroll>. This is my single biggest issue with these boxes. I really wish it was fixed. Lantronix, are you listening? I'm pretty sure that opengear is listening!