Bypassing a Cisco Terminal Server Menu

Question

The guys at a config center connect to devices by: placing them on a management rack, and plugging them into a management switch by means of some hwic/RJ45 reverse telnet connection. When you remote into the management switch, you're dropped onto a menu console where you enter a number and get forwarded into the corresponding port. As an intern with only a couple 300 level courses under his belt, this thing seems a little arcane.

The guys are sitting around and copying/pasting chunks of CLI commands from notepad into an SSH terminal. It's agreed that there should be an easy way to automate these tasks -- And there is! I've identified that Paramiko/Netmiko scripts, or short Ansible tasks all appear to be good choices.

The problem is that these configuration tools all assume that you can directly connect to the desired host.

I can't get many straight answers about this terminal server from my coworkers or google. Rumors on the wind that someone once somehow appended a port and loopback (Ex: 2003, 1.1.1.1?) to the IP address in putty -- Someone installed a net-card into a router somewhere that can forward requests through the menu, but only telnet requests.

It seems like this terminal server just isn't in vogue right now, does anyone have experience with these things? Is there a way to form an SSH connection that will be transparently forwarded into those telnet ports?

---

Additional clarification edit

The case is a little unusual on these staging racks. I'm encouraged to find a way to automate certain CLI input, to remedy engineers being stuck copying and pasting the same commands on 10 or 15 devices. The engineers often get stuck wasting a great deal of time on this step. The term server is being used on these staging racks because it's best suited to the wide and random variety of customer devices and tasks required of them, although there are many circumstances where the same sequence of CLI commands has been used thousands of times.

I'd started just writing a simple paramiko script to navigate the term, then feed lines from a given text file into specified ports. This works, but is only suited to dumping conf-t commands. File transfers and device reloads present serious timing/sequencing challenges. Realizing the complications, I've focused on researching how I might enable an actual tool (ansible/netmiko) to be used with the term server, instead of hacking together a lackluster utility of my own.

The complication is that information about the terminal server is scarce, and I'm vaguely made aware that I should only SSH to the term server, and get forwarded into the devices. I should not telnet directly to the term server on port 200N, because of security concerns about different clients who may have access to different portions of that network

Answer 1

does anyone have experience with these things?

Centuries, actually. And that experience says to leave things you know very little (or nothing) about alone, especially when they're systems that (a) work, and (b) have worked for years. Live with it for a few years before declaring it crap.

I call this "new kid syndrome"; the guy comes in, and from day-one declares everything to be antiquated, inefficient junk, and sets off to replace it all with whatever the current generation of "shiny" happens to be. (ruby, cloud, etc.) I've seen this hundreds of times. I've seen tank several companies. All because the new guy doesn't know the processes he's bent on replacing; they don't know the history of why we do things we do the way we do them.

What you are describing is an age old network serial console. That's a terminal server providing telnet access to a device that has no network access of its own -- either because it has no network capability, or isn't configured yet. Your terminal server was setup with a menu interface to select the port, most likely to simplify the process. Having to know the IP and/or TCP port for a specific port can get confusing.

