I have two droplets created, one in SF, the other in SGP, when I ping one from the other, I get duplicate responses. Can anyone tell me what’s going on with the network that would cause this and is it a problem? (nb not real IP address)
PING 188.166.22.1 (188.166.22.1) 56(84) bytes of data.
64 bytes from 188.166.22.1: icmp_seq=1 ttl=55 time=168 ms
64 bytes from 188.166.22.1: icmp_seq=1 ttl=119 time=168 ms (DUP!)
64 bytes from 188.166.22.1: icmp_seq=2 ttl=55 time=167 ms
64 bytes from 188.166.22.1: icmp_seq=2 ttl=119 time=168 ms (DUP!)
64 bytes from 188.166.22.1: icmp_seq=3 ttl=55 time=167 ms
64 bytes from 188.166.22.1: icmp_seq=3 ttl=119 time=168 ms (DUP!)```
These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.
This could be a network issue just as it could be a localized issue between your connection and the Droplet. In many cases, if you’re connecting over Wi-Fi or similar, any delay in response to or from your router could trigger duplicate requests.
If you’re on Wi-Fi, have you tried disabling Wi-Fi and connecting from a wired connection? If you still see the same, instead of connecting through the router, connect from the modem directly if possible.
This will at least eliminate two potential issues that I’ve seen numerous times in the past.
@andyg - hops 1, 2, and 8 are all digitalocean addresses, so those are OK. The final hop of the route not being your target IP is most likely because of the firewall rules at DO. The time through the ntt.net gateway has both sort and long time hops, so that’s most likely causing the dup problem. Note the time-to-live value of the dup ping packets are about 2x that of the non-dup packets. You can verify that by using the ‘-t 60’ to the ping command, which should eliminate the dup packets.
Hmm, something is not quite right:
That looks to me like something is looping. What do you think? Similar situation on the other droplet pinging the other direction.
If you have the traceroute command where you run the ping command, then using that might give you better clues as to what is happening to your packets.