OpenNMS, openstreetmap, geocoding APIs and SNMP

Thu Dec 10 09:24:47 UTC 2020

Anyone that has used a recent version of OpenNMS has probably noticed that
the default home page view now includes an openstreetmap based view of
node/device status, by geographical location.

Section 18.3 here:
https://docs.opennms.org/opennms/releases/latest/guide-admin/guide-admin.html

https://wiki.opennms.org/wiki/Geographical_Maps

example image here:
https://www.tecmint.com/wp-content/uploads/2019/05/opennms-default-admin-dashboard.png

While customizing a newly setup opennms VM for a unique purpose, I began
thinking that there's two possible ways to go about accurately placing
nodes on such a map, on a very large scale, with scripting/automation in
the provisioning and monitoring process.

*Method 1 *(as opennms does now): As defined in RFC3418, put the standard
street address of the node in the SNMP sysLocation field. Typically in a
human readable text format that would be understood when posted to a
geolocation API SaaS.

Example being: 2200 6th Avenue, Seattle WA 98121

   sysLocation OBJECT-TYPE
       SYNTAX      DisplayString (SIZE (0..255))
       MAX-ACCESS  read-write
       STATUS      current
       DESCRIPTION
               "The physical location of this node (e.g., 'telephone
               closet, 3rd floor').  If the location is unknown, the
               value is the zero-length string."
       ::= { system 6 }

The above is dependent on a few things. First, every node needs to have a
standard format street address entered into its sysLocation field. But what
if you have a telecom tower site on a mountain or hillside? What if it's a
node in a developing nation environment where standard third-party
geolocation API providers (S.18.3 of the opennms documentation) can't
resolve anything? What if it's a device that moves around, like a router on
an ocean going vessel or aircraft?

*Method 2 *(backwards compatible, possibly an improvement): Treat the 255
character sysLocation field as a rudimentary three column CSV file with
pipe delimiters. Put the standard human readable description of the node
location in the first column. Populate the second column with the latitude
and longitude in WGS84 decimal degree format, such as:

Suite 402 2200 6th Ave, Seattle WA 98121|47.616380|-122.341673

Where both columns have six decimal places of precision
Column 2 is positive integer if north of the equator
Column 3 is negative integer if west of Greenwich.
Optional 4th column: Elevation in metres, MSL

In the method 2 example described above, opennms can be customized to
retrieve the lat/long from sysLocation and place nodes on the dashboard,
rendering the underlying map from a self-hosted openstreetmap intranet
server without needing to call an external geolocation API. Provided that
the data provisioned into the CPE/node in the first place is accurate (this
is absolutely a GIGO problem), node locations for difficult-to-geocode
install locations should become much more accurate.

*Some issues that may be encountered:*
Very old or improperly implemented snmpd on some devices does not support a
255 character field length, sometimes not even 100 characters. Varies
greatly by vendor implementation.

Provisioning and configuration system for nodes need an automated way to
enter those lat/long coordinates into columns 2 and 3 in a scripted,
automated way. In an example of small 1/10GbE capable business-class ISP
CPE demarc devices, *perhaps* as the result of a provisioning system's call
to a geolocation API. But with some sort of optional step for configuring a
node in a location that won't geocode - such as having a provisioning tech
manually scroll to and click a location on a map in a browser.

For ISPs with large numbers of CPE endpoint/stub nodes that don't presently
have valid sysLocation, it will be a manually laborious one-time process to
hunt down all extant CPEs and verify their street address vs customer
records, google maps/bing maps/openstreetmap, and manually edit the
sysLocation field.

Environments that would have many nodes expected to fail third-party
geolocation APIs, would probably want to customize some sort of
click-on-map GUI for the persons doing the provisioning and hand-off of
CPEs to field installation techs. Or possibly using GPS data acquired from
an installation technician's mobile phone (standard iOS and Android browser
APIs for requesting GPS data), as a custom data field in a ticketing
system. Data from that field in the ticketing system could then be fed to
another piece of software and pushed to a script to write the sysLocation.

*Possibly outside scope*:
It's possible to self host your own openstreetmap tile server. The vector
data for the entire world is freely available to download. The tile
rendering engine and all software needed to set it up is all open source.
This can be implemented for ISP management/monitoring networks (NOC map
dashboard functionality, etc) that for security reasons have no connection
whatsoever to the global routing table.

Nodes that move around because they're mounted on some sort of vehicle may
be able to update and rewrite their own SNMP sysLocation field from GPS
data. Would require custom scripting or being accompanied by a very small
embedded Linux system with serial interface to a low-cost GPS chipset.
That's a data acquisition system that already exists for some category of
equipment such as two-way satellite terminals on ocean going vessels.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20201210/8b5c5dfe/attachment.html>