Managing gear with a Lantronix SLC

Out of band management is a must for an enterprise networker, and where possible, I like to deploy a robust RS-232 based terminal server. It must be the UNIX admin in me that's so gung-ho about console access, because I've encountered lots of network administrators with a take-it-or-leave-it attitude on this issue. Me? I never consider a deployment complete without some sort of console access to every device.

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)

Variations on the terminal server theme, include:

• 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:

1. Set defaults using front panel controls. The password is probably 999999.
2. Set IP/Mask/Gateway via front panel controls or console interface.
   
3. Upgrade to latest OS version (5.4). Http is the easiest way to do this. Default login is sysadmin/PASS.
   
4. Login via SSH, set admin password with 'passwd'
5. The rest of the configuration follows.
   

Basic configuration:

set network host mylantronix domain mydomain
set network dns 1 ipaddr 8.8.8.8
set network dns 2 ipaddr 8.8.4.4
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

Per-Port Addressing:
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 at the IP address assigned to the serial port where that console can be found. Usually, it's a CNAME, pointing at one of the A records associated with the Lantronix. Multiple supervisors complicate things. A snippet of the DNS zone file might look like:

myswitch IN A 192.168.255.1 # This is the loopback address of a piece of network gear
mylantronix 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

The names in red are the only ones that I expect to type during the course of most of my work. I quickly forget just how many terminal servers are out there, and where they live, but a quick nslookup of any '-console' name clues me in about where stuff is plugged in, if I need to know. Also, if myswitch-console lands me on a standby supervisor, nslookup makes it easy to figure out that myswitch-console-slot4 is where I should be headed.

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.

To make those DNS records useful, set up the per-port addresssing on the SLC:

set deviceport port 1-8 sshin enable
set deviceport port 1 ipaddr 192.168.50.11
set deviceport port 2 ipaddr 192.168.50.12
set deviceport port 3 ipaddr 192.168.50.13
set deviceport port 4 ipaddr 192.168.50.14
set deviceport port 5 ipaddr 192.168.50.15
set deviceport port 6 ipaddr 192.168.50.16
set deviceport port 7 ipaddr 192.168.50.17
set deviceport port 8 ipaddr 192.168.50.18

Label the ports:

set deviceport port 1 name myswitch-console-slot3
set deviceport port 2 name myswitch-console-slot4
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 edge-router-B

Syslog Servers:

set services syslogserver1 syslog1.mydomain.com
set services syslogserver2 syslog2.mydomain.com

TACACS+
Frustratingly, it doesn't seem to be possible to use a different secret with each server

set tacacs+ server1 tacacs1.mydomain.com
set tacacs+ server2 tacacs2.mydomain.com
set tacacs+ server3 tacacs3.mydomain.com
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

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.

set services authlog info
set services devlog info
set services clicommands enable
set services includesyslog enable

NFS:
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 enable
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

The 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.
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

Now, the situation is slightly improved: Interface bonding is supported. Sort of. The command to configure bonding is simple:

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!