Linux for Network Engineers: How to use fping

By February 10, 2021Linux

To summarize my coverage of the ping-verse, so far on the NetBeez blog, I have covered four different utilities: ping, nping, prettyping, gping. In this post, I am continuing with fping. And there is even more ping goodness coming your way soon…

Fping stands for fast ping, and its main differentiation with the regular ping is that it gives you the ability to scan a list of hosts (either coming from a file, an IP range, or a subnet) and tells you which ones are alive. Other than that, it can do pretty much everything the good old ‘original’ ping can do in terms of latency, configuring payload, IPv4/IPv6, etc.

Installation

Fping is available to install on Debian based linux with:

sudo apt-get install fping

However, I’d recommend to follow the instructions on the project’s github page here in order to download and install the latest version. Here is how I installed version 5.0:

git clone https://github.com/schweikert/fping.git
cd fping/
./autogen.sh
./configure
make
sudo make install

Basic Usage

The most basic task fping can do is tell you if a host is alive or not, as follows:

$ sudo fping google.com
google.com is alive

As you can see it doesn’t even return the latency. Note that you have to run fping as a root user.

To get the continuous pinging functionality that the regular ping does by default you have to add the-l flag as follows:

$ sudo fping -l google.com
google.com : [0], 64 bytes, 6.94 ms (6.94 avg, 0% loss)
google.com : [1], 64 bytes, 6.91 ms (6.92 avg, 0% loss)
google.com : [2], 64 bytes, 6.94 ms (6.93 avg, 0% loss)
google.com : [3], 64 bytes, 8.29 ms (7.27 avg, 0% loss)
google.com : [4], 64 bytes, 6.92 ms (7.20 avg, 0% loss)

The reason fping is called “fast” is because you can specify the interval between the ping packets down to the millisecond with the-p flag. To demonstrate this I am adding the-D option that prints the timestamp of each packet sent:

$ sudo fping -D -l -p 20 google.com
[1612995038.31063] google.com : [0], 64 bytes, 7.87 ms (7.87 avg, 0% loss)
[1612995038.31905] google.com : [1], 64 bytes, 6.23 ms (7.05 avg, 0% loss)
[1612995038.32906] google.com : [2], 64 bytes, 6.15 ms (6.75 avg, 0% loss)
[1612995038.34371] google.com : [3], 64 bytes, 6.14 ms (6.60 avg, 0% loss)
[1612995038.36380] google.com : [4], 64 bytes, 6.22 ms (6.52 avg, 0% loss)
[1612995038.38376] google.com : [5], 64 bytes, 6.18 ms (6.47 avg, 0% loss)
[1612995038.40372] google.com : [6], 64 bytes, 6.14 ms (6.42 avg, 0% loss)
[1612995038.42370] google.com : [7], 64 bytes, 6.12 ms (6.38 avg, 0% loss)
[1612995038.44356] google.com : [8], 64 bytes, 5.99 ms (6.34 avg, 0% loss)
[1612995038.46358] google.com : [9], 64 bytes, 6.01 ms (6.31 avg, 0% loss)
[1612995038.48356] google.com : [10], 64 bytes, 5.99 ms (6.28 avg, 0% loss)
[1612995038.50345] google.com : [11], 64 bytes, 5.87 ms (6.24 avg, 0% loss)
[1612995038.52351] google.com : [12], 64 bytes, 5.94 ms (6.22 avg, 0% loss)
[1612995038.55759] google.com : [13], timed out (6.22 avg, 7% loss)
[1612995038.57774] google.com : [14], timed out (6.22 avg, 13% loss)
[1612995038.59770] google.com : [15], timed out (6.22 avg, 18% loss)
[1612995038.61764] google.com : [16], timed out (6.22 avg, 23% loss)
.
.
.
[1612995044.81775] google.com : [326], timed out (6.22 avg, 96% loss)
[1612995044.83762] google.com : [327], timed out (6.22 avg, 96% loss)
[1612995044.85775] google.com : [328], timed out (6.22 avg, 96% loss)
[1612995044.87762] google.com : [329], timed out (6.22 avg, 96% loss)
^C
google.com : xmt/rcv/%loss = 330/13/96%, min/avg/max = 5.87/6.22/7.87

In this example, I am pinging google.com with a period of 20 milliseconds. The interesting observation is that the first ten or so packets get a response, and after that google.com stops responding. My assumption is that if Google detects such a low pinging period, it rate limits the responses to avoid DDoS attacks. If you try the same ping with a local host in your network, you won’t see this behavior. Keep in mind that when you use the -p flag the timeout time is less or equal to the period (e.g. if you sed a period of 1 millisecond and the host doesn’t respond within 1 millisecond, then that ping test will be considered as a failed one).

Host Scanning

For me, one of the most useful features of fping is the quick host discovery within a subnet or within an IP range with the generate-list option -g. Here is an example.

