Uploaded image for project: 'ZABBIX FEATURE REQUESTS'
  1. ZABBIX FEATURE REQUESTS
  2. ZBXNEXT-6320

Request for recursive LLD for SNMP items

    XMLWordPrintable

    Details

    • Type: Change Request
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 5.0.5
    • Fix Version/s: None
    • Component/s: Server (S)
    • Labels:
      None

      Description

      There is a case:

      One of the tings that we monitor are the power levels for our optical interfaces.
      We do this using SNMP OID 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 (jnxDomCurrentLaneRxLaserPower).
      This OID returns an integer which represents the receiver laser power on a particular lane of a SFF physcial interface.
      The returned value needs to be divided by 100 to get the value in dBm.

      This works just fine for optics up to 10G because they have just one single laser.
      But 40G and 100G optics are constructed internally using different lasers.
      For example a 100G optic internally uses 4 lanes each with it's seperate laser having a bandwidth of 25G. This is how 100G bandwidth is achieved. So there are 4 lasers each with their own power levels.

      The problem with LLD discovery here is that the index that is used in the OID isn't at the end, but is on the second to last position.

      1 GE optic example:
      ------------------------

       

      $ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.2.1.31.1.1.1.1.4935
      iso.3.6.1.2.1.31.1.1.1.1.4935 = STRING: "ge-0/1/0"
      --> This is a 1 gigabit optic.
      $ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 | grep 4935
      iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4935.0 = INTEGER: -563
      --> This means that the optic receives a signal of -5.63dBm
      

       

      10 GE optic example:
      ------------------------

       

      $ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.2.1.31.1.1.1.1.612
      iso.3.6.1.2.1.31.1.1.1.1.612 = STRING: "xe-11/0/0"
      --> This is a 10 gigabit optic.
      $ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 | grep 612
      iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.612.0 = INTEGER: -209
      --> This means that the optic receives a signal of -2.09dBm
      

       

      100 GE optic example:
      ------------------------

       

      $ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.2.1.31.1.1.1.1.4671
      iso.3.6.1.2.1.31.1.1.1.1.4671 = STRING: "et-8/0/5"
      --> This is a 100 gigabit optic.
      $ snmpwalk -c foobar -v2c r1.brueve 1.3.6.1.4.1.2636.3.60.1.2.1.1.6 | grep 4671
      iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.0 = INTEGER: -230
      iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.1 = INTEGER: -146
      iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.2 = INTEGER: -209
      iso.3.6.1.4.1.2636.3.60.1.2.1.1.6.4671.3 = INTEGER: -265
      

      --> This means that the optic receives a signal of -2.30dBm on Lane 0, -1.46dBm on Lane 1, -2.09dBm on Lane 2 and -2.65dBm on Lane 3.

      At the moment the only possibility that we have is to statically define an item for each possible lane:

       

      1.3.6.1.4.1.2636.3.60.1.2.1.1.6.index.0
      1.3.6.1.4.1.2636.3.60.1.2.1.1.6.index.1
      1.3.6.1.4.1.2636.3.60.1.2.1.1.6.index.2
      1.3.6.1.4.1.2636.3.60.1.2.1.1.6.index.3
      

      But since we don't know beforehand if a discovered interface is going to be 1G, 10G, 40G or 100G, this means that for all interfaces with less that 4 lanes we will have unsupported items (because the lanes don't exist).

      Is it possible to allow LLD for indexes that are not at the end of the OID? Discover indexes which also have indexes?

       

        Attachments

          Activity

            People

            Assignee:
            wiper Andris Zeila
            Reporter:
            igorbach Igor Gorbach
            Votes:
            2 Vote for this issue
            Watchers:
            3 Start watching this issue

              Dates

              Created:
              Updated: