ASA Quick Tip
I’ve always known that you could set the display prompt on the ASA CLI. Today I stumbled across an option in the prompt that I hadn’t realized was there.
ASA(config)# prompt ?
configure mode commands/options:
context Display the context in the session prompt (multimode only)
domain Display the domain in the session prompt
hostname Display the hostname in the session prompt
priority Display the priority in the session prompt
state Display the traffic passing state in the session prompt
Of course the default is just hostname. If you’re running a standalone ASA that’s fine but if you have a pair and have HA configured you’ll notice the hostname is the same on each node. If I remember correctly the old PIX firewalls would show you which one you were logged into, active or standby. This is handy in case you login to the wrong one and go into config mode – because when you do that you you break config synchronization. No a huge deal but annoying. This was one thing I did miss when I started dealing with the ASAs.
Well, in the ASAs it’s still there – you just have to enable it with the state option (last option from the above snippet). So, if you change the prompt to state/hostname you’ll always see the state of which one you’re on.
ASA(config)# prompt state hostname
act/ASA(config)#
Now you have device state listed just in front of the hostname. Here’s what it looks like on the standby node:
stby/ASA#
Again, this is a minor almost silly thing but in some situations this could be really useful. For example if you say, had an ASA Service Module then I could see this being very useful if you are connecting to the console from the host switch. This is also true for the old FWSMs – in fact that’s how I discovered it.
Happy Friday!
HOWTO: Cisco 871 Configuration Recovery
Recently I’ve run into a small problem. It doesn’t happen often but when it does it’s very annoying. At my current place of paycheck-giveth we have several Cisco 871 ISRs providing VoIP access for our staff who work remotely. Most of these folks are sales directors or call center workers – not the most technical of users. Every so often we’ll get a call in from one of the remote users saying that the VPN light on the router won’t light up and they can’t get to anything from behind the router. Power cycling the router and their Cable/DSL modem doesn’t do any good either. Usually this is a case where we overnight them a new router and have them send the old one back. Problem solved.
Once the router returns and lands on my desk, I power it up and see that the configuration is gone. As in the startup-config is gone. Erased. Doesn’t exist any more. They look like they were just taken out of the box. Thing is, they haven’t. In some cases these routers have been in the field for a year or more. What gives?
Last time this happened I posted a random tweet complaining about the issue. Fellow tweep Jody Lemoine responded saying he had similar issues on some of the 800 series ISRs but you could can save the config out so that when you hit the reset button it will recover the configuration you want it to. Really?! This I did not know. After trading a few tweets and emails I got it to work on one of my 871s.
What Really Happens When You Hit The Reset Button
If you look at the Cisco 800 Series ISR Q&A page you’ll find these two little gems:
This is where the router gets its “factory defaults” from. There is a little more detail as to how the device loads when the reset button is pressed further down:
The key take away here is you only need to hit the reset button once within the first 5 seconds of powering on the router.
The Mysterious xxx.cfg File
And no, I don’t mean that XXX – get your head out of the gutter. 
If we look at the contents of flash:/ we’ll see something like what’s below:
Remote_871_64#dir
Directory of flash:/
2 -rwx 21839140 Sep 23 2009 13:02:43 -04:00 c870-advipservicesk9-mz.124-24.T1.bin
3 -rwx 3179 Feb 28 2002 19:03:59 -05:00 sdmconfig-8xx.cfg
4 -rwx 931840 Feb 28 2002 19:04:16 -05:00 es.tar
5 -rwx 1505280 Feb 28 2002 19:04:39 -05:00 common.tar
6 -rwx 1038 Feb 28 2002 19:04:52 -05:00 home.shtml
7 -rwx 112640 Feb 28 2002 19:05:04 -05:00 home.tar
8 -rwx 720 Feb 28 2002 19:24:27 -05:00 vlan.dat
27611136 bytes total (3209216 bytes free)
As you can see, there’s a file there called sdmconfig–8xx.cfg. If we look at the beginning of that config file we’ll see that this is the default config file that gets loaded when reverting to factory defaults.
Remote_871_64#more flash:/sdmconfig-8xx.cfg
! The default startup configuration file for Cisco Router and Security Device Manager (SDM)
! DO NOT modify this file; it is required by SDM as is for factory defaults
! Version 1.0
Okay cool. So, if we hit the reset button within the first 5 seconds of turning on the power to the router it will look for a file ending with .cfg file and load the first one it finds. In this case it will be sdmconfig–8xx.cfg.
Note: Since this is an older router it has SDM loaded. Newer devices will come with Cisco Configuration Professional (CCP) which is the replacement for SDM. The CCP config files will be named something like cpconfig–8xx.cfg.
Putting It All Together
Now let’s put this all together. First, configure the router with what ever baseline configuration you would want to be able to go back to, save it to flash as you normally would, and finally either save the configuration to either a new file ending in .cfg or use the existing SDM/CCP filename.
Note: If you choose to use a new file name be sure that it’s the only .cfg file saved in flash. Otherwise, you could end up with an unexpected configuration being recovered.
Let’s test to make sure it all works. Make sure you’re connected to the console so you can see the whole process. First let’s erase the current startup configuration and reload the router. Remember, this recovery process is only triggered when you hit the reset button.
Remote_871_20#erase startup-config
Erasing the nvram filesystem will remove all configuration files! Continue? [confirm]
Remote_871_20#
Make sure you’re connected to the router console so you can watch it boot up. First reload the router and confirm we are back to the default configuration. Once the router is reloaded you should see the initial configuration prompt like below:
--- System Configuration Dialog ---
Would you like to enter the initial configuration dialog? [yes/no]:
Okay good, we’re back to default configuration. Now let’s test the configuration recovery. Turn off the router and hit the reset button within 5 seconds of turning the router back on. Personally, I prefer to just hold down the reset button as I turn the router back on and hold it for a second or two just to make sure it takes.
As the router boots up, after the bootstrap process and the initial copyright verbiage you should see the following:
[OK][OK]
Router IOS Configuration Recovery is in progress...
After the recovery is completed the router will reload again (you will see the bootstrap process again) and now your baseline configuration should be restored. Go ahead and login and confirm that the configuration is there and what you expect to see.
Final Thoughts
Using the configuration recovery feature can save your bacon in the field. Instructing a user to hit the reset button as the router is powered on is easier and certainly more time efficient than having to have a new router configured and shipped out. Fortunately for me our deployment a small one (about 30 routers) all things considered so it’s not a huge hassle to update our field deployed routers. I’ll certainly be including this in the configuration for all the routers we have on the shelf for new deployments and replacements and updating our documentation.
One final note: it was pointed out that you could also save the recovery config with the same name as the existing SDM/CCP config file. This, in theory, would allow you to utilize the recovery features within SDM/CCP. Since I’m an unabashed CLI junkie and avoid the GUI if at all possible when it comes to switches and routers I haven’t tested this so your milage may vary.
Nexus 1000v Licensing
I’ve been knee deep working on a data center refresh. The new infrastructure will make use of Cisco’s Nexus 7009s with the Nexus 2232 FEXs along with Nexus 1000v down at the VMWare level. One hurdle that came up in our design review discussions with our VAR was around licensing for the Nexus 1000v. See, management had decided to purchase the Nexus 1000v with the next purchase of VMWare servers. While this makes perfect sense, it also left the one person out of the loop to QA the order before it went through. But I digress… The only answer I could get from our VAR was “per physical socket.”
*blink*
Okay, but does that mean that you have to have licenses for every VMWare host server in your VCenter data center? Or is it only for the virtual supervisor modules (VSMs)? I should point out that we are small shop and I have been feeling a bit lazy a little extra busy lately and was hoping to get the answer from our VAR. After our VAR SE told us he’d have to find out and get back to me I went looking for the answer myself. After a 2 minute Google search I came across the Nexus 1000v License Configuration Guide. This guide has everything you need to know for licensing.
To break it down, the Nexus 1000v is real in two components – the virtual Ethernet module (VEM) and the virtual supervisor module (VSM). Just like in a physical 6500 or 4500 series switch you can have one or two supervisors. For the VSE though, it’s a little different. Cisco’s Nexus 1000v License Configuration Guide it states that (emphasis is mine):
Cisco Nexus 1000V manages a data center defined by the vCenter server. Each server in the data center is represented as a line card in Cisco Nexus 1000V and can be managed as if it were a line card in a physical Cisco switch.
The real answer to how the Nexus 1000v is licensed can be found in a little note right at the end of the VEM details section. Again, from the Nexus 1000v License Configuration Guide:
A license is required for every CPU on a VEM.
Gotcha! So, if one VEM = one VMWare host server in the datacenter, then the number of physical processors will tell you how many licenses you will need. So, as it tuns out for us, yes, we were very short on licenses. Fortunately, VMWare and Cisco both have bundle licensing for multiple purchases. At the end of the day, the price per license isn’t terrible (it’s also not the cheapest either).
Like this:
What to do when you can’t SSH to your ASA?
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://1.1.1.1/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://1.1.1.1/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).
