Failure to Upgrade the software of my AIP-SSM-20

Question

Dear all,
I have failed to upgrade the software of my AIP-SSM-20 on the ASA. The AIP-SSM-20 had an Image of version IPS-K9-5.1-7-E1.pkg and I tried to upgrade it to IPS-K9-6.1-1-E2.pkg but after the upgrade the AIP-SSM-20 became unusable. I can no longer log on  to the IPS Module from the ASA. When I initiated a connection to the module with session 1 command, the systems says card in slot 1 did not respond to system request. I decided to restored the system image from the ASA by using the hw-module module 1 recover configure and hw-module module 1 recover boot commands but has so far failed.When  I issued the command hw-module module 1 boot command, the status of the IPS shows recover and would be in that state even for days.And my TFTP server shows that it is transfering the images to the IPS.
I don't know where I have gone wrong and I would be very happy if somebody can give me a procedure that would help me to re-image the software of the IPS.
Any help would be highly appreciated.
Claude Fozao

Answer 1

Halijen has already send you a link to reimage,let me briefly answer what a system image and upgrade files are and the difference between them
The System Image files are meant to be used only when a complete erasing of the sensor's image is needed.  This is generally because the installed files were corrupted, or so old that it would be easier to start over and make it look like it came from the factory; than to use the standard "upgrade" files.So in case you are doing reimaging than use .img files which are system reimage files
In more than 90% of the cases, most customers will want to "upgrade" rather than do a System Image.  The "upgrade" is done from within the sensor itself, and will both load the higher version as well as convert your current configuration to work with the newer version.it uses .pkg files
A usual poblem with the System Re-imaging process is that the card winds up in a boot loop because of an error.  When ROMMON detects an error it reboots and tries the same steps again which usually winds up with the same error which causes a reboot, etc.....
So determining if the card is in a reboot loop, and what the error is would be the next step in your debugging process.
Execute "debug module-boot".  Enter "hw-module module 1 recover stop".   Wait for a few minutes, and then enter "hw-module module 1 recover boot".
The output from ROMMON on the SSM will be seen on your ASA connection.Look at the configuration being passed to the SSM's ROMMON and look for any bad entries.Watch to see if it able to download the System Image file, or if it continuously reboots.
If it continuously reboots, then look to see what error message is seen just prior to the reboot.
Some common problems:
1) Typos in IP address, gateway, tftp server IP, or system image filename.
2) If the tftp server is on the same subnet as the SSM's IP Address, then try leaving the Gateway address blank since it is not needed.
3) Remember that the IP Address is for the external interface of the SSM.  So be sure you are using an address that is applicable for the network where you are pluggin in the SSM's external interface.
4) If the TFTP Server is on another subnet, then be sure there is a route to the other network.  If having to route back through the ASA, then ensure that the ASA will allow TFTP packets to pass through the ASA.  (The ASA could wind up blocking the TFTP packets depending on the ASA configuration)
5) Be sure the file can be downloaded from the TFTP server.  Check the file permissions, and the directory where the file is located.   From your desktop try to downlaod the file from the tftp server.  This will ensure you are using the correct directory and that the file has correct permissions.  Once common problem is that the file may be /tftpboot/sensorfiles/IPS-SSM_20-K9-sys-1.1-a-6.1-1-E1.img.  But because the tftp server automatically starts in /tftpboot, you may need to NOT specify it for the file and instead just use: sensorfiles/IPS-SSM_20-K9-sys-1.1-a-6.1-1-E1.img
6) Check to make sure the file is not corrupted by running an md5sum and checking it against the value listed on cisco's web site.