64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.344 ms
64 bytes from 192.168.0.95: icmp_seq=1 ttl=63 time=0.401 ms (DUP!)
64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.296 ms
64 bytes from 192.168.0.95: icmp_seq=2 ttl=63 time=0.328 ms (DUP!)
64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.291 ms
64 bytes from 192.168.0.95: icmp_seq=3 ttl=63 time=0.316 ms (DUP!)
64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.279 ms
64 bytes from 192.168.0.95: icmp_seq=4 ttl=63 time=0.309 ms (DUP!)
64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.271 ms
64 bytes from 192.168.0.95: icmp_seq=5 ttl=63 time=0.299 ms (DUP!)
Check your ARP tables, local and on intervening switches/routers. Make sure there are no duplicate entries for that IP. If you note the response time, the second packet is always higher which might be indicative. I would also check for a botched MITM a la C&A.
Even if there is no obvious ARP table manglement, you might try flushing the local and intervening caches.
Try the ping from another host, another subnet, another segment, get more info.
Check to see whether or not the port connected to that host is mirrored or in a SPAN VLAN. Misconfiguration on an analyzer server can cause duplicate traffic to be generated.
Just hope it's not being caused by a Level3/Sprint circuit...ours is still doing this (when I change back to HDLC) and they just don't freaking care.
Sometimes I wish I worked for a big telco so I could leave things broken and say "hey, I'm the telco, I don't have to care."
Maybe we should refuse to pay for the affected DS3 and see if that gets more attention.
Instead, dispute the bill and then when they won't credit you for not giving you what you ordered, open a complaint with the state public utilities commission. It may get you some movement on the issue.
She'd have to actually specify -b to ping a broadcast address, and if
she did, she would only get replies back from the hosts on that
subnet, not duplicate replies from the same IP.
Only true if you're pinging the broadcast address of a network that you
have an interface on, or the system has other knowledge of the netmask/etc.
If you're pinging a remote address, your system (in general) has no way of
knowing if that .0.95 is a broadcast address for a /27, or a normal address
in the middle of a /26 (or one of the other possibilities).
(I've lost the original posting, and can't recall if the OP said if she was
pinging from on-subnet or off-subnet).
