jmanteau

Mon coin de toile - A piece of Web

The Facets of Ping

Posted: Mar 3, 2022

This article aims to provide you different ways and tools around “Ping”. By ping, I mean the tooling using icmp to help test, solve and troubleshoot connectivity issues. The section has been divided by “use cases” where the differents tools will be presented to solve a specific problem.

My personal tools of trade are : ping, fping, mtr and mtraceroute. Others tools exists and are listed in the section Others Tools.

Summary of use cases:

Hosts used as examples below

A file used in input for several tools is generated with:

$ cat <<EOF > input.txt
1.1.1.1
1.0.0.1
8.8.8.8
8.8.4.4
4.2.2.1
4.2.2.2
example.com
131.107.255.255
EOF

Determine the user MTU (IP MTU)

You know that the path is allowing a max MTU lower than what you expect on the path. You need to find it. The command below let you iterate between two values until you find one where it’s not answering anymore. The latest alive is the good one !

ping -D -g 1470 -G 1485 -h 1 -i 0.1 1.1.1.1
PING 1.1.1.1 (1.1.1.1): (1470 ... 1485) data bytes
1478 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=2.136 ms
1479 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=2.466 ms
1480 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=2.420 ms
ping: sendto: Message too long
ping: sendto: Message too long

For this use case, we are using an Ethernet underlay (see here in case of LTE or 5G) and we have 1500 of IP MTU (1480 of ICMP + 20 for IP Headers)

8faec7e77a1557af05fc8ad77b7885d8.png

Goto Summary

Check if many hosts are alive

Fping

fping is a program to send ICMP echo probes to network hosts, similar to ping, but much better performing when pinging multiple hosts. fping has a very long history: Roland Schemers did publish a first version of it in 1992 and it has established itself since then as a standard tool for network diagnostics and statistics.

A simple fping -f input.txt would work but you can tune it a little bit faster with:

   -i, --interval=MSEC  interval between sending ping packets (default: 1 ms)
   -r, --retry=N      number of retries (default: 3)
❯ cat input.txt
1.1.1.1
1.0.0.1
8.8.8.8
8.8.4.4
4.2.2.1
4.2.2.2
example.com
131.107.255.255
165.204.204.242

❯ fping  -r 1 -f input.txt                                                                                                                                                          
1.1.1.1 is alive
8.8.8.8 is alive
1.0.0.1 is alive
8.8.4.4 is alive
4.2.2.1 is alive
4.2.2.2 is alive
example.com is alive
131.107.255.255 is unreachable
165.204.204.242 is unreachable

You can play with the options

   -a, --alive        show targets that are alive
   -u, --unreach      show targets that are unreachable

to only print the alive or unreacheable hosts (useful when pinging large numbers of hosts during a migration)

❯ fping -f input.txt -u
131.107.255.255
165.204.204.242

❯ fping -f input.txt -a
1.1.1.1
1.0.0.1
8.8.8.8
8.8.4.4
4.2.2.1
4.2.2.2
example.com

Bash and Ping

If you don’t have ping installed, the poor man’s tool (but always available) is a simple bash script

$ cat << 'EOF' > massping.sh
#!/bin/bash

