Uploaded image for project: 'Observium'
  1. Observium
  2. OBS-5018

Juniper router inventory not working correctly

Details

    • Vendor Bug
    • Resolution: Fixed
    • Major
    • None
    • Professional Edition
    • Discovery, Poller
    • None

    Description

      We have some juniper routers with linecard that has 2 PICs or more.
      With devices like MX480, the discover is working ok.
      But devices like MX10003 and MX304, isn't.

      Usually, we saw that discovery is finding correctly the first pic (x/0), but the others are not discovered (x/1, x/2 and so on).

      Because of failing the second PIC discovery onwards, the ports and modules aren't also discovered.

       

      In the case below, second PIC was discovered (0/1/*) but all ports doesn't.

      Screenshot:

       

      We had already opened a issue about this fail (OBS-4815), but isn't working since.

       

      Thanks.

      Attachments

        Issue Links

          mentions

          Improvement - An improvement or enhancement to an existing feature or task. OBS-4815 Router inventory is not working

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Resolved

          Activity

            [OBS-5018] Juniper router inventory not working correctly
            eschoedler Eduardo Schoedler added a comment -

            After release r14036, it's working way better.
            Thanks!

            eschoedler Eduardo Schoedler added a comment - After release r14036, it's working way better. Thanks!
            landy Mike Stupalov added a comment -

            Switched discovery by ENTITY-MIB since r14036. Same as for EVO.

            landy Mike Stupalov added a comment - Switched discovery by ENTITY-MIB since r14036. Same as for EVO.
            eschoedler Eduardo Schoedler added a comment -

            The issue is not solved.

             

            If you look closely our pictures, the hierarchy of FPC => PIC => Port (Xcvr) are not populated, as shown in the junos screenshot.
            We dont care about the fans.

            eschoedler Eduardo Schoedler added a comment - The issue is not solved.   If you look closely our pictures, the hierarchy of FPC => PIC => Port (Xcvr) are not populated, as shown in the junos screenshot. We dont care about the fans.
            eschoedler Eduardo Schoedler added a comment -

            Testing, but in discovery we haven't seen any difference.
            Waiting for the polling.

            eschoedler Eduardo Schoedler added a comment - Testing, but in discovery we haven't seen any difference. Waiting for the polling.
            landy Mike Stupalov added a comment -

            It seems there’s an issue with the reported indexes for the fans - they aren’t associated with any chassis.

            This should be improved in display logic as of r14032,
            but the fans are still shown as unassociated with a chassis.

            landy Mike Stupalov added a comment - It seems there’s an issue with the reported indexes for the fans - they aren’t associated with any chassis. This should be improved in display logic as of r14032, but the fans are still shown as unassociated with a chassis.
            eschoedler Eduardo Schoedler added a comment -

            Observium Professional 25.5.14026

            eschoedler Eduardo Schoedler added a comment - Observium Professional 25.5.14026
            eschoedler Eduardo Schoedler added a comment -

            Hello, sent snmpwalk for Mike by email.

            eschoedler Eduardo Schoedler added a comment - Hello, sent snmpwalk for Mike by email.
            bot Observium Bot added a comment -

            General questions and device support can be discussed in our Discord channel, click here to join.

            Please make and attach additional information about the device:

            • full snmp dump from device: 

              snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1 > myagent.snmpwalk
              		 
              snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalk

              If device not support SNMP version 2c, replace -v2c with -v1.

            • If you have problems with discovery or poller processes, please do and attach these debugs: 

              ./discovery.php -d -h <device>
              		 
              ./poller.php -d -h <device>

            • additionally attach device and/or vendor specific MIB files

            This comment is added automatically.

            bot Observium Bot added a comment - General questions and device support can be discussed in our Discord channel, click here to join . Please make and attach additional information about the device: full snmp dump from device: snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1 > myagent.snmpwalk snmpwalk -v2c -c <community> -t 3 -Cc --hexOutputLength=0 -Ih -ObentxU <hostname> .1.3.6.1.4.1 >> myagent.snmpwalk If device not support SNMP version 2c, replace -v2c with -v1. If you have problems with discovery or poller processes, please do and attach these debugs: ./discovery.php -d -h <device> ./poller.php -d -h <device> additionally attach device and/or vendor specific MIB files This comment is added automatically.

            People

              landy Mike Stupalov
              eschoedler Eduardo Schoedler
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: