Showing results for 
Search instead for 
Did you mean: 

Test new config on remote ASA, with fallback option



(This ’trick’ might not work on all software versions or all ASA model. Please verify before it’s used in production)


It's always a bit scary to test a new configuration on a remote device, especially if the new configuration will change the external interface in some way. I have used this little ’trick’ on small ASA 5505 8.4(x) and 9.1(x), to make it a bit more ’safe’. Please try it out on a local ASA before you go live on a remote location ASA, if you have such option. I really don’t think this is how Cisco has planned to use their configuration files, so I can’t guarantee it will work in all cases. Let’s hope Cisco come up with an official command for this in a future release. Please, if anyone at Cisco thinks this is a good idea, also consider adding ’nano’ or equal command to the software. This way, it would be easy to do some changes directly on the ASA, without the need of download the configuration files.


I use this ’trick’ when I need to change the ’outside’ IP of a remote ASA. Usually, I have two different kind of external IP address change, 1) the new ISP uses a new WAN link cable to provide the services or 2) the new ISP uses existing WAN link cable, only to change the IP definition on it.


Usually I only have a none-technical person on site, typically an office employee not familiar with communication or computers. In this case, I try to instruct the person to ’swap’ the cable between the two ISP. Before the ’swap’ I do my ’trick’ with the ASA and if I can't reach the ASA using the new cable, I ask the person on site to reconnect the old cable. After a while the ASA will come back to its old configuration and I’m saved :)


In the second case, I prepare my configurations and do my ’trick’ on the ASA before the ISP change it’s IP addresses. If, for some reason, the ISP’s change did not work or was never performed, the ASA falls back to the original configuration after a certain period of time, which I have programmed.


So here is the ’trick’:


Copy the running config to disk0:/oldconfig and disk0:/newconfig.


   copy /noconfirm running-config disk0/oldconfig

   copy /noconfirm running-config disk0/newconfig


Download both files (newconfig and oldconfig) to your PC (easy with ASDM file management and the transfer to PC function).


*Carefully* edit the newconfig using the new IP addresses and new default route. Remember that you will not have any syntax check on what you configure. If you add wrong IP mask or spell route wrong, you will not get any warnings. Do the newconfig edit carefully and correct! Remember to allow access to the new IP address using SSH or ADSM. Also have a look at your ACL and correct any old IP address to the new one.


Here’s the ’trick’. You will then add the following two lines to the bottom of the newconfig file, like this:


   hpm topN enable

   ! ———— This two lines should be added ————

   reload in 10 noconfirm

   copy /noconfirm disk0:/oldconfig startup-config

   ! ——————————————————————


   : end


You will now do the same with the oldconfig, but it’s slightly different.


   hpm topN enable

   ! ———— This two lines should be added ————

   reload in 10 noconfirm

   copy /noconfirm disk0:/newconfig startup-config

   ! ——————————————————————


   : end


You can let the ASA ’stay’ on each configuration as long as you want by adjusting the 10 minute (se example: reload in 10 noconfirm). I have not seen any problem with the delay time, even if the ASA change it’s internal clock like a NTP update. The 10 minute seems to be 10 minute even if the internal clock change due to a NTP sync. I cant guarantee this, but I have not been able to ’force’ any change in the ’reload’ time even if I manually change the clock to something complete different.


Save both files (newconfig and oldconfig) on your PC and copy the file back to the ASA. Be carefully not to use wrong format in the file. I use a Mac and BBedit, it works fine.


You will now have two configuration files on your disk0:, oldconfig and newconfig, both files have two ’magic lines’ at the bottom.


When you are ready to make the new config go live, do the following:


   copy /noconfirm disk0:/newconfig startup-config

   reload noconfirm


Please notice that you should *not* save any configuration between the copy and the reload! If you do, the startup-config will be changed. You will loose the two ’magic’ lines and your ’reload noconfirm’ will boot your ASA into the same configuration as you already have.


Please ask the person at the remote office to switch to the new ISP cable if that’s the case.


After about two minute (boot time for a ASA 5505) you should be able to access the ASA using it’s new external IP address (remember to change any reverse IP sec peers too). If, for some reason, the new ISP cable did not work or your remote help did something wrong, your ASA will ’restore’ itself to the old configuration after about 14 minute (2min reload + 10 minute reload delay + 2 min restore reload). You will have to instruct the person at the remote site to restore all cables. The ASA will try each configuration forever until someone can tell it something else. It will ‘flip-flop’ each 12 minute.


If everything works and you really can reach the ASA using the new IP address (or old IP), you have about 9 minute to halt the reload. Access the ASA via SSH and cancel the reload by ’reload cancel’ or do it via ASDM.


   reload cancel



To permanent the new configuration, you have to save the current running-config (’write’).


Remember, add ’plain commands’ like ’reload’ and ’copy’ to the configuration file are probably not what Cisco has planned. So, I can’t guarantee that this ’trick’ will work on all software version or hardware models. Before you go live, I once again ask you to test it in your lab or at least, when you have a technical person on site to manually recover any problem.


This little ’trick’ has helped me changing external IP on remote located ASA. As I did say in the beginning, it would be great if Cisco add a more official command and configuration for it, making this ’trick’ a bit more secure. I would like to see a fall back list of configurations. This could also be true for software version. A command telling the ASA a list of configuration files and software version, with some sort of ’retry next’-time. If I can't reach the ASA and cancel the retry next schema, the ASA will try every possible alternative of the list until it reach the last one. Then it starts all over again. This way, you can play around with both software versions and configuration a bit more ’safe’ then today.


Good luck, I hope it will help.

Per Håkansson


Content for Community-Ad