Zabbix cannot display/monitor ISIS protocol juniper

[kronicklez]

Hi Expert Zabbix,

I'm already discover juniper device MX but unfortunately i cannot see ISIS protocol discover. I just see OSPFv4 and OSPFv6 only. May i know whether the current template Juniper device in zabbix support ISIS protocol or i need to add manually additional template?


Thanks and appreciate any feedback

[kronicklez]

Hi zabbix expert,


Any feedback regarding this request?

Thanks and appreciate any response.

[kronicklez]

Hi Expert,

May i know anyone can help?

[BradKnowles]

So, I've checked the list of official integrations at https://www.zabbix.com/integrations and I've checked the community templates repo at https://github.com/zabbix/community-templates/tree/main and I haven't found anything that seems to cover IS-IS, whether that's for Juniper or anything else. I also found the repo at https://github.com/initMAX/zabbix-templates but it also doesn't seem to have anything for IS-IS.

If there's anyone out there who has more information on this subject, please let me know. The Juniper MIB Explorer shows that their support for IS-IS starts at 1.3.6.1.2.1.138 (see https://apps.juniper.net/mib-explore...release=25.2R1) but it's hard to tell what OIDs under that tree actually need to be monitored, or what values mean what for which OID.

[ISiroshtan]

Never worked with IS-IS or Juniper, so would not know which templates exist or not, but... Looking at MIB file you shared the link to, I would say you have two way to write your own template:

1. Easier to write, but with less control is just to integrate the SNMP trap processing based on isisNotifications tree ( .1.3.6.1.2.1.138.0 ) . It has 18 traps, covering different problems with IS-IS like system database overload, corrupted LSP, adjcency state etc. You would need to talk with some one familiar with IS-IS operation to evaluate how critical this traps are tho. Also you would need to setup somewhat advanced processing as some of traps would contain additional information, like isisNotificationCircIfIndex (The identifier of this circuit relevant to this notification.) and isisAdjState (The current state of an adjacency.) meaning same notification used for indicating problem and problem resolution and can be notifying about different entities. (notification objects defined under OID .1.3.6.1.2.1.138.1.10.1.12 isisNotificationEntry)

2. Active monitroring where you would need to setup discoveries to iterate through specific sub-trees and get data and decide if alert is needed. I call it more complicated coz you actually need to understand IS-IS and figure out which of params are indicative of issues you are interested in catching. As I have no clue about IS-IS operation for me it's hard to guess what you would actually need. Looking randomly through MIB - .1.3.6.1.2.1.138.1.3.2 ( isisCircTable - The table of circuits used by this Intermediate System, contains entries like admin state of circuit, existence state, circuit uptime, etc.), .1.3.6.1.2.1.138.1.5 ( isisCounters - seems to be statistics information about circuit, like number of different errors etc.), .1.3.6.1.2.1.138.1.6.1 ( isisISAdjTable -
The table of adjacencies to Intermediate Systems. ). Dunno what else might be critical for IS-IS.

For reading MIBs I'd suggest to download free MIB browser https://www.ireasoning.com/mibbrowser.shtml + the MIB itself (https://apps.juniper.net/mib-explore...ib-rfc4444.txt) , load it into MIBbrowser and go through nodes. Each OID table and OID node has a description giving you idea of what it represents (still need understanding of IS-IS to make total sense of it)

Not sure it was overly helpful, but is the best I can do at this stage of your journey into IS-IS monitoring

[BradKnowles]

So, what I've decided to do is to take the existing Juniper MX by SNMP template and clone that, and then start making modifications.

According to our Network Administrator, we don't use OSPF, so I will take one of the parts of the template that deals with OSPF and convert that to dealing with IS-IS.

I've actually gotten most of the way through that process, and I am told that for the moment the only thing we care about is the isisCircExistState at 1.3.6.1.2.1.138.1.3.2.1.4, and I've been pointed at the article at https://supportportal.juniper.net/s/...language=en_US which says that we really should only care about two of the states listed.

However, I must have not completed the work correctly, because applying the modified template to one of the Juniper devices that we are using comes back with this error:

snmp_parse_oid(): cannot parse OID "1.3.6.1.2.1.138.1.3.2.1.4 ".

Unfortunately, I don't know enough about how this data is being returned to Zabbix to be able to tell what I have done wrong. I can show you the results of doing an `snmpwalk` against that OID on that server (with community string and IP address changed to protect the innocent):

$ snmpwalk -v 1 -c community 10.0.0.1 1.3.6.1.2.1.138.1.3.2.1.4
iso.3.6.1.2.1.138.1.3.2.1.4.16 = INTEGER: 1
iso.3.6.1.2.1.138.1.3.2.1.4.576 = INTEGER: 1
iso.3.6.1.2.1.138.1.3.2.1.4.578 = INTEGER: 1
iso.3.6.1.2.1.138.1.3.2.1.4.579 = INTEGER: 1​

