New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for Juniper CHASSIS and SYSTEM alerts #2358
Comments
@lunkwill42 I cannot find the word "alert" in the juniper mibs, do you mean notification, trap or alarm? If not, where is this described/documented? |
@hmpf I believe you want the JUNIPER-ALARM-MIB. It simply enumerates the number of present "red" alarms and "yellow" alarms in a device. There's a copy of it here: https://github.com/pgmillon/observium/blob/master/mibs/juniper/JUNIPER-ALARM-MIB You may want to talk to Håvard E for some guidance, as Zino actually employs this MIB (and potentially others)... |
Seems like step one is adding that mib to NAV's own library of mibs then :) Is there a howto for that? |
According to that MIB there are yellow alarms and red alarms, a count for each, whether the status is on, off or other, and a timestamp for when the status last changed. It might be relevant to mark whether these alarms are enabled or not as well (via jnxAlarmRelayMode: other, passOn, cutOff). |
Closest thing we have is this: https://nav.readthedocs.io/en/latest/hacking/adding-environment-probe-support.html?highlight=smidump#dumping-the-mib |
I've asked Håvard E. about what zino does about this. The JUNIPER-ALARM-MIB only exists on equipment that has a physical craft-interface installed, supplying one actual led to show the colors, and buttons to turn monitoring on or off for various subsystems. Older stuff generally have this interface but at least MX204 and MX10003 does not. There is still a counter for these alarms though, they're just not officially accessible via SNMP. A workaround is to have a script on the equipment that periodically reads the values (
|
When using the mib-jnx-util, zino uses the OIDs |
The steps so far seem to be:
|
#2368 adds the necessary documentation for some of the command line utilities that are useful for testing SNMP OID compatibility with NAV... |
I've decided on making a new ipdevpoll-plugin just for these weirdos. It does not store the value, just dumps them into eventengine if not zero. |
If converting a mib to python with smidump with the
If it complains
|
After a design discussion with @knutvi, we have sort of concluded on a way forward. For the CNaaS team, it's important to know at any one given time what the current number of yellow or red alerts in a Juniper chassis is. I offered up some interpretations of this, and after some discussion, we decided that the cleanest implementation in a NAV context would be this design:
This means that every change in the alert count that does not transition to a count of 0 should cause an entirely new AlertHistory state for B to be created, while any old ones are resolved. Any change in the alert count to 0 should resolve any existing corresponding AlertHistory states. |
Juniper devices have a concept of alerts, classified into Chassis alerts and system alerts.
Their SNMP MIBs support fetching a number of current alerts, but no details of what the alerts actually are.
The CNaaS team wants NAV to be able to report that alerts have been flagged, but some design is needed to figure out how this should work in NAV
Also needed:
The text was updated successfully, but these errors were encountered: