|
|
This chapter describes the basic procedure a router follows when it reboots, how to alter the procedure, and how to use the ROM Monitor.
For a complete description of the booting commands mentioned in this chapter, refer to the "Booting Commands" chapter in the Configuration Fundamentals Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.
You can perform the tasks related to rebooting discussed in the following sections:
Perform the following tasks in EXEC mode to display information about system software, system image files, and configuration files:
| Task | Command |
|---|---|
| List the contents of the BOOT environment variable, the name of the configuration file pointed to by the CONFIG_FILE environment variable, and the contents of the BOOTLDR environment variable. | show boot (Cisco 3600 series, Cisco 7000 family only) |
| List the startup configuration information.
On all platforms except the Cisco 7000 family, the startup configuration is usually in NVRAM. On the Cisco 7000 family, the CONFIG_FILE environment variable points to the startup configuration, defaulting to NVRAM. | show startup-config |
| List the system software release version, configuration register setting, and other information. | show version |
Refer to the Configuration Fundamentals Command Reference for examples of these commands.
You can also use the o command (the confreg command for some platforms) in ROM monitor mode to list the configuration register settings on some models.
The following sections describe what happens when the router reboots:
On all platforms except the Cisco 7000 family,
On the Cisco 7000 family,
Problems can include a bad checksum for the information in NVRAM or an empty NVRAM with no configuration information. See the publication Internetwork Troubleshooting Guide for troubleshooting procedures. See the "Using Setup for Configuration Changes" chapter in this publication for details on the setup command facility. For more information on environment variables, refer to the "Set Environment Variables" section.
When a router is powered on or rebooted, the following events happen:
When the boot field is 0x2 through 0xF, the router goes through each command in order until it boots a valid image. If bit 13 in the configuration register is set, each command will be tried once. If bit 13 is not set, the boot system commands specifying a network server will be tried up to five more times. The timeouts between each consecutive attempt are 2 seconds, 4 seconds, 16 seconds, 256 seconds, and 300 seconds.If it cannot find a valid image, the following events happen:
When looking for a bootable file in Flash memory:
Figure 11 illustrates the basic booting decision process.
The configuration register boot field determines whether the router loads an operating system image, and if so, where it obtains this system image. This section contains the following topics:
Refer to the documentation for your platform for more information on the configuration register.
The lowest four bits of the 16-bit configuration register (bits 3, 2, 1, and 0) form the boot field. The following boot field values determine if the router loads an operating system and where it obtains the system image:
You modify the boot field from either the hardware configuration register or the software configuration register, depending on the platform.
Most platforms have use a software configuration register. Refer to your hardware documentation for information on the configuration register for your platform.
The hardware configuration register can be changed only on the processor card with dual in-line package (DIP) switches located at the back of the router. For information on modifying the hardware configuration register, refer to the appropriate hardware installation guide.
To modify the software configuration register boot field, complete the following tasks:
| Task | Command |
|---|---|
| Step 1 Obtain the current configuration register setting. The configuration register is listed as a hexadecimal value. | show version |
| Step 2 Enter configuration mode, selecting the terminal option. | configure terminal |
| Step 3 Modify the existing configuration register setting to reflect the way in which you want to load a system image. The configuration register value is in hexadecimal form with a leading "0x." | config-register value |
| Step 4 Exit configuration mode. | end |
| Step 5 Verify that the configuration register setting is correct. Repeat steps 2 through 5 again if the setting is not correct. | show version |
| Step 6 Reboot the router to make your changes take effect. | reload |
In ROM monitor mode, use the o command or the confreg command on some platforms to list the value of the configuration register boot field.
Modify the current configuration register setting to reflect the way in which you want to load a system image. To do so, change the least significant hexadecimal digit to one of the following:
For example, if the current configuration register setting is 0x101 and you want to load a system image from boot system commands in the startup configuration file, you would change the configuration register setting to 0x102.
In the following example, the show version command indicates that the current configuration register is set so that the router does not automatically load an operating system image. Instead, it enters ROM monitor mode and waits for user-entered ROM monitor commands. The new setting instructs the router to a load a system image from commands in the startup configuration file or from a default system image stored on a network server.
Router1#show versionCisco Internetwork Operating System Software IOS (tm) 4500 Software (C4500-J-M), Version 11.1(10.4), MAINTENANCE INTERIM SOFTWARE Copyright (c) 1986-1997 by cisco Systems, Inc. Compiled Mon 07-Apr-97 19:51 by dschwart Image text-base: 0x600088A0, data-base: 0x60718000 ROM: System Bootstrap, Version 5.1(1) [daveu 1], RELEASE SOFTWARE (fc1) FLASH: 4500-XBOOT Bootstrap Software, Version 10.1(1), RELEASE SOFTWARE (fc1) Router1 uptime is 6 weeks, 5 days, 2 hours, 22 minutes System restarted by error - a SegV exception, PC 0x6070F7AC System image file is "c4500-j-mz.111-current", booted via flash cisco 4500 (R4K) processor (revision 0x00) with 32768K/4096K bytes of memory. Processor board ID 01242622 R4600 processor, Implementation 32, Revision 1.0 G.703/E1 software, Version 1.0. Bridging software. SuperLAT software copyright 1990 by Meridian Technology Corp). X.25 software, Version 2.0, NET2, BFE and GOSIP compliant. TN3270 Emulation software (copyright 1994 by TGV Inc). Basic Rate ISDN software, Version 1.0. 2 Ethernet/IEEE 802.3 interfaces. 2 Token Ring/IEEE 802.5 interfaces. 4 ISDN Basic Rate interfaces. 128K bytes of non-volatile configuration memory. 8192K bytes of processor board System flash (Read/Write) 4096K bytes of processor board Boot flash (Read/Write) Configuration register is 0x2100 Router1#configure terminalRouter1(config)#config-register 0x210FRouter1(config)#endRouter1#reload
Because many platforms can boot images from several locations, these systems use special ROM monitor environment variables to specify the location and filename of images that the router is to use. In addition, Cisco 7000 family can load configuration files from several locations and use an environment variable to specify startup configurations.
These special environment variables are as follows:
The BOOT environment variable specifies a list of bootable system images on various devices. Refer to the "Specify the Startup System Image in the Configuration File" section in the "Loading and Maintaining System Images and Microcode" chapter of the Configuration Fundamentals Configuration Guide. After you save the BOOT environment variable to your startup configuration, the router checks the variable upon startup to determine the device and filename of the image to boot.
The router tries to boot the first image in the BOOT environment variable list. If the router is unsuccessful at booting that image, it tries to boot the next image specified in the list. The router tries each image in the list until it successfully boots. If the router cannot boot any image in the BOOT environment variable list, the router attempts to boot the boot image.
If an entry in the BOOT environment variable list does not specify a device, the router assumes the device is tftp. If an entry in the BOOT environment variable list specifies an invalid device, the router skips that entry.
The BOOTLDR environment specifies the flash device and filename containing the boot image that the ROM monitor uses if it cannot find a valid system image. In addition, a boot image is required to boot the router with an image from a network server.
You can change the BOOTLDR environment variable on platforms which use a software boot image rather than boot ROMs. On these platforms, the boot image can be changed without having to replace the boot ROM.
This environment variable allows you to have several boot images. After you save the BOOTLDR environment variable to your startup configuration, the router checks the variable upon startup to determine which boot image to use if the system cannot be loaded.
The CONFIG_FILE environment variable specifies the device and filename of the configuration file to use for initialization (startup). For the Cisco 7000 family, valid devices are nvram:, bootflash:, slot0:, and slot1:. Refer to the "Location of Configuration Files" section in the "Modifying, Downloading, and Maintaining Configuration Files" chapter for more information on devices. After you save the CONFIG_FILE environment variable to your startup configuration, the router checks the variable upon startup to determine the location and filename of the configuration file to use for initialization.
The router uses the NVRAM configuration during initialization when the CONFIG_FILE environment variable does not exist or when it is null (such as at first-time startup). If the router detects a problem with NVRAM or a checksum error, the router enters setup mode. Refer to the "Using Setup for Configuration Changes" chapter in this publication for more information on the setup command facility.
Although the ROM monitor controls environment variables, you can create, modify, or view them with certain commands. To create or modify the BOOT, BOOTLDR, and CONFIG_FILE environment variables, use the boot system, boot bootldr, and boot config global configuration commands, respectively.
Refer to the "Specify the Startup System Image in the Configuration File" section in the "Loading and Maintaining System Images and Microcode" chapter of the Configuration Fundamentals Configuration Guide for details on setting the BOOT environment variable. Refer to the "Specify the Startup Configuration File" section in the "Modifying, Downloading, and Maintaining Configuration Files" chapter of the Configuration Fundamentals Configuration Guide for details on setting the CONFIG_FILE variable.
You can view the contents of the BOOT, BOOTLDR, and the CONFIG_FILE environment variables by issuing the show boot command. This command displays the settings for these variables as they exist in the startup configuration as well as in the running configuration if a running configuration setting differs from a startup configuration setting.
Use the show startup-config command to display the contents of the configuration file pointed to by the CONFIG_FILE environment variable.
To set the BOOTLDR environment variable, perform the following tasks, beginning in privileged EXEC mode:
| Task | Command |
|---|---|
| Step 1 Verify that internal Flash or bootflash contains the boot helper image. | dir [/all | /deleted] [/long] [device:][filename] |
| Step 2 Enter the configuration mode from the terminal. | configure terminal |
| Step 3 Set the BOOTLDR environment variable to specify the Flash device and filename of the boot helper image. This step modifies the runtime BOOTLDR environment variable. | boot bootldr device:filename |
| Step 4 Exit configuration mode. | end |
| Step 5 Save this runtime BOOTLDR environment variable to your startup configuration. | copy running-config startup-config |
| Step 6 Optionally, verify the contents of the BOOTLDR environment variable. | show boot |
Router#dir bootflash:-#- -length- -----date/time------ name 1 620 May 04 1995 26:22:04 rsp-boot-m 2 620 May 24 1995 21:38:14 config2 7993896 bytes available (1496 bytes used) Router#configure terminalRouter (config)#boot bootldr slot0:rsp-boot-m^ZRouter#copy running-config startup-config[ok] Router#show bootBOOT variable = slot0:rsp-boot-m CONFIG_FILE variable = nvram: Current CONFIG_FILE variable = slot0:router-config Configuration register is 0x0 Router#
To configure the router to reload the Cisco IOS software at a later time, perform one of the following tasks in privileged EXEC command mode:
| Task | Command |
|---|---|
| Schedule a reload of the software to take effect in the specified minutes or hours and minutes. | reload in [hh:]mm [text] |
| Schedule a reload of the software to take place at the specified time (using a 24-hour clock). | reload at hh:mm [month day | day month] [text] |
If you specify the month and day, the reload is scheduled to take place at the specified time and date. If you do not specify the month and day, the reload takes place at the specified time on the current day (if the specified time is later than the current time), or on the next day (if the specified time is earlier than the current time). Specifying 00:00 schedules the reload for midnight.
The following example illustrates how to use the reload command to reload the software on the router on the current day at 7:30 p.m.:
Router# reload at 19:30
Reload scheduled for 19:30:00 UTC Wed Jun 5 1996 (in 2 hours and 25 minutes)
Proceed with reload? [confirm]
The following example illustrates how to use the reload command to reload the software on the router at a future time:
Router# reload at 02:00 jun 20
Reload scheduled for 02:00:00 UTC Thu Jun 20 1996 (in 344 hours and 53 minutes)
Proceed with reload? [confirm]
To display information about a previously scheduled reload or to determine if a reload has been scheduled on the router, perform the following task in EXEC command mode:
| Task | Command |
|---|---|
| Display reload information including the time the reload is scheduled to occur, and the reason for the reload if it was specified when the reload was scheduled. | show reload |
To cancel a previously scheduled reload, perform the following task in privileged EXEC command mode:
| Task | Command |
|---|---|
| Cancel a previously scheduled reload of the software. | reload cancel |
The following example illustrates how to use the reload cancel command to stop a scheduled reload:
Router# reload cancel Router# *** *** --- SHUTDOWN ABORTED --- ***
High system availability (HSA) refers to how quickly your router returns to an operational status after a failure occurs. On the Cisco 7507 and Cisco 7513, you can install two RSP cards in a single router to improve system availability.
Two RSP cards in a router provide the most basic level of increased system availability through a "cold restart" feature. A "cold restart" means that when one RSP card fails, the other RSP card reboots the router. In this way, your router is never in a failed state for very long, thereby increasing system availability.
When one RSP card takes over operation from another, system operation is interrupted. This change is similar to issuing the reload command. The following events occur when one RSP card fails and the other takes over:
A router configured for HSA operation has one RSP card that is the master and one that is the slave. The master RSP card functions as if it were a single processor, controlling all functions of the router. The slave RSP card does nothing but actively monitor the master for failure.
A system crash can cause the master RSP to fail or go into a nonfunctional state. When the slave RSP detects a nonfunctional master, the slave resets itself and takes part in master-slave arbitration. Master-slave arbitration is a ROM monitor process that determines which RSP card is the master and which is the slave upon startup (or reboot).
If a system crash causes the master RSP to fail, the slave RSP becomes the new master RSP and uses its own system image and configuration file to reboot the router. The failed RSP card now becomes the slave. The failure state of the slave (formerly the master) can be accessed from the console via the show stacks command.
With HSA operation, the following items are important to note:
There are two common ways to use HSA. You can use HSA for:
You can also use HSA for advanced implementations. For example, you can configure the RSP cards with the following:
To configure HSA operation, you must have a Cisco 7507 or Cisco 7513 containing two RSP processor cards and Cisco IOS Release 11.1 or later.
When configuring HSA operation, complete the tasks in the following sections. The first two and last two tasks are required for both implementations. The third task relates to simple hardware backup. The fourth task relates to software error protection only.
Because your view of the environment is always from the master RSP perspective, you define a default slave RSP. The router uses the default slave information when booting as follows:
To define the default slave RSP, perform the following task, beginning in privileged EXEC mode:
Upon the next system reboot, the above changes take effect (if both RSP cards are operational). Thus, the specified default slave becomes the slave RSP card. The other RSP card takes over mastership of the system and controls all functions of the router.
If you do not specifically define the default slave RSP, the RSP card located in the higher number processor slot is the default slave. On the Cisco 7507, processor slot 3 contains the default slave RSP. On the Cisco 7513, processor slot 7 contains the default slave RSP.
The following example sets the default slave RSP to processor slot 2 on a Cisco 7507:
Router#configure terminalRouter (config)#slave default-slot 2^ZRouter#copy running-config startup-config
With both the simple hardware backup and software error protection implementation methods, you always want your master and slave configuration files to match. To ensure that they match, turn on automatic synchronization. In automatic synchronization mode, the master copies its startup configuration to the slave's startup configuration when you issue a copy command that specifies the master's startup configuration (startup-config) as the target.
Automatic synchronization mode is on by default; however, to turn it on manually, perform the following tasks, beginning in privileged EXEC mode:
The following example turns on automatic configuration file synchronization:
Router#configure terminalRouter (config)#slave auto-sync config^ZRouter#copy running-config startup-config
For simple hardware backup, ensure that both RSP cards have the same system image.
To ensure that both RSP cards have the same system image, perform the following tasks in EXEC mode:
| Task | Command |
|---|---|
| Step 1 Display the contents of the BOOT environment variable to learn the current booting parameters for the master and slave RSP. | show boot |
| Step 2 Verify the location and version of the master RSP software image. | dir [/all | /deleted] [/long] {bootflash | slot0 | slot1} [filename] |
| Step 3 Determine if the slave RSP contains the same software image in the same location. | dir [/all | /deleted] [/long] {slavebootflash | slaveslot0 | slaveslot1} [filename] |
| Step 4 If the slave RSP does not contain the same system image in the same location, copy the master's system image to the appropriate slave location. | copy file-id {slavebootflash | slaveslot0 | slaveslot1}
Note that you might also have to use the delete and/or squeeze command in conjunction with the copy command to accomplish this step. Refer to the "Delete Files on a Flash Device" section for more information on these commands. |
The following example ensures that both RSP cards have the same system image. Note that because no environment variables are set, the default environment variables are in effect for both the master and slave RSP. Therefore, the router will boot the image in slot 0.
Router#show bootBOOT variable = CONFIG_FILE variable = Current CONFIG_FILE variable = BOOTLDR variable does not exist Configuration register is 0x0 current slave is in slot 7 BOOT variable = CONFIG_FILE variable = BOOTLDR variable does not exist Configuration register is 0x0 Router#dir slot0:-#- -length- -----date/time------ name 1 3482498 May 4 1993 21:38:04 rsp-k-mz11.2 7993896 bytes available (1496 bytes used) Router#dir slaveslot0:-#- -length- -----date/time------ name 1 3482498 May 4 1993 21:38:04 rsp-k-mz11.1 7993896 bytes available (1496 bytes used) Router#delete slaveslot0:rsp-k-mz11.1Router#copy slot0:rsp-k-mz11.2 slaveslot0:rsp-k-mz11.2
To ensure that interface processors will load the same microcode, regardless of which RSP is used, perform the following tasks beginning in privileged EXEC mode:
| Task | Command |
|---|---|
| Step 1 Determine the microcode images used on the interface processors. If all interface processors are running from the bundled system microcode, no further action is required. | show controller cbus |
| Step 2 If any interface processors are running from the flash file system, verify the location and version of the master RSP's supplementary microcode. | dir [/all | /deleted] [/long] {bootflash | slot0 | slot1} [filename] |
| Step 3 Determine if the slave RSP contains the same microcode image in the same location. | dir [/all | /deleted] [/long] {slavebootflash | slaveslot0 | slaveslot1} [filename] |
| Step 4 If the slave RSP does not contain the same microcode image in the same location, copy the master's microcode image to the appropriate slave location. | copy file-id {slavebootflash | slaveslot0 | slaveslot1}
Note that you might also have to use the delete and/or squeeze command in conjunction with the copy command to accomplish this step. Refer to the "Delete Files on a Flash Device" section for more information on these commands. |
The following example ensures that both RSP cards have the same microcode image. Notice that slots 0, 1, 4, 9, and 10 load microcode from the bundled software, as noted by the statement software loaded from system. Slot 11, the (Fast Serial Interface Processor) FSIP processor, does not use the microcode bundled with the system. Instead, it loads the microcode from slot0:pond/bath/rsp_fsip20-1. Thus, you must ensure that the slave RSP has a copy of the same FSIP microcode in the same location.
Router#show controller cbusMEMD at 40000000, 2097152 bytes (unused 416, recarves 3, lost 0) RawQ 48000100, ReturnQ 48000108, EventQ 48000110 BufhdrQ 48000128 (2948 items), LovltrQ 48000140 (5 items, 1632 bytes) IpcbufQ 48000148 (16 items, 4096 bytes) 3571 buffer headers (48002000 - 4800FF20) pool0: 28 buffers, 256 bytes, queue 48000130 pool1: 237 buffers, 1536 bytes, queue 48000138 pool2: 333 buffers, 4544 bytes, queue 48000150 pool3: 4 buffers, 4576 bytes, queue 48000158 slot0: EIP, hw 1.5, sw 20.00, ccb 5800FF30, cmdq 48000080, vps 4096 software loaded from system Ethernet0/0, addr 0000.0ca3.cc00 (bia 0000.0ca3.cc00) gfreeq 48000138, lfreeq 48000160 (1536 bytes), throttled 0 rxlo 4, rxhi 42, rxcurr 0, maxrxcurr 2 txq 48000168, txacc 48000082 (value 27), txlimit 27 ......... slot1: FIP, hw 2.9, sw 20.02, ccb 5800FF40, cmdq 48000088, vps 4096 software loaded from system Fddi1/0, addr 0000.0ca3.cc20 (bia 0000.0ca3.cc20) gfreeq 48000150, lfreeq 480001C0 (4544 bytes), throttled 0 rxlo 4, rxhi 165, rxcurr 0, maxrxcurr 0 txq 480001C8, txacc 480000B2 (value 0), txlimit 95 slot4: AIP, hw 1.3, sw 20.02, ccb 5800FF70, cmdq 480000A0, vps 8192 software loaded from system ATM4/0, applique is SONET (155Mbps) gfreeq 48000150, lfreeq 480001D0 (4544 bytes), throttled 0 rxlo 4, rxhi 165, rxcurr 0, maxrxcurr 0 txq 480001D8, txacc 480000BA (value 0), txlimit 95 slot9: MIP, hw 1.0, sw 20.02, ccb 5800FFC0, cmdq 480000C8, vps 8192 software loaded from system T1 9/0, applique is Channelized T1 gfreeq 48000138, lfreeq 480001E0 (1536 bytes), throttled 0 rxlo 4, rxhi 42, rxcurr 0, maxrxcurr 0 txq 480001E8, txacc 480000C2 (value 27), txlimit 27 ....... slot10: TRIP, hw 1.1, sw 20.00, ccb 5800FFD0, cmdq 480000D0, vps 4096 software loaded from system TokenRing10/0, addr 0000.0ca3.cd40 (bia 0000.0ca3.cd40) gfreeq 48000150, lfreeq 48000200 (4544 bytes), throttled 0 rxlo 4, rxhi 165, rxcurr 1, maxrxcurr 1 txq 48000208, txacc 480000D2 (value 95), txlimit 95 ......... slot11: FSIP, hw 1.1, sw 20.01, ccb 5800FFE0, cmdq 480000D8, vps 8192 software loaded from flash slot0:pond/bath/rsp_fsip20-1 Serial11/0, applique is Universal (cable unattached) gfreeq 48000138, lfreeq 48000240 (1536 bytes), throttled 0 rxlo 4, rxhi 42, rxcurr 0, maxrxcurr 0 txq 48000248, txacc 480000F2 (value 5), txlimit 27 ........... Router#dir slot0:pond/bath/rsp_fsip20-1-#- -length- -----date/time------ name 3 10242 Jan 01 1995 03:46:31 pond/bath/rsp_fsip20-1 Router#dir slaveslot0:pond/bath/rsp_fsip20-1No such file 4079832 bytes available (3915560 bytes used) Router#copy slot0:pond/bath/rsp_fsip20-1 slaveslot0:4079704 bytes available on device slaveslot0, proceed? [confirm] Router#dir slaveslot0:pond/bath/rsp_fsip20-1-#- -length- -----date/time------ name 3 10242 Mar 01 1993 02:35:04 pond/bath/rsp_fsip20-1 4069460 bytes available (3925932 bytes used)
For software error protection, the RSP cards should have different system images.
When the factory sends you a new Cisco 7507 or Cisco 7513 with two RSPs, you receive the same system image on both RSP cards. For the software error protection method, you need two different software images on the RSP cards. Thus, you copy a desired image to the master RSP card and modify the boot system commands to reflect booting two different system images. Each RSP card uses its own image to boot the router when it becomes the master.
To specify different startup images for the master and slave RSP, perform the following tasks, beginning in EXEC mode:
| Tasks | Command |
|---|---|
| Step 1 Verify the location and version of the master RSP software image. | dir [/all | /deleted] [/long] {bootflash | slot0 | slot1} [filename] |
| Step 2 Determine if the slave RSP contains the same software image in the same location. | dir [/all | /deleted] [/long] {slavebootflash | slaveslot0 | slaveslot1} [filename] |
| Step 3 Copy a different system image to the master RSP. | copy file-id {bootflash | slot0 | slot1}
copy flash {bootflash | slot0 | slot1} |
| Step 4 Enter configuration mode from the terminal. | configure terminal |
| Step 5 From global configuration mode, configure the master RSP to boot the new image from the appropriate location. | boot system flash bootflash:[filename]
boot system flash slot0:[filename] boot system flash slot1:[filename] |
| Step 6 Also, add a boot system command that specifies the slave's boot image and location. This is the boot image that the slave uses when it becomes the master RSP and boots the system. Note that the because the slave will boot this image when the slave is actually the new master RSP, the command syntax does not use a "slave" prefix. | boot system flash bootflash:[filename]
boot system flash slot0:[filename] boot system flash slot1:[filename] |
| Step 7 (Optional) Configure the master RSP to boot from a network server. | boot system [rcp | tftp] filename [ip-address]
|
| Step 8 Set the configuration register to enable the system to load the system image from a network server or from Flash. | config-register value1 |
| Step 9 Exit configuration mode. | end |
| Step 10 Save the configuration file to the master's startup configuration. Because automatic synchronization is turned on, this step saves the boot system commands to the master and slave startup configuration. | copy running-config startup-config |
| Step 11 Reset the router with the new configuration information. | reload |
In this example, assume the following:
Figure 12 illustrates the software error protection configuration for this example. The configuration commands for this configuration follow the figure.
Because you always view the environment from the master RSP perspective, in the following command you view the master's slot 0 to verify the location and version of the master's software image:
Router# dir slot0:
-#- -length- -----date/time------ name
1 3482496 May 4 1993 21:38:04 rsp-k-mz11.1
7993896 bytes available (1496 bytes used)
Now view the slave's software image location and version:
Router# dir slaveslot0:
-#- -length- -----date/time------ name
1 3482496 May 4 1993 21:38:04 rsp-k-mz11.1
7993896 bytes available (1496 bytes used)
Because you want to run the Release 11.2 system image on one RSP card and the Release 11.1 system image on the other RSP card, copy the Release 11.2 system image to the master's slot 0:
Router# copy tftp slot0:rsp-k-mz11.2
Enter global configuration mode and configure the system to boot first from a Release 11.2 system image and then from a Release 11.1 system image.
Router#configure terminalRouter (config)#boot system flash slot0:rsp-k-mz11.2Router (config)#boot system flash slot0:rsp-k-mz11.1
With this configuration, when the slot 6 RSP card is master, it looks first in its PCMCIA slot 0 for the system image file rsp-k-mz11.2 to boot. Finding this file, the router boots from that system image. When the slot 7 RSP card is master, it also looks first in its slot 0 for the system image file rsp-k-mz11.2 to boot. Because that image does not exist in that location, the slot 7 RSP card looks for the system image file rsp-k-mz11.1 in slot 0 to boot. Finding this file in its PCMCIA slot 0, the router boots from that system image. In this way, each RSP card can reboot the system using its own system image when it becomes the master RSP card.
Configure the system further with a fault-tolerant booting strategy:
Router (config)# boot system tftp rsp-k-mz11.1 192.168.1.25
Set the configuration register to enable loading of the system image from a network server or from Flash and save the changes to the master and slave startup configuration file:
Router (config)#config-register 0x010FRouter (config)#endRouter#copy running-config startup-config
Reload the system so that the master RSP uses the new Release 11.2 system image:
Router# reload
In this example scenario, assume the following
In this scenario, you begin with the configuration shown in Figure 13.
First, copy the rsp-k-mz11.1 image to the master and slave RSP card, as shown in Figure 14.
Next, you delete the rsp-k-mz11.2 image from the slave RSP card. The final configuration is shown in Figure 15.
The following commands configure software error protection for this example scenario.
View the master and slave slot 0 to verify the location and version of their software images:
Router#dir slot0:-#- -length- -----date/time------ name 1 3482498 May 4 1993 21:38:04 rsp-k-mz11.2 7993896 bytes available (1496 bytes used) Router#dir slaveslot0:-#- -length- -----date/time------ name 1 3482498 May 4 1993 21:38:04 rsp-k-mz11.2 7993896 bytes available (1496 bytes used)
Copy the Release 11.1 system image to the master and slave slot 0:
Router#copy tftp slot0:rsp-k-mz11.1Router#copy tftp slaveslot0:rsp-k-mz11.1
Delete the rsp-k-mz11.2 image from the slave RSP card:
Router# delete slaveslot0:rsp-k-mz11.2
Configure the system to boot first from a Release 11.2 system image and then from a Release 11.1 system image.
Router#configure terminalRouter (config)#boot system flash slot0:rsp-k-mz11.2Router (config)#boot system flash slot0:rsp-k-mz11.1
Configure the system further with a fault-tolerant booting strategy:
Router (config)# boot system tftp rsp-k-mz11.1 192.168.1.25
Set the configuration register to enable loading of the system image from a network server or from Flash and save the changes to the master and slave startup configuration file:
Router (config)#config-register 0x010FRouter (config)#endRouter#copy running-config startup-config
You can optionally set environment variables on both RSP cards in a Cisco 7507 and Cisco 7513. For more information on environment variables, refer to the "Set Environment Variables" section.
You set environment variables on the master RSP just as you would if it were the only RSP card in the system. Refer to the following sections for more information on these steps:
You can set the same environment variables on the slave RSP card, manually or automatically. The following sections describe these two methods:
With automatic synchronization turned on, the system automatically saves the same environment variables to the slave's startup configuration when you set the master's environment variables and save them.
To set environment variables on the slave RSP when automatic synchronization is on, perform the following steps beginning in global configuration mode:
| Tasks | Command |
|---|---|
| Step 1 Set the master's environment variables as described in the "Controlling Environment Variables," "Set the BOOTLDR Environment Variable," and "Specify the CONFIG_FILE Environment Variable (Cisco 7000 family)" sections. | boot system
boot bootldr boot config |
| Step 2 Save the settings to the startup configuration. This also puts the information under that RSP card's ROM monitor control. | copy running-config startup-config |
| Step 3 Verify the environment variable settings. | show boot |
If you disable automatic synchronization of configuration files, you must manually synchronize the slave's configuration file to the master's configuration file to store environment variables on the slave RSP.
Once you set the master's environment variables, you can manually set the same environment variables on the slave RSP card using the slave sync config command.
To manually set environment variables on the slave RSP, perform the following steps beginning in global configuration mode:
| Tasks | Command |
|---|---|
| Step 1 Set the master's environment variables as described in the "Controlling Environment Variables," "Set the BOOTLDR Environment Variable," and "Specify the CONFIG_FILE Environment Variable (Cisco 7000 family)" sections. | boot system
boot bootldr boot config |
| Step 2 Exit global configuration mode. | end |
| Step 3 Save the settings to the startup configuration. This also puts the information under that RSP card's ROM monitor control. | copy running-config startup-config |
| Step 4 Save the same environment variables to the slave RSP by manually synchronizing their configuration files. | slave sync config |
| Step 5 Verify the environment variable settings. | show boot |
To monitor and maintain HSA operation, complete the tasks in the following sections:
You can override the slave image that is bundled with the master image. To do so, perform the following task in global configuration mode:
| Tasks | Command |
|---|---|
| Specify which image the slave runs. | slave image {system | device:filename} |
| Tasks | Command |
|---|---|
| Manually synchronize master and slave configuration files. | slave sync config |
 | Caution When you install a second RSP card for the first time, you must immediately configure it using the slave sync config command. This ensures that the new slave is configured consistently with the master. Failure to do so can result in an unconfigured slave RSP card taking over mastership of the router when the master fails, rendering the network inoperable. |
