Simple Network Management Protocol (SNMP) is a widely used Internet Standard protocol for collecting and organizing information about managed devices on IP networks. Network Monitoring Systems (NMS) rely heavily on SNMP to query infrastructure devices to determine their health and performance.
Core SNMP Architecture
SNMP operates on a manager/agent model consisting of several key components:
- SNMP Manager: The central server (e.g., your monitoring software) that actively requests information or listens for alerts.
- SNMP Agent: A software module residing on a Managed Device (like a router, firewall, switch, UPS, or wireless access point). The agent answers queries from the Manager.
- MIB (Management Information Base): A text file acting as a "dictionary" that tells the SNMP Manager what data the Agent is capable of providing.
- OID (Object Identifier): A long string of numbers (e.g.,
1.3.6.1.2.1.2.2.1.10) that points to exactly one specific piece of data, such as a switch port's inbound traffic counter.
How Polling and Counters Work
The standard workflow is Polling. Every 60 seconds, the Monitoring Server sends an SNMP Query (UDP Port 161) to the Device Agent asking for specific OIDs. The Agent responds.
Most network data is stored as a Counter. For example, ifInOctets counts the total number of bytes received on an interface since the device booted. If the counter reads 1,000,000 bytes at 12:00 PM, and 1,060,000 bytes at 12:01 PM, the monitoring server calculates the difference (60,000 bytes in 60 seconds) to plot an interface bandwidth rate of 8 kilobits per second on a graph.
Note: Modern networks with gigabit speeds require 64-bit counters (SNMPv2c/v3). Older 32-bit counters will "wrap" or reset to zero too quickly on high-speed interfaces, resulting in broken, inaccurate graphs.
Typical SNMP Metrics
- Interface Status (Up / Down)
- Bandwidth Utilization (In/Out Octets)
- Interface Errors and Discards
- Device CPU and Memory Utilization
- System Uptime
- Temperature (where hardware sensors are supported)
Traps and Informs
Polling is slow (usually every 1–5 minutes). If a power supply fails, you do not want to wait 5 minutes to find out. SNMP Traps allow the Managed Device to instantly send an unsolicited alert to the Manager (on UDP Port 162) the exact millisecond a failure occurs.
An Inform is essentially a Trap that requires an acknowledgment receipt from the Manager, ensuring the alert wasn't lost in transit.
SNMP Versions
| Version | Authentication | Privacy / Encryption |
|---|---|---|
| SNMPv1 | Plaintext Community String (Insecure) | None |
| SNMPv2c | Plaintext Community String (Insecure) | None (Adds 64-bit counter support) |
| SNMPv3 | Cryptographic Hash (SHA/MD5) | AES/DES Encryption |
Note: A "Community String" acts as a password. You should never expose real community strings in documentation or code.
Common Troubleshooting
- Wrong Version or Credentials: The monitoring system is sending SNMPv2c queries, but the switch is configured only for SNMPv3.
- Firewall Blocking: A Stateful Firewall or local ACL is blocking UDP 161.
- Unsupported MIB / Incorrect OID: You are asking a Cisco switch for a temperature OID that only exists on Juniper hardware.
- Interface Index Changes: Sometimes when a device reboots, its internal interface IDs change (e.g., eth0 moves from ID 2 to ID 3). The monitoring server continues polling ID 2, resulting in graphing the wrong port.
Security Best Practices
- Prefer SNMPv3 where practical for its cryptographic security.
- Never expose SNMP to the public Internet.
- Restrict permitted monitoring sources using strict ACLs on the managed device (only allow the exact IP of the monitoring server to query the device).
- Monitor your devices for SNMP authentication failure traps.