3.5. Ping

Ping is the most well-known command in the networking world to determine if a remote host is reachable. It works by sending ICMP Echo Request packets and displays any ICMP packet returned.

Besides the ping command, used for the IPv4 transport layer, there is also the ping6 command, used for the IPv6 transport layer. The options used for the IPv4 version can also be used for the IPv6 version unless noted differently.

3.5.1. Ping options

The following options are available:

  • The option -c # limits the number of ICMP packets send out.

  • The option -I <IP address> specifies the source IPv4 address to use and thus the outgoing interface. To specify the IPv6 source address, use the -I <interface> option, the IPv6 address on the specified interface will be used there.

  • The option -s # specifies the size of the ICMP packet payload.

  • The option -M do disables IP packet fragmentation due to MTU size issues.

3.5.2. Ping examples

On the Steelhead appliance, the ping command uses by default the IP address of the primary interface as the source IP address of the packets:

Figure 3.23. Ping a host via the primary interface

SH # ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=0 ttl=59 time=290.0 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=59 time=260.0 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=59 time=260.0 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 260.0/280.0/290.0/10.000 ms, pipe 2

The option -c 3 limits the number of ICMP packets send to three, otherwise it will keep sending ICMP Echo Request packets until the ping command is aborted via the control-C key combination. The next option is the IP address or the hostname of the destination host.

The output shows the IP address of the device which answered the ICMP Echo Request command, the sequence number of the ICMP Echo Reply packet received back, the TTL of the IP packet which can be used to identify the number of hops to the destination host is and the time it took for the answer to come back.

The -I option can be used to specify the IP address of an in-path interface to force the ICMP packet out via the corresponding LAN or WAN interfaces. It will follow the routing table of that interface.

Figure 3.24. Ping a host via the in-path interface

SH # ping -c 3 -I 10.0.1.6 192.168.1.1
PING 192.168.1.1 (192.168.1.1) from 10.0.1.6 : 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=0 ttl=59 time=290 ms
64 bytes from 192.168.1.1: icmp_seq=0 ttl=59 time=260 ms
64 bytes from 192.168.1.1: icmp_seq=0 ttl=59 time=260 ms

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 260.0/290.0/280.0/10.000 ms, pipe 2

In this example, 10.0.1.6 was the in-path interface IP address.

3.5.3. Detecting failure scenarios

3.5.3.1. No answer from a host on the local subnet

When pinging a host on a local subnet and you get an ICMP Destination Host Unreachable message, it means that the ARP request for the destination host didn't get an answered. Most of the time it means that the host with that IP address is turned off.

Figure 3.25. IP address 10.0.1.4 is not in use on this local IP subnet

SH # ping -c 3 10.0.1.4
PING 10.0.1.4 (10.0.1.4) 56(84) bytes of data.
From 10.0.1.5 icmp_seq=0 Destination Host Unreachable
From 10.0.1.5 icmp_seq=0 Destination Host Unreachable
--- 10.0.1.4 ping statistics ---
3 packets transmitted, 0 received, +2 errors, 100% packet loss, time 0ms , pipe 2

Note that the ICMP Destination Host Unreachable message occurred because the ARP request for the IP address did not get answered. If the host was firewalled and would drop the ICMP traffic, the ARP request would have been answered so instead of the ICMP Destination Host Unreachable message there would have been no output at all.

3.5.3.2. No answer at all from a remote host

For a host on a remote subnet, no answers can mean one of the following issues:

  • The IP address is not in use and the router for that subnet is not sending ICMP Destination Host Unreachable packets back.

  • The destination host has been configured to not respond to ICMP Echo Request packets.

  • The destination IP subnet is unreachable from the sending host.

  • The source IP subnet is unreachable from the remote host.

  • A firewall in the network has blocked either the ICMP Echo Request or the ICMP Echo Reply packet.

Figure 3.26. IP address 192.168.1.1 didn't reply.

SH # ping -c 3 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

--- 192.168.1.1 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 5000ms, pipe 2

3.5.3.3. Serious packet loss

In every ICMP Echo Request message sent, the icmp_seq field contains the sequence number of the request. The returned ICMP Echo Response will contain the same sequence number and it can be used to determine which packets were lost:

Figure 3.27. ICMP packets 3 to 5 and 8 to 9 didn't get answered.

SH # ping -c 10 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=0 ttl=59 time=260.0 ms
64 bytes from 192.168.1.1: icmp_seq=1 ttl=59 time=260.0 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=59 time=260.0 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=59 time=260.0 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=59 time=260.0 ms

--- 192.168.1.1 ping statistics ---
10 packets transmitted, 5 received, 50% packet loss, time 0ms
rtt min/avg/max/mdev = 260.0/260.0/260.0/0.000 ms, pipe 2

3.5.4. Path MTU detection

When an IP packet arrives at a router and the outgoing link has a maximum packet size which is smaller than the IP packet, it will break the IP packet in several smaller IP packets and send that over the wire. To prevent this breaking up from happening, the sender can set the Don't Fragment flag in the IP header. As a result, the router will not be able to forward the packet and will send an ICMP Fragmentation Needed packet back to the sender. This ICMP Fragmentation Needed packet contains the MTU size of the link. The sender should then retransmit the IP packet with a smaller payload.

The IP packets of the inner channel of an optimized TCP session have that Don't Fragment flag set. Therefore, routers on a link with a smaller MTU size than what is configured on the Steelhead in-path interface should send back an ICMP Fragmentation Needed packet. If the network for whatever reason doesn't deliver this to the Steelhead appliance, the packet will not be delivered, the inner channel will time-out and the optimized TCP session will break.

The size parameter on the ping command can be used to determine the maximum MTU size off the network.

The initial size value to check should be the MTU size of the interface on the Steelhead appliance minus 28 bytes. The 28 bytes are the IP header and the ICMP Echo Request header.

Figure 3.28. ICMP based MTU size detection - MTU of 1500 bytes

SH # ping -s 1472 -M do 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 1472(1500) bytes of data.
556 bytes from 10.0.1.9 (10.0.1.9): frag needed and DF set (MTU 1492)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src         Dst
 4  5  00 d505 0058   0 0000  40  01 b4e1 10.0.1.5 192.168.1.1

This ICMP Fragmentation Needed packet shows the following information:

  • The IP header contains 10.0.1.9, the IP address of the router which could not forward the IP packet.

  • The ICMP payload contains 0058, the IP packet identifier of the IP packet which could not be forwarded.

  • The ICMP payload contains 10.0.1.5 and 192.168.1.1, the source and destination IP address of the IP packet which was too big.

  • 1492, the MTU size of the outgoing link.

If no ICMP Fragment Needed packet or ICMP Echo Reply is returned, that is an indication that the network is dropping the reply packet.

The next steps is to reduce the size value to a value until you receive ICMP Echo Replies instead of ICMP Fragmentation Needed packets. In this case where it is now known that the MTU size of the first link is 1492, the next value to try should be 1492 minus 28 is 1464.

Figure 3.29. ICMP based MTU size detection - MTU of 1492 bytes

SH # ping -s 1464 -M do 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 1464(1492) bytes of data.
1472 bytes from 192.168.1.1: icmp_seq=0 ttl=59 time=260.0 ms

Setting the MTU size of the in-path interface to 1492 will overcome the communication problem towards this remote Steelhead appliance.