Has anyone had any problems with the ASA 5520's locking up?
We replaced a pair of PIX 525's towards the end of last month with a pair of ASA5520's in single context mode with active/standby failover. Afterward, several times a day, whichever unit was the current primary would for no apparent reason stop responding on the inside interface and stop passing traffic. Manually failing over to the standby unit would start things moving again until that one too would eventually lock up requiring manual failover back to the original primary unit. Cisco tech support is stumped by the problem. Pulling the IPS modules from the ASA's didn't help. Last Friday we reverted back to the Pix 525's due to the persistant disruption in service and pulled the ASA's offline.
The Pix 525's running pix os 6.3(3) with the same configuration (except for the syntax differences between 6.3(3) and the 7.2.1 OS version that the ASA's were running) are rock solid.
Has anyone had a similar experience that could provide any insight as to what is going on?
Look for another recent post on this forum titled "ASA Software Reliability". It discusses problems people have been having with PIX OS 7.1 and 7.2. The solution seems to be to downgrade to 7.0(4) or 7.0(6).
The tech I've been working with just kept asking to be sent more syslogs, and more captures of various show commands executed at the console at the time of the lockups. Other then exempting http packets from inspection he didn't have any suggestions. What he wanted was for us to set up a way for him to remote in at the time of a crash so he could view the problem live. We aren't able to allow this type of extended downtime.
In the absence of any imminent solution we had to pull the ASA's off line and revert back to the pixes due to the chronic instability of the ASA's. I read the other thread you referred me too and will try downgrading the OS.
Has any one else in the forum gotten specific confirmation or information from Cisco about the 7.1 and 7.2 OS versions?
We have been running 7.2.1(20) in production for 8 days now without major problems. At least nothing that was mentioned so far. As far as the inspect esmtp goes, there are still major issues with it and a new case will be opened probably tomorrow.
The issue is that the inspect (or fixup for the oldtimers) does not take into consideration smtp payload from previous packet to decide if it is the end of a message. If a packet comes in with a "." at the beginning of the smtp payload, everything else is being trashed as the ASA believed that it was the end of the mail message even if the period actually is part of the message.
I captured packets on both side of the ASA and I am surprised that nobody caught that before.
What is the probability of having such an email - had quite a few that were stuck in my mail servers because of the commands being invalidated.
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationConfigure one of the connectivity options to access the Cisco IMC from the n...
Firepower Threat Defense (NGFWv) on UCS E-series - Transparent Mode in HA
DocumentationCode download linksGoalRequirementLimitationsSupported ISR and UCS-E ModelSupported ISRG2 and UCS-E Blades:Supported ISR4K and UCS-E Blades:Step by Step ConfigurationCo...
I am currently unable to specify "crypto keyring" command when configuring VPN connection on my cisco 2901 router.
The following licenses have been activated on my router :