The recovery using this method can takes upwards of 30 minutes, and in some cases even longer.
How long have you left the SSM in the "recovery" state?
There may be something wrong in the config you entered. when that happens the SSM can go into a continuous reboot cycle trying to do the recovery.
Execute "debug module-boot" on the console of the ASA.
The debug output will show you the ROMMON output of the SSM itself. (The SSM has it's own ROMMON. The recovery boot command sends the settings made during the recover configure command to the SSM's ROMMON).
If the ROMMON is experiencing a problem in trying to download the tftp image you should now see that ROMMON error message.
Some typical problems I have seen:
1) Wrong IP given for the sensor.
2) Wrong IP given for the gateway (the gateway must exist on the same network as the sensor) this problem usually happens when using a non-standard netmasked network.
3) Not having the sensor's command and control port plugged into the right network. The external port of the SSM itself is where the IP is being applied. You need to ensure that the extenral port of the SSM is plugged into the right network for that IP.
4) The tftp server is not reachable from the network where the sensor's command and control port is attached. Some users think that if the ASA itself can reach the tftp server that the SSM will also be able to. This is not always the case. It is best to use a tftp server on the same network as the IP provided to the SSM. Or to test the tftp server from another machine on the same network as the SSM.
5) The file name is wrong. Check the captialization especially.
6) The file is not in the default directory on the tftp server. If the file is in a subdirectory you will need to add that subdirectory to the URL:
tftp://10.20.30.40/subdirectoryname/filename
7) The tftp is timing out.
There are 2 things that can cause this:
a) The tftp server is remote, and it takes too long to download the file. The ROMMON does have limits on the number of retries and per packet timeouts (but they are not user configurable). Try using a tftp server local to the SSM.
b) The switch that the SSM connects to has spanning-tree running and spanning-tree does not complete before the SSM ROMMON times out for the tftp attempt. The tftp attempt happens immediately upon ROMMON startup and link up. But with a switch the switch port may be in a "Listen" or "Learn" state for 40 seconds before the box can actually talk on the network. In some cases the tftp download attempts started as soon as link up, and may timeout even before the spanning-tree completes. To work around this configure "spanning-tree portfast" on the switchport. Spanning-tree will connect the port into the vlan immediately rather than 40 seconds later.
If it was a config problem when configuring the recovery settings, then there is a "recover stop" command on the ASA.
It will stop the reboot cycle from happening.
Let the module come up with the old image.
Then correct your "recover configure" settings, and try the "recover boot" again.
Another alternative:
Stop the recovery "recover stop"
Let it boot into the old image.
If it was a 5.0 version, then you can actually upgrade to 5.1 using the sensor's own CLI "upgrade" command. It is actually the preferred method.
The "recover" from the ASA will wipe the box clean and load a fresh image.
The "upgrade" from the sensor will convert your 5.0 config into a 5.1 config while installing 5.1.
5.1 upgrade file:
IPS-K9-min-5.1-1g.pkg
http://www.cisco.com/cgi-bin/tablebuild.pl/ips5
It can be applied through the sensor's CLI upgrade command, or pushed directly through IDM, or applied by CSM.
The "recover" should be limited to disaster recovery. When you can't access the SSM at all, or the files on the SSM have been corrupted.
For normal upgrades you want to use "upgrade" files done through the sensor itelf (CLI, IDM, or CSM).
