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

SFP Monitoring

OSDx provides SNMP-based monitoring of SFP transceiver modules on supported hardware platforms. This feature exposes SFP module identification and real-time optical diagnostics (DDM/DOM) through standard SNMP MIBs, enabling integration with third-party network management systems (NMS).

SFP data is exposed through two standard MIBs:

  • ENTITY-MIB (RFC 6933): Exposes the physical inventory of SFP transceivers via the entPhysicalTable, including vendor name, part number, serial number, and hardware revision.

  • ENTITY-SENSOR-MIB (RFC 3433): Exposes real-time sensor readings via the entPhySensorTable, including temperature, supply voltage, TX bias current, TX optical power, and RX optical power.

Note

SFP SNMP monitoring is only available on arm64 hardware platforms with SFP-capable interfaces. Virtual machines and SDE platforms are not supported.

OID structure

For each SFP-capable interface, entries are created in two SNMP tables:

entPhysicalTable (1.3.6.1.2.1.47.1.1.1):

Row

Class

Description

N+0

chassis(3)

Chassis root entity (OSDx device)

N+1

module(9)

SFP transceiver module (vendor, serial, PN)

N+2

sensor(8)

Temperature sensor

N+3

sensor(8)

Supply voltage sensor

N+4

sensor(8)

TX optical power sensor

N+5

sensor(8)

RX optical power sensor

N+6

sensor(8)

TX bias current sensor

entPhySensorTable (1.3.6.1.2.1.99.1.1):

Only sensor rows (entPhysicalClass = sensor(8)) are indexed in this table.

Sensor

Type

Scale

Units

Temperature

celsius(8)

units(9)

degrees Celsius

Voltage

voltsDC(4)

milli(8)

millivolts DC

TX Power

watts(6)

micro(7)

microwatts

RX Power

watts(6)

micro(7)

microwatts

Bias Current

amperes(5)

micro(7)

microamperes

When no SFP module is inserted in a cage, the sensor entPhySensorOperStatus is set to unavailable(2) and the sensor value is 0.

SFP configuration

No specific configuration is needed for SFP SNMP monitoring. It is automatically enabled when the service snmp service is configured and active on a device with SFP-capable interfaces.

SFP CLI monitoring

SFP module information can be viewed locally using the interfaces ethernet <value> show plugin-module operational command:

admin@osdx$ interfaces ethernet eth2 show plugin-module
  Identifier                                : 0x03 (SFP)
  Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
  Connector                                 : 0x07 (LC)
  Transceiver type                          : 10G Ethernet: 10G Base-SR
  Vendor name                               : EDGE
  Vendor PN                                 : 10G-SFP-300I-IN
  Vendor SN                                 : E021903020001
  Optical diagnostics support               : Yes
  Laser bias current                        : 6.734 mA
  Laser output power                        : 0.5763 mW / -2.39 dBm
  Receiver signal average optical power     : 0.0785 mW / -11.05 dBm
  Module temperature                        : 36.12 degrees C / 97.01 degrees F
  Module voltage                            : 3.3253 V

SFP SNMP monitoring

The SFP data is exposed via standard SNMP MIBs and can be queried using any SNMP management tool. The following examples use snmpwalk with SNMPv2c and community PUBLIC.

Querying the physical inventory (entPhysicalTable):

admin@osdx$ snmpwalk -v2c -c PUBLIC localhost 1.3.6.1.2.1.47.1.1.1
  ENTITY-MIB::entPhysicalDescr.1 = STRING: OSDx Network Device - osdx
  ENTITY-MIB::entPhysicalDescr.1020 = STRING: SFP Module on eth2 (10G-SFP-300I-IN)
  ENTITY-MIB::entPhysicalDescr.1021 = STRING: eth2 Temperature Sensor
  ENTITY-MIB::entPhysicalDescr.1022 = STRING: eth2 Voltage Sensor
  ENTITY-MIB::entPhysicalDescr.1023 = STRING: eth2 TX Power Sensor
  ENTITY-MIB::entPhysicalDescr.1024 = STRING: eth2 RX Power Sensor
  ENTITY-MIB::entPhysicalDescr.1025 = STRING: eth2 Bias Current Sensor
  ENTITY-MIB::entPhysicalClass.1 = INTEGER: chassis(3)
  ENTITY-MIB::entPhysicalClass.1020 = INTEGER: module(9)
  ENTITY-MIB::entPhysicalClass.1021 = INTEGER: sensor(8)
  ENTITY-MIB::entPhysicalClass.1022 = INTEGER: sensor(8)
  ENTITY-MIB::entPhysicalClass.1023 = INTEGER: sensor(8)
  ENTITY-MIB::entPhysicalClass.1024 = INTEGER: sensor(8)
  ENTITY-MIB::entPhysicalClass.1025 = INTEGER: sensor(8)
  ENTITY-MIB::entPhysicalName.1 = STRING: osdx
  ENTITY-MIB::entPhysicalName.1020 = STRING: eth2
  ENTITY-MIB::entPhysicalSerialNum.1020 = STRING: E021903020001
  ENTITY-MIB::entPhysicalMfgName.1020 = STRING: EDGE
  ENTITY-MIB::entPhysicalModelName.1020 = STRING: 10G-SFP-300I-IN
  ENTITY-MIB::entPhysicalIsFRU.1020 = INTEGER: true(1)

