SNMP v3 support is available in junos and the SRX platform for quite some time now. It's quite simple to set up. Let's recap what SNMPv3 provides;
It supports encryption ( privacy ) and authentication ( who has access )
It's backward compatible with communities
It supports views ( even v1 & v2c supports views btw )
Okay let's look a very basic v3 cfg;
set snmp v3 usm local-engine user nms authentication-md5 authentication-password mypasswordhereset snmp v3 usm local-engine user nms privacy-des privacy-password mypasswordhere
set snmp v3 vacm security-to-group security-model usm security-name nms group groupnms
set snmp v3 vacm access group groupnms default-context-prefix security-model any security-level privacy read-view all
set snmp v3 vacm access group groupnms default-context-prefix security-model any security-level privacy write-view all
set snmp view all oid .1
set snmp contact hyprops
The above is from my management & polling station. And for this SRX we are allowing both the Authentication & Privacy ( authPriv ) and my view is named "all". And within the view "all", we have allowed all views with in the .1 family ( so pretty much the whole tree for .iso & the ISO assigned oids or the start of the tree with the MIB walk )
My SNMPv3 user == "nms" and he belongs to the group known as "groupnms"
The group "groupnms" has a view ( "all" ) for the security level "privacy" and for both read/write access
Okay see how simple the above was ?
We can craft various views to ensure we give the appropiate user the right to read/write as required by the SNMP manager. Typically in my setups, I have numerous views depending on the SNMP manager functions & roles.
( e.g NMS polling station ( cacti ) and another for NMS monitor ( opsview/nagios ) )
Okay now let's look a more complex setup that leverage a more specific view ;
set snmp v3 usm local-engine user nmssys authentication-md5 authentication-password hyprf33d3efSnMpv3set snmp v3 usm local-engine user nmssys privacy-des privacy-password hyperFe3dP3nL921h
set snmp v3 vacm security-to-group security-model usm security-name nmssys group hyperfeedpen
set snmp v3 vacm access group hyperfeedpen default-context-prefix security-model any security-level privacy read-view hypr5387
set snmp v3 vacm access group hyperfeedpen default-context-prefix security-model any security-level privacy write-view hypr5387
set snmp view hypr5387 oid .126.96.36.199.4.1.5387 include
set snmp view hypr5387 oid .188.8.131.52.4.1.2636.3.11 include
set snmp view hypr5387 oid .184.108.40.206.4.1.2636.4 include
set snmp view hypr5387 oid .220.127.116.11.4.1.2618.104.22.168.2 include
set snmp view hypr5387 oid .22.214.171.124.4.1.2636 exclude
set snmp view hypr5387 oid ifIndex included
set snmp view hypr5387 oid ifName included
set snmp v3 snmp-community NMSac#ssH678 security-name nmssys
set snmp contact email@example.com
Okay the above provide a few oid that I've allowed and a few that I want to disallow for this view and user using a few juniper oids and the full range of oid under my own PEN " 5387 IANA " and a few common interface oid. I have a community string also created.
Another example and more common
I could have create a view to exclude certain details and apply these to my group and user;
set snmp view mycustomer oid ifDescr .6 include
set snmp view mycustomer oid ifName.6 include
set snmp view mycustomer oid ifOutOctets.6 include
set snmp view mycustomer oid ifInOctets.6 include
set snmp view mycustomer oid ifType.6 include
set snmp view mycustomer oid ifAlias.6 include
The above would allow the user/group to query the above objects and only those objects in the "mycustomer" view & for the interface index ID of ".6"
Great for when you want to accommodate a client & allow them to graph a port, but restrict his/her view to just that port.
With SNMPv3 we can use the common snmptools; snmpwalk or snmpget & to test the "views" and configuration parameters;
snmpwalk -u <username" -v3 -O ne -l authPriv -x md5 -X <authentication pass phrase> -x des -X <privacy passphrase > ip_address .126.96.36.199.4.1.5387
( the above would walk all in the Organization of registered "HyperFeed" starting at .188.8.131.52.4.1.5387* )
Things to key in mind;
- ciphers are limited to DES or AES128 ( not sure if 3des is support in any Junos release )
- you can provide further restriction by enabling a host ACL filter to restrict the SNMP manager access by ip_address targets
- passphrases need to be 8 characters or more , and try to avoid special characters like a ! or *
- A user can be a member of just one group ; for both the read or write
- try to identify the problem
- is a credential related matter ( a wrong user and/or password or auth/privacy level )
- or is it a ACL ( port 161/udp )
- or is it a encryption protocol/hash mismatch
Good luck and remember to diagnose you snmp issues and configuration, based on what errors you get;
FWIW: Your SNMPviews can be different for both read or write & don't have to match.
" I try to avoid taking a Hilter approach and place extremely tight SNMPviews . If you don't know what your SNMPmanager might poll. I 've spent countless hours trouble-shooting why Nagios is timeout or failing on a query and come to find out, we where blocking it from our view "
Freelance Network/Security Engineer
kfelix ------a@t --------hyperfeed ---.----- com
= ( @ @ ) =
/ ~ \