argc=$#
if [ $# -lt 1 ]
then
   echo "Usage: $0 <ip-list-file>"
   exit 1
fi

hosts=$1

function customping
{
  ping -c 1 -W 1 $1 >/dev/null 2>&1 && echo "$1 is up" || echo "$1 is down"
#  sleep 0.01s
}


DEFAULT_NO_OF_PROC=8
noofproc=$DEFAULT_NO_OF_PROC

if [ -n "$2" ] #user-set no. of process instead of default
then
  noofproc=$2
  echo "Max processes: $noofproc"
fi

while true
do
  echo ''
  date +%H:%M:%S
  export -f customping && cat $hosts | xargs -n 1 -P $noofproc -I{} bash -c 'customping {}' \;
  sleep 1
done

EOF
❯ bash massping.sh input.txt                                                                  
21:59:12
1.1.1.1 is up
8.8.8.8 is up
1.0.0.1 is up
8.8.4.4 is up
4.2.2.1 is up
4.2.2.2 is up
example.com is up
131.107.255.255 is down

21:59:14
1.1.1.1 is up
1.0.0.1 is up
8.8.8.8 is up
8.8.4.4 is up
4.2.2.1 is up
4.2.2.2 is up
example.com is up
131.107.255.255 is down

21:59:16
1.1.1.1 is up
^C

Goto Summary

Check the recovery time (failover, cut, recovery, roaming, etc)

The reason fping is called “fast” is because you can specify the interval between the ping packets down to the millisecond.

We use this to do a continuous ping and calculate the “cut time”.

I’m simulating a small cut on a local target with ìp l set dev ens33 down && sleep 0.04 && ip l set dev ens33 up.

We will use the fping options:

   -l, --loop         loop mode: send pings forever
   -p, --period=MSEC  interval between ping packets to one target (in ms)
                      (in loop and count modes, default: 1000 ms)
   -D, --timestamp    print timestamp before each output line                  
   -o, --outage       show the accumulated outage time (lost packets * packet interval)

Here we ping continuously every 10ms and print the timestamp at each packet and asked for the cumulated outage time at the end. We can still calculate the individual cut time by using the timestamp.

❯ fping 172.16.181.137 -l -p 10 -D -o                                                                                                                                                     
[557843.24942] 172.16.181.137 : [0], 64 bytes, 0.335 ms (0.335 avg, 0% loss)
[557843.25979] 172.16.181.137 : [1], 64 bytes, 0.244 ms (0.289 avg, 0% loss)
[557843.27067] 172.16.181.137 : [2], 64 bytes, 0.233 ms (0.271 avg, 0% loss)
[...]
[557844.13419] 172.16.181.137 : [80], 64 bytes, 0.215 ms (0.476 avg, 0% loss)
[557844.14629] 172.16.181.137 : [81], 64 bytes, 0.698 ms (0.479 avg, 0% loss)
[557844.15593] 172.16.181.137 : [82], 64 bytes, 0.241 ms (0.476 avg, 0% loss)
[557844.17629] 172.16.181.137 : [83], timed out (0.476 avg, 1% loss)
[557844.18682] 172.16.181.137 : [84], timed out (0.476 avg, 2% loss)
[557844.19702] 172.16.181.137 : [85], timed out (0.476 avg, 3% loss)
[557844.20725] 172.16.181.137 : [86], timed out (0.476 avg, 4% loss)
[557844.21926] 172.16.181.137 : [87], timed out (0.476 avg, 5% loss)
[557844.22999] 172.16.181.137 : [88], timed out (0.476 avg, 6% loss)
[557844.24045] 172.16.181.137 : [89], timed out (0.476 avg, 7% loss)
[557844.25207] 172.16.181.137 : [90], timed out (0.476 avg, 8% loss)
[557844.26298] 172.16.181.137 : [91], timed out (0.476 avg, 9% loss)
[557844.27391] 172.16.181.137 : [92], timed out (0.476 avg, 10% loss)
[557844.28457] 172.16.181.137 : [93], timed out (0.476 avg, 11% loss)
[557844.29672] 172.16.181.137 : [94], timed out (0.476 avg, 12% loss)
[557844.30889] 172.16.181.137 : [95], timed out (0.476 avg, 13% loss)
[557844.30947] 172.16.181.137 : [96], 64 bytes, 0.558 ms (0.477 avg, 13% loss)
[557844.32100] 172.16.181.137 : [97], 64 bytes, 0.232 ms (0.474 avg, 13% loss)
[557844.33195] 172.16.181.137 : [98], 64 bytes, 0.486 ms (0.474 avg, 13% loss)
[...]
[557845.13565] 172.16.181.137 : [171], 64 bytes, 0.594 ms (0.531 avg, 7% loss)
^C
172.16.181.137 : xmt/rcv/%loss = 172/159/7%, outage(ms) = 130, min/avg/max = 0.212/0.531/4.99

You can see the time it took to shut/unshut either with calculating the diff of the timestamp or with the cumulative outage time calculated by fping at the end.

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).

