OpenNMS to monitor Juniper, Cisco and Linux devices

This post will be about OpenNMS and what it can do to monitor the network.

OpenNMS is similar to LibreNMS covered here.

The installation is pretty straighforward and installation steps for various OSs are provided.

The official documentation containing installation steps, tutorials, links to community is on OpenNMS wiki.

But let’s see how this looks like.

This is my test network with Juniper(Junos), Cisco(IOS XR) and Linux(Ubuntu) devices:

Once the devices are added, OpenNMS will build the topology:

Multiple links between devices are shown in the topology because OpenNMS uses information from multiple sources to figure out how the devices are connected, physical or logical.

Between XR-1 and MX-1, one link is for physical link, one link is for LLDP neighbourship and one link is for OSPF neighbourship.

The screenshot shows this better:

And this is consistent with the MX1 CLI output:

[edit]
root@MX1# run show ospf neighbor
Address          Interface              State     ID               Pri  Dead
10.10.10.2       ge-0/0/3.0             Full      1.1.1.3          128    34
10.10.11.2       ge-0/0/4.0             Full      1.1.1.1            1    33

[edit]
root@MX1# run show lldp neighbors
Local Interface    Parent Interface    Chassis Id          Port info          System Name
ge-0/0/3           -                   00:05:86:cf:02:c0   519                MX2
ge-0/0/4           -                   02:3d:30:56:a4:05   Gi0/0/0/0          XR-1

[edit]
root@MX1#

You can see all the node characteristics:

The resource graphs can display various information gathered through SNMP:

And you can see information about BGP:

Which again matches the XR-1 CLI output:

RP/0/0/CPU0:XR-1#show route bgp
Thu Jun 22 13:23:37.142 UTC

B    100.100.1.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.2.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.3.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.4.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.5.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.6.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.7.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.8.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.9.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.10.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.11.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.12.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.13.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.14.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.15.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.16.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.17.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.18.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.19.0/24 [200/0] via 1.1.1.3, 03:23:00
B    100.100.20.0/24 [200/0] via 1.1.1.3, 03:23:00
RP/0/0/CPU0:XR-1#

As with any NMS, you can see various statistics of the interfaces:

Once a node goes down, the topology will show this:

The alarms are triggered:

And this information is kept in the outages section:

And this is just some small part of what OpenNMS can do.

However, I do not find OpenNMS user-friendly as much I find LibreNMS.

The same server was used for both LibreNMS and OpenNMS and I noticed that OpenNMS webpages are loading a little bit slower.

I hope you found this interesting.

 

The following two tabs change content below.

Paris ARAU

Paris ARAU is a networking professional with strong background on routing and switching technologies. He is a holder of CCIE R&S and dual JNCIE(SP and ENT). The day to day work allows him to dive deeply in networking technologies. Part of the continuously training, he is focusing on Software Defined Network and cloud computing.

Comments

So empty here ... leave a comment!

Leave a Reply

Your email address will not be published. Required fields are marked *

Sidebar



%d bloggers like this: