Juniper

JunOS SNMP configuration lives under the [edit snmp] hierarchy, using Junos's set-statement configuration style throughout.

SNMPv2c (community strings)

set snmp community public authorization read-only
set snmp community private authorization read-write
set snmp location "Rack 4, DC1"
set snmp contact [email protected]
commit

Restricting which clients can use a community is done with a client list, applied to the community:

set snmp client-list MYCLIENTS 10.0.0.0/24
set snmp community public client-list-name MYCLIENTS

SNMPv3

JunOS SNMPv3 is more layered than Cisco's - a USM user, a security-to-group mapping, a VACM access policy, and a view, each configured separately:

set snmp v3 usm local-engine user MYUSER authentication-sha authentication-password MYAUTHPASS
set snmp v3 usm local-engine user MYUSER privacy-aes128 privacy-password MYPRIVPASS
set snmp v3 vacm security-to-group security-model usm security-name MYUSER group MYGROUP
set snmp v3 vacm access group MYGROUP default-context-prefix security-model usm security-level privacy read-view MYVIEW
set snmp view MYVIEW oid 1 include
commit

The view statement (oid 1 include) is mandatory - unlike Cisco, where a default view is implied if you don't configure one, JunOS SNMPv3 requires at least one explicit view before a user can read anything.

Sending traps

Traps are organized into named trap-groups, each with its own destination(s) and category filter:

set snmp trap-group MYTRAPS categories authentication
set snmp trap-group MYTRAPS categories chassis
set snmp trap-group MYTRAPS targets 192.168.1.100
commit

Available categories include authentication, chassis, link, routing, startup, and several more - a trap-group only sends the categories explicitly listed for it, so a group with no categories statement sends nothing.

Platform differences

The core [edit snmp] syntax above is consistent across MX, EX, QFX, and SRX platforms - this is one of JunOS's strengths, a genuinely unified configuration model across very different hardware. The place platform differences show up is in what's available to monitor once SNMP is running, not how you turn it on - see the SRX-specific CPU monitoring gotcha below for a concrete example of that.

Common OIDs and MIBs

Everything Juniper-specific lives under enterprises.2636 (1.3.6.1.4.1.2636) - juniperMIB, Juniper's own IANA-assigned number.

• Chassis health - JUNIPER-MIB's jnxOperatingTable (1.3.6.1.4.1.2636.3.1.13.1). This one table covers temperature, CPU, and memory/buffer usage for every monitored component in the chassis at once - routing engines, FPCs, PICs, power supplies - with jnxOperatingTemp (.7), jnxOperatingCPU (.8), and jnxOperatingBuffer (.11) as the three columns almost every monitoring setup actually polls. It's genuinely one of the more useful tables in Juniper's whole MIB tree specifically because it's one table for the whole chassis, rather than fragmented across several separate ones.
• Optical/DOM monitoring - JUNIPER-DOM-MIB (1.3.6.1.4.1.2636.3.60). jnxDomCurrentRxLaserPower and jnxDomCurrentTxLaserOutputPower report per-interface optical receive/transmit power for DOM-capable transceivers, in units of 0.1 dBm - directly useful for spotting a degrading optic before it fails outright, well before any link actually goes down.
• SRX-specific data-plane monitoring - jnxJsSPUMonitoringCPUUsage (under 1.3.6.1.4.1.2636.3.39). SRX firewalls track data-plane (SPU) CPU load through an entirely separate table from the standard jnxOperatingTable above - see the gotcha below, since polling the wrong one of these two on an SRX is a genuinely common mistake.

Gotchas and platform-specific nuances

SRX CPU monitoring needs a different OID than every other JunOS platform. On a router or switch, jnxOperatingCPU in the standard chassis table is the right object. On an SRX, that same object frequently comes back as noSuchObject - the data-plane CPU load that actually matters for a firewall's performance lives under the SPU-specific jnxJsSPUMonitoringCPUUsage table instead, indexed by SPU/node rather than by the standard slot-based indexing the chassis table uses elsewhere. A monitoring template built against one JunOS platform doesn't reliably carry over to an SRX without this specific substitution - worth checking for explicitly rather than assuming "it's all JunOS, so the OIDs must be the same."

jnxOperatingTable's indexing is genuinely more involved than a simple integer. Real instance OIDs under this table look like ...jnxOperatingCPU.9.1.0.0 - a multi-part index reflecting which physical component the row describes (routing engine, FPC slot, PIC slot, and so on), not a single row number. Walking the whole table first, rather than guessing at a specific instance suffix, is the reliable way to find the exact row for a specific component - the index values aren't sequential or predictable enough to compute in advance, especially on a chassis with several linecards installed.

ifIndex values aren't guaranteed to survive a JunOS upgrade or reboot. Unlike Cisco's opt-in ifindex persist command, JunOS doesn't currently expose a documented, equivalent configuration knob - interface index reassignment after certain JunOS upgrades or reboots is a long-standing, widely-reported behavior across multiple platforms (M-series, MX-series, and others), and it's worth assuming ifIndex-based interface mappings may need re-validating after any JunOS upgrade, rather than assuming they'll hold. Where possible, matching on ifDescr or ifAlias instead of a bare ifIndex number is meaningfully more resilient to this.