Datasource development challenge

Userlevel 3
Badge +8

Anyone have any ideas about how to solve this challenge?

We'd like to collect dhcp relay stats from our Juniper routers, not necessarily for minute-by-minute graphs and alerts but to be able to show patterns of longer term trends (hourly, daily, monthly) I've got the list of OIDs for the counts of DORA plus Naks, Informs, total lease count and total drops.

The kicker is that they are stored on a per routing instance (ie VRF) basis and the OIDs aren't structured like #WILDVALUE (routing instance name or ID)#.n.n.n  Instead, all routing instances use the same OIDs, and to query them you issue a get at each OID with [routing instance name@(snmp community)] as the snmp community;  the output returned corresponds to the name of the routing instance.

Somehow this has to possible, but it may be a situation where the effort to achieve and/or sustain it is going to exceed the value of the data it would provide.



Best answer by Anonymous 29 May 2020, 20:15

View original

4 replies

In 15 years of SNMP monitoring, I've never seen it done that way. Somebody got needlessly creative. Just to be sure, you do make the SNMP get to the same address, regardless of VRF, right?

So, you could switch to groovy and make the SNMP queries custom. Looks like both the Snmp.get() and Snmp.walk have the ability to get specify the community string at runtime. So, if you have the list of VRF names and you have the base community string, you could construct the concatenated version and make the query using a different "community string" for each VRF.

Snmp method reference:

Userlevel 3
Badge +8

Thanks Stuart.

Correct, all snmp gets for this would go to the same loopback address that every other datasource uses.  An added layer of difficulty is that the OID that stores VPN names is--according to Juniper's published docs--"not accessible", so there's no way to include that as an automated discovery in a solution.   Therefore every run through each VRFs OIDs will need to be manually created, every time we add or remove VRFs from a router we will need to manually edit the script accordingly and since not every router has the same VRFs we might choose to create a datasource for each router (since I don't know how difficult it will be to account for what to do with "null" values from output)

And did I mention that while I conceptually understand what you've described, and that it mostly matches my expectation of the likely way to do it, my scripting skills are effectively limited to:


20 GOTO 10

So, if off the top of your head there's an appropriate datasource out there that could serve as a base into which I could substitute as needed with cuts/pastes, it would be great if you could send its link.  If not, anyone out there who's motivated by something like a beer delivery I might arrange or a donation to a local food bank/local COVID resource I might make in your name as compensation for kick-starting me should put their contact info in a reply.   Otherwise this will be at the end of the workbench where I will be flailing away at it over the rest of the summer as time permits.

You might look at other ways of discovering the list of VRF names, like maybe an API pull. You could do it in a property source and store the list as a property on each device. Then, instead of making a DS for each device, you could make a DS that pulls the list of VRFs from the device's property that was set previously.