Forum Discussion

KBrinkerhoff's avatar
KBrinkerhoff
Icon for Contributor rankContributor
25 days ago
Solved

Cloud-delivered FMC

Hi All,

We're seeing a bit of an uptick in customers moving to the cloud-delivered firewall management center from Cisco as opposed to traditional virtual FMCs.  This seems to be a trend with Cisco alongside things like Intersight becoming more prevalent, which the powerpack has already been developed for.  Is there any current intention (or possibly something I missed) to monitor Cisco Firewalls through cloud FMC?  Admittedly I haven't done much research yet into possible open API capabilities for this.

  • TaylorJohnson's avatar
    TaylorJohnson
    24 days ago

    "Best practices" will vary from user to user based on the parameters you have to work in, so I can't guide you to a definite answer there. If you're looking at the existing "pre-made" integrations for SL1, you'll have much more depth of monitoring with SNMP and/or Linux Base Pack to monitor FirePower devices. If you want to spend some time to whip up some REST API based dynamic applications to pull data from FMC and those other caveats I shared don't bother you, then that's a totally reasonable path to take as well. It mostly depends on what level of monitoring you're looking for and at what scale. 

    Creating a dynamic application to authenticate with FMC and collect the list of managed devices with basic config would be pretty simple and scale well, so if that's all you want, that's a reasonable approach. If you want detailed interface, cpu, memory and other performance metrics at the 1 minute or 5 minute interval along with collecting alarms, topology, and other things, then going through the FMC API may be the more difficult path as opposed to Cisco Base Pack and Linux Base Pack for each appliance. 

    Usually the "ideal" path is like you mentioned, Use the API to pull high level data (that may only be available in the API), then use SNMP/SSH directly to the appliances for the high fidelity, high volume data. If you choose to model the appliances through the rest API collections as components, you can merge those with the physical devices discovered via IP address in SL1. 

    If FirePower devices turn off connectivity features when in a managed mode, that does "throw a wrench" in things, and you will have to make some decisions on the fidelity and volume of monitoring you desire. 

3 Replies

  • We currently have nothing on the roadmap for FMC. In general, you'll have better breadth and depth of monitoring when communicating directly with the devices from SL1 as well as a more stable experience. Vendors like Cisco generally do not recommend attempting to pull all device data from their controllers through the API because the hardware is not spec'd for that and the API becomes a bottleneck quickly. Even product like Meraki where the API is the selling point warn against trying to pull interface data from their API into a monitoring product like SL1. API schemas change more frequently than things like SNMP as well so the maintenance cost is higher to keep the monitoring current. 

    That said, if you want to supplement direct monitoring with aggregate metadata FMC, it should be pretty easy to create simple dynamic applications to pull in data from the FMC rest API using the low-code Snippet Framework. Several examples can be seen here: https://support.sciencelogic.com/s/sl1-studio

    You could also try using the Dynamic Application builder tool found on that page to create those collections. 

    You aren't the first person to ask about this, so hopefully someone who has made a dynamic application for FMC will chime in. I'm sure someone in the "PowerPack" User Group has! I'm happy to discuss your use cases and what you're trying to solve more if you'd like! 

    • KBrinkerhoff's avatar
      KBrinkerhoff
      Icon for Contributor rankContributor

      Hey Taylor,

      Appreciate the feedback on this.  Makes sense to me.  Would it be fair to say that best practice with SL1 for any FMC deployment is direct SNMP to the devices then?  Then potentially leverage the FMC for aggregate data?  We typically try to monitor and get backups from the FMC because once an FTD is managed by FMC you can no longer manage the FTD directly, but if the data gleaned from FMC is little to no different from direct SNMP then perhaps we should rethink that.  

      • TaylorJohnson's avatar
        TaylorJohnson
        Icon for Moderator rankModerator

        "Best practices" will vary from user to user based on the parameters you have to work in, so I can't guide you to a definite answer there. If you're looking at the existing "pre-made" integrations for SL1, you'll have much more depth of monitoring with SNMP and/or Linux Base Pack to monitor FirePower devices. If you want to spend some time to whip up some REST API based dynamic applications to pull data from FMC and those other caveats I shared don't bother you, then that's a totally reasonable path to take as well. It mostly depends on what level of monitoring you're looking for and at what scale. 

        Creating a dynamic application to authenticate with FMC and collect the list of managed devices with basic config would be pretty simple and scale well, so if that's all you want, that's a reasonable approach. If you want detailed interface, cpu, memory and other performance metrics at the 1 minute or 5 minute interval along with collecting alarms, topology, and other things, then going through the FMC API may be the more difficult path as opposed to Cisco Base Pack and Linux Base Pack for each appliance. 

        Usually the "ideal" path is like you mentioned, Use the API to pull high level data (that may only be available in the API), then use SNMP/SSH directly to the appliances for the high fidelity, high volume data. If you choose to model the appliances through the rest API collections as components, you can merge those with the physical devices discovered via IP address in SL1. 

        If FirePower devices turn off connectivity features when in a managed mode, that does "throw a wrench" in things, and you will have to make some decisions on the fidelity and volume of monitoring you desire.