But I think Zabbix turns that into JSON for parsing purposes. I did find and install the `snmpwalk-parser` tool written in Python, which takes this output and turns it into this:

$ snmpwalk-parser parse -f isis.txt --format json

Parsing SNMP Output: isis.txt
=============================
✓ Parsed 4 entries
{
  "file": "isis.txt",
  "entries": [
    {
      "oid": "iso.3.6.1.2.1.138.1.3.2.1.4.16",
      "key": "iso.3.6.1.2.1.138.1.3.2.1.4",
      "index": "16",
      "type": "INTEGER",
      "value": 1,
      "raw_value": "1"
    },
    {
      "oid": "iso.3.6.1.2.1.138.1.3.2.1.4.576",
      "key": "iso.3.6.1.2.1.138.1.3.2.1.4",
      "index": "576",
      "type": "INTEGER",
      "value": 1,
      "raw_value": "1"
    },
    {
      "oid": "iso.3.6.1.2.1.138.1.3.2.1.4.578",
      "key": "iso.3.6.1.2.1.138.1.3.2.1.4",
      "index": "578",
      "type": "INTEGER",
      "value": 1,
      "raw_value": "1"
    },
    {
      "oid": "iso.3.6.1.2.1.138.1.3.2.1.4.579",
      "key": "iso.3.6.1.2.1.138.1.3.2.1.4",
      "index": "579",
      "type": "INTEGER",
      "value": 1,
      "raw_value": "1"
    }
  ],
  "count": 4
}

But that doesn't really tell me anything new. I must not be understanding what's going on here.

Searching for this error online, I found the articles at https://ixnfo.com/en/solving-the-err...e-oid-mib.html and https://github.com/jjmartres/Zabbix/issues/51 and https://github.com/matheusandrades/Z...uawei/issues/1 but I don't think these address my issue, since I'm using bare OIDs in my walk configuration (as the template did previously for OSPF), instead of MIB-specific terms that would not otherwise be understood if the MIB wasn't already installed on that server.

[ISiroshtan]

Would be good if you could share screenshots of what you set up

[BradKnowles]

And not five minutes after I report that, I found out what the problem was.

Originally, my snmpwalk definition in the template was:

walk[ 1.3.6.1.2.1.138.1.3.2.1.4 ]

Note the space characters between the OID and the square brackets. This does not work.

My snmpwalk definition is now:

walk[1.3.6.1.2.1.138.1.3.2.1.4]

Note that there are no spaces between the OID and the square brackets. This does work. At least, it gets the data.

Now, I've got a new problem. For each of the detected IS-IS circuits, when I go to look at the triggers I defined, I'm now getting the error:

Cannot evaluate function last(/hostname/juniper.mx.isis.state[isisCircExistState.579]): item is not supported.

I will upload an attachment showing what that looks like in the WebUI, with the hostname redacted:

[BradKnowles]

So, you can see that the discovery is now working, and it's pulling out circuits that exist on .579, .578, .576, and .16. Exactly as we would expect based on the snmpwalk data shown above.

But I'm not understanding what "Item is not supported" means.

[ISiroshtan]

Check not the tirgger status but instead discovered items status. They usually show why items is becoming unsupported.

[BradKnowles]

And here is the raw master item that I created:

[BradKnowles]

Here is the discovery rule I created (based on the OSPF example in the Juniper MX by SNMP template), with part of the template name redacted:






































And here is the pre-processing rules that I created (also based on the OSPF example):

[kronicklez]

Hi,

In the librenms its capable to monitor ISIS as per below snapshot. But is it possible zabbix can do similar like this?


Thanks

[ISiroshtan]

Can you collect all the same data? - yes.
Is there pre-made template for it? - seems like no and you would need to build it from scratch
Can you present data exactly like this? - I'm not sure. I've stopped using Zabbix data visualization for majority of cases and instead build Grafana dashboards using data from Zabbix. With such approach - definitely yes, you could build similar visualisation.

[BradKnowles]

Okay, I think I figured out my problem. I had updated the OID for the IS-IS Discovery dependent item itself, but I had not updated the OID for the Item Prototype under that dependent item. Here's what that looks like now:
I can see the status coming through:
I've created a Graph Prototype that enumerates all the circuit numbers:
I've created a dashboard on the template that references this Graph Prototype, which looks deceivingly empty:
And this now shows up as a host level dashboard for the system where I've been doing my testing:
Now I need to figure out things like how to identify which SNMP Index belongs to which circuit that may be better known by some other criteria, like the interface it's on, the IP address(es) associated with it, or whatever.

And it would be great if I could get them all stacked onto the same larger graph, instead of multiple smaller graphs. Because I've got only so much space on this dashboard, and there's a lot of overhead here. I don't know how many IS-IS circuits we may be dealing with in production.