==== SNMP ==== .. sidebar:: Contents .. contents:: :depth: 2 :local: This chapter covers some aspects related to the :osdx:cfg:`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. 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 :osdx:cfg:`service snmp`: .. code-block:: none 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: .. code-block:: none set service snmp community PUBLIC client 10.0.0.0/24 .. Enabling SNMPv1 notification sending .. ------------------------------------ .. Imagine that you want to configure the SNMP service to allow sending notifications .. to host 10.0.0.2, using SNMPv1. .. In OSDx, this can be achieved by setting the following commands: .. .. code-block:: none .. set service snmp community PUBLIC .. set service snmp trap-target 10.0.0.2 version v1 community PUBLIC .. set service snmp trap-target 10.0.0.2 version v1 source 10.0.0.1 .. Enabling SNMPv1 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 SNMPv1. .. In OSDx, this can be achieved by setting the following commands: .. .. code-block:: none .. set service snmp community PUBLIC notify-traps alarm ALARM1 .. set service snmp trap-target 10.0.0.2 version v1 community PUBLIC .. set service snmp trap-target 10.0.0.2 version v1 source 10.0.0.1 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: .. code-block:: none set service snmp community PUBLIC set service snmp trap-target 10.0.0.2 version v2c community PUBLIC .. Enabling SNMPv2c 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 SNMPv2c. .. In OSDx, this can be achieved by setting the following commands: .. .. code-block:: none .. set service snmp community PUBLIC notify-traps alarm ALARM1 .. set service snmp trap-target 10.0.0.2 version v2c community PUBLIC .. Enabling incoming SNMPv3 requests .. --------------------------------- .. Imagine that you want to configure the SNMP service to allow the reception of incoming .. requests, using SNMPv3. .. In OSDx, this can be achieved by setting the following commands: .. .. code-block:: none .. set service snmp user USERv3 .. Enabling SNMPv3 notification sending .. ------------------------------------ .. Imagine that you want to configure the SNMP service to allow sending notifications .. to host 10.0.0.2, using SNMPv3. .. In OSDx, this can be achieved by setting the following commands: .. .. code-block:: none .. 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 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: .. code-block:: none 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 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 :osdx:op:`service snmp get *`. GETNEXT Operation ^^^^^^^^^^^^^^^^^ The SNMP **GETNEXT** operation retrieves the next variable in the MIB tree. It can be used with operational command :osdx:op:`service snmp getnext *`. SET Operation ^^^^^^^^^^^^^ The SNMP **SET** operation sets the value of a specific OID. It can be used with operational command :osdx:op:`service snmp set *`. SNMP Versions and Commands ^^^^^^^^^^^^^^^^^^^^^^^^^^ The necessary options can differ, depending on the SNMP version you're using: **For SNMP v1/v2c:** ``service snmp oid version <1|2c> community `` **For SNMP v3:** ``service snmp oid version 3 user `` 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 :doc:`SNMP operations examples ` Monitoring ========== The following operational commands can be used to retrieve a subtree of information from local or remote agents: * :osdx:op:`service snmp walk local-agent v1 *`. * :osdx:op:`service snmp walk local-agent v2c *`. * :osdx:op:`service snmp walk local-agent v3 *`. * :osdx:op:`service snmp walk remote-agent * v1 *`. * :osdx:op:`service snmp walk remote-agent * v2c *`. * :osdx:op:`service snmp walk remote-agent * v3 *`. *Example:* .. code-block:: none 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:* .. code-block:: none 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 Additionally, operational commands :osdx:op:`service snmp monitor traps community *` and :osdx:op:`service snmp monitor traps user *` can be used to monitor SNMP traps. *Example:* .. code-block:: none 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 [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 .. depth=5 to show all snmp trap-target options .. osdx:cmdtree:: cfg :maxdepth: 5 service snmp .. osdx:cmdtree:: op :maxdepth: 5 service snmp