How to Configure a Cisco Console Router
- select the contributor at the end of the page -
A console server is a device which, via serial ports, has access to the physical console port of several different devices commonly located in the same rack. These are most commonly seen in two different environments: labs, where a number of different pieces of equipment will be located in close proximity and constant access to the console is essential (as the configuration changes often) and the second is in remote environments where companies locate equipment without easy access to remote personnel.
Cisco Console Router Basics
For those looking to set up a reasonably priced lab environment the older Cisco 2509 (8 ports) and 2511 (16 ports) should be considered. While these are certainly a bit dated they still work fine in many environments (including mine) and operate on little power and in flexible environmental conditions. For those looking to get a more modern equivalent device there are now HWIC modules (HWIC-8A, HWIC-16A) that support the same number of serial ports as the older 2509 and 2511 devices.
In either case, they utilize what is referred to as an octal cable which connects to the device with a single connector and has 8 different serial RJ-45 connectors on the other side which connect directly to the serial port of other Cisco devices (Shown in Figure 1). These cables can be found online for a reasonable price.
Figure 1 - 8-port Cisco Octal Cable
Cisco Console Router Configuration
The configuration of a console router is not overly complex. Since most Cisco (and other) equipment defaults to the same console settings (9600, 8, 1, Hardware) only some minor changes need to be added to ensure a good console experience. The steps to configure the console lines are shown in Table 1:
Table 1 - Console Line Configuration
|1||Enter privileged EXEC mode||Console>enable|
|2||Enter device configuration mode||Console#configure terminal|
|3||Enter line configuration mode|
Note: the numbers that are used depend on the specific platform; for the 2509 they are ‘line 1 8' for a 2511 they are ‘line 1 16'
|Console(config)#line 1 16|
|4||Disable EXEC processing|
Note: This ensures that an EXEC process can't capture the line for incoming connections
|5||Disable EXEC timeout|
Note: This ensures that the line is kept open until purposefully closed
|Console(config-line)#exec-timeout 0 0|
|6||Enable input telnet transport|
Note: The type of connection used to connect to another device's console port through a console router is referred to as a ‘reverse telnet'
|Console(config-line)#transport input telnet|
The next part is to configure easy access to those connected devices, but first let's cover why this is necessary. To create a connection from the console router to another connected device's console port the user has to initiate a telnet connection to the console router using a port number that maps to the specific line.
For example, on the 2511, if a device's console was connected to line 5 then a telnet connection would be initiated to console_router_ip_address using port number 2005 (for the 2511 line 1 maps to 2001 and line 16 maps to 2016 with the other lines mapping following this order). The specific mapping that is used depends on the platform. On platforms where the console ports are connected off an add-on module then what slot the add-on module was inserted into would also affect the port number to use.
Once these numbers have been initially mapped out it is certainly not that convenient to remember each of these port numbers every time access to the lab is needed. To get around this it is common to configure a local hostname list. For example, if Router1 was connected off of line 6 and Switch 1 was connected off of line 12 the user would either have to access the console and telnet to the specific ports (2006 and 2012, respectively) or a hostname could be associated with a hostname/IP address/Port. Table 2 shows an example of the configuration needed to perform this:
Table 2 - IP Hostname List Configuration
|7||Exit into global configuration mode||Console(config-line)#exit|
|8||Configure a local host entry|
Note: An example of this would be:
Console(config)#ip host Router1 2006 console-ip-address
|Console(config)#ip host hostname port-number ip-address|
For small lab environments it is common for console routers to only be accessed via a single Ethernet connection. This is fine for lab environments, but if the console server is being used as part of a larger Out-Of-Band management plan for a production network, this single point-of-failure is unacceptable. In these situations, multiple points of access to the console router are often required to meet redundancy requirements.
On newer platforms this can be done through multiple Ethernet connections through diverse switches and/or via a backup method like dial-up. In both cases the IP address being used to access the device is different depending on the access method. It is because of this that loopback IP addresses are typically configured on console routers which are then used in the console routers ip host statements. This way, regardless of access method, the ip host statements would still work and connect the user to the correct device. The configuration for this is shown in Table 3:
Table 3 - Loopback Interface Configuration
|9||Create a loopback interface||Console(config)#interface loopback 0|
|10||Configure an IP address for the interface|
Note: The IP address used can be used only locally or it can be integrated into a wider IP addressing plan
|Console(config-if)#ip address 10.10.10.10 255.255.255.255|
Assuming the configuration shown in Table 3 was entered, the configuration for Router1 shown above would be ip host Router1 2006 10.10.10.10. To access it via the console router the command telnet Router1 would be used.
As the cost of used Cisco equipment continues to come down and the interest in Cisco certification continues to rise, it is becoming more common for those getting into the field to invest in a lab. Adding a console router to this environment makes the access to the lab easy and allows the student to play around with a number of different configurations without having to worry about physical access or by inadvertently closing access to the device.
For those looking to deploy console routers into production environments, the question is why have you waited this long? Out-Of-Band options are an important part of any production environment and should be a consideration from the beginning of the planning stages.
Regardless of the environment it is the intention of this article to get the console router up and going as soon as possible. Hopefully the article fills these requirements and gets the reader one step closer to the final solution.