The slave sync config command is also a useful tool for more advanced implementation methods not discussed in this chapter.
When a new master RSP card takes over mastership of the router, it automatically reboots the failed RSP card as the slave RSP card. You can access the state of the failed RSP card in the form of a stack trace from the master console using the show stacks command.
| Tasks | Command |
|---|---|
| Reload the inactive slave RSP card. | slave reload |
The slave console does not have enable password protection. Thus, an individual connected to the slave console port can enter privileged EXEC mode and view or erase the configuration of the router. Use the no slave terminal command to disable slave console access and prevent security problems. When the slave console is disabled, users cannot enter commands.
If slave console access is disabled, the following message appears periodically on the slave console:
%%Slave terminal access is disabled. Use "slave terminal" command in master RSP configuration mode to enable it.
During the first 60 seconds of startup, you can force the router to stop booting. The router will enter ROM Monitor mode, where you can change the configuration register value or boot the router manually.
To stop booting and enter ROM monitor mode, complete the following tasks:
| Tasks | Command |
|---|---|
| Step 1 Restart the router. | reload |
| Step 2 Press the Break key during the first 60 seconds while the system is starting up. If you are connected via a telnet session, issue a "send break" command. | Break1 |
If your router does not find a valid system image, or if its configuration file is corrupted at startup, and the configuration register is set to enter ROM monitor mode, the system enters ROM monitor mode. From this mode, you can manually load a system image from the following locations:
You may only boot from a location if the router can store an image there. Therefore, not all platforms can manually load from these locations.
You can also enter ROM monitor mode by restarting the router and then pressing the Break key or issuing a "send break" command from a telnet session during the first 60 seconds of startup.
To manually boot from Flash memory, complete the following task in ROM Monitor mode:
| Tasks | Command |
|---|---|
| Manually boot the router from Flash. Refer to your hardware documentation for the correct form of this command to use. | boot flash [filename]
boot flash partition-number:[filename] boot flash flash:[ partition-number:] [filename] boot [device:][partition-number:][filename] (Cisco 1600 series and Cisco 3600 series) boot device:[filename] (Cisco 7000 family) |
If the filename is not specified, the first bootable file found in the device and partition is used.
In the following example, a router is manually booted from Flash memory. Because the optional filename argument is absent, the first valid file in Flash memory is loaded.
> boot flash
F3: 1858656+45204+166896 at 0x1000
Booting gs7-k from flash memory RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR [OK -
1903912/13765276 bytes]
F3: 1858676+45204+166896 at 0x1000
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
In the following example, the boot flash command is used with the filename gs7-k--the name of the file that is loaded:
> boot flash gs7-k
F3: 1858656+45204+166896 at 0x1000
Booting gs7-k from flash memory RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
RRRRRRRRRRRRRR [OK - 1903912/13765276 bytes]
F3: 1858676+45204+166896 at 0x1000
Restricted Rights Legend
Use, duplication, or disclosure by the Government is
subject to restrictions as set forth in subparagraph
(c) of the Commercial Computer Software - Restricted
System Bootstrap, Version 4.6(1012) [mlw 99], INTERIM SOFTWARE
Copyright (c) 1986-1992 by cisco Systems
RP1 processor with 16384 Kbytes of memory
The following command instructs the ROM monitor to boot the first file in the first partition of internal Flash memory:
> boot flash:
This command instructs the ROM monitor to boot the first file in the second partition of the Flash memory card in slot 0:
> boot slot0:2:
In this example, the ROM monitor boots the file named imagename from the third partition of the Flash memory card in slot 0:
> boot slot0:3:imagename
The following command fails to specify a valid device type (flash:, slot0:, or slot1:), so the ROM monitor invokes the boot helper to boot a system image.
> boot flash
To manually boot from a network file, complete the following task in EXEC mode:
| Tasks | Command |
|---|---|
| Manually boot the router from a network file. | boot filename [ip-address] |
In the following example, a router is manually booted from the network file network1:
>boot network1
To manually boot the router from ROM, complete the following step in EXEC mode:
| Tasks | Command |
|---|---|
| Manually boot the router from ROM. | boot |
On the Cisco 7200 series and Cisco 7500 series, the boot command loads the first bootable image located in bootflash.
In the following example, a router is manually booted from ROM:
>boot
You can interactively boot system software using MOP. Typically, you do this to verify that system software has been properly installed on the MOP boot server before configuring the router to automatically boot the system software image.
To manually boot the router using MOP, perform the following task in EXEC mode:
| Tasks | Command |
|---|---|
| Manually boot the router using MOP. | boot mop filename [mac-address] [interface] |
The Cisco 7200 series and Cisco 7500 series do not support the boot mop command.
In the following example, a router is manually booted from a MOP server:
>boot mop network1
To return to EXEC mode from the ROM monitor to use the system image instead of reloading, perform the following task in ROM monitor mode:
| Task | Command |
|---|---|
| Return to EXEC mode to use the system image. | continue |
|
|