ASA FirePOWER module down

[atsukane]

Hi there,

We have an issue with one of the ASA FirePOWER modules.

On the active primary ASA unit the sfr module state is Up but Data Plane Status is Down. This module was showing Unresponsive 10 mionutes earlier while I was looking and came back up without any intervention, not sure why.

The sfr module on the standby secondary ASA unit is showing Up/Up.

I'm planning on reloading the module with  sw-module module sfr reload, but wondered whether I need to failover the ASA first before doing so, or just putting the sfr to promiscuous mode is enough before reloading the module?

Please advise, and also please let me know if there are anything that I should be aware of before attempting to reload etc,.

Mod Status Data Plane Status Compatibility
---- ------------------ --------------------- -------------
0 Up Sys Not Applicable
ips Unresponsive Not Applicable
cxsc Unresponsive Not Applicable
sfr Up Down

Many thanks,

[Marvin Rhoads · Accepted solution]

If the primary ASA is active despite the module being up/down then you must have disabled monitoring of the module. Normally we would monitor this and then a failover event would occur automatically in the event of a fault.

So, in your case do a failover (after verifying that the secondary unit is in state Standby - Ready). Then you can reload primary unit's module (or ASA itself) at will.

[atsukane]

Thank you @Marvin Rhoads 

I shall failover ASA first, then once the new standby (former primary/active) is in "standby-ready" i'll reload the module, and maybe ASA if needed. Then discuss with my senior why the monitoring on the module is disabled, maybe to avoid unnecessary failover.

Thanks again.

[Marvin Rhoads]

Slight correction - check that it is Standby-Ready state BEFORE doing the failover. The manual failover should then cause it to switch to Active state.

[atsukane]

that makes sense.

[atsukane]

Reloaded the module but as the it was showing Unresponsive, reloaded the ASA  as well but the module is still in Unresponsive state. Getting the below when running sfr debugs, suppose SFR isn't very well. Opened a support case.

DP SFR Msg: SFR flow handle was not populated, so not informing SFR about flow cleanup.

cp_connect: Connecting to card 1, socket 3, port 7000
cp_connect: Error - cp_connect() returned -1
cp_check_connection: handle -1, conflicts with connection 1 (-1)
cp_check_connection: handle -1, conflicts with connection 2 (-1)
cp_check_connection: handle -1, conflicts with connection 3 (-1)
cp_update_connection: Error updating connection_id 0