[TABLE]
While it may be hard to believe, many administrators only think about the router's Internetwork Operating System (IOS) and configuration after disaster strikes. Corrupted IOS versions, lost router configurations, or being locked out of a router because a password was changed or lost -- these things happen to other administrators, not you.
What about IOS upgrades, how do you handle those? Each major release of the Cisco IOS (a major release is a mainline version number (i.e., 10, 11, 12) followed by a release version number (i.e., X.1, X.2, etc) has a three-year lifespan. It usually takes about a year before a release moves from Limited Deployment (LD) to General Deployment (GD) and then there are the numerous Early Deployment (ED) releases that provide IOS enhancements and bug fixes. Controlling how the router gets its operating system and configuration information is often taken for granted, but it shouldn't be.
This article focuses on working with the IOS image and router configuration files, reviewing the router's default bootstrap behavior, and looks at implementing alternative IOS loading and configuration loading options. We also include an overview of Internetworking File System (IFS) file management tools.
The IOS, router memory and datasets
All Cisco routers (most Cisco products, for that matter) run the IOS. The IOS is a kernel based operating system optimized for network communications. In terms of actual media, the "IOS" is a single self-decompressing binary image that is loaded from a local or remote storage point. On Cisco routers, for the most part, there are two types of local storage media: FLASH, which can be either Linear FLASH or ATA-PCMCIA Compact Flash and NVRAM, a small chunk of RAM between 32 K and 128 K in size. This is kept alive by a battery in the system board so the contents are not lost. IOS images are stored on FLASH and the system configuration is stored on NVRAM.
Being software,
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
the IOS must be loaded into the router's system RAM memory in order for the router to function. In fact, pretty much everything happens in RAM on Cisco routers. That's because of speed. RAM operates at the same bus speed as the processor and does not have the added overhead of needing to be fetched from physical magnetic media through repeated "reads" from a mechanical drive head. In addition to the IOS, the router's RAM also contains a number of key datasets. Routing tables, switching caches, ARP tables, packet and queuing buffers all reside in RAM. So the amount of installed RAM a router has partly determines overall performance. Simply put, if the router does not possess enough RAM to store the IOS and the various tables and caches needed for the router to function, it crashes. It is critical that you follow Cisco's memory allocation recommendation and keep aware of your memory utilization once the device is in production. While Cisco provides memory guidelines, they are not natural law. If you have deployed the wrong router with the wrong resources, be assured there will be problems.
There is also one other key dataset stored in the router's RAM that is not a direct component of the IOS. This is the router's system configuration. Once the IOS is loaded up and running, the router needs a number of operating parameters configured before the router can actually perform any useful function. Like the IOS, the router's configuration data is also stored as a single binary file named "startup-config" that is stored and loaded from the router's NVRAM or FLASH if need be. Once the configuration data is loaded into RAM, the configuration is named "running-config." The running-config file is modified whenever a change is made to the router through the CLI or over the network using TFTP, FTP, RCP, and SNMP and, in certain IOS versions, SCP. All changes made to the router configuration are applied instantly. However, new changes are only carried down to the startup-config by executing a <write memory> command or a <copy running-config startup-config>.
Controlling the router boot process
How the router determines which IOS and configuration data to load is determined by two factors. The primary attribute is the router's configuration-register setting. The secondary is the <boot> configuration setting contained in the "boot-start" section of the startup-config. These two variables in combination inform the router of the IOS image and configuration data it should when the router boots. Before we get into the details of how to change the boot behavior of the router, let's review the router's "default" bootstrap behavior:
Now that we have some idea of how the router behaves when if follows the default boot process, let's take a look at the prime mover of the router's boot behavior -- the configuration-register.
Setting the configuration-register and the ROM monitor (rommon)
The only reason to make changes to the configuration-register value is in the case of two catastrophic events (now you get the prime-mover reference). The first case is when the IOS has become corrupted. The second is when you have forgotten the password on the router. In the case of the former, be prepared for a painful process of loading the IOS over the console port via X-modem (yuck). In the event of the latter, you should be ashamed of yourself (unless the router was hacked) for not sharing information of that importance with at least one other person on your team. At the very least, you should have the information on paper, stored in a safe place.
Even though you should never need to modify it you may want to know what the configuration-register actually is. The configuration-register is a 16-bit value that sets a number of low-level diagnostic and operational values including:
In its first incarnation, the configuration-register was a series of jumpers on the AGS system board. As the Cisco product line evolved, it was integrated as an NVRAM value accessible through the ROM monitor or the IOS. To see the router's current configure-register setting, type the IOS exec command <show hardware> or <show version>:
Modifying the configuration-register can be accomplished either through rommon prior to the IOS booting or through the global configuration mode when the IOS is running. To modify the configure-register setting through rommon, restart the router and send a terminal break (alt-b) during the IOS loader sequence:
This will drop you into the rommon shell. You then type <confreg>, followed by the configuration-register value (see the different value options bellow) you want the router to boot with:
You must reset or power cycle for new config to take effect:
Once the configure-register value is changed, the router needs to be power-cycled or reset in order to take effect. To reset the router type <reset> at the rommon prompt:
The router should then behave in accordance to the new configure-register setting (see different setting options below.) To change the configuration-register setting in the IOS, enter global configuration mode:
Then type <config-register>, followed by the new configuration-register setting:
Then exit out of configuration mode:
When the change is complete, save the running-config to the starting-config and restart the router for the new configuration-register setting to take effect.
Like most IOS functions, there is always more then one option and they differ depending on the hardware platform. The configuration-register is no different. Here are a number of configuration-register settings that can be utilized to set the boot behavior of the router:
Password recovery: The quick version
There are a number of excellent IOS password recovery resources on the Internet by Cisco and others. But no discussion of rommon and the configuration-register would be complete without a quick overview of router password recovery. So, with that said, we'll just cover the basic process and then move on to covering the boot command options.
Working with Internetworking File System (IFS)
The <boot> configuration syntax and commands have changed as the IOS has evolved. This has resulted in the depreciation of some boot options and functional inconsistency with others. This is due largely in part to the adoption of the IFS (introduced in 12.x) and updated file system management (introduced in IOS 11.x) tools. When discussing the <boot> command options, we need to review the new file system management commands and the adoption of the universal resource locator (URL) metaphor. Here is a listing of the URL prefixes utilized by the IFS and file system management tools:
Along with the URL prefixes -- IOS 11.x also introduced an advanced set of file system manipulation commands:
<dir {fs:} or {/all}> - Prints out the listing of a specific or all available flash file systems (if multiple file system exist) with the "/all" option in place of a specific file system value. Here is an example:
<pwd> - Prints out the current file system. Here is a syntax example:
<cd {fs;}> - Used to change between file systems. Here is a syntax example:
<delete {fs:file name}> - Deletes a file from the file system. The command behaves differently depending on the file system it is used on. On NVRAM file systems, the file is immediately purged. On FLASH file systems, the file is "marked" as deleted. This allows the file to be recovered with the <undelete {fs:file name}> command. In order to purge the file (and free up actual space on the file system) the <squeeze {fs:file name}> command must be run to purge the file. Here is an example:
<format {fs}> - Erases the file system.
<rename {fs:file name}> - Renames a file.
<more {fs:file name}> - The <more> command functions in quite the same way the Unix version does. For non-Unix users, <more> is a file parser that allows you to move forward or backwards through any text file. This tool allows you to view any text file on a local or remote file system. Here is an example of looking at another router's configuration backup on the TFTP server:
Now that you are familiar with the IOS IFS file system management commands, we can have the brief discussion about boot commands.
Setting up alternative boot and configuration options
The "boot start" statements are located in the top portion of the router's startup-config following the <hostname> value. As of IOS 12.3, this configuration region is now indicated with the < boot-start-marker> and < boot-end-marker> entries. Here's an example:
We briefly covered the use of the <boot> command in configuration-register and rommon section above. Now we'll take a look at how the <boot> configuration option is implemented in the IOS. There are four boot option commands:
Conclusion
Well, that about covers setting router bootstrap options. I hope that you found this article informative and a good use of your time. As always, questions, comments and article topic suggestions are welcome. Please e-mail us and let us know!
