SNMP is how monitoring systems actually know your interface went down, your CPU spiked, or your optics are running hot. Every NMS you will ever deploy (LibreNMS, Zabbix, SolarWinds, Catalyst Center's assurance features) speaks it. This article explains the architecture, then polls a real Cisco IOS XE router from a Linux host with both SNMPv2c and SNMPv3, including what happens when credentials are wrong. It is part of the IP Services complete guide.
Manager, Agent, MIB, OID
Four terms carry the whole protocol. The manager is the monitoring station that asks questions. The agent is the process on the router that answers them. The MIB (Management Information Base) is the schema: a tree of everything the agent can report. And an OID (Object Identifier) is one specific leaf on that tree, written as dotted numbers. 1.3.6.1.2.1.1.5.0 is the device's name; the MIB file is what lets your tools display that as the human-readable sysName.0.
Traffic flows two ways: the manager polls the agent on UDP 161 (get/walk), and the agent can push unsolicited traps (or acknowledged informs) to the manager on UDP 162 when something happens.
SNMPv2c: One Line to Configure, One Secret to Steal
On the router, a read-only v2c setup is a single line plus optional identity strings:
snmp-server community pinglabz-ro RO
snmp-server location PingLabz CML Lab
snmp-server contact noc@pinglabz.comFrom the Linux management host, the classic first poll, straight from the lab:
j@llmbits:~$ snmpget -v2c -c pinglabz-ro 192.168.99.1 sysDescr.0 sysName.0 sysUpTime.0 sysLocation.0 sysContact.0
SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software [IOSXE], Linux Software (X86_64BI_LINUX-ADVENTERPRISEK9-M), Version 17.18.2, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2025 by Cisco Systems, Inc.
Compiled Fri 19-Dec-25 03:28 by mc
SNMPv2-MIB::sysName.0 = STRING: R1.pinglabz.lab
SNMPv2-MIB::sysUpTime.0 = Timeticks: (93503) 0:15:35.03
SNMPv2-MIB::sysLocation.0 = STRING: PingLabz CML Lab
SNMPv2-MIB::sysContact.0 = STRING: noc@pinglabz.comWalking a table is where SNMP earns its keep. The interface table (IF-MIB) is what every monitoring dashboard is built on:
j@llmbits:~$ snmpwalk -v2c -c pinglabz-ro 192.168.99.1 ifDescr
IF-MIB::ifDescr.1 = STRING: Ethernet0/0
IF-MIB::ifDescr.2 = STRING: Ethernet0/1
IF-MIB::ifDescr.3 = STRING: Ethernet0/2
IF-MIB::ifDescr.4 = STRING: Ethernet0/3
j@llmbits:~$ snmpwalk -v2c -c pinglabz-ro 192.168.99.1 ifOperStatus
IF-MIB::ifOperStatus.1 = INTEGER: up(1)
IF-MIB::ifOperStatus.2 = INTEGER: up(1)
IF-MIB::ifOperStatus.3 = INTEGER: up(1)
IF-MIB::ifOperStatus.4 = INTEGER: down(2)Index 4 (an unused interface) reports down(2). Your NMS turns exactly this walk into the red/green port map you look at every day.
Now the security problem. That community string travels in cleartext in every packet, and it is the entire authentication. Get it wrong (or don't have it) and the agent does not even send an error, it just stays silent:
j@llmbits:~$ snmpget -v2c -c wrongstring -r 1 -t 3 192.168.99.1 sysName.0
Timeout: No Response from 192.168.99.1.Silence is deliberate (no information leak to scanners), but the flip side is that anyone who sniffs one legitimate poll owns your read access. That is why v2c survives only on isolated management networks, and why the CCNA wants you to know v3.
SNMPv3: Users, Groups, and Real Cryptography
SNMPv3 replaces community strings with a user-based security model. Three security levels exist:
Username only, no crypto. Barely better than v2c.
Authenticated (SHA/MD5 HMAC), not encrypted. Tamper-proof but readable.
Authenticated and encrypted (AES). The only level worth deploying.
Configuration is a group (which sets the security level) plus a user (which carries the keys):
snmp-server group NETADMIN v3 priv
snmp-server user snmpadmin NETADMIN v3 auth sha AuthPass123! priv aes 128 PrivPass123!Verification on the router (note the user does not appear in the running config, by design; you must use show snmp user):
R1#show snmp group | include groupname|security
groupname: NETADMIN security model:v3 priv
groupname: pinglabz-ro security model:v1
groupname: pinglabz-ro security model:v2c
R1#show snmp user
User name: snmpadmin
Engine ID: 800000090300AABBCC001300
storage-type: nonvolatile active
Authentication Protocol: SHA
Privacy Protocol: AES128
Group-name: NETADMINAnd the authenticated, encrypted poll from the manager:
j@llmbits:~$ snmpget -v3 -u snmpadmin -l authPriv -a SHA -A 'AuthPass123!' -x AES -X 'PrivPass123!' 192.168.99.1 sysName.0 sysUpTime.0
SNMPv2-MIB::sysName.0 = STRING: R1.pinglabz.lab
SNMPv2-MIB::sysUpTime.0 = Timeticks: (94125) 0:15:41.25Same data as v2c, but now the request is HMAC-authenticated and the payload rides inside AES-128. A wrong auth key fails cryptographically instead of just timing out, and nothing on the wire is readable.
Reading the OID Tree Without Crying
Every OID in the captures above lives under one famous prefix: 1.3.6.1.2.1 is mib-2, the standard tree every vendor implements (iso.org.dod.internet.mgmt.mib-2). System identity sits at 1.3.6.1.2.1.1 (sysDescr is .1, sysUpTime .3, sysName .5), and interfaces at 1.3.6.1.2.1.2. Vendor-private data lives under 1.3.6.1.4.1.<enterprise>, and Cisco's enterprise number is 9, which is why Cisco-specific counters (CPU, memory, temperature) all start with 1.3.6.1.4.1.9. You do not memorize trees; you learn the two prefixes, and you use snmptranslate -On IF-MIB::ifDescr when you need to convert between names and numbers. Scalar objects end in .0; table cells end in their row index, which is why sysName.0 but ifDescr.2.
Version Comparison at a Glance
1988 vintage. Community strings, 32-bit counters (they wrap fast on 10G links). Historical only.
Adds getbulk and 64-bit counters. Still cleartext communities. Fine on an isolated mgmt VLAN, indefensible elsewhere.
User security model, SHA auth, AES privacy, engine IDs. The deployable answer; slightly more config, much less regret.
Traps: The Agent Speaks First
Polling has a blind spot: if you poll interfaces every five minutes, a flap that lasts ninety seconds can come and go between polls. Traps close that gap by letting the agent push events the moment they happen. Configuration is two parts, what to send and where to send it:
snmp-server enable traps snmp linkdown linkup
snmp-server enable traps config
snmp-server host 192.168.99.100 version 3 priv snmpadminBe selective with enable traps: enabling everything turns your trap receiver into a firehose of BGP, entity, and environmental noise that nobody triages. Link state, config changes, and environmental alarms are the usual short list. Traps ride UDP 162 and are unacknowledged; if delivery matters, use informs (snmp-server host ... informs), which are retransmitted until the manager acknowledges them, at the cost of state on the device.
In practice, mature monitoring uses both planes: traps for immediacy, polling as the safety net that catches whatever a lost trap missed. That combination (plus syslog, which overlaps traps considerably) is what keeps dashboards honest.
Operational Notes
Several things bite people in production. First, restrict who may poll: pair the community or group with an ACL (snmp-server community pinglabz-ro RO 99, where ACL 99 permits only your NMS addresses) so random hosts get the same silence a wrong community gets. Second, MIB files live on the manager, not the router; if your tooling prints raw numeric OIDs, your manager is missing MIBs (the agent was never going to send names, only numbers). We hit exactly this in the lab: the fresh Linux manager resolved nothing until the standard IETF MIB files were installed, at which point the same queries started printing SNMPv2-MIB::sysName.0 instead of dotted decimals. Third, interface indexes (that .1, .2 suffix in the walks above) are not guaranteed stable across reloads unless you configure snmp-server ifindex persist, and a graphing system that trusts unstable indexes will happily attach the WAN graph to the loopback after a reboot. Fourth, SNMP writes (RW communities) are how attackers reconfigure devices; if you do not have a tested reason for write access, do not enable it. Modern operations are moving the config side to model-driven APIs and automation tools and keeping SNMP for what it is genuinely good at: fast, cheap, universal telemetry polling.
Key Takeaways
SNMP is a manager polling an agent for OIDs defined in MIBs, on UDP 161, with traps coming back on 162. v2c is one line of config whose community string is a cleartext password (and whose failure mode is silence, as the timeout capture showed). v3 with authPriv gives you SHA authentication and AES encryption for barely more configuration, verified with show snmp group and show snmp user. Scope access with ACLs, keep RW disabled unless you need it, and let your monitoring build on the IF-MIB walks you saw here. For syslog, NTP, and the rest of the operational stack, head back to the IP Services complete guide.
