FirePOWER – ‘DataPlaneInterface0’ is not receiving and packets

KB ID 0001344 

Problem

While replacing a FirePOWER Management console, I got this error;

FirePOWER Data Plane Interface0 not recieving any packets

Interface Status
Interface ‘DataPlaneInterface0’ is not receiving any packets

 

Solution

A look a the health monitor showed me the same thing;

FirePOWER Alert Data Plane Interface0 not recieving any packets

Firstly, common sense dictates, that this is a live firewall and traffic is actually flowing though it? In my case the traffic simply needed to be ‘sent though’ the module. Execute the following, (or check for the presence of matching configuration);

access-list ACL-FirePOWER extended permit ip any any
class-map CM-SFR
 match access-list ACL-FirePOWER
 exit
policy-map global_policy 
 class CM-SFR
  sfr fail-open
exit
exit
write mem

Note: Here I’m assuming you want to ‘fail-open’ i.e. not block traffic if the FirePOWER module fails, and you are inspecting ‘inline’ (not passively).

Then apply the cup of coffee rule, and ensure some traffic is sent via the firewall.

FirePOWER Alert fixed

Failover (Active / Standby) Firewalls and FirePOWER

As pointed out (below, thanks Marvin) If you have an active/standby failover firewall pair, you will also see this error from the SFR module in the standby firewall. Which makes sense because this firewall is not passing any traffic!

Dataplane not receiving packets

Related Articles, References, Credits, or External Links

NA

Author: PeteLong

Share This Post On

8 Comments

  1. The other common cause of this alert that bears mentioning is that the device may be standby in an Active-Standby High Availability (HA) pair.

    Keep up the good work Pete!

    Post a Reply
    • 🙂 Hi Marvin Yes – I didn’t consider that, (need more coffee and less Microsoft jobs!)
      Always a pleasure.
      Pete

      Post a Reply
  2. Hi

    I guess for an Active/Active asa with firepower-5516-x ,deployment will behave the same ?

    Regards

    Charles

    Post a Reply
    • No? With active/active both SFRs should be receiving traffic.

      Post a Reply
  3. So the real question is how to monitor firepower module activity in a failover pair without having to constantly see the error message for the standby ASA interface not receiving traffic. I actually just got done troubleshooting an issue with a client where their policy-map had “sfr fail-open” removed from the sfr defined class. I had previously turned off interface monitoring in the health policy, because I hated seeing the standby ASA in a constant failed mode in FMC. This option needs to be more tune-able. Or perhaps I just need to upgrade all my clients to FTD or FPR devices.

    Post a Reply
    • Hi Greg, Agreed, it’s nothing if a bit ‘clunky’ but then that’s pretty much the same for most FirePOWER things! FTD I don’t like at all 🙁

      P

      Post a Reply
  4. FirePOWER modules running independently inside ASAs have still more advantages than FTD.

    But Cisco is still well behind on this IDS/IPS race…. I visit data centers and I mention FirePOWER to security teams and is the equivalent of saying Windows XP/7/10/20xx in a hacker course…. it is a joke!

    I like Cisco but I can’t disagree with network gurus trashing Cisco moves like the SG switches and Firesource…. it simply does not work!

    Post a Reply
    • I 100% agree with you, not sure how it will play out, But Cisco traditionally have rested on their, ‘People will just buy our product, don’t worry about it’ attitude. TBF its worked for them so far. Firepower is a massive bag of spanners.

      Post a Reply

Leave a Reply to PeteLong Cancel reply

Your email address will not be published. Required fields are marked *