SNMP Router Monitoring: Interfaces, CPU & Uptime

By the SNMP Monitoring team · Reviewed July 2026

A router is the one box where a single failure takes a whole site offline, so it's usually the first thing anyone points SNMP at. The good news: the stuff that matters most on a router — the interfaces — is standardized. Traffic, errors and link state all come out of the IF-MIB, exactly the same objects you'd walk on a switch or a server NIC. The catch is everything around the interfaces: CPU, memory and temperature aren't standardized at all, and every vendor buries them in their own enterprise MIB. Knowing which half is portable and which half is vendor-specific is the whole trick to monitoring routers well.

This is a use-case page. It leans on the IF-MIB explainer rather than repeating it — see network monitoring and interface OIDs. Parent: network monitoring.

What to monitor on a router

Priorities, roughly in the order they'll wake you up:

• Interfaces first — per-port traffic, errors and up/down state. A flapping uplink or a saturated WAN circuit is the most common router incident.
• Reachability and uptime — is the box even answering, and did it reboot on you?
• CPU load — a router pegged at 100% CPU drops packets and delays routing updates. Vendor-specific OID.
• Memory — control-plane memory exhaustion (big routing tables, leaks) can wedge a router. Vendor-specific.
• Temperature and environment — chassis routers expose sensor MIBs; overheating precedes hardware failure.
• Routing health — BGP/OSPF neighbour state, where the platform's protocol MIBs expose it.

The first two are portable across every vendor. The rest need you to know whose box you're on.

Per-interface metrics

This is the portable core, and it's identical to any other IF-MIB device. Each interface is a row you walk:

• Traffic — ifHCInOctets / ifHCOutOctets, diffed between polls (see interface traffic).
• Errors and discards — ifInErrors / ifOutErrors, watched as a rate (see interface errors).
• State — ifOperStatus (.8), so you know a link is actually up, not just configured.
• Speed — ifHighSpeed, to feed utilization math on WAN uplinks.

On a router the interfaces you care about most are the uplinks and WAN circuits — a congested transit link is felt by everyone behind it. Full object types live on the reference twin, interface OIDs; the mechanics are on the network pillar. No point repeating the counter-wrap lecture here.

Router CPU & memory

Here's where portability ends. There is no universal "router CPU" OID. Unlike hrProcessorLoad on a general-purpose server, network vendors expose CPU and memory through their own enterprise trees under 1.3.6.1.4.1:

• Cisco IOS reports CPU and memory via its process and memory-pool MIBs — see Cisco SNMP for the exact objects.
• MikroTik RouterOS exposes them under its own enterprise branch — see MikroTik SNMP.
• Juniper has yet another set under its enterprise tree — see Juniper SNMP.

Don't hard-code one OID and expect it to work everywhere; it won't. The right move is to identify the platform (walk sysDescr / sysObjectID), then pull the CPU and memory objects documented for that vendor. Some routers that also implement HOST-RESOURCES-MIB will answer hrProcessorLoad, but plenty don't — treat that as a bonus, not a guarantee.

Uptime & reachability

Two questions, both cheap to answer. "Is it up?" is really "does it respond to SNMP at all," so a simple GET on sysUpTime (1.3.6.1.2.1.1.3.0) doubles as a liveness probe. And that same object answers "did it reboot?" — sysUpTime is timeticks since the agent started, so a value that suddenly drops toward zero means the router restarted between polls.

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.3.0

DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (884213700) 102 days, 8:22:17.00

A hundred-plus days of uptime and it answered — this router is healthy and hasn't rebooted. Pair reachability with an off-box check so a dead site still pages you; see availability monitoring.

Vendor specifics

Because CPU, memory and environment are enterprise-MIB territory, the approach differs by vendor:

The pattern is consistent: interfaces are standard everywhere, everything else is a vendor lookup. That's why the device pages exist.

Example: walking a router with snmpbulkwalk

The order that saves you time on an unfamiliar router:

1. Fingerprint it — GET sysDescr (1.3.6.1.2.1.1.1.0) to learn the vendor and model.
2. Confirm it's alive and note uptime — GET sysUpTime.
3. Bulk-walk the interface counters — ifHCInOctets and friends — for the portable traffic view.
4. Look up that vendor's CPU/memory objects on its device page and poll those.

Start by fingerprinting the box, then pull the interface table:

snmpget -v2c -c <RO_string> <host> 1.3.6.1.2.1.1.1.0
snmpbulkwalk -v2c -c <RO_string> <host> 1.3.6.1.2.1.31.1.1.1.6

SNMPv2-MIB::sysDescr.0 = STRING: Cisco IOS Software, C3900 ...
IF-MIB::ifHCInOctets.1 = Counter64: 884120394855
IF-MIB::ifHCInOctets.2 = Counter64: 1204773991002
IF-MIB::ifHCInOctets.3 = Counter64: 0

sysDescr tells you it's Cisco IOS, which points you at the Cisco CPU/memory objects; the interface counters are standard IF-MIB you diff between polls. <RO_string> is a placeholder — never commit a live community string.

Reference

This is the router use-case how-to. For object types and the full interface column list, use the reference twin: interface OIDs. Vendor object specifics live on the device pages: Cisco, MikroTik, Juniper. Definitions at glossary; full index at all sensors.

Frequently asked questions

How do I monitor a router with SNMP?

Walk the IF-MIB for per-interface traffic, errors and status (portable across every vendor), read sysUpTime for reachability and reboot detection, and pull CPU/memory from the router's vendor-specific enterprise MIB. Fingerprint the box with sysDescr first so you know which vendor objects to poll.

What OID is router CPU?

There isn't a single universal one. Router CPU is vendor-specific, living under each vendor's enterprise tree at 1.3.6.1.4.1 — Cisco, MikroTik and Juniper each expose it differently. Identify the platform via sysObjectID/sysDescr, then use that vendor's documented CPU object rather than assuming one OID works everywhere.

Can SNMP monitor BGP or OSPF on a router?

Yes, where the platform implements the relevant protocol MIBs — for example a BGP peer table exposing neighbour state, or OSPF neighbour objects. Availability and detail vary by vendor and MIB support, so check what your specific router exposes before building alerts on it.

Which MIB gives router interface traffic?

The standard IF-MIB (1.3.6.1.2.1.2 and the extended 1.3.6.1.2.1.31). It's implemented consistently across router vendors, which is why interface monitoring is portable while CPU and memory are not.

Key takeaways

• On a router, interfaces are portable (IF-MIB); CPU, memory and sensors are vendor-specific.
• Read sysUpTime (1.3.6.1.2.1.1.3.0) for both liveness and reboot detection.
• Fingerprint with sysDescr / sysObjectID, then pull vendor CPU/memory from 1.3.6.1.4.1.
• Prioritize uplinks and WAN circuits — a saturated transit link hits everyone behind it.
• Vendor object detail: Cisco, MikroTik, Juniper; types on interface OIDs.
• Back the primary poller with an off-box external check via external monitoring so a dead site still reaches you.