SNMP Monitoring — A Practical Guide for Network Teams

SNMP is the backbone of network monitoring. Almost every router, switch, server and network appliance supports it. Yet many NOC teams barely scratch the surface of what SNMP can tell them. This guide goes beyond the basics.

Understanding SNMP Versions — Which One Should You Use?

SNMPv1 is the original standard from 1988. Community string authentication, no encryption. Still used for legacy equipment but should be replaced wherever possible.

SNMPv2c adds 64-bit counters (critical for high-speed interfaces where 32-bit counters wrap around too quickly) and bulk operations for faster data collection. Still uses community strings without encryption. This is the most widely deployed version in Indian networks.

SNMPv3 adds authentication (MD5/SHA) and encryption (AES/DES). For any security-conscious deployment — government networks, financial institutions, telecom operators — SNMPv3 should be mandatory. The performance overhead is minimal on modern equipment.

OIDs and MIBs — What You Actually Need to Monitor

Every monitorable parameter on a network device has an OID (Object Identifier) — a dotted numeric string like 1.3.6.1.2.1.2.2.1.10 (which is the interface input octet counter). MIBs (Management Information Bases) are the dictionaries that translate these numeric strings into human-readable names.

For most network monitoring, the following OIDs from the standard IF-MIB and RFC1213-MIB are sufficient:

• Interface utilisation — ifInOctets / ifOutOctets (bandwidth consumption)
• Interface errors — ifInErrors / ifOutErrors / ifInDiscards (packet loss indicators)
• CPU utilisation — varies by vendor (check vendor MIB)
• Memory utilisation — varies by vendor
• Interface operational status — ifOperStatus (1=up, 2=down)
• System uptime — sysUpTime

For vendor-specific parameters (temperature sensors, power supply status, fan status, optical power on transceivers), you need the vendor's proprietary MIB. Cisco, Juniper, Huawei and Ericsson all publish their MIBs. Import them into your NMS and suddenly you have 200+ additional monitorable parameters per device.

Setting Alert Thresholds That Actually Matter

The most common NMS problem we see is alert fatigue — a NOC screen with 400 active alarms, most of which are spurious or low-priority. The NOC team learns to ignore everything, and the one critical alarm gets missed.

Good threshold setting requires:

• Baselining — run your NMS for 4 weeks without alerting to understand what "normal" looks like for each device and each time of day
• Tiered severity — not every alert is critical. CPU at 85% for 5 minutes is a warning. CPU at 95% for 15 minutes is critical. Define these tiers.
• Holddown timers — an interface that bounces up-down-up in 30 seconds should generate one alert, not three. Holddown prevents alert storms during transient events.
• Suppression rules — if a parent link is down, suppress alerts from child devices. Otherwise a single backbone failure generates 500 alarms for every downstream device.

Trap-Based vs Poll-Based Monitoring

Poll-based monitoring asks each device for data on a schedule — every 5 minutes, every 15 minutes. It is proactive and gives you trends, but it only catches problems between polls. If a link goes down at minute 1 and recovers at minute 4, polling at 5-minute intervals misses the event entirely.

Trap-based monitoring is reactive — the device sends an alert to the NMS the moment a threshold is crossed or a state changes. This gives you near-instant notification of critical events. The combination of both — polling for trends and traps for immediate alerts — is what professional telecom and enterprise NOC teams use.

Back to Blog