cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2453
Views
0
Helpful
9
Replies

IPS auto-update vs manual download

corey
Level 1
Level 1

Is there a delay in what's available via auto-update and updates that are available for manual download through cisco.com?  I noticed today that S498 became available yesterday, but my IPS module in my ASA hasn't downloaded it automatically yet.  When I do a #sh statistics host, I have a recent download attempt that says "Success: No installable auto update package found on server.

Just wondering if there is a delay between manual and auto updates or if I need to be concerned that my auto-udpates aren't working properly.

Thanks!

1 Accepted Solution

Accepted Solutions

Corey;

  It sounds like you are encountering bug CSCsq53214.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsq53214

  The fix is, as you asked, to reboot the module.  You should be able to confirm current signature update from the output of 'sh ver' issued on the CLI.

Scott

View solution in original post

9 Replies 9

Scott Fringer
Cisco Employee
Cisco Employee

There should not be a delay on the availability of the update on the website.  When your sensor is scheduled to check may be later than the time it was posted and cause a potential delay.

Scott

I believe it's checked today - last directory read attempt was today, but I guess the last download attempt was yesterday.  What's the difference?  And if it is indeed not working, what's the best way to troubleshoot my issue.  Here's the pertinent info from my sh statistics host:

Auto Update Statistics
   lastDirectoryReadAttempt = 18:24:12 UTC Wed Jun 23 2010
    =   Read directory: https://198.133.219.25//cgi-bin/front.x/ida/locator/locator.pl
    =   Success: No installable auto update package found on server
   lastDownloadAttempt = 19:44:09 UTC Tue Jun 22 2010
   lastInstallAttempt = 19:45:05 UTC Tue Jun 22 2010
   nextAttempt = 19:24:00 UTC Wed Jun 23 2010

Thanks!

The "lastDirectoryReadAttempt" is when the last check occurred (should match your scheduled timing).  If the status is that there is no available update, that is as far as the process goes.  If an update is available, the sensor should attempt to download.

The "lastDownloadAttempt" will indicate the last time an update download was found and the download was attempted.

The "lastInstallAttempt" will indicate the last time an update was downloaded and install initiated.

It does look like it checked at a point today and did not find an available update.  That your outputs are UTC, I cannot correlate when the check today was run in relation to the publishing of the latest update.  It may be that there is a cache engine between your sensor and Cisco, and it is indicating that there is nothing available.  I would give the process another 24 hours to update.

Scott

I think I may have a larger issue.  According to IDM, my CPU has been sitting at 100% for the last few days and the Analysis Engine Status has been sitting on "Processing Transaction" the whole tim as well.  I'm wondering if it might have had an issue trying to apply it's sig update.  Is there a way to kick the process in the pants and get it moving again?  Should I reboot the module?  The sensor is still picking up events.

Corey;

  It sounds like you are encountering bug CSCsq53214.

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsq53214

  The fix is, as you asked, to reboot the module.  You should be able to confirm current signature update from the output of 'sh ver' issued on the CLI.

Scott

I think you're right, Scott.  One final question - rebooting the module does not affect the ASA, right? (I can reboot it without affecting my users, right?)

Corey;

  It is possible to reboot the AIP-SSM without impacting user traffic.  There are some things to check:

- mode of operation:

  - fail-open will allow traffic to traverse the ASA while the AIP-SSM is rebooting

  - fail-close will dstop traffic from traversing the ASA while the AIP-SSM is rebooting

- presence of failover for the ASA

  - if no failover configured, you should encounter no issue

  - if you are operating in active/standby failover, a failover will occur

    - you can overcome this by removing the service policy for IPS inspection prior to the reboot of the AIP-SSM

Scott

Thank you for all your replies!

Corey;

  You're certainly welcome - always a pleasure to assist!

Scott

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: