MIB Viewer

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 admin@example.com
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 - for example, SRX-specific data-plane CPU monitoring needs a different OID entirely from the standard chassis health table, even though the SNMP service itself was configured identically.