After debugging why ssl_cert and http services checks still used IPv4 to reach hosts, even tho the librenms server should be fully IPv6 only.
I found that many nagios plugins relies on nmap to do it’s works, and thus it does not default to IPv6 (which it should, since IPv4 is now legacy)
The workaround here is to add -6 parameter to the individual service settings.
One way to improve this could be to detect udp6 setting for SNMP and add -6 by default. (or even better do our own detections, if DNS resolves any AAAA records, do -6, if any A records do A, meaning doing possibly multiple checks for each service)
Well then, make it explicit, and per RFC, prefer IPv6.
The current functionality is broken, happy to try and PR any update on this, but I think there needs to be some guidance on IPv6 in LNMS for the future.
There has been some movement on this front. Currently, LibreNMS relies on dependencies to handle IPv6 resolution properly. A lot of them don’t.
One way to fix this on the LibreNMS side would be to send IPs to the scripts it calls. But that has other complications. What if one service listens on IPv4, but not IPv6, if we only send the IPv6, it will not fall back to Ipv4 (as per happy eyeballs).
When we send just a hostname to a script, we don’t have very much control over how it resolves that hostname. But there is a lot that can go wrong if we only send an IP too.
Plugins != nagios plugins, it is for LibreNMS plugins.
mostly Agreed
But you can not send IPs, because you need to verify hostname for certs, but also http thru SNI headers etc.
But what I think should be done is for LMNS to be explicit for any nagios plugins, or where these discrepancies are found, so in the case of nagios, add explicit -6 or -4 to the commands (-4 and -6 seems to be universal for nagios)
The question is, how should the -6 and -4 be determined, probably by DNS lookups and checking for A vs AAAA records, if both exists, try both and report them separately?
But you probably also need some way to check if the host is v6 or v4 enabled, checking if route exists for the given protocol?
Yes, that is what I explained in OP that I did as a workaround.
So with that out of the way, how do we improve this experience so users don’t have to hunt sourcecode and try to figure out that they need to add a magic -6 in params?
Also consider the case of many many services defined, and now IPv6 is deployed, going thru, and changing all of these manually is a pain, at the same time, that is what you might want to have since there is no guarantee that the v6 and v4 address is on the same server.
Circling back to, maybe both should be shown, without the user having to do anything.
One issue I can see is that while many (or most) nagios plugins support the -6/-4 flags, it is not universal, so LibreNMS cannot know which ones to add this command line flag to.
I think the correct behaviour is that the nagios plugin should prefer IPv6 if neither -4 or -6 is specified. The nagios plugin(s) need fixing if this isn’t happening.