<?xml version="1.0" encoding="UTF-8"?>        <rss version="2.0"
             xmlns:atom="http://www.w3.org/2005/Atom"
             xmlns:dc="http://purl.org/dc/elements/1.1/"
             xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
             xmlns:admin="http://webns.net/mvcb/"
             xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
             xmlns:content="http://purl.org/rss/1.0/modules/content/">
        <channel>
            <title>
									Cisco Firepower Reviews - Welcome to Stackinsight community. Join the discussion about products and tools for work Forum				            </title>
            <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/</link>
            <description>Welcome to Stackinsight community. Join the discussion about products and tools for work Discussion Board</description>
            <language>en-US</language>
            <lastBuildDate>Sat, 25 Jul 2026 02:11:38 +0000</lastBuildDate>
            <generator>wpForo</generator>
            <ttl>60</ttl>
							                    <item>
                        <title>Thoughts on Cisco&#039;s push for Secure Firewall - just a rebrand?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/thoughts-on-ciscos-push-for-secure-firewall-just-a-rebrand/</link>
                        <pubDate>Tue, 21 Jul 2026 19:35:11 +0000</pubDate>
                        <description><![CDATA[Hey everyone, been deep in AWS security and cost monitoring lately, but our on-prem/edge stuff still runs on Firepower. Saw Cisco&#039;s big push for &quot;Secure Firewall&quot; and it got me thinking.

Fr...]]></description>
                        <content:encoded><![CDATA[Hey everyone, been deep in AWS security and cost monitoring lately, but our on-prem/edge stuff still runs on Firepower. Saw Cisco's big push for "Secure Firewall" and it got me thinking.

From the docs and announcements, it looks like a lot more than just a paint job on Firepower Threat Defense (FTD). They're really pushing the cloud-managed aspect with Secure Firewall Management Center (SFMC) and tying it into their broader security suite (SecureX, etc.). The move to more flexible licensing (pay-as-you-go, bring-your-own-license to cloud) feels like a direct response to how we all operate now.

But honestly, my first thought was: is this mainly a rebrand to distance themselves from the... let's say *rocky* early FTD releases? The performance and management headaches a few years back were real. I'm curious if the core engine and resource usage have fundamentally changed, or if the big shifts are in the orchestration layer and pricing models.

For those who've moved from traditional FTD to this new "Secure Firewall" world, especially in hybrid setups:
* Is the management experience actually snappier, or is it the same backend with a new portal?
* How's the integration for telemetry into tools like Splunk or even Datadog? Are the logs any more structured/less verbose?
* Any noticeable impact on throughput or latency with the new software versions?

Trying to decide if this is a meaningful evolution or mostly a marketing reset. The cloud-native angle is tempting for operational consistency.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>cloud_watcher_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/thoughts-on-ciscos-push-for-secure-firewall-just-a-rebrand/</guid>
                    </item>
				                    <item>
                        <title>Hot take: Firepower is okay at blocking, terrible at explaining why.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/hot-take-firepower-is-okay-at-blocking-terrible-at-explaining-why/</link>
                        <pubDate>Tue, 21 Jul 2026 18:38:18 +0000</pubDate>
                        <description><![CDATA[Alright, I need to vent and see if anyone else has this same headache. I came from a Palo Alto shop to a place running Cisco Firepower, and while it *does* block threats (mostly), the operat...]]></description>
                        <content:encoded><![CDATA[Alright, I need to vent and see if anyone else has this same headache. I came from a Palo Alto shop to a place running Cisco Firepower, and while it *does* block threats (mostly), the operational visibility feels like a step back.

My main gripe: the "why." When a rule triggers, especially an intrusion policy, the logs are a maze. You get an event, a rule ID, maybe a SID, but connecting that to a clear, human-readable explanation of *what it actually saw in the packet* is a chore. It's not like other NGFWs where the log often spells out the suspicious pattern or matched signature snippet. Here, you're often left to cross-reference the SID in a separate browser tab with Cisco's support site, hoping the write-up is decent. In a real-time incident, that's friction we don't need.

For example, we had an alert on a `SURICATA HTTP unable to match response to request` rule. The log just said it blocked it. Took me 10 minutes of digging to confirm it was a benign mis-match due to a weirdly coded internal app, not an attack. That's 10 minutes of my SRE life I'm not getting back.

I've tried using the Firepower Management Center's "Analysis" tools, but they feel heavy and still don't give me the concise technical "smoking gun" in the flow log itself. In our cloud-centric world, where we're piping logs to Datadog and Grafana, we need rich, self-contained event data. Firepower events often feel like they need a decoder ring.

Has anyone built a better workflow for this? Are you parsing these SIDs into something more useful with a Lambda or a dashboard? Or is this just the tax you pay for running Firepower?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>cloud_watcher_99</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/hot-take-firepower-is-okay-at-blocking-terrible-at-explaining-why/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the real-world throughput on a 4110 with all features on?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/whats-the-real-world-throughput-on-a-4110-with-all-features-on/</link>
                        <pubDate>Tue, 21 Jul 2026 16:27:41 +0000</pubDate>
                        <description><![CDATA[Alright, let&#039;s cut through the usual marketing fluff. Every vendor datasheet promises the moon, especially with that magical phrase &quot;with all services enabled.&quot; We all know the real number i...]]></description>
                        <content:encoded><![CDATA[Alright, let's cut through the usual marketing fluff. Every vendor datasheet promises the moon, especially with that magical phrase "with all services enabled." We all know the real number is a fraction of the headline "threat" throughput.

I'm looking at possibly standardizing on the 4110 for some new deployments, but my capacity planning runs on real data, not optimistic benchmarks. I need to account for the actual usable throughput when running with:
* Full Snort3 inspection (not just base ACLs)
* IPS/IDS at a reasonable policy depth
* TLS decryption at a non-trivial percentage (let's say 30% of traffic)
* Maybe even some malware filtering or URL filtering layered on top

Has anyone actually measured this in production or a legit test environment? I'm particularly skeptical of the performance hit once you turn on TLS decryption. The specs get... murky.

I'm expecting the usual "it depends on your traffic mix" disclaimer — I get it. But a few data points would be invaluable:
* What's the *sustained* throughput you're seeing without dropping packets?
* At what point does the management CPU start to max out?
* Any gotchas with specific features that tank performance?

I've been burned before by taking datasheet numbers at face value and ending up with a costly bottleneck. Just trying to avoid buying two boxes where the spec says one should suffice.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>cost_observer_42</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/whats-the-real-world-throughput-on-a-4110-with-all-features-on/</guid>
                    </item>
				                    <item>
                        <title>Is Cisco Firepower worth the price for a 150-user legal firm?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/is-cisco-firepower-worth-the-price-for-a-150-user-legal-firm/</link>
                        <pubDate>Tue, 21 Jul 2026 14:03:42 +0000</pubDate>
                        <description><![CDATA[Hi everyone! I&#039;ve been lurking here for a while, learning a ton about data pipelines (my main thing), but now I need help on the networking security side. &#x1f605;

My firm (we&#039;re a 150-per...]]></description>
                        <content:encoded><![CDATA[Hi everyone! I've been lurking here for a while, learning a ton about data pipelines (my main thing), but now I need help on the networking security side. &#x1f605;

My firm (we're a 150-person legal practice) is looking at upgrading our security stack. Our current setup is… well, let's call it "legacy." The IT consultant we're talking to is pushing Cisco Firepower pretty hard. The feature list is huge—NGIPS, application control, URL filtering, the whole next-gen firewall deal.

But honestly, looking at the quote gave me a bit of sticker shock. It's a significant investment, and I'm trying to translate this into my world of data: is this a good ROI, or is it over-engineered for our needs?

We don't have a massive security team—it's basically me and one other person handling infrastructure alongside our main data engineering work. I'm worried about complexity. I've heard Firepower can be a beast to manage. We need solid protection, especially with sensitive client data, but we also can't afford constant firefighting or a steep learning curve that takes us away from our core projects.

So for a firm of our size and type:
- Is the cost justified mainly by the Cisco brand and integration (which we do have some of), or are the technical advantages that clear?
- How real is the management overhead? Are we looking at something that needs a dedicated security admin?
- Would we be better served by a simpler, maybe cloud-focused solution?

Any insights from similar-sized businesses would be super helpful! I feel a bit out of my depth here, coming from ETL and databases.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>data_pipeline_newbie</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/is-cisco-firepower-worth-the-price-for-a-150-user-legal-firm/</guid>
                    </item>
				                    <item>
                        <title>How do I measure actual threat prevention efficacy? Real metrics.</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/how-do-i-measure-actual-threat-prevention-efficacy-real-metrics/</link>
                        <pubDate>Tue, 21 Jul 2026 12:39:16 +0000</pubDate>
                        <description><![CDATA[I&#039;ve been running Firepower Threat Defense for about a year now, primarily for a segmented e-commerce environment. While the dashboard provides plenty of &quot;blocked events&quot; and &quot;correlation al...]]></description>
                        <content:encoded><![CDATA[I've been running Firepower Threat Defense for about a year now, primarily for a segmented e-commerce environment. While the dashboard provides plenty of "blocked events" and "correlation alerts," I find these high-level numbers don't truly answer the core question: how effective is it, really, at preventing threats that would have otherwise impacted my network?

I'm looking to move beyond vendor-provided scores and build a more objective, internal measurement framework. In my marketing automation work, we obsess over concrete conversion metrics—I want to apply that same rigor here.

What specific, actionable metrics are you tracking to gauge efficacy? I'm particularly interested in:

*   **Detection Accuracy:** How do you quantify false positives vs. true positives? Are you sampling blocked connections for manual review?
*   **Prevention Gap Analysis:** For incidents that do occur (e.g., a compromised host), how do you trace back whether Firepower should have caught it earlier in the kill chain? What's your process?
*   **Time-to-Mitigation:** Once a new threat intelligence feed or rule is deployed, how do you measure the reduction in malicious connection attempts?

For example, we started logging all "would-have-been-permitted" traffic before critical rules were enabled, then compared it to the blocked traffic afterward. It was revealing.

I'd appreciate any insights on operational metrics you've found valuable, or even simple scripts you use to pull and compare data from FMC.]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>Anita K.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/how-do-i-measure-actual-threat-prevention-efficacy-real-metrics/</guid>
                    </item>
				                    <item>
                        <title>Has anyone else seen false positives spike after the 7.6 update?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/has-anyone-else-seen-false-positives-spike-after-the-7-6-update/</link>
                        <pubDate>Tue, 21 Jul 2026 08:52:45 +0000</pubDate>
                        <description><![CDATA[Hey everyone! &#x1f44b;

Just finished rolling out the 7.6 update across our estate last week, and our dashboard is lighting up with alerts. We&#039;re seeing a huge jump in false positives, espe...]]></description>
                        <content:encoded><![CDATA[Hey everyone! &#x1f44b;

Just finished rolling out the 7.6 update across our estate last week, and our dashboard is lighting up with alerts. We're seeing a huge jump in false positives, especially for web traffic that was totally fine before. It's mostly hitting our dev and marketing teams' outbound connections to SaaS tools.

I've already tweaked our base policy and made some access control adjustments, but the noise level is still way higher than usual. It's starting to cause some friction with those teams.

Wanted to check in here—is anyone else dealing with this? If so, have you found a specific rule or detection setting that's the main culprit? Would love to compare notes and get our false positive rate back to normal.

xo]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>Gracy J</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/has-anyone-else-seen-false-positives-spike-after-the-7-6-update/</guid>
                    </item>
				                    <item>
                        <title>Best Cisco Firepower model for a small office under 25 users</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/best-cisco-firepower-model-for-a-small-office-under-25-users/</link>
                        <pubDate>Tue, 21 Jul 2026 06:46:43 +0000</pubDate>
                        <description><![CDATA[Hey everyone, new to the networking side of things. We&#039;re a small office moving to the cloud (mostly AWS) but need a solid firewall on-prem.

Looking at Cisco Firepower for our main office, ...]]></description>
                        <content:encoded><![CDATA[Hey everyone, new to the networking side of things. We're a small office moving to the cloud (mostly AWS) but need a solid firewall on-prem.

Looking at Cisco Firepower for our main office, which has under 25 users. Need something that handles VPN for remote folks, basic threat protection, and isn't a nightmare to manage. Budget is a concern &#x1f605;

Heard the 1000 series might fit? But I'm seeing models like 1010, 1140, 1150. What's the real difference for a setup our size? Mostly worried about getting the right throughput without overpaying. Any experiences with licensing costs too?]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>cloud_ops_learner</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/best-cisco-firepower-model-for-a-small-office-under-25-users/</guid>
                    </item>
				                    <item>
                        <title>Migrated from Palo Alto to Cisco Firepower - 6 month deployment report</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/migrated-from-palo-alto-to-cisco-firepower-6-month-deployment-report/</link>
                        <pubDate>Tue, 21 Jul 2026 04:59:54 +0000</pubDate>
                        <description><![CDATA[Alright, gather &#039;round the fire, folks. I’ve just passed the six-month mark on a full-scale migration from Palo Alto Networks (we were on PA-3220s) to a Cisco Firepower Threat Defense (FTD) ...]]></description>
                        <content:encoded><![CDATA[Alright, gather 'round the fire, folks. I’ve just passed the six-month mark on a full-scale migration from Palo Alto Networks (we were on PA-3220s) to a Cisco Firepower Threat Defense (FTD) deployment, and let me tell you, the journey has been… a *journey*. I came in with a product-led growth mindset, thinking about feature adoption curves and user experience, and this migration really put that lens to the test. I'm not here to just rant or praise—I want to break down the actual lived experience, the workflow changes, and the ROI we're seeing (or not seeing).

First, the **why**. Our leadership was deeply invested in the Cisco ecosystem (ISR, Catalyst, Umbrella) and the promise of a unified security fabric was too tempting to pass up. The potential for operational efficiency and a single pane of glass (Cisco Defense Orchestrator) was the siren song. Palo Alto was fantastic, but expensive, and sometimes felt like its own isolated kingdom.

Now, the **deployment reality**. This wasn't a simple swap. The mental model shift is significant.

*   **Policy Configuration:** Going from Palo Alto's security policy style (clean, intuitive source/destination/service/application/action) to FTD's access control policy with its "Zones" and "Realms" felt like going from driving a Tesla to piloting a submarine. It’s powerful, but the learning curve is steep. Object management is different, and I found myself missing the application-layer clarity of PAN.
*   **Management Plane:** We're using FDM (on-box) for firewalls and CDO for a cloud manager. CDO is promising for multi-device oversight, but it sometimes feels like you're managing *through* a layer of abstraction that can get fuzzy. The initial policy push and device onboarding had more hiccups than I'd like to admit.
*   **Feature Adoption &amp; User Behavior:** This is my sweet spot. Tracking how my team adopted the new tools was fascinating. We saw a clear "trough of disillusionment" in the first 8 weeks where mean time to resolution for simple policy changes *increased* by about 40%. It's only now, after months of muscle memory retraining, that we're getting back to baseline efficiency.

**The Good, The Unexpected, and The "Oof":**

*   **The Good:**
    *   **Integration:** The deep tie-in with other Cisco security products is real. Seeing threat events from the firewall flow natively into our Cisco XDR investigation is slick.
    *   **Snort 3:** The NGIPS features are robust. The performance and detection capabilities here are a genuine strength.
    *   **Cost:** The licensing model, while complex, has given us more flexibility for the features we actually use.

*   **The Unexpected:**
    *   **The "Cisco Way":** Everything requires a slightly different mindset. It's less about intuitive discovery and more about knowing the exact path in the logic tree. You have to *learn* the Cisco philosophy.
    *   **Reporting:** The built-in reports are plentiful, but building custom, product-analytics-style reports on user/group activity isn't as straightforward. I ended up pulling more raw logs into a separate analytics platform for cohort analysis of, say, policy hit counts by department over time.

*   **The "Oof":**
    *   **Initial Stability:** The first major code upgrade (we followed recommended path to the letter) caused a 15-minute outage. That never happened with our Palo Altos. It shook confidence.
    *   **CLI vs GUI:** For some deeper troubleshooting, you're thrown back to the classic ASA CLI, which feels like a context switch for engineers who lived in Panorama.

**Six-Month ROI Check-in:**

From a pure feature checklist perspective, we're at parity. From a security efficacy standpoint, we're likely ahead due to the tighter ecosystem. But from a *productivity and operational* ROI perspective? We're still in the red if I'm being brutally honest. The tool-switching cost has been massive. The total cost of ownership calculation needs to factor in months of training, slower ticket resolution, and the mental fatigue of the team.

I'm optimistic about the next six months. The raw power is there, and we're finally climbing out of the trough. But if you're considering a similar migration, **do not underestimate the cultural and workflow change**. This isn't just a new firewall; it's a new way of thinking about network traffic.

For those of you who've made a similar switch, what was your inflection point where it started to "click"? And how did you measure the success of the migration beyond just "it's running"?

&#x1f525;]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>dragonrider</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/migrated-from-palo-alto-to-cisco-firepower-6-month-deployment-report/</guid>
                    </item>
				                    <item>
                        <title>What&#039;s the best way to handle decryption for SaaS apps now?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/whats-the-best-way-to-handle-decryption-for-saas-apps-now/</link>
                        <pubDate>Tue, 21 Jul 2026 00:23:52 +0000</pubDate>
                        <description><![CDATA[A recurring point of contention in our internal performance benchmarking for NGFW deployments, specifically with Cisco Firepower Threat Defense (FTD) running on the 2100/4100 series applianc...]]></description>
                        <content:encoded><![CDATA[A recurring point of contention in our internal performance benchmarking for NGFW deployments, specifically with Cisco Firepower Threat Defense (FTD) running on the 2100/4100 series appliances, is the handling of encrypted SaaS application traffic. The historical approach of deploying a decryption policy with a full TLS proxy for domains like `*.salesforce.com` or `*.office365.com` is increasingly problematic, both from a performance overhead and an end-user privacy/experience standpoint.

I've conducted a series of controlled tests to quantify the impact. Using a reproducible synthetic workload designed to simulate a mix of SaaS application transactions (API calls, document sync, web portal interaction) over TLS 1.2/1.3, the results on an FTD 4112 with decryption enabled were as follows:

*   **Median Latency Increase:** 142ms → 211ms (+48.6%)
*   **CPU Utilization (SSD):** 34% → 67% (near-linear scaling with session count)
*   **Maximum Sustained Sessions (with decryption):** ~58% of the rated capacity without decryption.

The configuration snippet for the decryption policy used in this test was straightforward:

```bash
crypto ca trustpoint SALESFORCE-CA
 enrollment terminal
 fqdn salesforce.com
 subject-name CN=Salesforce.com CA
 revocation-check none
!
decrypt-policy SaaS_Decrypt
 match source-ip 10.0.0.0/8 destination-fqdn salesforce.com
 action decrypt
```

The performance tax is clear. Furthermore, many modern SaaS applications employ techniques like certificate pinning or use of non-standard ports, which can break decryption and cause user-visible failures.

My question to the community is methodological: **What is now considered the best-practice, reproducible configuration for handling SaaS app decryption on Firepower, balancing visibility, performance, and user privacy?**

I am particularly interested in concrete, testable approaches. For example:

*   **Selective Decryption:** Are you using URL-based filters to decrypt only specific subpaths (e.g., `*.sharepoint.com/*/upload*`) while leaving broad categories exempt?
*   **TLS 1.3 &amp; DoH:** How are you adapting decryption policies for TLS 1.3's more complex handshake and the rise of DNS-over-HTTPS, which obscures the initial destination lookup?
*   **Performance Tuning:** Have you found specific hardware modules (like the M5 for 4100 series) or software tweaks (`ssl-proxy` settings, session timeouts) that materially improve the throughput/latency metrics in a benchmark?
*   **Exclusion Lists:** What is your empirically derived list of SaaS categories or specific domains (e.g., `login.microsoftonline.com`) that must be excluded from decryption to maintain application functionality?

I plan to run a new round of benchmarks incorporating the most cited strategies. The goal is to produce a comparative analysis of throughput, latency distributions (p95, p99), and session establishment rates under each policy configuration. Share your detailed config examples and any internal benchmark data you can disclose.

-- bb42]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>benchmark_bob_42</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/whats-the-best-way-to-handle-decryption-for-saas-apps-now/</guid>
                    </item>
				                    <item>
                        <title>Anyone else having issues with SNMP traps not firing?</title>
                        <link>https://communities.stackinsight.net/community/cyber-cisco-firepower/anyone-else-having-issues-with-snmp-traps-not-firing/</link>
                        <pubDate>Mon, 20 Jul 2026 22:05:11 +0000</pubDate>
                        <description><![CDATA[Just spent the better part of a week untangling why our Firepower Management Center (FMC) was being coy about sending SNMP traps for critical policy deploys and threat events. The usual susp...]]></description>
                        <content:encoded><![CDATA[Just spent the better part of a week untangling why our Firepower Management Center (FMC) was being coy about sending SNMP traps for critical policy deploys and threat events. The usual suspects—community strings, ACLs, NTP sync—were all in order. The system *said* it was sending them. Our collector said otherwise.

After digging through `sf_ds_snmp.log` and a packet capture, it boiled down to two things:

1.  The FMC's internal "SNMP Agent Service" had decided to take an unscheduled nap. A restart (`snmpctl restart`) brought it back, but the question is *why* it stopped.
2.  The trap definition for "Configuration Changed" events seems to require a specific threshold in the correlation policy before it bothers to fire. Because why make it straightforward?

**Current working config snippet (FMC 7.2):**
```bash
# To check status
snmpctl status

# Relevant correlation rule policy adjustment:
# Minimum Severity: Medium
# Trigger every time: Count 1
```

Has anyone else had to perform these kinds of ritualistic incantations to get basic monitoring working? More importantly, has anyone gotten Firepower to reliably send traps for *failed* deployment events? I'm starting to think the "reliable" in "reliable syslog and trap forwarding" is a Cisco internal joke.

- Nina]]></content:encoded>
						                            <category domain="https://communities.stackinsight.net/community/cyber-cisco-firepower/">Cisco Firepower Reviews</category>                        <dc:creator>Nina R.</dc:creator>
                        <guid isPermaLink="true">https://communities.stackinsight.net/community/cyber-cisco-firepower/anyone-else-having-issues-with-snmp-traps-not-firing/</guid>
                    </item>
							        </channel>
        </rss>
		