Want to learn more about router and switch management? Automatically sign up for our free Cisco Routers and Switches newsletter, delivered each Friday!
Does this situation sound familiar? You're working from home on a firewall, router, or switch, and you manage to lock yourself out of the device. You end up driving to the office to reverse the configuration or reboot the device.
How about this one? The network's down, and you need quick and easy access to the console ports of all network devices. You find yourself running around the network racks with your laptop—connecting to every console port, one at a time.
However, there's an easier way around such problems. Using a Cisco router and an asynchronous module or a router with built-in async serial ports, you can enjoy full console connectivity to a number of network devices in a room or data center.
I've set this up in the network room of my data center using a Cisco 2511 router, and it's definitely made my life easier in times of trouble. When I need to connect to the console of these network devices, I can either Telnet to the console server and Telnet to the device I'm trying to connect to, or I can Telnet directly to the console on the device.
I tend to go with the first option because I rarely remember the port numbers I need to Telnet directly to the devices. In the rare occasion that the network freezes up, I can go directly to the console server's console and access the consoles of all network devices from one place.
You don't necessarily have to use a 2511 router to accomplish this. However, a used 2511 router (Cisco no longer makes them) is one of the least expensive models you can buy for this purpose.
If you're not working with a large amount of devices, you can also use a 2509 router, which has eight serial ports. (The going rate for a used Cisco 2509 router on eBay averages about $200.)
You can also accomplish the same thing with more modern routers, including 2610, 3620, 3640, or 3800 series routers. With these, you would use an NM-16A or NM-32A module. The NM-XXA modules are asynchronous port modules with either 16 or 32 ports.
To set this up, I took a Cisco 2511 router and ran one of the async serial ports to each of the consoles on my core network switches, routers, and firewalls (as well as any device that has a serial console). Next, I configured the new Cisco terminal server with the following ip host commands to make it easier for me to connect to each device.
ip host internet 2016 10.253.100.19 ip host gig_switch3 2015 10.253.100.19 ip host dmz_switch 2013 10.253.100.19
The third section of each command contains the port number for the devices, and the last two digits of the number designate the port. For example, 2016 follows the first router ("internet"), meaning this router is on port 16. The last part of the command contains the IP address of the Ethernet port on the console server.
Here's the best part: By creating these names, you don't need to know which port the device is on. All you need to do is Telnet to the host (in this case, internet) off of the console server.
You could also reach this device directly from a PC. For example, you could Telnet to 10.253.100.19 2016 from your PC. This tells the Telnet client to go to port 2016 instead of the default Telnet port 23.
To see a sample of my configuration, check out Listing A.
Managing multiple connections
After you Telnet to the console server and connect to these devices, you need to know how to manage multiple connections at the same time. This can help you more easily compare configurations and troubleshoot.
Follow these steps:
- To Telnet to a device you've configured with an IP host, just enter the hostname at the command line. This is connection #1.
- To go back to the command line without disconnecting, press [Ctrl][Shift]6, and then press x. This displays the console server prompt.
- From here, you can Telnet to another device by entering its hostname from the ip host list. This is connection #2.
- Once connected to that router, press [Ctrl][Shift]6 again, and then press x to return to the console server prompt.
- Enter show sessions. This command lists your sessions. For this example, you have two sessions—one to the first router and one to the second router. To disconnect from either session, enter disconnect X, where X is the connection number (in this case, 1 or 2).
- To go to either session, enter the session number (again, either 1 or 2). Or, hitting [Enter] on a blank command line also takes you back to your previous session.
A note of caution: If you try to go back to an existing session by entering the name you gave it in the ip host command, it will return, "Connection refused by remote host." This means that either you already have a connection or someone else has connected to that console port.
Balancing convenience and security
Keep in mind that security and convenience are always trade-offs. As you know from airport security, the more security you have, the less convenient it is. It's important that you find a compromise between the two that best suits your organization's needs.
Any time you put all of your eggs into one basket—in this case, all access to core network equipment connected to the same console server—security needs to be top-of-mind. As always, you should put a console password on all network devices. If someone gains access to the console server, the intruder will only be able to access devices that have no console authentication.
In addition, you should also configure the consoles on those servers with an exec-timeout. That way, if you disconnect, the consoles log out within seconds.
You may also be wondering how you'll be able to Telnet to the console server if the network is down, a valid concern. You could install a dial-up modem on the console server and, in a worst-case scenario, remotely dial into the console server. On the other hand, security managers all over the world will cringe at this solution. However convenient it might be, it opens up your core network devices to dial-up hackers all over the world.
Finally, remember that any Telnet communication over a network contains no encryption. Therefore, we're transmitting the core network device usernames and passwords in our example over the network in clear text. However, you can accomplish the same thing using SSH instead of Telnet. Again, you need to find a balance between convenience and security, according to your organization's needs.
David Davis has worked in the IT industry for 12 years and holds several certifications, including CCIE, MCSE+I, CISSP, CCNA, CCDA, and CCNP. He currently manages a group of systems/network administrators for a privately owned retail company and performs networking/systems consulting on a part-time basis.