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

Non-DOM supported transceivers showing power sensors on IOS-XR 7.9.21

Details

    • Vendor Bug
    • Resolution: Fixed
    • Minor
    • None
    • None
    • Discovery, Poller

    Description

      Since upgrading some Cisco ASR9010 Routers to Cisco IOS-XR 7.9.21, we've noticed that non-DOM supported transceivers (i.e. copper) now have voltage, current & power sensors. See the attached screenshot. This is creating a lot of alerts.

      I believe this is similar to issue OBS-3335.

      Thoughts?

      Attachments

        Issue Links

          Activity

            [OBS-4954] Non-DOM supported transceivers showing power sensors on IOS-XR 7.9.21

            I not sure that this is correct, without real system or snmpdump I can't check this.
            Probably fixed in r13812.

            Note, this fix is in rolling updates now: https://docs.observium.org/updating/#switch-between-rolling-and-stable-trains

            landy Mike Stupalov added a comment - I not sure that this is correct, without real system or snmpdump I can't check this. Probably fixed in r13812. Note, this fix is in rolling updates now: https://docs.observium.org/updating/#switch-between-rolling-and-stable-trains

            As I see in snmp output, this interfaces reports entPhysicalVendorType as cevSFP10GSR:

            entPhysicalDescr.847355804 = 1000BASE-T SFP (NEBS 3), UTP, 100m
            entPhysicalVendorType.847355804 = cevSFP10GSR
            entPhysicalContainedIn.847355804 = 847250123
             
            entPhysicalClass.847355804 = module
            entPhysicalParentRelPos.847355804 = 0
            entPhysicalName.847355804 = GigabitEthernet104/0/0/16
            entPhysicalHardwareRev.847355804 = V02
            entPhysicalFirmwareRev.847355804 =
            entPhysicalSoftwareRev.847355804 =
            entPhysicalSerialNum.847355804 = MTC203606EG
            entPhysicalMfgName.847355804 = CISCO-METHODE
            entPhysicalModelName.847355804 = SFP-GE-T
            entPhysicalAlias.847355804 = ASSTAL
            entPhysicalAssetID.847355804 = ASSTID-1
            entPhysicalIsFRU.847355804 = true
            

            this type corresponds to

             -- 10GBASE-SR SFP+ Module for MMF
            

            It seems you use unsupported modules which incorrectly report their type.

            landy Mike Stupalov added a comment - As I see in snmp output, this interfaces reports entPhysicalVendorType as cevSFP10GSR : entPhysicalDescr.847355804 = 1000BASE-T SFP (NEBS 3), UTP, 100m entPhysicalVendorType.847355804 = cevSFP10GSR entPhysicalContainedIn.847355804 = 847250123   entPhysicalClass.847355804 = module entPhysicalParentRelPos.847355804 = 0 entPhysicalName.847355804 = GigabitEthernet104/0/0/16 entPhysicalHardwareRev.847355804 = V02 entPhysicalFirmwareRev.847355804 = entPhysicalSoftwareRev.847355804 = entPhysicalSerialNum.847355804 = MTC203606EG entPhysicalMfgName.847355804 = CISCO-METHODE entPhysicalModelName.847355804 = SFP-GE-T entPhysicalAlias.847355804 = ASSTAL entPhysicalAssetID.847355804 = ASSTID-1 entPhysicalIsFRU.847355804 = true this type corresponds to -- 10GBASE-SR SFP+ Module for MMF It seems you use unsupported modules which incorrectly report their type.

            By first, you need write Cisco TAC about firmware issue. This is very hard track all vendor errors after update firmwares..

            landy Mike Stupalov added a comment - By first, you need write Cisco TAC about firmware issue. This is very hard track all vendor errors after update firmwares..

            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
              nathan.desmond Nathan ND Desmond
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: