SNMP

This chapter covers some aspects related to the service snmp tool, which allows you to configure the Simple Network Management Protocol (SNMP) service (versions v1, v2c and v3) in OSDx.

By default, SNMP is configured to listen on all interfaces (port 161) and to accept both IPv4/IPv6 connections. This can be changed using the listen field.

address: to configure multiple IPv4/IPv6 addresses to listen for incoming requests.
- port: to configure multiple ports to listen for incoming requests to these addresses (161 by default).
port: to configure multiple ports to listen for incoming requests on all interfaces.

Moreover, SNMP can also be configured to listen on a specific VRF only, using the local-vrf field.

In addition, SNMP can be configured with multiple OID-rules to control and restrict the information that is exposed and accessible on incoming requests, using the view field.

oid: to indicate the OID to be controlled.
- mask: to set significant sub-identifiers for an OID.
- type: to indicate whether an OID should be excluded or included (included by default).

SNMPv1 and SNMPv2c rely on the use of communities. In OSDx, a community can be created using the community field.

client: to indicate IPv4/IPv6 addresses and subnets that are allowed access in a community (all interfaces by default).
view: to indicate the view that affects a community.
notify-traps: In OSDx, updates in interfaces, alarms and/or advisors can be notified through SNMP traps. This field is used to indicate the traps to be notified in a community. In the case of alarm/advisor, multiple names or the label all can be indicated.
read-write: gives the community read-write permissions.

Warning

Granting read-write permissions to an SNMP v1 or v2c community risks unauthorized access, as these versions lack robust authorization credentials. Consider using SNMP v3 for enhanced security.

SNMPv3 relies on the use of users, which offer a much more powerful security profile than communities. In OSDx, a user can be created using the user field.

view: same as for communities.
notify-traps: same as for communities.
authentication: to enable authentication for a user. SNMPv3 provides two different authentication mechanisms: SHA1 and MD5, which can be selected using the protocol field. The authentication password must also be configured via the password field.
privacy: to enable privacy (encryption) for a user. SNMPv3 provides two different encryption schemes: AES and DES, which can be selected using the protocol field. The privacy password must also be configured via the password field. This field can not be configured without specifying authentication parameters.
read-write: same as for communities.

Users can be configured using three different security models:

noAuthNoPriv: without authentication and privacy.
authNoPriv: with authentication, but without privacy.
authPriv: with both authentication and privacy.

SNMPv3 also lets you specify the engine identifier through the engine-id field.

An SNMP agent usually waits for incoming SNMP requests and responds to them. However, SNMP can be configured to take a more active role. In OSDx, notification sending can be enabled via the trap-target field.

First, select the SNMP version to send notifications. Then, depending on the selected version, OSDx offers different fields to configure:

SNMPv1:
- community: to indicate the community used for notifications.
- port: to configure the destination port used for notifications.
- source: to configure the local IPv4/IPv6 address used for notifications.
SNMPv2c:
- community: same as for SNMPv1.
- port: same as for SNMPv1.
- type: to configure the type of notification to send (see details below).
SNMPv3:
- user: to indicate the user used for notification purposes.
- port: same as for SNMPv1.
- type: same as for SNMPv2c.

There are two different types of notfication that can be sent: traps and inform. For versions v2c and v3, the notification type can be selected using the type field (for version v1, only trap notifications are possible).

traps: one-way communication (these are used by default).
inform: these notifications require an acknowledgement from the receiver.

Then you can specify whether the notifications should be sent only when the trap-target is reachable or not, using the reachability-check field. This field accepts an advisor as parameter, a common use case is to use the service nsm to monitor the reachability of the remote host. When the reachability-check is set, OSDx will store the traps in a queue until the target host is reachable, and then send them all at once, the queue size is limited to 100 per trap to send.

By default, the source address used in notifications is the one corresponding to the interface through which they are sent. This can be changed using the local-address field.

Configuration 

This is the syntax to create a service snmp:

set service snmp [ ... ]

Examples 

Enabling incoming SNMPv1 and SNMPv2c requests 

Imagine that you want to configure the SNMP service to allow receiving incoming requests from any host on the 10.0.0.0/24 subnet, using either SNMPv1 or SNMPv2c.

In OSDx, this can be achieved by setting the following commands:

set service snmp community PUBLIC client 10.0.0.0/24

Enabling SNMPv2c notification sending 

Imagine that you want to configure the SNMP service to allow sending notifications to host 10.0.0.2, using SNMPv2c.

In OSDx, this can be achieved by setting the following commands:

