search

influxdata / telegraf

Agent for collecting, processing, aggregating, and writing metrics, logs, and other arbitrary data.
https://influxdata.com/telegraf
MIT License
14.51k stars 5.56k forks source link

Support IPv6 in the ping plugin #2159

Closed kostasb closed 5 years ago

kostasb commented 7 years ago

Feature Request: Support IPv6 ping by adding a configuration option in the plugin to switch to using the ping6 tool instead of ping.

IPv6 ICMP is not supported by the ping tool.

ping6 ipv6.google.com
PING6(56=40+8+8 bytes) 2a02:214d:8225:4000:b932:d1e7:533d:be94 --> 2a00:1450:4016:804::200e
16 bytes from 2a00:1450:4016:804::200e, icmp_seq=0 hlim=56 time=43.345 ms

Reference:

The ping6 utility is intentionally separate from ping.

     There have been many discussions on why we separate ping6 and ping.
     Some people argued that it would be more convenient to uniform the ping
     command for both IPv4 and IPv6.  The followings are an answer to the
     request.

     From a developer's point of view: since the underling raw sockets API is
     totally different between IPv4 and IPv6, we would end up having two types
     of code base.  There would actually be less benefit to uniform the two
     commands into a single command from the developer's standpoint.

     From an operator's point of view: unlike ordinary network applications
     like remote login tools, we are usually aware of address family when
     using network management tools.  We do not just want to know the
     reachability to the host, but want to know the reachability to the host
     via a particular network protocol such as IPv6.  Thus, even if we had a
     unified ping command for both IPv4 and IPv6, we would usually type a
     -6 or -4 option (or something like those) to specify the particular
     address family.  This essentially means that we have two different
     commands.

source

danielnelson commented 7 years ago

We need to gather ping6 examples for Linux, BSD, Windows. Also interesting, on Debian ping6 is a symlink to ping which has a -6 option.

MarkMartinec commented 7 years ago

From an operator's point of view: unlike ordinary network applications like remote login tools, we are usually aware of address family when using network management tools. We do not just want to know the reachability to the host, but want to know the reachability to the host via a particular network protocol such as IPv6. Thus, even if we had a unified ping command for both IPv4 and IPv6, we would usually type a -6 or -4 option (or something like those) to specify the particular address family. This essentially means that we have two different commands.

That assumption is wrong, or better, it has been invalidated by pragmatic needs of users, and by time. A monitoring application or a user may not know the address family of the target address, it/he is often just interested in reachability of a target host. Even when one does indeed care about a specific address family, it is as easy as specifying a -4 or -6 option in a rare case where a target is specified as a DNS name (as opposed to an IP address) and has both an A as well as an AAAA address record.

Now consider the opposite: when a monitoring application is given a host name of a target (not its IP address). In order to determine whether to call ping or ping6, the application (or a script) has to perform a DNS lookup to collect addresses, and has to be aware of the connectivity capabilities of the monitoring host, to be able to find an intersection and choose which protocol to use. This complication is way above competences of some ad-hoc monitoring/testing script, and even beyond many dedicated monitoring applications, which just hand the burden of choice over to a user, washing hands and murmuring something about internal coding complications and different ICMP protocol numbers.

Even though icmp and icmp6 protocols use a different protocol number and differ in details, their purpose and functionality is pretty much the same (with icmp6 providing more functions, but keeping basic functions very close to icmp).

To summarize the choices of a protocol to use:

The world has moved on. Producers of network equipment have chosen a pragmatic approach years ago by providing a unified ping (and traceroute) in their gear, with options to override the automatic choice. This holds true for players like Cisco, Extreme Networks, MikroTik RouterOS, I believe also Juniper, and more.

Similarly, Microsoft did the same, the ping command in Windows 7/8/10 is a unified ping, with optional protocol override. (also the unified traceroute)

Luckily Linux has followed the lead, so in CentOS 7 / RHEL 7, Fedora 25 (probably in 24 as well), there is a unified ping with options -4 and -6, and for compatibility the ping6 is a link to it.

In OpenBSD 6.1 the ping and ping6 are the same file (hard link), although unfortunately it does not automatically chose the protocol by itself. Similarly in Ubuntu 16.10 the ping4 and ping6 are soft links to the same program.

Sorry about the rambling, I had to let it out. Now to the topic of options compatibility. I tried a couple of platforms, considering that the ping plugin to telegraf only cares about options -I, -i, -c, -s, -n, and -W, so here are my findings.

I tried: FreeBSD 11 (and 10, should be the same as MacOS), NetBSD 7.1, OpenBSD 6.1 (devel), Debian 8, Ubuntu 16.10, Fedora 25, CentOS 7, and Windows 10.

Interface to send ping from:

Interval at which to ping:

Number of pings to send:

Packet size (in bytes):

Numeric only:

The troublesome option is a ping timeout, which varies wildly:

As for the IPv4 vs. IPv6 override options on platforms which provide a unified ping:

Cisco IOS:

Summit ExtremeXOS:

MikroTik RouterOS:

Windows 10:

Fedora 25:

CentOS 7:

danielnelson commented 7 years ago

Obviously this is tricky since ping is many different programs. I think we could get closer if we allow the path to ping to be configured as well as letting the user pass a list of args. It would be similar to the proposal in #2505