Autodetection of BGP on Juniper MX

Problem:
OpenNMS detects BGP sessions for Juniper MX104 node but only shows “BGP Updates”.
Number of routes / prefixes as well as accepted / rejected / damped graphs would be helpful.

Expected outcome:
As OpenNMS automatically detects “BGP Updates”, it could also autodetect prefix stats.

OpenNMS version:
Horizon v25, latest

Other relevant data:
None, might be a newbie question.
As far as I understand SNMP, prefix OIDs are part of the Juniper MIB:
http://oidref.com/1.3.6.1.4.1.2636.5.1.1.2.6.2.1.7

The graphs you see by default are driven by this “Collectd” configuration:

And, the graph itself is rendered by this configuration:

I don’t think OpenNMS is configured to collect BGP4-V2-MIB-JUNIPER::jnxBgpM2PrefixInPrefixes by default. You’d have to either teach it yourself, or see if it’s already available in the Juniper config module project (though it doesn’t appear to be):

It’s a good approach to enhance the config module. It’s easier to maintain.

Thank you!

I’ve installed the module (I hope so) and restarted the services but have not yet found any difference in the views.
Seems like I need to wait a bit for the data to flow.

As soon as I understand how this works, I will look into adding the OIDs. OpenNMS ist compely new for me, as I am using Icinga2 most of the time.

Ok, does not seem to work for me (yet):
My HOME seems to be “/usr/share/opennms” (Debian Buster).
(Example: /usr/share/opennms/opennms-config-workspace/juniper/README.adoc)
Also, all events and graphs + XML edits are in place.

I’ve restarted everything but nothing changed.
I was unable to find a wiki page about the “opennms-config-workspace” folder, do I need to enable the “juniper” module somewhere?

The config module repo was created to have vendor specific configuration in a separate place and not in the default installation.
The benefit is, that the configs are easier to maintain and the next step is, to ‘pluginize’ them to be usable for the OIA

Do you know what OIDs are missing in the data collection?

I understand that and absolutely support this.
After some research it looks like that the module fits best for SRX devices, which would explain why I don’t see additional graphs.

I would like to learn how my requests need to be implemented as this is the part I am stuck with (SNMP things). After that, I would like to extent it myself and spin up some PRs.

juniper> show snmp mib walk jnxBgpM2 (relevant parts)

