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:
Some tests that may help include:
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:
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.
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 (http:/http://www-dev.slac.stanford.edu/cgi-wrap/scriptdoc.pl?name=pingroute.pl) (unfortunately mtr does not report duplicates), it is seen that only www.cern.ch responds with duplicate packets.
We have data from PingER going back to 2005 which I have mined to look for DUP's. The input data is one line per set of pings made from SLAC to a remote host. The line indicates whether there were DUP’s. Each line is for a remote host monitored from SLAC with up to 10 successful (with a cut off at 30 tries) 100 Byte pings each 30 mins.
We wrote a perl script (dupes.pl) to analyze the data.
The monitoring host (pinger.slac.stanford.edu) is not using multicast, the interfaces are not bonded. It is running Linux:
Linux pinger 2.6.32-279.19.1.el6.i686 #1 SMP Sat Nov 24 14:42:18 EST 2012 i686 i686 i386 GNU/Linux
Of the 128 S. E. Asian hosts monitored from SLAC (number of hosts with DUPs / number of hosts monitored in country)
BN | IN | KH | LA | MM | MY | PH | SG | TH | VN |
---|---|---|---|---|---|---|---|---|---|
0/5 | 1/50 | 0/1 | 1.4 | 0/3 | 0/40 | 0/10 | 0/7 | 1/11 | 1/4 |
See spreadsheet.
Year | DUPs | Hosts DUPing | Hosts monitored | Samples | % | CERN | Diff | % CERN |
2005 | 93 | 27 | 481 | 11408092 | 0.0008% | 0 | 93 | 0.00% |
2006 | 9228 | 40 | 514 | 13715929 | 0.0673% | 5751 | 3477 | 62.32% |
2007 | 35673 | 42 | 541 | 16315320 | 0.2186% | 34721 | 952 | 97.33% |
2008 | 39262 | 57 | 592 | 19680482 | 0.1995% | 34249 | 5013 | 87.23% |
2009 | 42356 | 52 | 663 | 17889767 | 0.2368% | 27469 | 14887 | 64.85% |
2010 | 74638 | 51 | 623 | 19862304 | 0.3758% | 19693 | 54945 | 26.38% |
2011 | 30769 | 79 | 659 | 22889278 | 0.1344% | 22518 | 8251 | 73.18% |
2012 | 85217 | 50 | 797 | 23786399 | 0.3583% | 34402 | 50815 | 40.37% |
2013 | 74128 | 76 | 774 | 25475771 | 0.2910% | 34916 | 39212 | 47.10% |
2014 | 16990 | 41 | 836 | 29933696 | 0.0568% | 14026 | 2964 | 82.55% |
2015 | 164 | 4 | 514773 | 0.0319% | 104 | 60 | 63.41% |