Monitor Juniper via SNMP
SNMP Juniper monitoring is the workhorse method for keeping tabs on an SRX, an EX switch, or an MX router without leaning on a full streaming-telemetry stack. Junos has spoken SNMP for its entire life, the agent is built into the OS, and the configuration is a handful of set statements followed by a commit. This guide walks through enabling it safely, the OIDs that actually earn their place on Juniper hardware, and the reason polling the box from outside your own network catches failures that an internal collector never will.
SNMP support on Juniper
Junos includes a native SNMP agent, so there's no package to bolt on — the daemon is part of the operating system and simply waits for you to configure it. Juniper supports SNMPv1, SNMPv2c, and SNMPv3, which maps neatly onto how most shops actually run: v2c for straightforward read-only polling behind a management network, v3 when you need authentication and privacy on the wire.
That version choice isn't cosmetic. A v2c community is a shared secret sent in the clear, so it's fine on a trusted out-of-band management VLAN and a poor idea across anything else — the same trade-off spelled out under SNMP versions. Junos makes v3 straightforward: you define a USM user, attach SHA authentication and AES privacy, and bind it to a view that limits what it can read. The v3 vs v2c comparison covers when the extra setup pays off.
Here's the Junos-specific wrinkle worth knowing up front. Junos leans hard on the idea of views and clients — you don't just open the agent, you declare which OID subtrees a community may see and which source addresses may ask. That's a feature, not friction: it means a read-only community really is read-only and really is scoped to your poller. Configure it once and the box politely ignores everyone else. Get the clients list wrong and the symptom is silence, not an error, which sends more than a few engineers chasing a firewall problem that doesn't exist.
One more practical note. On a chassis-based platform, SNMP is answered by the routing engine, and interfaces are indexed the way Junos enumerates them internally — physical ports, aggregated bundles, logical units, and management interfaces all share the same table. So before you build dashboards, walk ifDescr once and map each ifIndex to a name you recognize. Do that mapping up front and your alerts point at "ge-0/0/3" instead of a bare number nobody can decode at 3 a.m.
What you can monitor on Juniper
As with any router or switch, the readings you'll reach for most are per-interface, and those come from the standard IF-MIB (RFC 2863) — no vendor knowledge required. Interface counters live in ifTable at 1.3.6.1.2.1.2.2.1; on the high-speed ports typical of MX and QFX gear you'll want the 64-bit counters in ifXTable at 1.3.6.1.2.1.31.1.1.1, because the 32-bit octet counters roll over too quickly to trust on a busy link.
| Metric | OID | Source MIB |
|---|---|---|
| Bytes in (per interface) | 1.3.6.1.2.1.2.2.1.10 (ifInOctets) | IF-MIB (RFC 2863) |
| Bytes out (per interface) | 1.3.6.1.2.1.2.2.1.16 (ifOutOctets) | IF-MIB (RFC 2863) |
| Operational status | 1.3.6.1.2.1.2.2.1.8 (ifOperStatus) | IF-MIB (RFC 2863) |
| Interface speed | 1.3.6.1.2.1.2.2.1.5 (ifSpeed) | IF-MIB (RFC 2863) |
| 64-bit bytes in | 1.3.6.1.2.1.31.1.1.1.6 (ifHCInOctets) | IF-MIB (RFC 2863) |
| 64-bit bytes out | 1.3.6.1.2.1.31.1.1.1.10 (ifHCOutOctets) | IF-MIB (RFC 2863) |
| System uptime | 1.3.6.1.2.1.25.1.1.0 (hrSystemUptime) | Host Resources MIB (RFC 2790) |
Chassis health — routing-engine CPU, temperature, fan status, power supplies — is exposed through Juniper's enterprise MIB (JUNIPER-MIB), not through a public RFC. The operating-status tables there report per-component values on your specific platform. Because those numeric OIDs are vendor-defined and shift between product families, load the Juniper MIB and walk the tree on your own device rather than borrowing a number from elsewhere. For the standard interface story, the interface traffic and interface errors pages own the detail.
A quick way to decide where a given reading comes from on a Junos device:
- Interface traffic, status, errors, speed — standard IF-MIB, portable across every vendor.
- System uptime — Host Resources MIB, also standard.
- Routing-engine CPU, temperature, fans, PSUs — JUNIPER-MIB (enterprise), numeric OIDs vary by platform.
- BGP/OSPF session state — standards-based routing MIBs where supported, otherwise the enterprise tree.
Enabling SNMP — steps
Junos configuration is declarative — you stage changes, then commit. Here's a minimal read-only v2c agent scoped to a management subnet:
- Define a read-only community:
set snmp community <community> authorization read-only - Restrict which hosts may poll it so only your collector is answered:
set snmp community <community> clients 10.0.0.0/24 - Label the box so it self-identifies in your dashboards:
set snmp contact "netops" location "dc1-rack-4" - Commit the change to make it live:
commit - Verify from your workstation with a Net-SNMP walk of the interface table:
snmpwalk -v2c -c <community> 10.0.0.2 1.3.6.1.2.1.2.2.1
Some discipline keeps this safe. Treat the community like a password — long, random, never the literal word public. The clients statement is your allowlist; keep it tight to the management network. Where policy demands encryption, configure an SNMPv3 USM user with SHA and AES instead of a bare community. And if the agent faces any exposed segment, consider moving it off the default port; the custom port guide and the broader setup section cover the collector side and hardening.
Monitoring it externally
Everything above gets the agent answering. The question that decides whether you actually hear about an outage is where the poller lives. A collector inside the same data center, on the same power and the same uplinks as the Juniper, goes dark in the exact failure it's supposed to warn you about. When the site drops, so does your monitoring — and silence gets mistaken for health.
That's the case for double durability: watch the device from somewhere that doesn't share its fate. ostr.io Monitoring does exactly this for Junos gear — it polls your SNMP agent from outside your network, with nothing extra installed on the router, and sends real-time email and SMS alerts the moment a link drops or a value crosses your threshold. Because the check is independent and external, a full-site failure still reaches you. Wire it to your public monitoring endpoint for a second opinion the device can't give about its own downtime.
None of this replaces your internal collector — it complements it. Keep polling the Juniper from inside for the fine-grained interface graphs and capacity trends you live in day to day, and let the external check be the one that survives when the whole site goes quiet. The two answer different questions: one tells you how a healthy device is behaving, the other tells you the device stopped answering at all. You want both, and you especially want the second one to originate somewhere the outage can't reach.
