Router/Switch Startup Procedures
Objective:
- Describe the operation of Cisco routers (including: router bootup process, POST, router components) 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 in Chapter 6, “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 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 a 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, your saved configuration is loaded and applied to the device’s operating functions. The next sections 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 ROM Monitor or commonly called ROMmon.
ROMmon
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 codeset 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.
TIP
Keep in mind that your default console speed is 9600bps, and a typical IOS file exceeds 16 megabytes. If you need to re-copy a working IOS to the Cisco device in ROMmon mode over the console, I recommend changing the default console speed in ROMmon to a higher speed or taking a long lunch or dinner break.
ROMmon 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 passwords). It is possible to force your Cisco device to go directly to ROMmon on boot by sending a break sequence in your terminal session in the first 60 seconds of bootup. You can tell you are in ROMmon 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 increments 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 register is 1-F, the router or switch boots normally.
TIP
In older router and switch models, a configuration register of 0x2101 (if the boot field has a value of one), the router or switch would boot a mini IOS located in ROM and commonly referred to as RxBoot. RxBoot looks very similar to the normal IOS; however, it does not provide the majority of the IOS’s services. This mini IOS provides just enough functionality to reach a TFTP server and download a working IOS to the Cisco device. You can easily determine you are in RxBoot if the prompt looks like Router(boot)> in a router or Switch(boot)> in a switch.
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-do3smz.123-5.T1 172.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.
NOTE
Do not confuse this step with loading the configuration. This is just a step in the IOS loading process that enables the bootstrap code to implement any configuration specifications you previously saved that told the device where to boot. The configuration itself is not loaded until after the IOS is located and running.
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 ROMmon 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.
EXAM ALERT
The running-config is the active configuration running in RAM.
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 autoinstall 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 autoinstall 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 autoinstall configuration on your TFTP server, the router or switch prompts you for something called Setup Mode.
EXAM ALERT
It is imperative that you can identify the steps that a switch or router follows during initialization, the memory or device architectures where these steps occur, and the fallback sequences when a failure has occurred in the boot-up sequence.
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. Illustrated in Figure 7.2, the Setup Mode dialog initially asks you whether you wish to continue with Setup Mode. If you answer “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.
FIGURE 7.2 Setup Mode dialog.
TIP
Throughout the configuration with the IOS, you may encounter several different types of interactive dialogs similar to Setup Mode. To save yourself from unnecessary typing, you can use the default value that is located in the brackets to answer any single-answer question by simply hitting the Enter key. For example, notice in Figure 7.2, the Enter host name prompt contains the word Router in brackets. If you were to press the Enter key at that prompt, this Cisco router would have a host name of Router.
Password Recovery
As the next chapter explains, you can secure access to your Cisco devices in several ways. In times where you inherit a pre-configured device or accidentally forgot or mis-configured 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 Cisco device initialization.
The third character in the configuration register enables you to tell the device to ignore any configurations that might be saved in NVRAM. If this field is changed from a 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.
CAUTION
Don’t Forget the Natural Order Do not forget when performing password recovery to set your configura tion register back to 0x2102. Failing to do so forces your router to constantly ignore your configurations, causing your router or switch to repeatedly enter Setup Mode.
EXAM ALERT
Be sure to recognize that a configuration register of 0x2142 is a typical setting for performing pass word recovery.
REVIEW BREAK
To solidify the startup process, the following is a recap of the stages of the boot-up, any fallback 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 ROMmon in ROM.
- After IOS is loaded, the configuration register is checked. If it is 0x2142, ignore startup-config in NVRAM. If it is 0x2102, load startup-config in NVRAM. If there is no startup-config, TFTP autoinstall. If no TFTP autoinstall configuration is found, enter Setup Mode.
