Unfortunately, Cisco devices are not at the point where they can automatically configure themselves. With that being said, each Cisco device that contains an IOS (internetwork operating system) must have some interface in which you, the expert Cisco administrator, can interact with the operating system to perform any administration, configuration, and troubleshooting services.
This article explores the options available for interacting with Cisco IOS using the command-line interface (CLI). In the future article “Understanding the Cisco SDM”, you will see that Cisco has simplified some Cisco device administration by creating a graphical user interface (GUI) in which many configurations and verification commands can be performed using a web browser.
Granted this is a great tool for many tasks; however, you will inevitably need to access the CLI of Cisco IOS to perform tasks outside of the GUI’s capabilities. As a consequence, you will need to understand the command hierarchy of the IOS CLI to accurately navigate your way around to achieve your administrative goal.
This article also looks into the multiple boot-up steps that occur when a Cisco router or switch is powered on, and how you can manipulate that startup sequence.
Terminal options
After starting a router configuration using the console port or Auxiliary Port, you can choose from among several options to gain access to Cisco IOS software. These access methodologies are commonly referred to as EXEC sessions. Assuming that the device model and IOS supports them, certain Cisco devices can support up to five means of gaining an EXEC session to that IOS, which are discussed in the following subsections.
Console port
Several Cisco devices do not have a default IP address that can be utilized to gain access to the IOS. Therefore, administrators gain initial out-of-band terminal access to Cisco devices via the console port.
After an EXEC access is gained, you can configure the device via the CLI of IOS. To connect to a console port, Cisco supplies you with a flat rollover cable.
The pins in a rollover cable are reversed images of each other when the cable is viewed with both sides of the tabs in the same orientation.
Cisco console cables either come with two RJ-45 connectors in which a DB-9 adapter is required for connection to the PC or come with the DB-9 connector attached to one end of the cable. The 9-pin connector of the console cable connects to your terminal PC’s COM port.
Keep in mind that this management connection is for initial terminal access only and should not be confused with an actual networking Ethernet cable of any sort.
An ASCII terminal emulation software program must be running on your management PC if it is to interact with the Cisco IOS. There are several different terminal programs available, such as Hyper Terminal, Tera Term, Secure CRT, and others.
The terminal setup of the COM port connected to the rollover console cable must be set to the following default console parameters: 9600 baud, 8 data bits, 1 stop bit, and no flow control. After the terminal is set up correctly and you have powered on the Cisco device, you should see the output from your console EXEC session in the terminal window.
Auxiliary Port
Certain Cisco models may contain another out-of-band management port called an auxiliary (AUX) port. This port is very similar to the console port in that it uses a rollover cable and has an RJ-45 connection to the Cisco device.
The difference between the auxiliary and the console port is that the auxiliary port has flow control capability, which is useful for analog modem connectivity. By connecting an external modem to this management port, you can dial into the modem remotely and gain an EXEC session without being physically next to the Cisco device.
Telnet
As discussed in the previous article, “Standard Internetworking Models,” Telnet is an Application layer protocol of the TCP/IP protocol suite that uses TCP port 2 to gain virtual terminal emulation to a device.
Telnet is considered in-band management because it is required to have IP connectivity to the Cisco device into which you are trying to Telnet. Most Cisco devices allow at least 5 Telnet EXEC sessions to be connected for remote terminal access. For the sake of security, there is some configuration involved to allow Telnet access into the Cisco devices.
HTTP and HTTPS
Similar to Telnet, HTTP and HTTPS are also Application Layer protocols of the TCP/IP protocol suite. HTTP uses TCP port 80 to establish a management connection to the Cisco device.
HTTPS is a secure version of HTTP over Secure Socket Layer (SSL) and uses TCP port 443. HTTP and HTTPS terminal sessions require IP connectivity to the Cisco device, making it an in-band management communication methodology. The key difference between HTTP/HTTPS and Telnet is that when you use HTTP or HTTPS, you can have a graphical interface to the configuration and administrations features of the Cisco IOS.
The HTTP EXEC session is made possible by an HTTP server service that can run if configured on the Cisco device. For security purposes, some Cisco routers do not have this functionality enabled by default. If this functionality is not going to be utilized, it is recommended that you disable this service to avoid any security vulnerabilities.
SSH
Imagine you have Telnetted into a Cisco device and it is prompting you for a password. If an attacker has the capability to eavesdrop on that Telnet terminal session, he could very well detect the password because the Telnet communications are in cleartext.
With SSH (Secure Shell), you are provided a secure terminal EXE connection through the use of encrypted communications between your terminal client and the Cisco device.
Your terminal application must support SSH to connect securely to your Cisco device. Some terminal programs that support SSH are Secure CRT and Putty. In addition, the version and feature set of the Cisco IOS must support SSH. Similar to its brother in-band protocols, SSH also requires initial configurations before gaining access to an EXEC session. Granted, this additional configuration may seem tedious; however, the benefit of having secure remote terminal connections to the Cisco devices outweighs the work involved.
Review Break
| In-band versus Out-of-band | Cabling | IP connectivity Required | Notes | |
| Console | out-of-band | Rollover | No | Requires physical connectivity. |
| Auxiliary | Out-of-band | Rollover | No | Requires external modem for remote connectivity |
| telnet | In-band | Network cable | Yes | Can support at least five connections to most Cisco devices. |
| HTTP/HTTPS | In-band | Network cable | Yes | Must be enabled on Cisco routers. Should be disabled if not utilized. |
| SSH | In-band | Network cable | Yes | Requires SSH compliant terminal emulation program and specific Cisco IOS version and feature set. |
Router/switch Startup Procedures
Now that you have an understanding of how to connect to the Cisco IOS, you can now look at the startup procedures for a Cisco router or switch to determine how the IOS is loaded and running in the first place when you power on those devices.
Additionally, these devices would be doing us a huge administrative injustice if they did not load the configurations that you have toiled over in previous EXEC sessions (despite the obvious level of job security). Thus, you also need to look into how a saved configuration is applied after the IOS is loaded.
As you will see, each of the memory components that were discussed here, “Introduction to Cisco Routers and Switches” performs a pivotal part in the storing, loading, and running of the IOS and the configuration.
Router and switch startup procedures are extremely similar to a computer’s boot-up process. For instance, when you turn on a computer, the computer utilizes ROM (Read-only memory) chips to perform a POST (Power-on self-test) to check the critical hardware initially for a startup.
Then it consults the BIOS (Basic Input/output system) settings to determine the order in which to search the hard drives, floppy drives, or CD drives to locate the operating system. After the operating system is loaded, it applies any custom configurations you have made in the past and utilizes those settings toward its normal operation.
Similarly, when you turn on a Cisco router and a switch, ROM chips perform POST and then load the IOS process. You can manipulate the location sources of the IOS similar to specifying the boot drive in the BIOS settings on a computer. After the IOS is loaded, you saved configuration is loaded and applied to the device’s operating functions. The next section delve further into the specific processes that are occurring at each stage.
POST
When you first apply power to a Cisco router or switch, a specialized ROM performs a series of tests of the critical hardware components that are pertinent for startup and basic operation such as Flash Memory, CPU, and interfaces. It makes sense to utilize ROM chips for this service because they are already hard-coded with their programs and they do not require constant power to keep those programs stored in the memory. If a failure occurs during this stage of the startup process, you may encounter one of several outcomes, ranging from a non-functioning interface all the way to complete device failure. In any case, your equipment should be under warranty or you have an active support contract in place to fix the failing hardware.
Bootstrap
After the hardware passes all its tests (if only the CCNA was that easy), another ROM seeks out the operating system in accordance to its programming routines. The code that is run in the ROM is commonly referred to as the bootstrap code. If a failure occurs at this stage of the boot-up process, your Cisco device could very likely enter what is known as a ROM monitor or commonly called ROM mon.
ROM mon
In your travels, if you or someone else has ever coined the phrase “hit rock bottom” you have a general idea of what purpose ROMmon serves. The ROM Monitor is a very limited code set that enables you to perform elementary functions to manually get the router or switch back to a functioning state. You can perform low-level diagnostics and even copy a new IOS file to the Cisco device over the console port or configure TFTP information so the device can download the IOS image off of a TFTP server.
ROM mon is also utilized during password recovery on a Cisco router to make it possible to tell the device manually to ignore any saved configurations (including the password). It is possible to force your Cisco device to go directly to ROM mon on boot by sending a break sequence in your terminal session in the first 60 seconds of boot up.
You can tell you are in ROM mon mode if you are presented with a command prompt that looks like rommon 1 >. Any time you type a command in ROMmon, the number at the prompt increaments by one (rommon 2 >, rommon 3 >, and so on).
IOS loading
Up to this point, the cisco router or switch has performed only initial diagnostics. With that being said, the IOS itself still has not been located or loaded. The bootstrap’s programming has a specific search order which it typically follows to locate and load the IOS. I say “typically” because you can alter the natural order of things with the router or switch’s startup process if you manipulate something called the configuration register.
Located in NVRAM, the configuration register is a 16-bit (4 hexadecimal characters) value that specifies how the router or switch should operate during initialization. For instance, 0x2102 (0x signifies all characters that follow are hexadecimal) is a common configuration register that specifies that the router or switch should boot in its typical fashion.
However, if you manipulate certain characters in the configuration register, you can manually modify the startup process to load the IOS from locations other than the default. Specifically, the last hexadecimal character in the configuration register, known as the boot field, is the value that dictates where the bootstrap code can find the IOS. The possible boot field values are as follows:
- 0x2100 When the boot field is a zero, the configuration register instructs the bootstrap to boot directly into ROM and load ROMmon.
- 0x2101-0x210F When the last field in the configuration registers is 1-F, the router or switch boots normally.
Assuming the configuration register is 0x2102 (the default configuration register), the next step for initialization is to have the bootstrap search the configuration located in NVRAM to see whether the Cisco administrator has placed a command telling the router or switch specifically where to boot. The tools to do this are known as boot system commands. For example, if you have previously configured your device and put in the boot system tftp c2600-do3s-mz.123-5.T1172.16.1.1 command, you have instructed the bootstrap to load the IOS file c2600-do3s-mz.123-5.T1 from a TFTP server located at 172.16.1.1.
If the default configuration register is utilized and you have not configured the device with any boot system commands, the default action of the bootstrap is to load the first IOS file in Flash memory. After the file is found, it is decompressed and loaded into RAM. At this point, the IOS is successfully loaded and running on your Cisco device.
What would happen if the IOS image were corrupted or missing? As with many functions of Cisco devices, a couple of failsafes are put in place to keep the device in an operating state or a mode in which you can get it back to an operating state. Specifically, if the Cisco router or switch cannot locate a working IOS file, it broadcasts out all interfaces in the hopes that a backup IOS file is stored on a TFTP server on its connected segments. If there isn’t a TFTP server or the TFTP server does not contain a valid IOS file, the next failsafe for the IOS is to boot to ROM mon where you can copy the IOS over via the console or TFTP.
Configuration Loading
With the IOS loaded, the router or switch is now able to apply any saved configuration parameters. NVRAM is the first location where the device searches for the configuration. Here, a file called startup-config contains all the previous configurations that were present the last time an administrator saved the configuration. As the name states, this is the configuration that is loaded each time the Cisco device starts up. Similar to the IOS, after this configuration file is found, it is loaded into RAM as well. After the configuration is loaded and running at this point, it is conveniently referred to as running-config.
Cisco devices do not ship with a complete startup configuration, which is why you might have to initially configure your Cisco device through some means of out-of-band management such as the console or auxiliary port. So the question begs, what happens when you initially turn on a new Cisco router or switch, or if someone erases the startup configuration?
Many Cisco devices attempt to do an auto-install by downloading a configuration file from an active TFTP server (similarly to the IOS) when they detect that the startup-config is not located in NVRAM. Typically, these files contain enough configuration parameters (such as IP addresses for interfaces) for you to Telnet into the device and configure the remaining parameters.
If the Cisco device finds an auto-install configuration file from a TFTP server, the device loads the file and makes that the running-config. On the chance that you were not proactive enough to have an auto-install configuration on your TFTP server, the router or switch prompts you for something called setup mode.
Setup Mode
With non-CCNA technicians in mind, Cisco created Setup Mode so you can build a working configuration on a device without having to memorize the nuances of the CLI of the IOS.
Setup Mode is a friendly interactive dialog in which the IOS asks the administrator questions about common configuration parameters that enable the Cisco device to have basic operations. The Setup Mode dialog initially asks you whether you wish to continue with Setup Mode. If you answer to “NO” to this question, you exit out of Setup Mode and are brought immediately to a CLI EXEC session.
In addition, if you want to cancel at any point in the Setup Mode and get to the command prompt, you can use Ctrl+C to terminate the setup dialog. After you complete all questions, Setup Mode displays the parameters that you specified and asks you whether you want to use this configuration. If you answer “YES”, the Cisco device saves your configuration and applies the settings to the device’s operations.
Password recovery
As we’ll see next, you can secure access to your Cisco devices in several ways. In times where you inherit a pre-configured device or accidentally forgot or misconfigured a password, you need some loophole in the boot-up process that enables you to regain access to the device. Once again, the configuration register plays a pivotal part in the quest to manipulate the natural order of the Cisco device initialization.
The third character in the configuration register enables you to tell the devices to ignore any configurations that might be saved in NVRAM. If this field is changed from 0 to a 4, the device inevitably boots into Setup Mode because the router or switch is fooled that there is no startup configuration. Now, with the configuration register changed to 0x2142, you can reconfigure the Cisco device creating your own unique passwords and save that configuration for future device startups.
Review Break
To solidify the startup process, the following is a recap of the stages of the boot-up, any fall back procedures, and the memory locations involved:
- POST, located in ROM, tests hardware.
- Bootstrap, located in ROM, looks at the boot field in the configuration register to locate IOS. 0x2100 boots to ROMmon located in ROM.
- 0x2101-0x210F prompts bootstrap to parse startup-config in NVRAM for any boot system commands. If it finds any commands, it does what they say.
- If no boot system commands are found, the first file in Flash is loaded. If no file is found in Flash, TFTP boots. If no IOS file is found from TFTP, the device goes to ROM mon in ROM.
- After IOS is loaded, the configuration register is checked. If it is 0x2142, ignore start config in NVRAM. If it is 0x2120, load startup-config in NVRAM. If there is no startup-config, TFTP auto-install. If no TFTP auto install configuration is found, enter Setup Mode.