Pinging some hosts causes multiple responses for a ping echo request. This is reported by the Linux ping command but not by Windows.
Duplicate packets should never occur when pinging a unicast address, and seem to be caused by inappropriate link-level retransmissions. Duplicates may occur in many situations and are rarely (if ever) a good sign, although the presence of low levels of duplicates may not always be cause for alarm. Duplicates are expected when pinging a broadcast or multicast address, since they are not really duplicates but replies from different hosts to the same request. From http://www.gsp.com/cgi-bin/man.cgi?section=8&topic=ping#4
Duplicate ping responses can be seen for example from SLAC to CERN or www.realbroadband.co.sz. They can be caused by:
- More than one host has the same IP address, so all these hosts will respond to the ICMP echo request.
- The IP address pinged may be a broadcast address.
- The host has multiple TCP stacks bound to an Ethernet adaptor (see http://www.doxpara.com/read.php/tcp_chorusing.html).
- A router believes it has two routes by which it can reach the end host and (presumably mistakenly) forwards the ICMP echo requests by both routes, thus the end host sees two echo requests and responds twice.
- There maybe two or more (non-routed) paths to the end host and each request is forwarded by more than one path.
- It may be caused by NIC bonding (see http://slashzeroconf.wordpress.com/2008/04/29/duplicate-ping-error-with-network-bonding-driver-in-linux/).
- A misbehaving NAT box.
Some tests that may help include:
- Pinging the routers along the route to see if any of them respond with duplicates. Examples: Duplicate pings from SLAC to realimage.realnet.co.sz , www.lonab.bf.
- Capture the ping packets and look to see if all the packets are returned from the same Ethernet address. See the examples of SLAC to CERN and SLAC to www.lonab.bf where in both cases all responses are from the same IP address.
- Do multiple hosts at a site/network domain/subnet return duplicate packets? For example www.cern.ch (137.138.144.16) gives 3 pings in response to each one sent, while ping.cern.ch (137.138.28.176) and pinger.cern.ch (192.91.244.6) see no duplicate pings. CERN has a /16 IP network space 137.138..
An example of the prevalence of duplicate ping packets comes from PingER measurements on March 31st 2012 from SLAC to 703 hosts in over 160 countries. Of these hosts 15 responded with duplicate pings. For 13 of the 15 hosts it occured on both 100 and 1000 Byte pings. Out of 10 pings sent:
- 6 hosts had 1 ping duplicated,
- 5 had 2 pings duplicated,
- 2 had 4 pings duplicated,
- 1 had 3 pings duplicated and
- 1 returned 12 pings for each ping sent.
The sites of the hosts range from national labs (CERN, IHEP SU), developed countries (Israel), developing countries (Burkina Faso, Malawi, Mauritius, Sierra Leone, Swaziland, Zambia), and educational sites (SDSC). Only the www.cer.ch address was consistent in the number and frequency of duplicate pings.
PingER simply reports whether there were duplicates or not. A useful metric is to report the number of pings received/number pings sent. The number received may depend on the ping command options. One option will send a given number of pings until it receives that many back or times out. Another option will send 10 pings and wait (or time out) until they are received. So the metric value may also depend on the ping command.
CERN
For each ping sent to www.cern.ch it responds with ~3 pings consistently. Using the normal traceroute www.cern.ch does not respond. Using the ICMP traceroute it does respond (twice). Pinging each node along the route using pingroute.pl (unfortunately mtr does not report duplicates), it is seen that only www.cern.ch responds with duplicate packets.