Pinging some hosts causes multiple responses for a ping echo request. This is reported by the Linux and Mac OSX ping command but not by Windows. For iPhones the results depend on the app, e.g. NetAnalyzer and Ping Lite do not show the DUPs, whereas Ping does. Typically from a RHEL6-64 Linux host (pinger.slac.stanford.edu, not using multicast, the interfaces are not bonded) at SLAC it appears as:
290cottrell@pinger:~$ping www.cern.ch
PING webrlb02.cern.ch (188.184.9.235) 56(84) bytes of data.
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1 ttl=109 time=163 ms
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1 ttl=109 time=163 ms (DUP!)
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1 ttl=109 time=163 ms (DUP!)
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=2 ttl=109 time=163 ms
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=2 ttl=109 time=163 ms (DUP!)
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=2 ttl=109 time=163 ms (DUP!)
On a SunOS host it appears as:
290cottrell@flora04:~>ping -s www.cern.ch
PING www.cern.ch: 56 data bytes
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=0. time=166. ms
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=0. time=308. ms
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=0. time=308. ms
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1. time=166. ms
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1. time=166. ms
64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1. time=166. ms
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
...