jnxBgpM2PrefixInPrefixes.0.1.1 = 765823
jnxBgpM2PrefixInPrefixes.1.2.1 = 72863
jnxBgpM2PrefixInPrefixes.2.1.1 = 764297
jnxBgpM2PrefixInPrefixes.3.2.1 = 54988
jnxBgpM2PrefixInPrefixes.4.1.1 = 0
jnxBgpM2PrefixInPrefixes.5.2.1 = 0
jnxBgpM2PrefixInPrefixes.6.1.1 = 0
jnxBgpM2PrefixInPrefixes.7.2.1 = 0
jnxBgpM2PrefixInPrefixes.8.1.1 = 31
jnxBgpM2PrefixInPrefixes.11.1.1 = 44
jnxBgpM2PrefixInPrefixes.12.2.1 = 37
jnxBgpM2PrefixInPrefixes.13.1.1 = 1
jnxBgpM2PrefixInPrefixes.14.2.1 = 1
jnxBgpM2PrefixInPrefixes.15.2.1 = 74233
jnxBgpM2PrefixInPrefixes.17.2.1 = 76161
jnxBgpM2PrefixInPrefixesAccepted.0.1.1 = 765823
jnxBgpM2PrefixInPrefixesAccepted.1.2.1 = 72858
jnxBgpM2PrefixInPrefixesAccepted.2.1.1 = 764297
jnxBgpM2PrefixInPrefixesAccepted.3.2.1 = 54986
jnxBgpM2PrefixInPrefixesAccepted.4.1.1 = 0
jnxBgpM2PrefixInPrefixesAccepted.5.2.1 = 0
jnxBgpM2PrefixInPrefixesAccepted.6.1.1 = 0
jnxBgpM2PrefixInPrefixesAccepted.7.2.1 = 0
jnxBgpM2PrefixInPrefixesAccepted.8.1.1 = 0
jnxBgpM2PrefixInPrefixesAccepted.11.1.1 = 44
jnxBgpM2PrefixInPrefixesAccepted.12.2.1 = 37
jnxBgpM2PrefixInPrefixesAccepted.13.1.1 = 1
jnxBgpM2PrefixInPrefixesAccepted.14.2.1 = 1
jnxBgpM2PrefixInPrefixesAccepted.15.2.1 = 74231
jnxBgpM2PrefixInPrefixesAccepted.17.2.1 = 75661
jnxBgpM2PrefixInPrefixesRejected.0.1.1 = 0
jnxBgpM2PrefixInPrefixesRejected.1.2.1 = 5
jnxBgpM2PrefixInPrefixesRejected.2.1.1 = 0
jnxBgpM2PrefixInPrefixesRejected.3.2.1 = 2
jnxBgpM2PrefixInPrefixesRejected.4.1.1 = 0
jnxBgpM2PrefixInPrefixesRejected.5.2.1 = 0
jnxBgpM2PrefixInPrefixesRejected.6.1.1 = 0
jnxBgpM2PrefixInPrefixesRejected.7.2.1 = 0
jnxBgpM2PrefixInPrefixesRejected.8.1.1 = 31
jnxBgpM2PrefixInPrefixesRejected.11.1.1 = 0
jnxBgpM2PrefixInPrefixesRejected.12.2.1 = 0
jnxBgpM2PrefixInPrefixesRejected.13.1.1 = 0
jnxBgpM2PrefixInPrefixesRejected.14.2.1 = 0
jnxBgpM2PrefixInPrefixesRejected.15.2.1 = 2
jnxBgpM2PrefixInPrefixesRejected.17.2.1 = 500
jnxBgpM2PrefixOutPrefixes.0.1.1 = 5
jnxBgpM2PrefixOutPrefixes.1.2.1 = 7
jnxBgpM2PrefixOutPrefixes.2.1.1 = 5
jnxBgpM2PrefixOutPrefixes.3.2.1 = 7
jnxBgpM2PrefixOutPrefixes.4.1.1 = 766350
jnxBgpM2PrefixOutPrefixes.5.2.1 = 75749
jnxBgpM2PrefixOutPrefixes.6.1.1 = 766069
jnxBgpM2PrefixOutPrefixes.7.2.1 = 75749
jnxBgpM2PrefixOutPrefixes.8.1.1 = 0
jnxBgpM2PrefixOutPrefixes.11.1.1 = 5
jnxBgpM2PrefixOutPrefixes.12.2.1 = 7
jnxBgpM2PrefixOutPrefixes.13.1.1 = 5
jnxBgpM2PrefixOutPrefixes.14.2.1 = 7
jnxBgpM2PrefixOutPrefixes.15.2.1 = 1
jnxBgpM2PrefixOutPrefixes.17.2.1 = 1
jnxBgpM2PrefixInPrefixesActive.0.1.1 = 716219
jnxBgpM2PrefixInPrefixesActive.1.2.1 = 70871
jnxBgpM2PrefixInPrefixesActive.2.1.1 = 49800
jnxBgpM2PrefixInPrefixesActive.3.2.1 = 1881
jnxBgpM2PrefixInPrefixesActive.4.1.1 = 0
jnxBgpM2PrefixInPrefixesActive.5.2.1 = 0
jnxBgpM2PrefixInPrefixesActive.6.1.1 = 0
jnxBgpM2PrefixInPrefixesActive.7.2.1 = 0
jnxBgpM2PrefixInPrefixesActive.8.1.1 = 0
jnxBgpM2PrefixInPrefixesActive.11.1.1 = 44
jnxBgpM2PrefixInPrefixesActive.12.2.1 = 37
jnxBgpM2PrefixInPrefixesActive.13.1.1 = 1
jnxBgpM2PrefixInPrefixesActive.14.2.1 = 1
jnxBgpM2PrefixInPrefixesActive.15.2.1 = 2689
jnxBgpM2PrefixInPrefixesActive.17.2.1 = 263

This would perfectly fit into the BGP graphs as they show anomalies at a peers network, especially outages at ASs in front of them.

Example:

12.10.2019 12:02:37 (29 ms) : Custom OID 1.3.6.1.4.1.2636.5.1.1.2.6.2.1.10.4.1.1
12.10.2019 12:02:37 (221 ms) : SNMP Datatype: ASN_UNSIGNED
12.10.2019 12:02:37 (229 ms) : -------
12.10.2019 12:02:37 (236 ms) : Value: 766364
12.10.2019 12:02:37 (243 ms) : Done

Ok, looks like the juniper package is already part of “opennms-common”. Seems like I got the comment wrong, as I first thought, I need to manualy load the module.

I’ve now tried a lot more plugins to understand how that works. Seems like a lot of modules need an adjustment like that:
find /etc/opennms/datacollection \( -type d -name .git -prune \) -o -type f -print0 | xargs -0 sed -i 's/org\.opennms\.netmgt\.dao\.support\.IndexStorageStrategy/org\.opennms\.netmgt\.collection\.support\.IndexStorageStrategy/g'
I can file some PRs if you like (just like the one you did here).

I’ve also automated the deployment for OpenNMS over at my CDStack project:
https://bitbucket.org/code-orange/django-cdstack-tpl-opennms

Looks like I’ve got a problem with duplicates:

root@mon-onms01 /etc/opennms # grep -i “juniper” eventconf.xml
events/Juniper.mcast.events.xml
events/Juniper.events.xml
events/Juniper.ive.events.xml
events/Juniper.screen.events.xml
events/juniper.ive.events.xml
events/juniper.screen.events.xml
events/juniper.netscreen.events.xml
events/juniper.mcast.events.xml
events/juniper.events.xml

Why are they modified during packaging? I would assume it to keep the filename to make upstream patches (monkey patching in python terms) possible. So I miss something here?