$ sudo fping -g  172.31.0.0/24
172.31.0.1 is alive
172.31.0.14 is alive
172.31.0.16 is alive
172.31.0.17 is alive
172.31.0.18 is alive
172.31.0.21 is alive
172.31.0.25 is alive
172.31.0.38 is alive
172.31.0.39 is alive
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.2
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.2
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.2
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.2
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.3
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.3
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.3
.
.
.
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.252
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.253
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.253
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.253
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.253
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.254
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.254
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.254
ICMP Host Unreachable from 172.31.0.25 for ICMP Echo sent to 172.31.0.254
172.31.0.2 is unreachable
172.31.0.3 is unreachable
172.31.0.4 is unreachable
172.31.0.5 is unreachable
172.31.0.6 is unreachable
172.31.0.7 is unreachable
172.31.0.8 is unreachable
172.31.0.9 is unreachable
.
.
.
172.31.0.250 is unreachable
172.31.0.251 is unreachable
172.31.0.252 is unreachable
172.31.0.253 is unreachable
172.31.0.254 is unreachable

I find this output to be too verbose. Usually, I am interested in discovering all pingable hosts in a subnet, and here is how I do it.

$ sudo fping -q -a -s -g 172.31.0.0/24
172.31.0.1
172.31.0.14
172.31.0.16
172.31.0.17
172.31.0.18
172.31.0.21
172.31.0.25
172.31.0.38
172.31.0.39
172.31.0.183
172.31.0.188
172.31.0.222
172.31.0.223
172.31.0.243

     254 targets
      14 alive
     240 unreachable
       0 unknown addresses

     960 timeouts (waiting for response)
     974 ICMP Echos sent
      14 ICMP Echo Replies received
     960 other ICMP received

 0.043 ms (min round trip time)
 0.399 ms (avg round trip time)
 0.906 ms (max round trip time)
        9.697 sec (elapsed real time)

This uses the quiet flag-q, only targets that are alive with -a, and also prints a summary of statistics at the end with-s.

Additionally, fping can take as input a file that has a list of target hosts. As an example, I have the following file

$ cat ping-hosts.txt
google.com
one.one.one.one
cnn.com
cmu.edu

And I can ask fping to ping all these hosts to check if they are alive with:

$ sudo fping -f ping-hosts.txt
[sudo] password for panos:
google.com is alive
one.one.one.one is alive
cnn.com is alive
cmu.edu is alive

Or I can run continuous ping tests with:

$ sudo fping -l -f ping-hosts.txt
google.com      : [0], 64 bytes, 6.89 ms (6.89 avg, 0% loss)
one.one.one.one : [0], 64 bytes, 7.11 ms (7.11 avg, 0% loss)
cnn.com         : [0], 64 bytes, 9.20 ms (9.20 avg, 0% loss)
cmu.edu         : [0], 64 bytes, 62.8 ms (62.8 avg, 0% loss)
google.com      : [1], 64 bytes, 6.81 ms (6.85 avg, 0% loss)
one.one.one.one : [1], 64 bytes, 6.51 ms (6.81 avg, 0% loss)
cnn.com         : [1], 64 bytes, 8.47 ms (8.84 avg, 0% loss)
cmu.edu         : [1], 64 bytes, 62.2 ms (62.5 avg, 0% loss)
google.com      : [2], 64 bytes, 7.88 ms (7.19 avg, 0% loss)
one.one.one.one : [2], 64 bytes, 7.25 ms (6.96 avg, 0% loss)
cnn.com         : [2], 64 bytes, 9.09 ms (8.92 avg, 0% loss)
cmu.edu         : [2], 64 bytes, 62.5 ms (62.5 avg, 0% loss)
google.com      : [3], 64 bytes, 6.74 ms (7.08 avg, 0% loss)
one.one.one.one : [3], 64 bytes, 6.35 ms (6.80 avg, 0% loss)
cnn.com         : [3], 64 bytes, 8.85 ms (8.90 avg, 0% loss)
cmu.edu         : [3], 64 bytes, 62.6 ms (62.5 avg, 0% loss)

google.com      : xmt/rcv/%loss = 4/4/0%, min/avg/max = 6.74/7.08/7.88
one.one.one.one : xmt/rcv/%loss = 4/4/0%, min/avg/max = 6.35/6.80/7.25
cnn.com         : xmt/rcv/%loss = 4/4/0%, min/avg/max = 8.47/8.90/9.20
cmu.edu         : xmt/rcv/%loss = 4/4/0%, min/avg/max = 62.2/62.5/62.8

Note that when fping sends ICMP requests to multiple hosts, it does that in parallel without waiting for one host to respond and then move to the next one.

Fping has several other options, but not too many to be overwhelming. They are available underfping --help.

netbeez-monthly-webinar