set service snmp community PUBLIC
set service snmp trap-target 10.0.0.2 version v2c community PUBLIC when alarms are updated

Enabling SNMPv3 notification sending when alarms are updated 

Imagine that you want to configure the SNMP service to allow sending notifications to host 10.0.0.2 when an alarm has been updated, using SNMPv3.

In OSDx, this can be achieved by setting the following commands:

set service snmp user USERv3 notify-traps alarm ALARM1
set service snmp user USERv3 authentication protocol SHA
set service snmp user USERv3 authentication password auth_pass_12345
set service snmp user USERv3 privacy protocol AES
set service snmp user USERv3 privacy password priv_pass_12345
set service snmp engine-id 0x80000009010a0101c1
set service snmp trap-target 10.0.0.2 version v3 user USERv3

Enabling SNMPv3 notification sending depending on the reachability of the target 

Imagine that you want to configure the SNMP service to allow sending notifications to host 10.0.0.2 only when it is reachable, using SNMPv3 and the NSM service to monitor the reachability of the remote host.

In OSDx, this can be achieved by setting the following commands:

set service snmp user USERv3 notify-traps alarm ALARM1
set service snmp user USERv3 authentication protocol SHA
set service snmp user USERv3 authentication password auth_pass_12345
set service snmp user USERv3 privacy protocol AES
set service snmp user USERv3 privacy password priv_pass_12345
set service snmp engine-id 0x80000009010a0101c1
set service snmp trap-target 10.0.0.2 version v3 user USERv3
set service snmp trap-target 10.0.0.2 reachability-check ADVISOR_REACHABLE
set service nsm operation CHECK_REACHABILITY destination-address 10.0.0.2
set service nsm operation CHECK_REACHABILITY type icmp
set service nsm operation CHECK_REACHABILITY window 2
set service nsm operation CHECK_REACHABILITY alarm ALARM_REACHABILITY activate loss 1
set service nsm operation CHECK_REACHABILITY alarm ALARM_REACHABILITY deactivate loss 0
set system alarm ALARM_REACHABILITY initial-state true
set system advisor ADVISOR_REACHABLE test 'not ALARM_REACHABILITY'

SNMP operations: GET, GETNEXT and SET 

GET Operation

The GET operation retrieves data associated with a specific OID. It can be used with operational command service snmp get <ipv4>.

GETNEXT Operation

The SNMP GETNEXT operation retrieves the next variable in the MIB tree. It can be used with operational command service snmp getnext <ipv4>.

SET Operation

The SNMP SET operation sets the value of a specific OID. It can be used with operational command service snmp set <ipv4>.

SNMP Versions and Commands

The necessary options can differ, depending on the SNMP version you’re using:

For SNMP v1/v2c:

service snmp <get|getnext|set> <SNMP_AGENT_IP> oid <OID> version <1|2c> community <COMMUNITY_NAME>

For SNMP v3:

service snmp <get|getnext|set> <SNMP_AGENT_IP> oid <OID> version 3 user <USER_NAME>

Security levels

To use the authentication or privacy functionalities available on SNMPv3, you will have to set a security-level:

noAuthNoPriv: The default security level. This level does not use authentication or privacy credentials..

authNoPriv: This level uses only authorization options.

auth-key

auth-protocol (optional, default is MD5)

authPriv: This level uses both authorization and privacy options.

auth-key

auth-protocol (optional, default is MD5)

priv-key

priv-protocol (optional, default is AES)

Examples of the use of GET and GETNEXT commands are available at SNMP operations examples

Monitoring 

There are multiple ways to monitor the SNMP service. The walk and table commands can be used to retrieve information from local or remote agents. Additionally, traps can be used to receive information from an agent without soliciting it, a trap is triggered when a especific event occurs in the device. To monitor the behaviour of a especific device through the journal, the log-level sets the amount of information displayed.

Log Levels 

There are three types of messages to be written to the snmp log file. The types are errors, warning, and information.

Error types:
- emergency: the system is unusable.
- alert: action must be taken immediately .
- critical: critical conditions.
- error: error conditions.
Warning type:
- warning: warning conditions.
Information types:
- notice: normal but significant conditions.
- information: informational messages.
- debug: debug-level messages.

In OSDx, the following command can be used to change the log-level: service snmp log-level <txt>.

Walk and Table Commands 

The following operational commands can be used to retrieve a subtree of information from local or remote agents: * service snmp walk local-agent v1 <txt>. * service snmp walk local-agent v2c <txt>. * service snmp walk local-agent v3 <txt>. * service snmp walk remote-agent <ipv4|ipv6|txt> v1 <txt>. * service snmp walk remote-agent <ipv4|ipv6|txt> v2c <txt>. * service snmp walk remote-agent <ipv4|ipv6|txt> v3 <txt>.

