==== 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. 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 :osdx:cfg:`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 :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 when alarms are updated .. 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 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: .. 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 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 :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 ========== 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: :osdx:cfg:`service snmp log-level *`. Walk and Table Commands ----------------------- 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 Traps ----- 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 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 :osdx:cfg:`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 :osdx:op:`interfaces ethernet * show plugin-module` operational command: .. code-block:: none 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):** .. code-block:: none 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):** .. code-block:: none 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: .. code-block:: none 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:** * Verify the SNMP service is configured and running: ``show service snmp`` * Check that the device has SFP-capable interfaces by running :osdx:op:`interfaces ethernet * show plugin-module` on each interface **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 :osdx:op:`interfaces ethernet * show plugin-module` command, which provides comprehensive optical diagnostics including alarm/warning flags. .. osdx:cmdtree:: cfg :maxdepth: 5 service snmp .. osdx:cmdtree:: op :maxdepth: 5 service snmp