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
- Nina