I was checking out the Cisco IOS Hints and Tricks (an outstanding blog) and ran across a posting about the “warm-reboot” feature. As always, go and read the entire entry as it is very well written. Here’s the skinny on the warm-reboot:
“The theory behind warm reload is simple: the router saves initial data (as stored in IOS image) in a separate memory region and reuses saved data together with IOS code already residing in RAM to restart IOS. Of course, the IOS code (depending on platform’s memory management capabilities) or saved data could get corrupted, therefore the warm reload cannot be used continuously (and the router falls back to traditional reload if the router crashes before a specified time interval).
Warm reload is configured with the warm-reboot count number uptime minutes configuration commands. After it has been configured, a router reload (or power-up) is needed to initialize the saved data region. When the warm reboot is operational (as verified with the show warm-reboot command), you can use reload warm command to start it.”
I jumped on my rack to test this out. The first router that I tried it on was a 2651XM running 12.4(10) code. It seems that this command is not available for this router model:
r1#sh ver
Cisco IOS Software, C2600 Software (C2600-ADVENTERPRISEK9-M), Version 12.4(10), RELEASE SOFTWARE (fc1)
…
System image file is “flash:c2600-adventerprisek9-mz.124-10.bin”
…
Cisco 2651XM (MPC860P) processor (revision 3.1) with 253952K/8192K bytes of memory.
…
r1#show w?
whoami wlccp wrr-queue
Since this command has been around since 12.3(2), this could just be a case of the model not supporting the command or the memory not being sufficient/capable of supporting the feature.
I decided to try my 2821 and found that it did support the feature:
r2#sh ver
Cisco IOS Software, 2800 Software (C2800NM-ADVENTERPRISEK9-M), Version 12.4(11)T
…
System image file is “flash:c2800nm-adventerprisek9-mz.124-11.T2.bin”
…
Cisco 2821 (revision 53.51) with 249856K/12288K bytes of memory.
…r2#sh warm-reboot
Warm Reboot is not enabled
First, let’s reload the router and see how long it takes to recover:
r2#reload
Proceed with reload? [confirm]
*Jul 13 22:28:41: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 13 22:30:10: %SYS-6-BOOTTIME: Time taken to reboot after reload = 90 seconds
It takes 90 seconds for the router to recover from a conventional reload. Okay, let’s config this pig:
By default, the warm-reboot option is not enabled:
r2#sh warm-reboot
Warm Reboot is not enabledHere are the options for the command:
r2(config)#warm-reboot ?
count Set max number of continuous warm reboots
uptime Set the uptime after which warm reboot is safe in case of a crash
<cr>r2(config)#warm-reboot count ?
<1-50> Default 5r2(config)#warm-reboot count 5 uptime ?
<0-120> Time in minutes, default 5Let’s keep the default count, but make the uptime 1 minute:
r2(config)#warm-reboot count 5 uptime 1
Warm reboot will be possible after the next power cycle or reload.r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 5
Uptime after which warm reboot is safe in case of a crash is 1 (min)Warm reboot can take place only after the next power cycle or reload.
The router warns you that you’re going to need to reload once before the warm-reload feature is implemented. This is good to know. You could push this config out to a bunch of routers only to be disappointed when they don’t recover quickly on their first reload after the configuration is written. You’ll either need to reload the router after the configuration is written to ensure that the warm-reboot feature is in effect, or just allow the router one mulligan.
Let’s reload the router (this should be a “cold” reload and should take about 90 sec to restore):
r2#reload
Proceed with reload? [confirm]*Jul 13 22:39:34: %SYS-5-RELOAD: Reload requested by console. Reload Reason: Reload Command.
After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 13 22:41:09: %SYS-6-BOOTTIME: Time taken to reboot after reload = 94 seconds
Okay, let’s verify that the warm-reboot is configured and then go ahead and do a warm-reload:
r2#show warm
Warm Reboot is enabled
Maximum warm reboot count is 5
Uptime after which warm reboot is safe in case of a crash is 1 (min)Statistics:
0 warm reboots due to crashes and 0 warm reboots due to requests have taken
place since the last cold reboot
3149 KB taken up by warm reboot storageNotice the “warm” option for reloads now:
r2#reload ?
/noverify Don’t verify file signature before reload.
/verify Verify file signature before reload.
LINE Reason for reload
at Reload at a specific time/date
cancel Cancel pending reload
in Reload after a time interval
warm Reload should be warm
<cr>r2#reload warm ?
LINE Reason for reload
at Reload at a specific time/date
file Image file to load
in Reload after a time interval
<cr>
r2#reload warm
Proceed with reload? [confirm]After reload:
r2#sh log | i %SYS-6-BOOTTIME
*Jul 13 23:08:33: %SYS-6-BOOTTIME: Time taken to reboot after reload = 35 seconds
NICE!!! This shaved nearly a minute off of the reload time.
I like the statistics as well:
r2#sh warm
Warm Reboot is enabled
Maximum warm reboot count is 5
Uptime after which warm reboot is safe in case of a crash is 1 (min)Statistics:
0 warm reboots due to crashes and 1 warm reboots due to requests have taken place since the last cold reboot
3149 KB taken up by warm reboot storage
While the statistics are nice, they do get blown away if the router is power-cycled.
This is a feature that is pretty useful for production networks. Every engineer knows that waiting 60 seconds for a router to restore after a reload can feel like an eternity. This command should be able to shave some significant time as well as give you some additional information concerning reloads and crashes.
Cisco Documentation:warm-reboot
[…] looks like an interesting feature and should work nicely with “warm reboot”. For enterprises that have a number or devices that require IOS upgrades and do not use a […]
Pingback by Automatically Upgrade Your IOS With Cisco IOS Auto-Upgrade Manager « CCIE Pursuit — October 26, 2007 @ 12:29 pm |
Thanks for the great tip! That minute and a half of waiting is killer.
Comment by Steven Murawski — November 2, 2007 @ 11:25 am |