This is easily done using the boot system flash command as shown below:. SG is the only one referenced:. Next, we must ensure the configuration is saved to the startup-configuration:. If no such message was reported when saving the configuration, it means that the IOS currently running does not have this cosmetic bug.
On another note, every time we save our configuration to startup-config the system will immediately synchronize the configuration changes to the standby supervisor. Cisco Supervisor Engines, by factory default, have their configuration register set to 0x The value 0x instructs the system to boot the first system image in the onboard flash memory bootflash. This is usually the oldest image in the flash. The value of 0x instructs the system to use the image specified in the BOOT environment variable , which is essentially whatever was specified in the previous step No.
To view the environment variables on both Supervisor Engines, use the show bootvar command:. Notice how the newly uploaded IOS image cate-universal. Which image is that? As we can see, despite the boot system flash command being correctly set to load the second IOS image, the configuration register setting of 0x will force the Supervisor Engine to boot the first image found, that is: cate-universal.
We decided to set the configuration register just to be on the safe side:. Take note that the system is confirming that both configuration register and startup-config have been successfully synchronized with the standby supervisor. At this point we are ready to force the standby Supervisor Engine SE2 to reload. To force the reload of the standby Supervisor Engine SE2 , use the redundancy reload peer command:.
The second standby Supervisor Engine is now restarting. This process will take a couple of minutes and will have no negative impact on the R switch.
Once the IOS has loaded and the restart process is complete we will receive a message similar to the following:. The above messages indicate that the standby Supervisor Engine has successfully completed its reboot and is fully synchronized with the active Supervisor Engine. To verify that the standby Supervisor Engine is running the latest and greatest IOS image we just loaded, use the show module command:. The show module command provides a generous amount of information including all line cards installed, Supervisor Engine models, IOS software versions, serial numbers, operational status and redundancy mode SSO by default.
Notice the software image the system is reporting for both Supervisor Engines. Our current active Supervisor Engine is running version SG, while our standby Supervisor Engine is running version SG — the new IOS loaded! To initiate the Supervisor Engine switchover, use the redundancy force-switchover command as shown below:.
This is normal expected behaviour — do not be alarmed! Apart from the switch cutting our telnet session, users will not notice any service disruption — the switchover will be completely transparent to them no matter the network load during the switchover.
To reconnect to the switch, simply telnet back into the same IP address. If connected via console cable it will be necessary to connect it to the new active supervisor engine in order to continue controlling the switch. Engineers who would like to monitor, via telnet or direct console cable connection to the new active engine , the reload progress of the Supervisor Engine can use the show module command. In addition the redundancy status of the first engine is Disabled — an expected result since the Supervisor Engine SE1 has not booted yet.
At this point, we can continue to issue the show module command and monitor the output changes. At some point the system will show the Supervisor Engine SE1 loaded with the new IOS, however, the redundancy status will go through the following phases until it is ready Standby hot :. When the Supervisor Engine reaches Standby hot status, it is ready to take over in the event the active Supervisor Engine fails.
If your network is live, make sure that you understand the potential impact of any command. Refer to the Cisco Technical Tips Conventions for more information on document conventions. Check whether your switch supports these requirements. You can use the release notes to verify the requirements for the new software image. You can use any TFTP server that can be installed on any platform.
Download the software image to the TFTP server root directory. You can download the images to the default root directory of the TFTP server or change the root directory path to the directory in which the software image resides. Alternatively, deselect Enable Logging , and click Ok. By default, logging is enabled. Note: You can use remote Telnet access to upgrade the switch.
However, you lose Telnet connectivity when the switch reloads during the software upgrade. You can re-establish the Telnet after the new image loads. However, to troubleshoot in case of failure, you need to have local console access. Cisco recommends a switch upgrade through the console access. Sometimes, your upgrade procedure can fail due to these reasons:. You can recover the switch to normal mode with the same image that was present in the switch.
If you lose the switch configuration for any reason, you can restore the configuration from the TFTP server. If you have modified your configuration, make sure to issue the write memory command to copy the current configuration to startup configuration and perform the backup.
You can issue the copy bootflash: tftp: or copy slot0: tftp: commands to copy the current software images from bootflash or slot0 to the TFTP server. In this section, you are presented with the information to configure the features described in this document.
Note: Use the Command Lookup Tool registered customers only to obtain more information on the commands used in this section. You only have the option to copy the new software image from the TFTP server into the switch bootflash.
If you are not ready with this setup, see the Requirements section of this document. Step 2 : Configure the management IP address sc0.
In this sample scenario, use the Step 3: Verify whether you have enough space available in the bootflash to copy the new image from the TFTP server into the bootflash. You can check the size of the new image on the PC to which the image is downloaded. In case there is not enough free space to copy the new image, delete the current image with the delete command.
Issue the squeeze command to permanently erase files tagged as "deleted" to make more space available for the new image. Step 4: Copy the new software image into the bootflash from the TFTP Server and verify whether the image is properly copied.
Confirm that the file size of the new image is an exact match with the size that the Software Center on Cisco. If you find a difference, the image probably became corrupt during transfer. Download the image again in order to ensure that the switch does not go into ROMmon mode after reload.
You can also confirm the checksum of the file on the Flash device with the verify command:. Step 5: Clear the old boot variable so that switch does not boot with an old image even if the image is available in bootflash.
0コメント