Our AIP-SSM [version 6.1(2)E3] crashed during a S389 Signature upgrade on Friday. Neither a "session 1" command from its host, an ASA5520, or a "reload" command of the ASA5520 succeeded in bringing back up the AIP-SSM. Fortunately, after the ASA's power was recycled, the AIP-SSM successfully booted, albeit not to S389, but to its previously loaded S383. I established an SR and supplied the "show tech" and "show config," but the Cisco tech replied "nothing stands out" in them and said just run the S389 update again and send the same info if it crashes. I have several problems with that approach: 1) he had replied that several other customers had had the same problem; 2) our current AIP-SSM is a replacement for an RMA'ed one which had choked on the E2 engine upgrade a few months ago; 3) if another S389 upgrade attempt fails, our client's network will be down because our security policy requires the ASA's bypass mode for the AIP-SSM to be "fail-close." My questions to the forum include:
1) If the "show tech" command is run after an AIP-SSM has rebooted after a previously-attempted S389 upgrade, can it include any information specific to the previously-attempted S389 upgrade? 2) Could the hardware components of the AIP-SSM-10 be inadequate for the combination of the E3 engine plus the cumulative signatures? 3) If the answer to question 2 is "yes" or "possibly," could Cisco modularize the signatures, eg. provide an "only-activated-signatures" (ie smaller) file for customers like us and an "everything" for others? Advice and recommendations heartily requested.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...