Example:

admin@DUT1$ service snmp walk remote-agent 10.0.0.1 v1 PUBLIC oid ifTable | head

IF-MIB::ifIndex.1 = INTEGER: 1
IF-MIB::ifIndex.2 = INTEGER: 2
IF-MIB::ifIndex.3 = INTEGER: 3
IF-MIB::ifIndex.4 = INTEGER: 4
IF-MIB::ifDescr.1 = STRING: lo
IF-MIB::ifDescr.2 = STRING: Intel Corporation 82540EM Gigabit Ethernet Controller
IF-MIB::ifDescr.3 = STRING: Intel Corporation 82540EM Gigabit Ethernet Controller
IF-MIB::ifDescr.4 = STRING: Intel Corporation 82540EM Gigabit Ethernet Controller
IF-MIB::ifType.1 = INTEGER: softwareLoopback(24)
IF-MIB::ifType.2 = INTEGER: ethernetCsmacd(6)

Operational command snmp table [ ... ] can be used to retrieve information from local or remote agents and display it in a table.

Example:

admin@DUT1$ snmp table remote-agent 10.0.0.1 v2c PUBLIC oid ifTable

SNMP table: IF-MIB::ifTable

 ifIndex                                               ifDescr           ifType ifMtu    ifSpeed
       1                                                    lo softwareLoopback 65536   10000000
       2 Intel Corporation 82540EM Gigabit Ethernet Controller   ethernetCsmacd  1500 1000000000
       3 Intel Corporation 82540EM Gigabit Ethernet Controller   ethernetCsmacd  1500 1000000000
       4 Intel Corporation 82540EM Gigabit Ethernet Controller   ethernetCsmacd  1500 1000000000

SNMP table IF-MIB::ifTable, part 2

   ifPhysAddress ifAdminStatus ifOperStatus ifLastChange ifInOctets ifInUcastPkts ifInNUcastPkts
                            up           up 0:0:00:00.00       2200            44              0
 8:0:27:ff:f6:f1            up           up 0:0:00:00.00      88209           736              0
 8:0:27:84:f2:61          down         down 0:0:00:00.00          0             0              0
 8:0:27:ad:c9:a0            up           up 0:0:00:00.00    1552165         15972             92

SNMP table IF-MIB::ifTable, part 3

 ifInDiscards ifInErrors ifInUnknownProtos ifOutOctets ifOutUcastPkts ifOutNUcastPkts ifOutDiscards
            0          0                 0        2200             44               0             0
            0          0                 0      148777            762               0             0
            0          0                 0           0              0               0             0
            4          0                 0      640599           5265               0             0

SNMP table IF-MIB::ifTable, part 4

 ifOutErrors ifOutQLen              ifSpecific
           0         0 SNMPv2-SMI::zeroDotZero
           0         0 SNMPv2-SMI::zeroDotZero
           0         0 SNMPv2-SMI::zeroDotZero
           0         0 SNMPv2-SMI::zeroDotZero

Traps 

Additionally, operational commands service snmp monitor traps community <txt> and service snmp monitor traps user <txt> can be used to monitor SNMP traps.

Example:

admin@DUT1$ service snmp monitor traps user USERv3 auth-key auth_pass_12345 auth-protocol SHA priv-key priv_pass_12345 priv-protocol AES engine-id 0x80000009010a0101c1

NET-SNMP version 5.7.3
2022-09-22 07:20:59 <UNKNOWN> [UDP: [10.0.0.1]:38763->[10.0.0.2]:162]:
SNMPv2-MIB::sysUpTime.0 = Timeticks: (3) 0:00:00.03   SNMPv2-MIB::snmpTrapOID.0 = OID: SNMPv2-MIB::coldStart  SNMPv2-MIB::snmpTrapEnterprise.0 = OID: NET-SNMP-TC::linux

SNMP

Configuration 

Examples 

Enabling incoming SNMPv1 and SNMPv2c requests 

Enabling SNMPv2c notification sending 

Enabling SNMPv3 notification sending when alarms are updated 

Enabling SNMPv3 notification sending depending on the reachability of the target 

SNMP operations: GET, GETNEXT and SET 

GET Operation

GETNEXT Operation

SET Operation

SNMP Versions and Commands

Security levels

Monitoring 

Log Levels 

Walk and Table Commands 

Traps 

Configuration commands

Operational commands