Using the reload command with HP Switches – HP Networking Series Part 2

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

Advertisements
No comments yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s