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, 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

  • 1
    If the devices to be configured are new devices, then they have no configuration, and you cannot connect to them on the network because there is no network configuration on the device, so you have a terminal server that connects via a serial interface into the console interfaces of the devices. What can be done, and how it can be done depends on the particular model and configuration of the terminal server. – Ron Maupin Aug 1 '18 at 16:43
  • 1
    Since you can telnet into the terminal server, you can certainly automate that part. But it's not as much of a time-saver as you might think. You might consider creating a simple config on the router and then use tftp to upload the full configuration. – Ron Trunk Aug 1 '18 at 17:35
  • The "arcane" serial console access method you describe provides out-of-band access to a device without configuration or when the in-band access fails for whatever reason. It's an essential method for recovering out of situations where mostly everything else fails. Ever removed the management VLAN from the uplink trunk? Of course, you can automate and script this as well but very often, the template scripts require some customization before deployment. – Zac67 Aug 2 '18 at 5:20
  • I'm not sure what you are asking with your clarification edit. We use a terminal server, and if we have multiple devices connected that need similar configurations, our terminal application that we use will allow you to have multiple connections in tabs, and you can send a single command to all tabs, or you can send a command to a single tab. – Ron Maupin Aug 7 '18 at 21:16
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 25 '18 at 9:09

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 3007
line 33 41
 session-timeout 30  output
 location DEX-600E Switch Port
 refuse-message ^C
All XXX switch ports are in use. Please try again later.
 modem DTR-active
 rotary 7
 no exec
 transport input telnet
 stopbits 1
 flowcontrol software out

The first line maps 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".)

  • I've got no desire to replace anything, and you're correct in assuming that I haven't really got authorization to make any configuration changes to the terminal server. – Matthew Bruna Aug 7 '18 at 20:16
  • I'm Learning stack exchange as well. Accidentally Sent the comment early and took too long editing it. Not changing the system, I've been trying to find a transparent solution that runs on the workstation's side. One of the engineers suggested I use my down time to try and research a solution to automate some CLI configuration (our better engineers get stuck painfully pasting lines into console window, by hand). I'm vaguely informed that security demands It SSH to the terminal first, not telnet to port 200N, different clients have partial access to some of the lines involved. – Matthew Bruna Aug 7 '18 at 20:39
  • I swear someone reinvents this wheel every week. I think the current shiny is an Ansible module. I've had perl scripts to do it for over twenty years. – Ricky Beam Aug 8 '18 at 3:29
  • As others have stated, the amount of serial console cut-n-paste should be minimal. Get enough configured to reach it across the network; from there any number of methods are available to add/modify/replace configuration(s). (unless you're working with a Lucent 5ESS that has no network, or Alcatel 600E that only speaks ISO CLNS) – Ricky Beam Aug 8 '18 at 3:32

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.


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

         | "Console" Port (RS-232/USB/Bluetooth/...)
  |             |
  |             o-------->
  |             |
  |             o--------> Network Interfaces
  |             |
  |             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
            |           |
            |                 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, 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 2001' from your laptop will directly take you to the console port of device A, 'telnet 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.