Network map device groups and customisation

[DBMandrake]

Hi Everyone,

I wonder if anyone has any advice on how to better optimise the network map in LibreNMS?

While it has so many other fantastic features that I have come to know and love, ironically the feature that pushed me to set up and try LibreNMS in the first place - automatically generated network maps, doesn’t work very well for me.

There are two basic options here - LLDP based auto-generation of network maps and MAC based auto-generation of network maps.

LLDP based ($config['network_map_items'] = array('xdp'); in config.php) does work pretty well, but has some limitations on a network where not all switches support LLDP.

Only approx half of our switches do, this means the map is both incomplete and in error, as having multiple switches which do support LLDP connected via a switch which doesn’t (and thus forwards LLDP packets on all ports) causes the network map to draw weird and incorrect loops. So the map is better than nothing but incomplete and a bit inaccurate in places.

Today I was trying to track down the exact interconnect topology of a number of switches which don’t support LLDP so I did it manually using data available in the FDB tables. I had three switches in one building which link back to the core switch in another building but I wasn’t sure if there was only one uplink (with the other two switches uplinked from the first) or multiple uplinks etc.

To figure out if there was one or two inter-building uplinks I checked the FDB table on the upstream core switch to see if the IP addresses of the three downstream switches appeared on only one port or whether they were spread across two ports - it turned out to be two ports, so from that I know there are two uplinks and the third switch was uplinked via one of the first two.

Then on each of the downstream switches I could check which port they see each other from and was able to work out the topology from that. So the information to work out the interconnection of the switches to a fairly high degree of confidence is available in the FDB tables if you want to do it manually.

From my reading the mac mode ( $config['network_map_items'] = array('mac'); ) should be able to automate this for me but here I run into a number of issues.

If I enable mac mode my main network map - previously a bit incomplete but still useful turns into a big unusable fur ball which has pretty much every device on the network including all clients, when all I want is the network backbone, eg switches:

It also runs at about 1 frame per 10 seconds.

Next I read about Device group maps - in the docs it says “Also you can Build Device Groups and those Device Groups can be drawn with Network Map.”

Sounds perfect. So I create a device group that is devices.type = network (which has only our ethernet switches in it) and view the device group for that and I get an improvement but it’s still a mess and includes lots of devices that aren’t switches in it:

The top centre of that new fur ball is a switch, with all the things coming off it being client devices like printers etc, while in the middle of the bottom group is the LibreNMS server itself. There are thick lines between switches and thin lines between servers. I don’t know what the significance of the thin lines are. It also shows a lot of small loops - that also don’t make sense as there aren’t any network loops.

So it seems that device group maps take all the devices in the group and show ALL other devices which those devices know about, rather than only drawing a map between devices in the device group, which is what I was hoping for based on the description?

So should device group maps show only devices in that group and their interconnections, (which would make the graph above a bug, since there shouldn’t be printers and servers on the graph at all) or is it expected to show many/all devices known about in the FDB tables in these devices? (which seems a bit pointless, as most devices will have most other devices in their FDB tables)

To make use of mac address correlation in device group maps I would have to leave mac enabled in config.php, but this makes the standard network map unusable.

Am I missing something here? All I’m trying to build is a network map that includes only the devices I’m interested in - only switches, or maybe switches and servers to see where those servers are plugged in.

At the moment that doesn’t seem to be possible. Anyone else have any luck with customising the network map or getting device group maps working in a reasonable way?

[DBMandrake]

Nobody else uses the network maps?

By the way I’m not sure why this got moved into Feature requests (where it’s likely to get less visibility among fellow users) when I’m asking for help to get an existing feature working properly, (or at least ascertain whether my understanding of how it should work is correct or not) and also reporting what seems to be a bug. (Device group maps include lots of devices that are not members of the device group…)

Neither of these are feature requests.

[rhinoau]

Gave up on the map ages ago as could never make good sense of it, but just found the configurator in the docs after another look:

Network Map - LibreNMS Docs

I can’t (or perhaps don’t know how to) get the interactive configuration to work/display, but I can work out from the example link some things like:

$config['network_map_vis_options'] = '{
  "layout": {
    "hierarchical": {
      "enabled": true
    },
   }
}';

