Active/Standby ASA 5520 + SSM-10=Failures

Unanswered Question
Dec 17th, 2007


We have two ASA5520s, both at 7.2(2) running in active/standby failover. Each of the ASA's have an AIP-SSM-10 in them running 6.0(3)E1. The configuration is in promiscuous mode assign to global policy, all traffic.

The primary will be running fine until it transitions to the secondary with a message: Module in slot slot experienced a data channel communication failure, data channel is DOWN. When I go to the SSM it will not let us in by ASDM, I can telnet and it will allow us to log in, shows the disclaimer info but never gives a cli prompt. The secondary will be running for a while, then it exhibits the same behavior and its SSM become unresponsive. The ASA transition again regardless if the SSM is back online or not. If it is it operates normally.

If it were 1 SSM I'd say it was the problem but both of them are doing it which leads me to consider configuration or is there something else I am missing somewhere.

We want to put these SSM-10's inline but not with there current instability.

Any suggestion at this point would be most helpfull.

Jim Collin

Maui Land and Pineapple Company Inc.

[email protected]

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
tstanik Tue, 12/25/2007 - 11:34

You are hitting cisco bug CSCse41795. The workaround will be to disable esmtp inspection and then re enable it and check if the problem still persists.

warcorp999 Sun, 12/30/2007 - 11:07

Unfortunately no, this bug was corrected in 7.2(2), which we are running. Any other ideas?

ty-smith Fri, 01/18/2008 - 13:53

I've got the exact same problem. I opened a TAC case and was told too much traffic was being redirected to the AIP module, overflowing a queue, causing the failure. We were using the modules for a couple of months before we began experiencing this issue. It got so bad I had to completely disable redirection to the module. We're not inspecting ESMTP traffic, but I'm going to try disabling protocol inspection entirely and apply the service-policy to see if it could be one of the other defaults that is the culprit. That makes more sense to me than volume because our traffic volume didn't changed considerably. Need approval so it may be awhile.

warcorp999 Fri, 01/18/2008 - 13:56

I'd come to the same conclusion and lowered the type of traffic being redirected to see if it improved the issue.

ty-smith Fri, 01/18/2008 - 14:01

I also tried limiting redirected traffic to no avail. Did you happen to try disabling all default protocol inspections (i.e. FTP, DNS, NETBIOS, etc)? I can't make any changes now because we're in a blackout period.

warcorp999 Mon, 01/21/2008 - 12:43

The only thing I have done up to this point is limit traffic, we are sending all traffic limited by ACL but I see one just dropped off, so we will start to limit to inspected protocols shortly. I'll let you know how it goes.

ty-smith Wed, 02/13/2008 - 12:18

Just wanted to let you know I completely removed the global default inspection policy and excluded VoIP traffic from the list of traffic to be inspected by the AIP module and have been inline (dropping IM and P2P traffic with the module) for about a week now with no HA failovers. Not sure which fixed it or if both are necessary but so far so good. Let me know what you find out.


This Discussion