For a long time, we have used Cisco terminal servers to access the CLI of our network devices. This was fun and all, but we had to connect using octal cables which meant we needed a particular type of Async module on the Cisco router. This interface type allowed the router to function for reverse telnet and reverse SSH.
In this scenario, you would have one interface on the router that connected to the management LAN. That IP address is used for out-of-band management purposes. You then telnet to this IP address and specific port number which would access one of the lines of the octal cable. You then have access to the console of your Cisco router. These were often called one-armed bandits.
There were also routers used in the core that served a dual purpose. These routers in the core might have dual NICs and dual IPs. One set would be for management and the other for core operations and forwarding.
A third deployment we would see would be a high-density rack where routers would be loaded up with these serial Async interfaces, and we would use patch panels to route the console to devices all over the place. These routers serving as console servers did the job. In fact, I've created many menus to make these as simple as possible for an end user to access the console. The menu looked something like the following:
menu MYMENU prompt ^ Please make a selection: ^ // "#" DOESN'T WORK, USE "^" menu MYMENU text 1 Connect to Rack1 ASA1 menu MYMENU text 2 Connect to Rack1 ASA2 menu MYMENU text s Show all established sessions menu MYMENU text e Exit Menu menu MYMENU text c# Clear the session by number, example: c1 menu MYMENU text q Quit TS session
Creating something like this was very time consuming but we did it. Now the issue with this is that you first had to SSH or telnet, to the IP address of the terminal server, and then from there, the menu would get you into various console devices. It was always a two-step process. That's true unless you knew the port number in which you could telnet directly to the device like this:
telnet 10.0.1.100 2001
Not bad, but you had to know the port.
So what's the problem with this method you ask? A router is not purpose built for out-of-band access. Sure it can do it, but it's a router and its designed to route. Using this method adds a little bit of complexity not only in creating menus to simplify the connection process but also for the connection itself. Enter the OpenGear CM7196.
SEE: Server deployment/migration checklist (TechRepublic)
The OpenGear CM7196
The opener CM7196 can take a 4U device and squash that down to a 1U appliance, so I like it because it saves me some rack space. And configuring it is pretty simple. The LAN interface has an IP address assigned to it, so initially, you just connect a cable, set your IP address and browse to the web interface.
Once you're in you should change the admin password and create your account. You can also integrate it with an external AAA setup. I didn't show this, but it's not hard.
When you add a user, you need to define the username, select the groups they have access to, and then set the password.
As you scroll down the add user page, you'll have an option to select all the ports that the user has access to for direct SSH or telnet. In this case, I am allowing my new user to access all ports.
Next, I need to make sure that the console port settings are correct and that the ports enabled. Go to Serial Port and then edit the port.
On the specific port you can set the baud rate, data bits, stop bits, parity and flow control. Also you would check the box to enable telnet or SSH. In this case, I only enabled SSH.
At this point, you have enough to get going. You can save the config and connect one end of a cable to the first port on the CM7196 and the other to a console port on a Cisco device (Or any networking device for that matter).
SEE: Wireless networking policy (Tech Pro Research)
What have you accomplished?
At this point, you have created a transparent replacement for that old terminal server that uses the same connection methods as before, only now you are using a purpose-built device. But really, this is just the tip of the iceberg. Also, you can SSH directly to a port using its name. Here's how this works:Start by defining an Alias on the port.
Next from a CLI telnet to the device using its name or Alias. My CM7196 is 10.0.2.105, and the SSH port is 3001, but I don't need to know that. My DNS server defines 10.0.2.105 as og.gcts.io.
GC084:~ bcarroll$ ssh -l bcarroll:ASA1 og.gcts.io Password: ftd1 login:
But wait, there's more. You can also use a web UI. This connection method is particularly useful for students who want to access the CLI from a link on a landing page.
There are some additional features I didn't mention, but using a purpose-built console server is most definitely the way to go today when you need secure out-of-band management of your devices. One line of thinking that some are trending towards is that we don't need CLI access since network automation is becoming more prevalent. That line of thinking isn't entirely correct. Yes, our interaction with the CLI will be much more limited regarding configuration. We can let the API interaction handle our configuration, but often a connection should still be available for troubleshooting and bootstrapping at a minimum.
- Cisco is reinventing networking with a new intuitive system (TechRepublic)
- How to set up server weight and HTTPS load balancing with NGINX (TechRepublic)
- How to quickly install OpenNMS on Ubuntu 16.04 or Debian 8 (TechRepublic)
- Cisco's 'network intuitive' the next era of networking: Chuck Robbins (ZDNet)
Brandon Carroll has been in the industry since the late 90s specializing in data networking and network security in the enterprise and data center. Brandon holds the CCIE in security and is a published author in network security.