Which does this which is a good start for further digging:

I have tried mac and xdp and always tend to get incorrect correlations/links, and loops, with all the links radiating from the main upstream device:

I’ve not had the time or priority to dig further, but I’ll keep looking at it more and see if there is anything I can figure out which may help us all.

In the future I will need to start walking long layer 2 switch chains which will continually change location, and also start pulling in Cisco REP topologies and building layout and topology health maps and state validation - more along the lines of pyATS Genie. If I end up hacking something together, it would make sense to try and do it via LibreNMS if I can figure out how!

[rhinoau]

Replying to myself, some further testing and in my cases - the loops and incorrect topology are using mac, and xdp works.

Here it is with default and hierarchical using device groups, I am lucky they are all Cisco with CDP enabled though:

Other devices and neighbour reporting variants result in nothing, despite having LLDP neighbours reporting correctly along with full and correct FDB tables visible in the web UI:

(mac/ip columns correct but omitted from screenshot)

[DBMandrake]

@rhinoau

I can’t (or perhaps don’t know how to) get the interactive configuration to work/display, but I can work out from the example link some things like:

$config['network_map_vis_options'] = '{
  "layout": {
    "hierarchical": {
      "enabled": true
    },
   }
}';

Which does this which is a good start for further digging:

Thanks! I’ll give the hierarchical setting a try to see how it looks.

I have tried mac and xdp and always tend to get incorrect correlations/links, and loops, with all the links radiating from the main upstream device:

@rhinoau

Replying to myself, some further testing and in my cases - the loops and incorrect topology are using mac, and xdp works.

Yes, I see the same weird loops and incorrect topology if I enable mac. With xdp alone the topology is correct provided all the switches support LLDP, however we have quite a few switches which don’t - not only do those not show up in an xdp only graph (as you would expect) you get really weird topology errors and loops if there is a switch which doesn’t support LLDP (and thus forwards LLDP on all ports) which is connecting multiple other switches which do. (As each one of those other LLDP switches is unaware of the intervening switch)

LibreNMS’s network drawing algorithm seems to get confused if a switch reports multiple LLDP partners on a single port, which happens if an intervening switch does not support LLDP.

@rhinoau

Other devices and neighbour reporting variants result in nothing, despite having LLDP neighbours reporting correctly along with full and correct FDB tables visible in the web UI:

I’ve noticed that for an LLDP link to appear in the network map, BOTH devices at each end of the link must report LLDP data via SNMP.

All our Meraki wireless access ports support LLDP, thus if I look at LLDP remote link partners directly on a switch which has an access point is connected, I can see the Name, IP address, etc of the Access point listed, and via the interface for the access point I can see the name/ip/port of the switch reported, so there is definitely bi-directional LLDP going on between the switch and Access point.

However the access points don’t show up in the xdp network map despite the access points being devices in LibreNMS and being polled with SNMP - presumably the reason is that while the AP’s report interface statistics via LLDP they don’t report LLDP via SNMP, so LibreNMS does not “connect the dots” and display the link.

They also aren’t listed under “ports” in the switch which is a shame. It’s a shame there isn’t a configuration setting to allow all LLDP remote partner information to be listed in the ports for a switch, not just devices that are also monitored via LibreNMS and report their LLDP state via SNMP.

[rhinoau]

@DBMandrake

All our Meraki wireless access ports support LLDP, thus if I look at LLDP remote link partners directly on a switch which has an access point is connected, I can see the Name, IP address, etc of the Access point listed, and via the interface for the access point I can see the name/ip/port of the switch reported, so there is definitely bi-directional LLDP going on between the switch and Access point.

On the Meraki side, I’ve previous used SolarWinds and a plugin which talks to their cloud dashboard API - which was very effective. Integrating via the API may be a way in the future, but would be a lot of work to integrate to LibreNMS. I’ve left that world behind, but feel your pain!

I have a few MikroTik devices around which report all neighbours on each device via broadcast discovery/forwarding. If you don’t dig deep enough on a Cisco switch upstream it can lead you astray, and justly via the ‘mac’ network mapping in LibreNMS, it causes incorrect topology.

I’m hoping I’ll soon be technically enlightened, motivated and showered in copious free time to start working on this in some way