Moniting with SNMPv3 is much like monitoring with SNMPv2 or 1 for that matter, except SNMPv3 offers greater security options. SNMPv1 or v2 offers very little security being based on a plain text community string, of course on the monitored device you can restrict which hosts are allowed to connect to your monitored device via SNMP to improve things, but nowadays SNMPv3 should be used where at all possible.
SNMPv3 Basics
So what is different about SNMPv3, well let’s run through the basic compoents first.
MIB Tree – The MIB Tree is the list of OIDs for the various monitored objects within the device, these are all the values that are exposed in the MIB Tree that you can query for.
View – A View is a view of the MIB Tree, this might be the whole of the MIB Tree including all the OIDs within or may just be a subset of the MIB Tree that only includes a small number of OIDs. For example you may want a view that just includes the OIDs for the network interfaces of a switch, but doesn’t include anything else. Kinda enforcing the “need to know” approach, if the View is only ever going to be used to query for the interface statuses, why have it able to see all the power supply statuses as well?
USM Group (User-Based Security Mode) Group – Simply put it is a group that contains users (see next), the Group then has a View assigned to it, with various required access levels to the View defined, e.g. Read Only, Read/Write etc. Users are placed into groups.
User – A user is the entity that can access the device via SNMPv3 and based on the USM Group (with its assigned permissions and View) can query the MIB Tree (and/or a subset of OIDs) based on the specification of the View.
There are also three access levels of the USM Group to be aware of:
- NoAuthNoPriv – Communication without authentication and privacy
- AuthNoPriv – Communication with authentication (MD5 or SHA) and without privacy
- AuthPriv – Communication with authentication (MD5 or SHA) and privacy (DES or AES)
There are sometimes reasons to use NoAuthNoPriv and AuthNoPriv (e.g. the overheads in encryption added by AuthPriv may consume more resources on the monitored and monitoring systems) but these in our case are pretty rare, so we should really only use AuthPriv that provides encryption and privacy of the username, password and payload.
Extreme Networks VOSS Switch SNMPv3 Configuration Example
The following example is for an Extreme Networks VOSS based switch running 8.5.2.0.GA. You’ll find a complete example configuration below, but first, let’s step through each line to explain what is going on, firstly these lines are just for reference and add configuration to the switch that you can query to assist in determining the location and function of the switch. You’ll have done something similar with the switch’s actual hostname (as it appears at the CLI).
snmp-server contact "helpdesk@domain.com"
snmp-server location "Site Name - Rack Location"Now we move to the real meat of the configuration, firstly this created a View called “ALL” which starts from 1 in the MIB Tree, i.e. this includes the whole of the MIB Tree within the View. If you want a View that only includes a single OID or a sub-tree you can specify it here, but in our case we want to be able to query the whole thing.
snmp-server view ALL 1Next we create a USM Group called “MONITORING”, which is specified for the GlobalRouter VRF by the two speech marks. We then specify the auth-priv access level must be used, which means it is expecting both a username/password and privacy password all of which are encrypted. When then specify the group’s read-view, i.e. what it has Read Only access to, in this case specifying the “ALL” view we just created. Then we specify this group’s Notify view which again is the “ALL” view we just created. You can if you wish also add the Write View (with write-view) that will then specify the view that is used for having write privileges, in our case we are not specifying this, so this group will only allow read only and notify (via SNMP traps).
snmp-server group MONITORING "" auth-priv read-view ALL notify-view ALLThen we need to create the User, so to do this use the following command, this creates the User called “monitoring-user” and adds it into the group “MONITORING”, it then specifies the Auth password (and hashing type, we picked SHA in this case) and then the Priv password (and encryption cipher type, in our case we picked AES).
snmp-server user monitoring-user group MONITORING sha <AUTHPASSWORD> aes <PRIVPASSWORD>Note: Refer to the Key Store for the Auth Password and Priv Password that you should use for your monitoring device.
There are then these three lines, which specify the host that this switch will send SNMP traps to, the IP from which this switch will send those from which on this version of VOSS did not seem to be required, and finally the command to ensure that SNMP blocking is turned off to ensure that the requests can make it through to the switch.
snmp-server host 192.168.5.100 v3 authpriv monitoring-user
snmp-server sender-ip 192.168.1.10 192.168.5.100 (Does not appear to be required with current VOSS version)
no boot config flags block-snmpExample Configuration
The below is an example configuration that can be used to provide access to the SNMP MIB Tree and its OIDs.
snmp-server contact "helpdesk@domain.com"
snmp-server location "Site Name - Rack Location"
snmp-server view ALL 1
snmp-server group MONITORING "" auth-priv read-view ALL notify-view ALL
snmp-server user monitoring-user group MONITORING sha <AUTHPASSWORD> aes <PRIVPASSWORD>
snmp-server host 192.168.5.100 v3 authpriv monitoring-user
snmp-server sender-ip 192.168.1.10 192.168.5.100 (Does not appear to be required with current VOSS version)
no boot config flags block-snmpFor reference if you wanted to include “write-view” you’d use this for the group configuration directive.
snmp-server group MONITORING "" auth-priv read-view ALL write-view ALL notify-view ALL- https://extremeportal.force.com/ExtrArticleDetail?an=000083460
- https://community.extremenetworks.com/t5/extremeswitching-vsp-fabric/snmpv3-voss-solarwinds/m-p/80010
NagiosXI Example Monitoring Command
When you wish to use SNMPv3 within a monitoring command you need to ensure you are including whatever is required to collect your desired information.
Example 1 – Simple Query of VOSS Version
We’ll perform a very simple check that will just return the sysDecr.0 (.1.3.6.1.2.1.1.1.0) value, once you have verified this is working you can progress to more complicated (and useful) monitoring commands.
./check_snmp -H <HOSTNAME> -o <OID_STRING> -P 3 -L authPriv -a SHA -x AES -U <USERNAME> -A <AUTHPASSWORD> -X <PRIVPASSWORD>So with some real information you might have a command and output that looks like this:
./check_snmp -H switch1.domain.com -o .1.3.6.1.2.1.1.1.0 -P 3 -L authPriv -a SHA -x AES -U mon-user -A T0pS3cr3t! -X D0nt!Tell1
SNMP OK - "VSP-7400-48Y-8C (8.5.2.0)" |Example 2 – Query Interface Operating Status
Perform a query on the operating status of the GigabitEthernet 1/49 port on the switch, this port has the OID ending in “256”, the GigabitEthernet 1/50 port on the switch has the OID ending in “257”.
./check_snmp -H switch1.domain.com -o .1.3.6.1.2.1.2.2.1.8.256 -P 3 -L authPriv -a SHA -x AES -U mon-user -A T0pS3cr3t! -X D0nt!Tell1 -s "1"
SNMP CRITICAL - *2* | iso.3.6.1.2.1.2.2.1.8.256=2
./check_snmp -H switch1.domain.com -o .1.3.6.1.2.1.2.2.1.8.257 -P 3 -L authPriv -a SHA -x AES -U mon-user -A T0pS3cr3t! -X D0nt!Tell1 -s "1"
SNMP OK - 1 | iso.3.6.1.2.1.2.2.1.8.257=1As you can see GigabitEthernet 1/49 is reporting status “2” which means Down, and GigabitEthernet 1/50 is reporting status “1” which means is Up!
Note: SNMP Responses are as follows: INTEGER { up ( 1 ) , down ( 2 ) , testing ( 3 ) , unknown ( 4 ) , dormant ( 5 ) , notPresent ( 6 ) }
