kurotsuki
By:
kurotsuki

Timeout on certain outgoing connection

April 5, 2018 115 views
Networking Ubuntu 16.04

I've recently spun out a new droplet in your Singapore data center. When I try to ping 'fixer.io' (or any action to that address like curl, wget, lynx), it always resulting connection timeout. If I try accessing google, other sites, or even my other droplet, the result is success.

When I try to traceroute to fixer.io, it gives this result:

kuro@meili-v1:~# traceroute fixer.io
traceroute to fixer.io (23.246.243.2), 30 hops max, 60 byte packets
 1  206.189.32.254 (206.189.32.254)  1.442 ms 206.189.32.253 (206.189.32.253)  1.388 ms 206.189.32.254 (206.189.32.254)  1.726 ms
 2  138.197.250.252 (138.197.250.252)  2.593 ms  2.593 ms  2.580 ms
 3  138.197.250.205 (138.197.250.205)  1.024 ms 138.197.250.203 (138.197.250.203)  0.967 ms *
 4  * * *
 5  * * *
...
30  * * *

This doesn't happen to my old droplet (same data center, DO's Singapore). That old droplet showing this when doing traceroute:

kuro@rd-devel:~# traceroute fixer.io
traceroute to fixer.io (23.246.243.2), 30 hops max, 60 byte packets
 1  188.166.208.253 (188.166.208.253)  0.659 ms 188.166.208.254 (188.166.208.254)  3.143 ms 188.166.208.253 (188.166.208.253)  0.601 ms
 2  138.197.250.208 (138.197.250.208)  0.618 ms 138.197.250.210 (138.197.250.210)  0.586 ms 138.197.250.212 (138.197.250.212)  0.595 ms
 3  36351.sgw.equinix.com (27.111.228.69)  2.233 ms  1.840 ms 138.197.250.205 (138.197.250.205)  0.604 ms
 4  36351.sgw.equinix.com (27.111.228.69)  1.800 ms  1.781 ms  1.762 ms
 5  ae5.cbs01.eq01.sng02.networklayer.com (169.45.19.172)  7.020 ms ae0.cbs01.eq01.tok01.networklayer.com (169.45.19.182)  86.449 ms ae5.cbs01.eq01.sng02.networklayer.com (169.45.19.172)  3.747 ms
 6  9d.13.2da9.ip4.static.sl-reverse.com (169.45.19.157)  83.926 ms  83.692 ms  83.521 ms
 7  9d.13.2da9.ip4.static.sl-reverse.com (169.45.19.157)  83.596 ms  83.392 ms  83.595 ms
 8  ae2.bbr02.eq01.sjc02.networklayer.com (50.97.18.160)  184.258 ms  184.853 ms ae6.dar01.sjc01.networklayer.com (50.97.19.167)  172.943 ms
 9  ae6.dar01.sjc01.networklayer.com (50.97.19.167)  173.068 ms  174.659 ms  172.946 ms
10  9f.76.1732.ip4.static.sl-reverse.com (50.23.118.159)  174.856 ms 2.f3.f617.ip4.static.sl-reverse.com (23.246.243.2)  172.120 ms 9f.76.1732.ip4.static.sl-reverse.com (50.23.118.159)  173.074 ms

For comparison, my network interface setting are like this:
new droplet, which has timeout issue:

auto lo
iface lo inet loopback
    dns-nameservers 8.8.8.8 8.8.4.4

auto eth0
iface eth0 inet static
    address 206.189.40.193/20
    gateway 206.189.32.1

# control-alias eth0
iface eth0 inet static
    address 10.15.0.6/16

while old droplet, which can call "fixer.io" successfully has this setting:

auto lo
iface lo inet loopback
    dns-nameservers 8.8.8.8 8.8.4.4

auto eth0
iface eth0 inet static
    address 188.166.210.197
    gateway 188.166.208.1
    netmask 255.255.240.0

# control-alias eth0
iface eth0 inet static
    address 10.15.0.5
    netmask 255.255.0.0

So what exactly happen here? Why the new droplet cannot access "fixer.io" while old droplet can? What exactly cause the problem?

2 Answers
kurotsuki April 6, 2018
Accepted Answer

Ok... It seems that the ip address bound to that droplet is faulty. I had to create a snapshot and spun a new droplet from that snapshot. It now works well.

I'm not sure it would have any bearing on this particular issue but your first config file is missing the netmask for your interfaces (the correct values can always be found on the web console page in the control panel (Droplet->Access->Console)

If updating that and restarting your Droplet fails to resolve the issue, I'd recommend opening a ticket with our support team so they can investigate further.

  • I've try to add the netmask and the issue persist. I'll wait for tomorrow while looking at it a bit more. If there are no conclusion, I'll open support ticket. Thanks.

Have another answer? Share your knowledge.