Your demand to use SSH will only complicate attempts of automated/scripted access. (there's a lot more work than simply opening a socket.)

I doubt you have access, or authorization, to make changes, but here's how we used to manage access to telco gear:

ip alias 10.200.5.201 3007
!
line 33 41
 session-timeout 30  output
 location DEX-600E Switch Port
 flush-at-activation
 refuse-message ^C
All XXX switch ports are in use. Please try again later.
^C
 modem DTR-active
 rotary 7
 no exec
 transport input telnet
 autohangup
 stopbits 1
 flowcontrol software out

The first line maps 10.200.5.201 to connect to port 3007 -- 3000(telnet) + rotary. One could also connect to the router's IP:3007 and get the same thing. The line configuration programs 9 ports in a group ("rotary".)

Answer 2

Echoing the response of Ricky Beam ...

There is a lot to be said for the age-old serial console. For this kind of scenario, the most successful and robust methods I've seen are reverse-telnet from a master configuration Unix machine with various Bourne shell scripts using netcat or expect. The configs all kept under version control of git/whatever. As suggested by Ron Trunk, a minimal bootstrap config and then network load is sometimes a good idea.

To directly answer the question about the menu, the usual way of reverse telnet to a particular outgoing serial line on Cisco equipment is to connect to port 2000 + N, where N is the outgoing line number. This is usually set up to take you straight out, without any menu. On Lantronix equipment it's 10000 + N.

The main thing is to have it robust, documented and very, very, infrequently changed. If I was in charge of it I wouldn't want to use anything clever at all, and I would want to remove every dependency I possibly could. Having wasted too much of my life fighting serial settings, I even insist all the consoles are remain at default 9600 baud. Why? So no one ever spends even a second wondering what the settings are.

SSH, in particular, is subject to changes which can be surprising: my firm recently lost control (temporarily) of some remote equipment when the workers' laptops were 'upgraded'. Those in charge of Open SSH had decreed that certain crypto settings were now insecure and couldn't be used by default. It took a little while until appropriate settings could be changed so that these people could ssh to the remote gear again.

Answer 3

A typical networking device (switch/router/firewall etc.) has these connections to the outside world:

         +------
         | "Console" Port (RS-232/USB/Bluetooth/...)
  +------o------+
  |             |
  |             o-------->
  |             |
  |             o--------> Network Interfaces
  |             |
  |             o-------->
  |             |
  +------o------+
         | "Management"
         | Interface (ethernet)
         +---------------

The "console" port is a serial interface, and can be used to monitor and operate the device as soon as it is powered up, i.e. before the operating system boots up and brings up the IP/TCP/SSH protocol stack. (If you've installed Linux on a desktop computer without a keyboard and monitor, you may be familiar with the process of redirecting the initial user interface (e.g. the GRUB menu) to a COM port; the Console port on the networking device performs a similar role).

Even after the network device boots up (and therefore can be accessed by direct telnet/ssh), it is a common practice in many installations to continue to manage the device over the console port. I won't get into the pros and cons of this practice; suffice to say that that's how it is. Here's the typical way this is done:

               "Terminal Server"
            +----------------------+
            |                 COM1 +-----------> console port of device A
            |                      |
            |                 COM2 +-----------> console port of device B
            |                      |
   ---------+ Ethernet        COM3 +-----------> console port of device C
            | 192.0.2.11           |
            |                 COM4 +-----------> console port of device D
            |                      |
            |                 COM5 +-----------> console port of device E
            +----------------------+

There are, AFAIK, two ways to use this setup to gain access to the console ports of the network devices:

(1) Telnet or SSH to the device (using the IP address, 192.0.2.11 in the above example). At this point you are presented with a menu, and upon choosing the appropriate option (e.g. 'a' for Device A, 'b' for Device B and so forth), you get connected to the appropriate device. From your question, this is what you appear to have.

(2) Initiating a telnet connection to a specific TCP port will directly take you to the console port of the device. E.g. invoking 'telnet 192.0.2.11 2001' from your laptop will directly take you to the console port of device A, 'telnet 192.0.2.11 2002' will take you to the console port of device B, and so forth.

Depending on your terminal server model, one or the other method will have to be used. Maybe both methods will work, you'll have to check.

Coming to your automation requirement: certainly the practice of pasting configs from Notepad is ugly; this is 2018 after all. I think you have the following options:

(a) Start making the devices accessible over IP (over the management port, or over the network ports). Then you can use SSH, and thereby netmiko and thereby ansible. Know however that this is not a trivial change. You will have to setup a 'management network' and make configuration changes on all the devices to allow access. There are security aspects to be considered as well.

(b) Somehow "convince" the netmiko software to work over the terminal server. I have a vague recollection that netmiko does support method (2) described above, i.e. telnet to a specific TCP port on the terminal server taking you to the console port of a specific device. You'd have to check the docs though.