Hi all,
We are suffering the same problem on a lot of 10G interfaces that we have down.
We think that this is a junos bug.
Sometimes, checking diagnostics optics on the cli, you can see the RX optical power as “-Inf”, instead of a dbm value. When this happens, the snmp value returned on jnxDomCurrentRxLaserPower is 0, instead of the real dbm value (typically between -20dbm and -40dbm). This situation results on triggering the alert when the real value is returned again.
There is a possible workaround to avoid this.
In the same MIB, if you check the value of jnxDomCurrentAlarms and domRxLaserPowerLowAlarm is active, then you can ignore a 0 in jnxDomCurrentRxLaserPower, and replace it by a logical value like -40dbm, or jnxDomCurrentRxLaserPowerLowAlarmThreshold – 0.01.
Best regards
Javier Valero
IP Services Coordinator
IslaLink / OranLink
De: observium [mailto:observium-bounces@observium.org]
En nombre de Milton Ngan
Enviado el: viernes, 3 de noviembre de 2017 5:34
Para: Observium Network Observation System <observium@observium.org>
Asunto: [Observium] Optic dbm alert checker and interface status
Hi,
Is there a way to only trigger the dbm sensor alert if the corresponding interface is up? I thought I could get away with just testing if the sensor values fall outside the sensor limits. But when ports are down (even when unplugged) I get spiky readings which will trigger the alert. So it would be nice to check if the interface is up as part of the alert check.
I suspect this isn't possible as things are right now. It seems sensors have no relationship to another entity (e.g a port on a router). Ideally, I would like to say something like this:
Port Checker Condition
ifOperStatus eq up
sensors.dbm.juniper-dom-rx.sensor_value < @sensors.dbm.juniper-dom-rx.sensor_limit_low
Port Checker Entity Match
ifAdminStatus eq up
dbm in sensor_classes
juniper-dom-rx in sensor_types
So only ports that are admin up and have an associated sensor type of the appropriate type would get added to the checker. This will ensure the condition will be able to refer to the appropriate sensor.
This would imply there is some mapping/relationship between sensors and other entities. This is probably very MIB specific and very platform specific. But it would make for a very useful checker.