When configuring network hardware over the network itself it’s very easy to issue a command that breaks the network connection to the switch, requiring you to visit the switch and connect to it with a console cable to fix the issue. This is not a big problem if the switch is just down the hall in a closet somewhere, but in today’s world a switch that you’re configuring might be hundred of miles away from where you’re sitting.
Of course this whole issue can be sidestepped by just thinking through what you’re doing before hitting the enter key, but in the real world this is not always an available luxury.
The solution to this problem is to cleverly utilize the “reload” command in combination with the “write” command.
Getting started
For starters, run the command “write memory” to write the running config to the persistent startup config memory.
This is to ensure that you have committed all previous changes to memory, so that if the switch were to reload, you’ll get it back to the state it was in before you started messing with it.
Issuing the reload command
The “reload” command gives you two options. Either you tell the switch to reload at a specific time (like 1AM tomorrow) or you can tell it to reload after a specific amount of time has passed. For this application, I think the “reload after” command is better since it doesn’t rely on functioning time synchronization.
“reload after” accepts time as [DD:][HH:]MM, meaning that hours and days are optional. I normally set the switch to reload after 30 minutes, so to do that I just have to tell it the minutes
SW1# reload after 30
Reload scheduled in 0 days, 0 hours, 30 minutes
System will be rebooted at the scheduled time from primary image.
Do you want to continue [y/n]? Y
SW1#
Be paranoid about it (Optional)
If you’re really paranoid (like me), then you can check that a reload is scheduled with the following command:
SW1# show reload after
Reload scheduled in 0 days, 0 hours, 29 minutes
SW1#
Do whatever you came to do
Now you can try all the drastic changes that you wanted to try, as long as they don’t take more time than your reload time. A good test would be for example to disable the uplink port to the device, which would cut you off completely from the switch. If your hacking starts to take too long, you can always extend the reload timer by issuing a new reload command.
SW1# reload after 30
Reload scheduled in 0 days, 0 hours, 30 minutes
System will be rebooted at the scheduled time from primary image.
Do you want to continue [y/n]? y
SW1# reload after 40
Reload scheduled in 0 days, 0 hours, 40 minutes
System will be rebooted at the scheduled time from primary image.
Do you want to continue [y/n]? y
SW1# show reload after
Reload scheduled in 0 days, 0 hours, 39 minutes
Cancelling the reload
If you manage to make all your changes without breaking anything, congratulations! Then you only have a slight problem, the timer is still ticking towards impending doom! Cancel the reload by issuing the “no reload” command.
SW1# show reload after
Reload scheduled in 0 days, 0 hours, 29 minutes
SW1# no reload
SW1# show reload after
reload is not scheduled
Write the changes to memory
Now that you have confirmed that your changes didn’t break anything and that the reload is cancelled, you can issue the “write memory” command to write the changes to the startup config. This makes sure that if the switch were to reboot, you changes will be saved.
What to do if things didn’t go according to plan
If you do manage to loose the connection to the switch or otherwise completely lock it, don’t worry! What will happen is the switch will reload after the set amount of time since there’s no one there to cancel the command. At reload, the switch will load the persistent startup configuration, which you saved in step 1. This configuration does not contain whatever you did to break the switch, as without somebody issuing the “write memory” command, these changes are only stored in the running configuration, which is cleared when the switch reloads!
This trick basically relies on the difference between the running configuration and the startup configuration in a switch, which is that the running configuration is only stored in volatile memory, while the startup configuration is stored in persistent memory. The “write memory” command overwrites the startup configuration with whatever is stored in the running configuration, which is why we run it before we start to work on the switch, and after we’ve confirmed that our changes didn’t break anything.
At reboot or reload, the switch reads the startup configuration and stores a copy of it in the running configuration.
This post is part of a new series called Network Friday, where I explain a new networking concept every Friday and tell you have to configure it on (mostly) HP hardware. The series will mostly focus on the configuration side, as I feel there are lots of resources out there that do a fine job of explaining complex concepts, but very few that show you how to do it on your specific hardware. This series aims to address this somewhat, at least on the HP side of the fence.
This how-to was originally posted over at the Spiceworks community:
http://community.spiceworks.com/how_to/93373-using-the-reload-command-with-hp-procurve-switches
Grumpy Techie 
Leave a comment