Querying the sensor readings (entPhySensorTable):

admin@osdx$ snmpwalk -v2c -c PUBLIC localhost 1.3.6.1.2.1.99.1.1
  ENTITY-SENSOR-MIB::entPhySensorType.1021 = INTEGER: celsius(8)
  ENTITY-SENSOR-MIB::entPhySensorType.1022 = INTEGER: voltsDC(4)
  ENTITY-SENSOR-MIB::entPhySensorType.1023 = INTEGER: watts(6)
  ENTITY-SENSOR-MIB::entPhySensorType.1024 = INTEGER: watts(6)
  ENTITY-SENSOR-MIB::entPhySensorType.1025 = INTEGER: amperes(5)
  ENTITY-SENSOR-MIB::entPhySensorScale.1021 = INTEGER: units(9)
  ENTITY-SENSOR-MIB::entPhySensorScale.1022 = INTEGER: milli(8)
  ENTITY-SENSOR-MIB::entPhySensorScale.1023 = INTEGER: micro(7)
  ENTITY-SENSOR-MIB::entPhySensorScale.1024 = INTEGER: micro(7)
  ENTITY-SENSOR-MIB::entPhySensorScale.1025 = INTEGER: micro(7)
  ENTITY-SENSOR-MIB::entPhySensorValue.1021 = INTEGER: 361
  ENTITY-SENSOR-MIB::entPhySensorValue.1022 = INTEGER: 3325
  ENTITY-SENSOR-MIB::entPhySensorValue.1023 = INTEGER: 576
  ENTITY-SENSOR-MIB::entPhySensorValue.1024 = INTEGER: 79
  ENTITY-SENSOR-MIB::entPhySensorValue.1025 = INTEGER: 6734
  ENTITY-SENSOR-MIB::entPhySensorOperStatus.1021 = INTEGER: ok(1)
  ENTITY-SENSOR-MIB::entPhySensorOperStatus.1022 = INTEGER: ok(1)
  ENTITY-SENSOR-MIB::entPhySensorOperStatus.1023 = INTEGER: ok(1)
  ENTITY-SENSOR-MIB::entPhySensorOperStatus.1024 = INTEGER: ok(1)
  ENTITY-SENSOR-MIB::entPhySensorOperStatus.1025 = INTEGER: ok(1)
  ENTITY-SENSOR-MIB::entPhySensorUnitsDisplay.1021 = STRING: degrees Celsius
  ENTITY-SENSOR-MIB::entPhySensorUnitsDisplay.1022 = STRING: millivolts DC
  ENTITY-SENSOR-MIB::entPhySensorUnitsDisplay.1023 = STRING: microwatts
  ENTITY-SENSOR-MIB::entPhySensorUnitsDisplay.1024 = STRING: microwatts
  ENTITY-SENSOR-MIB::entPhySensorUnitsDisplay.1025 = STRING: microamperes

In the example above, the sensor values correspond to:

  • Temperature: 361 (with precision=1) = 36.1 degrees C

  • Voltage: 3325 millivolts = 3.325 V

  • TX Power: 576 microwatts = 0.576 mW (-2.40 dBm)

  • RX Power: 79 microwatts = 0.079 mW (-11.02 dBm)

  • Bias Current: 6734 microamperes = 6.734 mA

Querying with no SFP inserted:

When no SFP module is inserted, the module entry is still present but sensor readings are unavailable:

admin@osdx$ snmpwalk -v2c -c PUBLIC localhost 1.3.6.1.2.1.99.1.1
  ENTITY-SENSOR-MIB::entPhySensorOperStatus.1021 = INTEGER: unavailable(2)
  ENTITY-SENSOR-MIB::entPhySensorValue.1021 = INTEGER: 0

Interpreting sensor values

The entPhySensorValue is an integer whose meaning depends on the associated entPhySensorType, entPhySensorScale, and entPhySensorPrecision objects.

Temperature (type=celsius, scale=units, precision=1):

The value represents degrees Celsius multiplied by 10. For example, a value of 361 means 36.1 degrees C.

Voltage (type=voltsDC, scale=milli, precision=0):

The value is in millivolts. For example, a value of 3325 means 3.325 V.

TX/RX Power (type=watts, scale=micro, precision=0):

The value is in microwatts. To convert to dBm: dBm = 10 * log10(microwatts / 1000)

For example, 576 microwatts = -2.40 dBm and 79 microwatts = -11.02 dBm.

Bias Current (type=amperes, scale=micro, precision=0):

The value is in microamperes. For example, 6734 means 6.734 mA.

SFP Troubleshooting

SNMP walk returns no SFP data:

Sensor status shows unavailable(2):

  • No SFP module is inserted in the cage, or

  • The SFP module does not support DDM/DOM diagnostics

Note

For detailed SFP module diagnostics beyond SNMP, use the interfaces ethernet <value> show plugin-module command, which provides comprehensive optical diagnostics including alarm/warning flags.

Configuration commands

Operational commands