Hello my friend,
Quite often, when we do the troubleshooting of our networks and systems, we want to figure out, which hosts are alive in the certain range. The quickest and the easiest way (though, not 100% accurate) is to run the ping against a specific range of IPs. There is a brilliant tool for this purpose, which is called fping.
2
3
4
5
retrieval system, or transmitted in any form or by any
means, electronic, mechanical or photocopying, recording,
or otherwise, for commercial purposes without the
prior permission of the author.
Can automation help to find issues in the network quickly?
All the time, when the outage is happening in the production environment, either with the network or server/application infrastructure, the race starts to restore the service as soon as possible. Automation is a key helper there.
In our trainings, the Live Network Automation Training (10 weeks) and Automation with Nornir (2 weeks), we explore a lot of real use cases, where the automation helps you to validate the state of you network and change it if necessary. You will learn the whole spectre of the automation approaches starting from the text-based automation used in the hyper scalers with the full configuration templated till the model-driven automation with NETCONF/RESTCONF/gNMI loaded with YANG data models for Cisco, Nokia, Arista and Cumulus. This knowledge comes with a lot of different exercises with direct console as well as Ansible/Python and Bash scripts. On top to that, you learn a lot of infrastructure skills such as building and managing Linux, KVM and Docker.
Moreover, we are running our trainings for 2 years already and constantly adopting them to the changes happening in the automation world. Master your automation skills.
Brief description
The fping is a must have tool in the toolkit of any system, support, or network engineer. It allows you quickly to check the liveness of:
- a single host provided as an argument
- a range of hosts (e.g., a subnet) provided as an argument
- a predefined set of hosts stored in a file
The good thing about fping is that it supports both IPv4 and IPv6 addresses, even in a single test, what makes it quite valuable for testing your environment as a whole.
Besides the direct results of the reachability test (telling if host/hosts are reachable or not), fping also allows you to measure the reachability with a certain constrains (e.g., max TTL, max response time, etc) and even to measure the latency.
Usage
Let’s take a look how you can benefit from using fping.
#1. Installation
The fping is available via package manager on all the *nix (Linux, Unix, Mac OS) platforms. Depending on the package manager available the installation the installation may vary.
For the Ubuntu/Debian (example from Raspberry PI):
For CentOS/RHEL 7 (replace yum to dnf for Fedora or CentOS 8):
For Mac OS it would depend on the installed package manager. For example, if you use brew, it would be:
The installation is very quick and right after it is completed, you can start with your tests.
#2. Simple tests
In the simplest scenario, the execution of the fping tests is very simple. You just need to type the fping address, where address is the IPv4 or IPv6 address of the host you are willing to test.
IPv4 test:
2
192.168.1.1 is alive
IPv6 test:
2
2a00:1450:4009:80d::200e is alive
Provided IPv6 address is one of the public IPv6 addresses of Google.com.
You may think that you can reach the same result with the ordinary ping and ping6 tools available in your Linux (CentOS, Debian, Ubuntu, Raspberry PI OS) or Max OS. And that would be absolutely true. Therefore, let’s take a look on more advanced cases, which form the real power of fping.
#3. Advanced tests
The first use case is the possibility to ping the range of the IP addresses, which can be provided either as a pair of starting_IP ending_IP addresses or as subnet/prefix with the key -g. This approach is available only for the IPv4 addresses only:
2
3
4
5
6
7
8
9
10
11
12
13
192.168.1.0: error while sending ping: Permission denied
192.168.1.1 is alive
192.168.1.34 is alive
192.168.1.86 is alive
192.168.1.212 is alive
192.168.1.236 is alive
192.168.1.255: error while sending ping: Permission denied
192.168.1.0: error while sending ping: Permission denied
ICMP Host Unreachable from 192.168.1.236 for ICMP Echo sent to 192.168.1.3
ICMP Host Unreachable from 192.168.1.236 for ICMP Echo sent to 192.168.1.2
!
! FURTHER OUTPUT IS TRUNCATED FOR BREVITY
You see in the output the list of the IP addresses, which are alive. For others, you will see the notification, that they are unreachable (the exact output may depend from platform to platform.
The second example of the same approach:
2
3
4
5
6
7
8
9
10
11
192.168.1.1 is alive
192.168.1.34 is alive
192.168.1.86 is alive
192.168.1.212 is alive
192.168.1.236 is alive
ICMP Host Unreachable from 192.168.1.236 for ICMP Echo sent to 192.168.1.4
ICMP Host Unreachable from 192.168.1.236 for ICMP Echo sent to 192.168.1.4
ICMP Host Unreachable from 192.168.1.236 for ICMP Echo sent to 192.168.1.3
!
! FURTHER OUTPUT IS TRUNCATED FOR BREVITY
As said, the method above unfortunately doesn’t work for IPv6. However, the fping allows to read the input from the text file, where the IP addresses are provided line by line. In this scenario, IP addresses can be both IPv4 and IPv6:
2
3
4
5
6
7
8
9
10
11
8.8.8.8
2a00:1450:4009:80d::200e
142.250.178.14
2a00:1450:4009:806::200e
$ fping -f test.txt
8.8.8.8 is alive
2a00:1450:4009:80d::200e is alive
142.250.178.14 is alive
2a00:1450:4009:806::200e is alive
fping allows you also to modify the output of what you see. You may reduce the noise level by adding two out of those three keys:
- -q (stands for quiet) will hide the individual results including both successful and not
- -a (stands for alive) will show the list of the live hosts even if -q is enabled
- -u (stands for unreachable) will show the list of the hosts, which are not responding even if -q is enabled.
Depending on your testing logic, you may want to use either “-q -a” or “-q -u” together. The following example shows the list of the reachable hosts:
2
3
4
5
192.168.1.1
192.168.1.86
192.168.1.212
192.168.1.236
And this example demonstrates only unreachable hosts:
2
3
4
5
6
192.168.1.2
192.168.1.3
192.168.1.4
!
! FURTHER OUTPUT IS TRUNCATED FOR BREVITY
You can also get some understanding about the latency between your host and your targets by adding the -e key:
2
3
4
5
6
192.168.1.1 (2.32 ms)
192.168.1.34 (43.6 ms)
192.168.1.86 (139 ms)
192.168.1.212 (115 ms)
192.168.1.236 (0.09 ms)
If you are interested, you can also print the aggregated statistics about the results of your reachability tests using the -s key:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
254 targets
5 alive
249 unreachable
0 unknown addresses
249 timeouts (waiting for response)
1001 ICMP Echos sent
5 ICMP Echo Replies received
988 other ICMP received
0.07 ms (min round trip time)
90.7 ms (avg round trip time)
265 ms (max round trip time)
11.846 sec (elapsed real time)
There are some more possible arguments, which allows you extend your capabilities for filtering. Read about them using -h key.
#4. Ideas for automation
Like other examples you have seen in these series, the fping can be perfectly integrated into the automation you use in troubleshooting. For example, you run the reachability test and then connect to the live hosts to test the HTTP/GRPC service or send the report with unreachable hosts over the mail towards the engineers on shift. The possibilities for automation are endless.
Take me to the examplesLessons learned
The biggest opening for me was that fping supports both IPv4 and IPv6 in a single test. It allowed me to create a set of the hosts I’m interested in testing using both address families. Relying the ordinary ping and ping6 tools, it could be a little annoying, when you need to do a lot of tests quickly, as it is very easy to do a typo by adding 6 for the IPv4 address or not adding 6 for IPv6 address.
Conclusion
Understanding of what is reachable and what not is one of the first steps in the troubleshooting of the service outage. One of questions we typically ask, if the only one host is not reachable, or the whole range. That is where the fping helps a lot. Moreover, doing the troubleshooting in an automated way could significantly decrease the time for the service restoration via the thorough analysis of your environment and giving you instant access to the valuable insights. Take care and good bye.
Support us
P.S.
If you have further questions or you need help with your networks, I’m happy to assist you, just send me message. Also don’t forget to share the article on your social media, if you like it.
BR,
Anton Karneliuk