In my current role I manage several ASA HA pairs across a few sites. Recently, I encountered a situation where, due to a bug I was unable to SSH into the active ASA; however, I could SSH into the standby unit just fine. This only affected SSH – I was able to login to ASDM just fine and could certainly do everything I needed to do from there. In fact, I could even manually trigger a failover and would then be able to login to the formerly active unit that’s now in standby. Very odd, although I’ve seen this occur on 8.2 as well as 8.4 code releases under certain bug conditions it would seem.
While I’m sure some folks would happily use ASDM all day long and not even care about the CLI, I personally have come to loath using ASDM. It has its useful instances but those are far and few between in my view. I’ve had several issues in the past with new versions of ASDM sending commands in an incorrect order causing them to fail on commit. Then you have to go back and do each step over again and individually apply the changes. Not fun if you’re in the middle of trying to fix something at 0100. Also, I find that I’m 9.8 times out of 10 faster when configuring from the CLI. Oh, and did I mention the GUI is written in Java? Yeah, always fun when you update Java and find out that it breaks ASDM. I could continue hating on ASDM but I digress… 🙂
So, as a CLI junky, what can you do if you’re stuck in this situation. Well, there’s a very useful command: failover exec. This command allows you to, while on one ASA execute a command on the other ASA in the HA pair. So, for example, let’s say there’s a file you have on your active unit but want to make sure that same file is there on the standby unit so when you failover everything will work as it should. You could go and login to the standby unit and check for the but that takes a few extra cycles. You can save time by using the failover exec command like this:
ASA# failover exec standby dir disk0:/asa84* Directory of disk0:/asa84* 141 -rwx 25178112 12:36:18 Aug 20 2011 asa842-2-k8.bin 157 -rwx 24938496 15:23:00 Mar 19 2011 asa841-k8.bin
Fairly straight forward, you can see that I’ve done a directory listing on disk0 for any file starting with asa84 (directory listings on the ASAs do allow for wildcards). Of course there’s always the context-sensitive help if you need it.
ASA# failover exec ? active Execute command on the active unit mate Execute command on the peer unit standby Execute command on the standby unit ASA# failover exec
As you can see, you can choose to run the command on the active or standby unit specifically, or, run it on the mate unit if you don’t know which one your on. I always make it a habit of remembering which unit I’m on before using this command. This leads to another key-note from the ASA 8.4 Command Reference Guide: “By default, the failover exec command mode is global configuration mode for the specified device.” That is, any command you issue in config t mode you can issue with the failover exec command. The command reference also points out that it would be very wise to set a failover key-pair in order to encrypt the failover traffic between devices.
So what else could you do? Well, another pet peeve of mine with the ASAs is when you upload anything to the file system on the active unit you must go and then copy those same files to the standby unit. Manually. Every time. I can’t even begin to count the number of times I forget this and get burned when a failover occurs (usually with VPN XML profiles). From the CLI on the active unit we would do the following:
copy /noconfirm tftp://18.104.22.168/someprofile.xml disk0:/someprofile.xml
This will put the someprofile.xml file on the active unit. Then, all you have to do is pre-pend the above command with failover exec to execute the same copy command on the standby unit:
failover exec standby copy /noconfirm tftp://22.214.171.124/someprofile.xml disk0:/someprofile.xml
Note in both copy commands I used the /noconfirm option. While completely optional when copying on the local unit, it’s critical when using the failover exec command. This is because you are sending single line commands with no chance of interaction with the standby unit. If you forget to use the /noconfirm option, you will get an error message stating the command failed. This is true not only for the copy command but any interactive command (e.g. reload).