Cisco

SNMP configuration on Cisco gear centers on the snmp-server command family - but the exact syntax and capabilities differ meaningfully between classic IOS, IOS-XE, NX-OS, and ASA, covered later in this guide. Beyond configuration, Cisco's own MIBs for CPU, memory, and environmental monitoring are genuinely fragmented across product lines and IOS versions in a way that trips up a lot of first-time monitoring setups - covered in detail below, since knowing which MIB actually applies to a given box is often the harder part.

SNMPv2c (community strings)

configure terminal
snmp-server community public RO
snmp-server community secretstring RW
snmp-server location "Rack 4, DC1"
snmp-server contact [email protected]
end

RO and RW control read-only vs. read-write access. Restricting a community to specific source addresses with a standard ACL is worth doing on anything internet-reachable:

access-list 10 permit 10.0.0.0 0.0.0.255
snmp-server community public RO 10

SNMPv3

SNMPv3 uses groups (which define a security level and view permissions) and users (which belong to a group):

snmp-server group MYGROUP v3 priv
snmp-server user MYUSER MYGROUP v3 auth sha MYAUTHPASS priv aes 128 MYPRIVPASS

v3 priv on the group requires both authentication and encryption (authPriv); auth instead of priv would require authentication only, and noauth neither - matching community-string-level security.

Sending traps

snmp-server enable traps
snmp-server host 192.168.1.100 version 2c public
snmp-server host 192.168.1.100 version 3 priv MYUSER

snmp-server enable traps with no further arguments enables the full default set; it also accepts specific trap categories (snmp-server enable traps snmp linkdown linkup) if you want to be selective rather than sending everything.

Platform differences

• IOS-XE - the syntax above applies essentially unchanged; IOS-XE is close enough to classic IOS for SNMP purposes that most guides don't distinguish between them.
• NX-OS (Nexus) - a real syntax difference here: rather than a simple RO/RW keyword, NX-OS maps a community directly to an RBAC role: snmp-server community public group network-operator. The group name refers to a role defined under NX-OS's own role-based access control system, not a simple read/write flag.
• ASA (firewalls) - older ASA/PIX code only supports SNMPv1; SNMPv2c and SNMPv3 were added in later releases. If a community string configured the IOS way doesn't seem to work on an ASA, checking the code version against what that release actually supports is the first thing to check.

Common OIDs and MIBs

Every Cisco-specific MIB lives under enterprises.9 (1.3.6.1.4.1.9) - Cisco's own IANA-assigned number - with the actively-maintained ones concentrated under ciscoMgmt (1.3.6.1.4.1.9.9). A handful come up constantly enough to be worth knowing by name:

• CPU utilization - CISCO-PROCESS-MIB (1.3.6.1.4.1.9.9.109). cpmCPUTotal5minRev and cpmCPUTotal1minRev are the objects almost every monitoring setup polls, giving a 0-100 percentage over the last 5 or 1 minutes. They deprecate older objects with almost identical names - cpmCPUTotal5min and cpmCPUTotal1min, without the Rev suffix - which used a narrower, less precise value range. If a walk of the newer, Rev-suffixed objects comes back empty on an older device, the plain (non-Rev) versions are worth trying instead.
• Memory - CISCO-MEMORY-POOL-MIB (1.3.6.1.4.1.9.9.48). ciscoMemoryPoolUsed, ciscoMemoryPoolFree, and ciscoMemoryPoolLargestFree cover memory on most classic IOS platforms. Newer platforms increasingly report memory through CISCO-ENHANCED-MEMPOOL-MIB (1.3.6.1.4.1.9.9.221) instead - see the gotcha below, since which one a given box actually populates is genuinely platform-dependent.
• Environmental sensors - CISCO-ENVMON-MIB (1.3.6.1.4.1.9.9.13). ciscoEnvMonTemperatureStatusValue, ciscoEnvMonFanState, and ciscoEnvMonVoltageStatusValue cover temperature, fan, and voltage status on hardware that implements this older MIB. Newer platforms report the same kind of data through CISCO-ENTITY-SENSOR-MIB (1.3.6.1.4.1.9.9.91) instead, which ties sensor readings to ENTITY-MIB's physical inventory rather than a flat, Cisco-specific table.
• Syslog messages - CISCO-SYSLOG-MIB (1.3.6.1.4.1.9.9.41). clogMessageGenerated is the notification fired for each logged syslog message, when notifications are enabled - see Understanding MIBs for how a notification's own definition works, and the Uploading MIBs guide if you want to browse this one directly.
• Standard interface data still comes from the cross-vendor IF-MIB, not a Cisco-specific one - but see the ifIndex gotcha below, since Cisco's own handling of that standard MIB's indexing has a real platform-dependent quirk worth knowing about.

Gotchas and platform-specific nuances

CPU and memory MIBs are genuinely fragmented across platforms and IOS versions. This isn't a rare edge case - it's a commonly-hit issue, including on current hardware. Walking cpmCPUTotal5minRev against a newer ISR4000-series router on recent IOS-XE, for instance, can come back as noSuchObject or "end of MIB view" even though the same object works fine on older platforms - the underlying data has moved to a different table structure on some newer platforms, or in some cases to CISCO-ENHANCED-MEMPOOL-MIB for memory specifically. If a CPU or memory OID that's supposed to be standard comes back empty, walking the whole parent MIB (1.3.6.1.4.1.9.9.109 or 1.3.6.1.4.1.9.9.221) rather than a single leaf object is the fastest way to see what that specific box actually populates, rather than assuming the object name alone will be consistent across your whole fleet.

ifIndex values can silently change across a reboot or upgrade. By default, the mapping between a physical interface and its numeric ifIndex in IF-MIB isn't guaranteed to survive a reboot - especially on boxes with virtual interfaces, SVIs, tunnels, or loopbacks, where index reassignment on restart is common. A monitoring platform that's mapped "interface 47 = core uplink" against a specific ifIndex can end up silently graphing the wrong interface's data after a routine reload, with no error or warning that anything changed. snmp-server ifindex persist (global config mode, or per-interface as snmp ifindex persist) fixes this by keeping the mapping stable across reboots - worth enabling proactively on anything being monitored by ifIndex, rather than after the first time it causes a confusing, hard-to-explain data discontinuity. One platform-specific catch: this isn't supported at all on ASA/FTD in most releases (tracked under Cisco bug IDs CSCtx33616 and CSCvx28168) - FXOS-based platforms have persistence by default instead, but ASA/FTD specifically may still reorder interfaces on reload regardless of this command.

Environmental monitoring is also platform-fragmented. Older CISCO-ENVMON-MIB and newer CISCO-ENTITY-SENSOR-MIB frequently coexist across a mixed-age fleet, and a monitoring template built against one won't automatically work against the other - a genuinely common source of "temperature/fan monitoring works on some switches but not others" within the same environment, even when every box is unambiguously a Cisco product.