You can adjust this behaviour with the option:

   -t, --timeout=MSEC individual target initial timeout (default: 500 ms,
                      except with -l/-c/-C, where it's the -p period up to 2000 ms)

Example with sending packet every ms but changing the timeout:

❯ fping -l 192.168.1.1 -p 1 -D -t 3                                                                                                                                                       
[558096.44057] 192.168.1.1 : [0], timed out (NaN avg, 100% loss)
[...]
[558096.65789] 192.168.1.1 : [20], timed out (NaN avg, 100% loss)
[558096.66834] 192.168.1.1 : [21], timed out (NaN avg, 100% loss)
[558096.67823] 192.168.1.1 : [22], 64 bytes, 2.92 ms (2.92 avg, 95% loss)
[558096.68953] 192.168.1.1 : [23], timed out (2.92 avg, 95% loss)
[558096.69938] 192.168.1.1 : [24], 64 bytes, 2.78 ms (2.85 avg, 92% loss)
[558096.71198] 192.168.1.1 : [25], timed out (2.85 avg, 92% loss)
[558096.72292] 192.168.1.1 : [26], timed out (2.85 avg, 92% loss)
[558096.73393] 192.168.1.1 : [27], timed out (2.85 avg, 92% loss)
[558096.74474] 192.168.1.1 : [28], 64 bytes, 2.76 ms (2.82 avg, 89% loss)
[558096.75631] 192.168.1.1 : [29], timed out (2.82 avg, 90% loss)
[558096.76660] 192.168.1.1 : [30], 64 bytes, 2.95 ms (2.85 avg, 87% loss)
[558096.77725] 192.168.1.1 : [31], timed out (2.85 avg, 87% loss)
[...]
[558098.09303] 192.168.1.1 : [153], timed out (2.86 avg, 87% loss)
[558098.10365] 192.168.1.1 : [154], timed out (2.86 avg, 87% loss)
[558098.11418] 192.168.1.1 : [155], timed out (2.86 avg, 87% loss)
[558098.12540] 192.168.1.1 : [156], timed out (2.86 avg, 87% loss)
[558098.13637] 192.168.1.1 : [157], timed out (2.86 avg, 87% loss)
[558098.14721] 192.168.1.1 : [158], timed out (2.86 avg, 88% loss)
^C
192.168.1.1 : xmt/rcv/%loss = 159/19/88%, min/avg/max = 2.63/2.86/2.98

❯ fping -l 192.168.1.1 -p 1 -D -t 20                                                                                                                                                      
[558055.99775] 192.168.1.1 : [0], 64 bytes, 2.03 ms (2.03 avg, 0% loss)
[558056.00885] 192.168.1.1 : [1], 64 bytes, 2.07 ms (2.05 avg, 0% loss)
[...]
[558057.45439] 192.168.1.1 : [135], 64 bytes, 3.77 ms (4.43 avg, 0% loss)
[558057.46721] 192.168.1.1 : [136], 64 bytes, 5.69 ms (4.44 avg, 0% loss)
[558057.47837] 192.168.1.1 : [137], 64 bytes, 5.79 ms (4.45 avg, 0% loss)
^C
192.168.1.1 : xmt/rcv/%loss = 138/138/0%, min/avg/max = 2.03/4.45/11.5

Goto Summary

Check the latency toward one host over time

ping

For eye balling a latency, ping is the easiest way:

❯ ping 1.1.1.1                                                                                                    ─╯
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=64 time=4.213 ms
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=1.573 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=1.803 ms
64 bytes from 1.1.1.1: icmp_seq=3 ttl=64 time=3.278 ms
64 bytes from 1.1.1.1: icmp_seq=4 ttl=64 time=2.314 ms
64 bytes from 1.1.1.1: icmp_seq=5 ttl=64 time=21.072 ms
64 bytes from 1.1.1.1: icmp_seq=6 ttl=64 time=4.648 ms
64 bytes from 1.1.1.1: icmp_seq=7 ttl=64 time=2.283 ms

mtr

The MTR (My Traceroute) network monitor combines Ping and Traceroute with the availability measuring capabilities of Ping with the hop-to-hop analysis of Traceroute. MTR uses ICMP packets to measure the availability of devices and the length of time taken to travel from hop to hop.

MTR records packet loss and jitter as well. MTR thus measures the quality of a connection time it takes to complete a transfer and the percentage of packets lost in transit.

34ab42c718ffd97f766af31ce5fa1c7b.png

You can use D to change the graphical aspect:

image-20220303131513618

gping

Ping, but with a graph.

While you can use a standard ping and estimate the latency, https://github.com/orf/gping provide a nice CLI live graphical output.

200766e39c239cf9b1d22689c8df495c.png

Goto Summary

Check the path toward the host

A network path refers to the sequence of network devices a packet passes through in order to reach its destination.

Traceroute

Traceroute or Tracert is a valuable tool for recording the response delays and routing loops existing in a network pathway across packet-switched nodes. The device records the complete path of a network request between two network resources or connections.

Don’t use traceroute as “proof” for packet loss. The only thing traceroute can tell you is pathing. If you’re very lucky, sometimes it might show where the packet loss is on a forward/reverse path.

In 2009 at NANOG 47 Richard A Steenbergen (aka RAS) gave a talk titled: “A Practical Guide to (Correctly) Troubleshooting with Traceroute”.

This presentation is very thorough and breaks down how the tool works, how routers (and their interfaces react), how to interpret the results, and as a result how to use Traceroute to properly troubleshoot. I cannot recommend this presentation highly enough.

Here is the 2020 updated one: 20201020_Steenbergen_Troubleshooting_With_Traceroute_v1.pdf

I usually run traceroute on Mac with -P UDP which is faster to complete than the standard ICMP one

❯ traceroute -P UDP example.com
traceroute to example.com (93.184.216.34), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  4.318 ms  7.620 ms  11.550 ms
 2  xxxxxxx (xxxxxxxxx)  9.850 ms  16.785 ms  18.249 ms
 3  ae116-0.nctou201.rbci.orange.net (193.249.214.94)  22.149 ms  19.348 ms  8.230 ms
 4  ae43-0.nipoi201.rbci.orange.net (193.252.160.49)  12.853 ms  20.822 ms  16.848 ms
 5  193.252.137.18 (193.252.137.18)  28.647 ms  20.889 ms  19.272 ms
 6  prs-b3-link.ip.twelve99.net (62.115.171.226)  42.218 ms  16.209 ms  23.292 ms
 7  prs-bb1-link.ip.twelve99.net (62.115.118.58)  103.897 ms  98.953 ms
    prs-bb2-link.ip.twelve99.net (62.115.118.62)  99.454 ms
 8  rest-bb1-link.ip.twelve99.net (62.115.122.159)  122.924 ms
    ash-bb2-link.ip.twelve99.net (62.115.112.242)  115.030 ms
    ldn-bb1-link.ip.twelve99.net (62.115.135.24)  98.944 ms
 9  ash-b2-link.ip.twelve99.net (62.115.123.123)  100.320 ms  100.254 ms
    ash-b2-link.ip.twelve99.net (62.115.123.125)  171.338 ms
10  verizon-ic342246-ash-b2.ip.twelve99-cust.net (62.115.175.71)  99.813 ms  99.880 ms  104.520 ms
11  ae-65.core1.dcb.edgecastcdn.net (152.195.64.129)  107.839 ms
    ae-66.core1.dcb.edgecastcdn.net (152.195.65.129)  98.123 ms
    ash-b2-link.ip.twelve99.net (62.115.123.125)  101.752 ms
12  93.184.216.34 (93.184.216.34)  97.986 ms  99.057 ms  107.525 ms
13  93.184.216.34 (93.184.216.34)  99.361 ms  106.103 ms  103.944 ms

MTR

mtr combines the functionality of the ‘traceroute’ and ‘ping’ programs in a single network diagnostic tool.

As mtr starts, it investigates the network connection between the host mtr runs on and a user-specified destination host. After it determines the address of each network hop between the machines, it sends a sequence ICMP ECHO requests to each one to determine the quality of the link to each machine. As it does this, it prints running statistics about each machine.

Like traceroute, MTR can use ICMP or UDP for outgoing packets but relies on ICMP for return (Type 11: Time Exceeded) packets.

MTR is fast compared to trace route. For “standard usage” of traceroute, I would recommand mtr when available.

Reporting (ASCII output)

MTR execute by default in a ncurses like CLI with real time refresh. You can ask for an ASCII output with:

❯ mtr --report 8.8.8.8                                                                                            
Start: 2022-03-03T13:24:12+0100
HOST: LOCAL                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%    10    3.7   4.8   3.7   7.5   1.4
  2.|-- 90.20.127.232              0.0%    10    5.2   6.8   5.0  11.8   2.2
  3.|-- ae116-0.ncxxx201.rbci.ora  0.0%    10    5.5   6.4   5.5   8.8   1.0
  4.|-- ae43-0.nipoi201.rbci.oran  0.0%    10   11.3  12.1  11.2  14.5   1.0
  5.|-- ae40-0.nipoi202.rbci.oran  0.0%    10   12.7  14.3  12.1  20.3   2.6
  6.|-- 193.252.137.14             0.0%    10   19.3  19.4  18.2  21.9   1.2
  7.|-- 72.14.210.158              0.0%    10   18.4  20.3  18.1  24.4   2.2
  8.|-- 72.14.236.91              20.0%    10   22.6  26.6  21.0  52.1  10.5
  9.|-- 142.250.224.95             0.0%    10   20.8  22.7  18.3  28.9   3.2
        209.85.244.155
        142.250.234.43
        108.170.234.51
        108.170.236.97
        216.239.48.151
        216.239.48.143
 10.|-- dns.google                 0.0%    10   17.5  19.1  17.0  27.6   3.4

UDP/TCP (instead of ICMP)

By default, mtr uses ICMP. You can ask it to use UDP with -u or TCP with -T and specify a port with -P (by default, it starts at 33000 and goes up for UDP and use 80 for TCP )

Even if UDP or TCP packet are sent on outgoing packets, mtr relies on ICMP for return (Type 11: Time Exceeded) packets.

❯ mtr -u 8.8.8.8 -P 53 --report                                                                           
Start: 2022-03-03T13:31:06+0100
HOST: XXXXXXXXXXXXXX               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%    10    7.2   6.3   3.8   9.4   1.7
  2.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- xxxxxx                     0.0%    10    5.2   9.5   5.0  26.6   6.4
  4.|-- ae43-0.nipoi201.rbci.oran  0.0%    10   11.5  14.2  11.4  22.9   3.7
  5.|-- ae40-0.nipoi202.rbci.oran  0.0%    10   13.1  13.4  11.7  17.3   2.1
  6.|-- 193.252.137.14            10.0%    10   19.0  23.9  19.0  56.2  12.2
  7.|-- 72.14.202.232              0.0%    10   19.2  20.1  18.5  27.0   2.6
        72.14.210.158
        google-45.gw.opentransit.net
        74.125.50.250
        google-46.gw.opentransit.net
        72.14.198.18
        72.14.218.40
        72.14.202.100
  8.|-- 72.14.235.25               0.0%    10   19.2  20.3  17.4  25.6   2.2
        108.170.244.225
        72.14.236.91
        108.170.244.161
        72.14.233.195
        209.85.255.139
        108.170.235.161
  9.|-- 64.233.174.93              0.0%    10   19.6  20.1  19.0  23.3   1.2
        216.239.59.209
        142.251.49.135
        64.233.174.175
        66.249.94.105
        108.170.234.51
        216.239.48.139
        216.239.48.45
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
❯ mtr google.com -T -P 443 --report                                                                                                                                    
Start: 2022-03-03T13:41:58+0100
HOST: xxxxx                        Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%    10    4.9   4.6   1.9  10.5   2.6
  2.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  3.|-- ae116-0.nctou201.rbci.ora  0.0%    10    6.0   6.1   3.7   9.9   2.3
  4.|-- ae43-0.nipoi201.rbci.oran  0.0%    10   13.6  11.4  10.1  14.0   1.3
  5.|-- ae40-0.nipoi202.rbci.oran  0.0%    10   12.3  11.8  10.3  16.2   1.7
  6.|-- 193.252.137.14             0.0%    10   21.3  20.9  17.5  31.0   3.9
  7.|-- google-45.gw.opentransit.  0.0%    10   24.8  20.4  16.5  32.7   4.9
        72.14.210.158
        74.125.50.250
        72.14.218.40
        google-46.gw.opentransit.net
        74.125.147.10
  8.|-- 72.14.233.195              0.0%    10   28.4  21.9  15.2  28.4   3.8
        72.14.235.25
        108.170.244.193
        108.170.235.161
        72.14.236.137
  9.|-- 64.233.174.93              0.0%    10   16.3  19.2  15.4  23.7   2.8
        64.233.174.49
 10.|-- par21s05-in-f14.1e100.net  0.0%    10   16.8  22.0  16.8  40.4   7.3

You can add more details in the output such as the IP (in addition of the DNS name) or the AS numbers.

 -z, --aslookup             display AS number
 -b, --show-ips             show IP numbers and host names
 -w, --report-wide          output wide report 

The -w is needed for the show-ips option instead of the -r/--report.

❯ mtr example.com -bzw
Start: 2022-03-03T13:52:12+0100
HOST: xxxxx                                                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS???    192.168.1.1                                                      0.0%    10    4.0   4.9   3.0  10.1   2.7
  2. AS???    xxxxx                                                            0.0%    10    8.0   6.2   4.5  11.4   2.2
  3. AS???    xxxxx     xxxxx                                                  0.0%    10    6.8   8.5   4.8  22.5   5.5
  4. AS???    ae43-0.nipoi201.rbci.orange.net (193.252.160.49)                 0.0%    10   13.5  12.6  10.3  17.7   2.2
  5. AS???    193.252.137.18                                                  50.0%    10   18.2  15.7  14.6  18.2   1.5
  6. AS1299   prs-b3-link.ip.twelve99.net (62.115.171.226)                    60.0%    10   17.7  17.0  16.0  18.0   1.0
  7. AS1299   prs-bb2-link.ip.twelve99.net (62.115.118.62)                     0.0%    10   94.0  95.4  92.8 103.2   3.4
  8. AS1299   rest-bb1-link.ip.twelve99.net (62.115.122.159)                   0.0%    10   93.8  94.2  92.6  96.5   1.4
  9. AS1299   ash-b2-link.ip.twelve99.net (62.115.123.123)                     0.0%    10   94.1  95.4  92.4 102.8   3.4
 10. AS1299   verizon-ic-315152-ash-b1.ip.twelve99-cust.net (213.248.83.119)   0.0%    10   97.3 100.9  93.7 121.2   8.8
 11. AS15133  ae-66.core1.dcb.edgecastcdn.net (152.195.65.129)                 0.0%    10   93.8  96.9  92.9 118.8   8.2
 12. AS15133  93.184.216.34                                                    0.0%    10   91.7  93.6  91.7  98.0   1.8

Only print part of the path

If you need to only inspect part of the path, you can use the following options (one or both at the same time):

 -f, --first-ttl NUMBER     set what TTL to start
 -m, --max-ttl NUMBER       maximum number of hops
❯ mtr example.com -bzw --first-ttl=6  --max-ttl=10
Start: 2022-03-03T13:54:29+0100
HOST: xxxxx                                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
  6. AS1299   prs-b3-link.ip.twelve99.net (62.115.171.226)                    80.0%    10   15.9  15.7  15.5  15.9   0.3
  7. AS1299   prs-bb2-link.ip.twelve99.net (62.115.118.62)                     0.0%    10   93.4  95.1  92.7 100.2   2.5
  8. AS1299   rest-bb1-link.ip.twelve99.net (62.115.122.159)                   0.0%    10   94.6  94.5  93.3  96.4   1.0
  9. AS1299   ash-b2-link.ip.twelve99.net (62.115.123.123)                     0.0%    10   92.3  94.5  92.3  97.0   1.8
 10. AS1299   verizon-ic-315152-ash-b1.ip.twelve99-cust.net (213.248.83.119)   0.0%    10   98.3  98.9  93.7 110.9   5.4

Reduce the load

You can use the -i, --interval SECONDS ICMP echo request intervaloption to be less ‘aggressive’ on the router on the path and reduce the impact of potential ICMP rate limiting (you can check the hop 6 in the example below)

❯ mtr example.com -bzw --first-ttl=6  --max-ttl=10
Start: 2022-03-03T13:54:29+0100
HOST: TOLA302006216                                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  6. AS1299   prs-b3-link.ip.twelve99.net (62.115.171.226)                    80.0%    10   15.9  15.7  15.5  15.9   0.3
  7. AS1299   prs-bb2-link.ip.twelve99.net (62.115.118.62)                     0.0%    10   93.4  95.1  92.7 100.2   2.5
  8. AS1299   rest-bb1-link.ip.twelve99.net (62.115.122.159)                   0.0%    10   94.6  94.5  93.3  96.4   1.0
  9. AS1299   ash-b2-link.ip.twelve99.net (62.115.123.123)                     0.0%    10   92.3  94.5  92.3  97.0   1.8
 10. AS1299   verizon-ic-315152-ash-b1.ip.twelve99-cust.net (213.248.83.119)   0.0%    10   98.3  98.9  93.7 110.9   5.4
                                                                                                                                          Took 11s
                                                                                                                                          
❯ mtr example.com -bzw --first-ttl=6  --max-ttl=10 --interval=10
Start: 2022-03-03T13:55:48+0100
HOST: TOLA302006216                                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  6. AS1299   prs-b3-link.ip.twelve99.net (62.115.171.226)                    60.0%    10   14.6  16.4  14.6  18.2   1.5
  7. AS1299   prs-bb2-link.ip.twelve99.net (62.115.118.62)                     0.0%    10   93.2  93.8  92.3  96.8   1.5
  8. AS1299   rest-bb1-link.ip.twelve99.net (62.115.122.159)                   0.0%    10   92.6  95.1  92.6  98.2   1.8
  9. AS1299   ash-b2-link.ip.twelve99.net (62.115.123.123)                     0.0%    10   93.9  94.0  91.9  97.8   1.7
 10. AS1299   verizon-ic-315152-ash-b1.ip.twelve99-cust.net (213.248.83.119)   0.0%    10  115.4  97.3  92.2 115.4   7.9
                                                                                                                                          Took 57s 
                                                                                                                                          
❯ mtr example.com -bzw --first-ttl=6  --max-ttl=10 --interval=15
Start: 2022-03-03T13:57:43+0100
HOST: TOLA302006216                                                           Loss%   Snt   Last   Avg  Best  Wrst StDev
  6. AS1299   prs-b3-link.ip.twelve99.net (62.115.171.226)                    30.0%    10   19.8  16.9  14.0  20.1   2.3
  7. AS1299   prs-bb2-link.ip.twelve99.net (62.115.118.62)                     0.0%    10   97.8  96.2  93.6 106.6   3.9
  8. AS1299   rest-bb1-link.ip.twelve99.net (62.115.122.159)                   0.0%    10   94.2  94.2  93.0  96.3   1.0
  9. AS1299   ash-b2-link.ip.twelve99.net (62.115.123.123)                     0.0%    10   93.3  95.5  93.1 102.3   2.9
 10. AS1299   verizon-ic-315152-ash-b1.ip.twelve99-cust.net (213.248.83.119)   0.0%    10   94.0  95.2  93.2  99.8   2.1
 
Took 1m 23s                                                             

Ping (for information)

Ping provide a quick way to provide the network path. However this need a special option on the ICMP packet and it is frequently dropped on the Internet or enterprise networks.

 -R      Record route.  Includes the RECORD_ROUTE option in the ECHO_REQUEST
         packet and displays the route buffer on returned packets.  Note that
         the IP header is only large enough for nine such routes; the
         traceroute(8) command is usually better at determining the route pack-
         ets take to a particular destination.  If more routes come back than
         should, such as due to an illegal spoofed packet, ping will print the
         route list and then truncate it at the correct spot.  Many hosts
         ignore or discard the RECORD_ROUTE option.
PING 192.168.1.63 (192.168.1.63) 56(84) bytes of data.
64 bytes from 192.168.1.63: icmp_seq=1 ttl=61 time=2.05 ms
RR:   192.168.9.118
        192.168.3.25
        192.168.10.35
        192.168.1.26
        192.168.1.63
        192.168.1.63
        192.168.10.4
        192.168.3.10
        192.168.4.25
64 bytes from 192.168.1.63: icmp_seq=2 ttl=61 time=2.00 ms      (same route)

Goto Summary

Do a visual traceroute

Traceroute or MTR are nice but sometimes you need to gather several traceroutes in one. While MTR and Traceroute are able to show parallel paths they cannot correlate inputs from several traceroutes.

Scapy is the perfect tool for that. There is a basic implementation of TCP traceroute on the documentation and easily find a lot of others by search “traceroute scapy”.

My favourite implentation is the one NST uses inside their distribution. You can allow find it as standalone like explained below.

mtraceroute

A python3 library for performing an enhanced scapy Multi-Traceroute (MTR) with a resulting SVG.

Features include running multiple queries with each target, display of Round Trip Time (RTT) calculations, selection of using Network Protocols: TCP, UDP and ICMP and with enhanced scapy SVG visual results and session packet capture output.

The upstream repo has some issues installation so I forked it to correct it: (jmanteau/mtraceroute)

Here is two examples.

First one is one target only with one trace (more or less a visual traceoute/mtr):

❯ mtrrt \
  --targets 'example.com' \
  --dirfile '/tmp/scapy.svg' --nquery 1 --interface 'en0' \
  --netproto 'TCP' --dports '443' \
  --retry 0 --minttl 1 --maxttl 30 --asnresolver 'All' --verbose 1 \
  --stype 'Random' --dotfile --rtt --privaddr --ptype 'Disabled' \
  --vspread 0.75 --title 'Multi-Traceroute (MTR) Probe' --ts $(date) --timeout 2 2>&1;

image-20220303141414411

Second one is multi target with several traces (which is where mtraceroute is shining):

❯ mtrrt \
  --targets 'photos.google.com,dns.google,www.registry.google,mail.google.com,www.google.com' \
  --dirfile '/tmp/scapy.svg' --nquery 4 --interface 'en0' \
  --netproto 'TCP' --dports '443' \
  --retry 0 --minttl 1 --maxttl 30 --asnresolver 'All' --verbose 1 \
  --stype 'Random' --dotfile --rtt --privaddr --ptype 'Disabled' \
  --vspread 0.75 --title 'Multi-Traceroute (MTR) Probe' --ts $(date) --timeout 2 2>&1;

image-20220303141414411

Goto Summary

Hear it if the host if off or back

The audible ping gives a beep when the peer is reachable

This option is useful during troubleshooting. There is no need for you to look at the ping output after each and every change. You can continue working with your changes, and when the remote machine become reachable/unreacheable you’ll hear the beep automatically.

 -A      Audible.  Output a bell (ASCII 0x07) character when no packet is received before the next
         packet is transmitted.  To cater for round-trip times that are longer than the interval between
         transmissions, further missing packets cause a bell only if the maximum number of unreceived
         packets has increased.

 -a      Audible.  Include a bell (ASCII 0x07) character in the output when any packet is received.
         This option is ignored if other format options are present.
ping -a IP # Beep if the host is back/there
ping -A IP # Beep when the host is down/not answering

Goto Summary

Others Tools

PrettyPing

prettyping is a wrapper around the standard ping tool, making the output prettier, more colorful, more compact, and easier to read.

image-20220303141414411

Hping

hping is a command-line oriented TCP/IP packet assembler/analyzer. The interface is inspired to the ping(8) unix command, but hping isn’t only able to send ICMP echo requests. It supports TCP, UDP, ICMP and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel, and many other features.

While hping was mainly used as a security tool in the past, it can be used in many ways by people that don’t care about security to test networks and hosts. A subset of the stuff you can do using hping:

For more details, please refer to the Hping wiki or this article

liboping: Oping/Noping

liboping was inspired by ping, libping and fping: It differs from these existing solutions in that it can “ping” multiple hosts in parallel using IPv4 or IPv6 transparently. Other design principles were an object oriented interface, simplicity and extensibility.

On top of liboping two command line applications have been built. “oping” is a drop-in replacement for ping(1) with very similar output. “noping” is an ncurses-based application which displays statistics while pinging and highlights aberrant round-trip times.

Oping:

❯ sudo oping -f input.txt
PING 1.1.1.1 (1.1.1.1) 56 bytes of data.
PING 1.0.0.1 (1.0.0.1) 56 bytes of data.
PING 8.8.8.8 (8.8.8.8) 56 bytes of data.
PING 8.8.4.4 (8.8.4.4) 56 bytes of data.
PING 4.2.2.1 (4.2.2.1) 56 bytes of data.
PING 4.2.2.2 (4.2.2.2) 56 bytes of data.
PING example.com (93.184.216.34) 56 bytes of data.
56 bytes from 1.1.1.1 (1.1.1.1): icmp_seq=1 ttl=64 time=14,35 ms
56 bytes from 1.0.0.1 (1.0.0.1): icmp_seq=1 ttl=56 time=18,88 ms
56 bytes from 8.8.8.8 (8.8.8.8): icmp_seq=1 ttl=115 time=18,81 ms
56 bytes from 8.8.4.4 (8.8.4.4): icmp_seq=1 ttl=116 time=19,73 ms
56 bytes from 4.2.2.1 (4.2.2.1): icmp_seq=1 ttl=55 time=34,10 ms
56 bytes from 4.2.2.2 (4.2.2.2): icmp_seq=1 ttl=55 time=34,02 ms
56 bytes from example.com (93.184.216.34): icmp_seq=1 ttl=53 time=95,84 ms
56 bytes from 1.1.1.1 (1.1.1.1): icmp_seq=2 ttl=64 time=4,29 ms
56 bytes from 1.0.0.1 (1.0.0.1): icmp_seq=2 ttl=56 time=18,97 ms
56 bytes from 8.8.8.8 (8.8.8.8): icmp_seq=2 ttl=115 time=17,99 ms
56 bytes from 8.8.4.4 (8.8.4.4): icmp_seq=2 ttl=116 time=18,75 ms
56 bytes from 4.2.2.1 (4.2.2.1): icmp_seq=2 ttl=55 time=29,21 ms
56 bytes from 4.2.2.2 (4.2.2.2): icmp_seq=2 ttl=55 time=30,46 ms
56 bytes from example.com (93.184.216.34): icmp_seq=2 ttl=53 time=93,81 ms
56 bytes from 1.1.1.1 (1.1.1.1): icmp_seq=3 ttl=64 time=7,59 ms
56 bytes from 1.0.0.1 (1.0.0.1): icmp_seq=3 ttl=56 time=18,33 ms
56 bytes from 8.8.8.8 (8.8.8.8): icmp_seq=3 ttl=115 time=18,19 ms
56 bytes from 8.8.4.4 (8.8.4.4): icmp_seq=3 ttl=116 time=19,03 ms
56 bytes from 4.2.2.1 (4.2.2.1): icmp_seq=3 ttl=55 time=35,51 ms
56 bytes from 4.2.2.2 (4.2.2.2): icmp_seq=3 ttl=55 time=35,46 ms
56 bytes from example.com (93.184.216.34): icmp_seq=3 ttl=53 time=94,79 ms

Noping:

image-20220303141616253

Deadman

deadman is a curses-based host status checking application using ping . It is nice for a small amout of host as it add a graphical summary.

$ git clone https://github.com/upa/deadman
$ cd deadman
$ cat <<EOF > deadman.conf
CloudFlareDNS1 1.1.1.1  
CloudFlareDNS2 1.0.0.1
GoogleDNS1 8.8.8.8
GoogleDNS2 8.8.4.4
Level3DNS1 4.2.2.1
Level3DNS2 4.2.2.2
Example.com 192.0.43.10
MicrosoftNCSI 131.107.255.255 
EOF

5e560a95398dd2be926cd701cb00fc4a.png

Comparison between tools (from Prettyping page)

ping mtr oping prettyping
Programming language C C C bash and awk
How easy to install from scratch? Should already come with your system Medium (C compiler + root privileges) Medium (C compiler + ncurses + root privileges) Trivial (just one file)
Requires root to install? Yes (suid) Yes (suid) Yes (suid) No (wrapper for ping, which is suid)
How many hosts? One All hosts in path One or more One
Minimum ping interval 0.2s for non-root users 1.0s for non-root users 0.001s The same as ping or oping
How easy to read the latency? Precise individual values are printed, average is only printed upon exit Statistics for each host are updated on each response, plus a non-intuitive legend for the graph oping: Looks the same as ping noping: Enhances the normal output with colors and live statistics and prettyping-inspired graphics Statistics for each host are updated on each response, plus an intuitive and colorful graph
How easy to see lost packets? Hard (lost packages aren’t printed on the Linux ping) Easy (? at the graphic, plus listed in the statistics) Very easy (oping prints missing responses, noping additionally shows them in the graph) Very easy (red ! at the graphic, plus listed in the statistics)
Statistics Only shown upon exit Updated in real-time, considers all responses since the beginning of the run oping: Only shown upon exit noping: Updated in real-time, considers all responses since the beginning of the run Updated in real-time, shows statistics for all responses since the beginning of the run, as well as statistics for the most recent 60 responses
Can redirect output to file? Yes No oping: Yes noping: No Yes
Terminal behavior Standard output Curses full-screen app oping: Standard output noping: Curses full-screen app Standard output with optional colors and VT100 escapes
Terminal dimensions Ignores the terminal size Reacts immediately to the terminal size oping: Ignores the terminal size noping: Adapts to the terminal size Adapts to the terminal size (only the future responses, the past responses are not changed)