devices

SNMP on Juniper (Junos): Configuration & Key OIDs

Enable and monitor Juniper devices over SNMP — Junos configuration, interfaces via IF-MIB, and chassis/CPU/temperature via the Juniper enterprise MIBs.

By the SNMP Monitoring team · Reviewed July 2026

Juniper gear sits in a lot of service-provider and enterprise cores, and SNMP is a standard way to watch it. The now-familiar pattern applies: interfaces come from the universal IF-MIB, while chassis, CPU, and environmental data live in Juniper's enterprise MIBs under 1.3.6.1.4.1.2636 — the JUNIPER-MIB family, with jnxBoxAnatomy as the key chassis module. This guide covers enabling SNMP in Junos, reading interfaces, and locating the vendor metrics. As with any vendor tree, we name the MIB and point you at Juniper's documentation rather than inventing specific jnx leaf OIDs, which vary across platforms.

Parent: devices. Related: interface sensor, enterprise OIDs.

Enabling SNMP in Junos

Junos uses set configuration statements, applied with a commit. A minimal read-only setup restricted to your manager:

set snmp community S3cr3tR0str1ng authorization read-only
set snmp community S3cr3tR0str1ng clients 10.0.0.5/32
set snmp location "Rack 12, DC-East"
set snmp contact "netops@example.com"

The workflow:

  1. Enter configuration mode and add the set snmp community statements above.
  2. Set authorization read-only — never read-write for monitoring.
  3. Restrict with clients <ip/prefix> so only your manager can query.
  4. Add location and contact for identification.
  5. commit to apply — Junos changes aren't live until committed.

The clients restriction is Junos's built-in source allowlist; combined with a random community it's the baseline. Verify after commit with a walk from the manager. Broader hardening is on security best practices.

Interfaces via IF-MIB

Juniper interfaces are standard IF-MIB, so traffic counters, operational status, and errors read the same as on any device — ifName, ifHCInOctets/ifHCOutOctets, ifOperStatus, and so on, no Juniper MIB required. On a core router that's often the highest-value data: per-interface throughput and up/down state across dozens or hundreds of ports. The high-capacity .31 counters matter here because core links move enough traffic to wrap 32-bit counters quickly. The interface objects are covered on the interface sensor page, with device context on router monitoring.

Chassis/CPU/temperature via Juniper MIBs

Juniper's hardware and environmental data lives under enterprise 1.3.6.1.4.1.2636, primarily in the jnxBoxAnatomy area of the JUNIPER-MIB family:

MetricJuniper MIB area
Chassis components / inventoryjnxBoxAnatomy (JUNIPER-MIB)
Temperature sensorsjnxBoxAnatomy operating table
CPU / memory utilizationjnxBoxAnatomy operating table

The jnxBoxAnatomy subtree exposes a table of chassis components — routing engines, line cards, fans, power supplies — each with operating state, temperature, and utilization readings. Because the specific leaf OIDs and which components appear depend on the platform (an MX router, an EX switch, and an SRX firewall differ), load the JUNIPER-MIB into your MIB browser and consult Juniper's MIB documentation for your model rather than assuming a leaf number. Don't invent jnx OIDs — resolve them against the actual MIB for your gear.

Reading with snmpwalk

Confirm SNMP and identify the device:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 system
SNMPv2-MIB::sysDescr.0 = STRING: Juniper Networks, Inc. mx240 internet router, JUNOS 21.4
SNMPv2-MIB::sysName.0 = STRING: core-mx01

The sysDescr names the platform and Junos version — telling you which JUNIPER-MIB components to expect. Then, with the JUNIPER-MIB loaded, walk the chassis subtree by name to enumerate components and their readings:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 jnxOperatingDescr
JUNIPER-MIB::jnxOperatingDescr.1 = STRING: Routing Engine 0
JUNIPER-MIB::jnxOperatingDescr.7 = STRING: FPC: MPC ...

Those component descriptions index the operating table, so you map each to its temperature or CPU reading. Filtering by the jnxOperating names is the practical way to find the sensor you want.

The reason this indexed-table approach matters is that Juniper hardware is often modular, and the component layout differs from chassis to chassis. On an MX router you might have multiple routing engines, several FPCs, and a rack of PICs, each appearing as its own row with its own temperature and utilization; on a compact EX switch the table is far shorter. So rather than hard-coding "the CPU is at OID X," you walk jnxOperatingDescr first to see what components this device actually has, then read the corresponding temperature or CPU value at the matching index. That two-step — enumerate the components, then read the metric per component — is the pattern that makes Juniper monitoring portable across a mixed fleet, because it adapts to whatever hardware is present instead of assuming a fixed layout. It's the same discipline that keeps the monitoring working when you swap a line card or add an FPC.

Securing it

For anything beyond a trusted management network, use SNMPv3 on Junos. It's configured under set snmp v3, defining a USM user with authentication and privacy plus a VACM view — the same authPriv model as elsewhere, authenticating with SHA and encrypting with AES so no cleartext community crosses the wire. Combine it with the clients allowlist and an OID view to expose only what your poller needs. The v3 concepts and security levels are on SNMPv3 setup; verify the exact Junos set snmp v3 syntax against your release, as the statement hierarchy is detailed.

Frequently asked questions

How do I enable SNMP on Juniper?

In Junos configuration mode, add set snmp community <string> authorization read-only, restrict it with set snmp community <string> clients <ip/prefix>, set location and contact, then commit — changes aren't live until committed. For encrypted access, use set snmp v3 to configure a USM user. Always keep it read-only and client-restricted.

What is jnxBoxAnatomy?

jnxBoxAnatomy is the part of the JUNIPER-MIB (under enterprise 1.3.6.1.4.1.2636) that describes the device's physical chassis — routing engines, line cards, fans, and power supplies — including their operating state, temperature, and utilization. It's where you find Juniper's CPU, memory, and environmental sensor data. Load the MIB and check Juniper's docs for the exact leaves on your platform.

What is Juniper's SNMP enterprise number?

Juniper's enterprise number is 2636, so its private OIDs live under 1.3.6.1.4.1.2636. The JUNIPER-MIB family — including jnxBoxAnatomy for chassis and environmental data — sits under that branch. Interface statistics, by contrast, use the standard IF-MIB, not the Juniper enterprise tree.

Does Junos support SNMPv3?

Yes. Junos fully supports SNMPv3, configured with set snmp v3 to define a USM user with SHA authentication and AES privacy plus a VACM access view. It's the recommended choice over a v2c community for exposed or sensitive deployments, since it authenticates and encrypts rather than sending a cleartext community string.

Key takeaways

  • Juniper follows the standard + vendor pattern: IF-MIB for interfaces, JUNIPER-MIB for the rest.
  • Enable with set snmp community … read-only + clients restriction, then commit.
  • Chassis/CPU/temperature live in jnxBoxAnatomy under enterprise 1.3.6.1.4.1.2636.
  • Leaves vary by platform — load the MIB and check Juniper's docs; never invent jnx OIDs.
  • Prefer SNMPv3 (set snmp v3) with a client allowlist and OID view.
  • For independent off-box checks, see external monitoring with ostr.io.

Monitor it from outside the network

SNMP only tells you a box is healthy while something is still asking. ostr.io polls your endpoints externally and fires email + SMS alerts the moment a reading crosses your line — or the agent goes silent.