Droplet access is unreliable

August 25, 2016 106 views
DigitalOcean Ubuntu

I am experiencing some serious reliability problems with DO. I have read other posts on this, but none had any suggestions that I had not already tried.

Yesterday, I created a droplet and accessed it via SSH; life was good. This morning, that same droplet could not be accessed and the Console remained disconnected (no matter how many times I tried).

I've tried many 'tricks' (rebooting my Windows PC, disabling my firewall, power-cycle the droplet, creating droplets in different regions, ping, ssh, retrying several hours later, retrying from a different network, ...).

I have noticed that the Console access is very unreliable. At times it connected long enough for me to change the password. Some minutes later, it would disconnect and I could not get it back.

Even when I had access to the console, I could not ping the droplet's static IPv4 address.

I have not found any logs that might help to narrow this down. It's all a mystery at the moment. Any suggestions? Is DO becoming DOn't?

As an aside: despite the connectivity issues to my droplets, I still have full web-based access to DO, so I can at least administer the droplets via the web interface.


2 Answers

Well, that does not sound like a good experience at all. This does sound like a bit of a mystery but because you seem to be seeing connectivity issues both with your droplet and with it's console my first thought is that there is a routing issue causing networking issues between your location and your droplet.

I would recommend opening a ticket with our support team and including the results of a MTR/traceroute between your location and your droplet so they can start investigating.

Thanks Ryan.

I tried again this morning from a hotel room. Access has been reinstated, yay! Still no logs to give any clue as to the cause, so this is going to remain a mystery.

This was the traceroute from a hotel room for one of my (now destroyed) droplets... it's nasty, but it eventually gets there.

$ tracert

Tracing route to over a maximum of 30 hops

1 5 ms 2 ms 2 ms
2 * * * Request timed out.
3 * * * Request timed out.
4 688 ms 44 ms 19 ms Bundle-Ether12.cha-edge901.brisbane.telstra.net []
5 556 ms 208 ms 62 ms bundle-ether6.cha-core4.brisbane.telstra.net []
6 50 ms 44 ms 41 ms bundle-ether11.ken-core10.sydney.telstra.net []
7 65 ms 37 ms 39 ms bundle-ether1.pad-gw11.sydney.telstra.net []
8 47 ms 35 ms 46 ms bundle-ether1.sydp-core04.sydney.reach.com []
9 522 ms 67 ms 47 ms i-0-1-0-46.sydp-core03.bi.telstraglobal.net []
10 424 ms 306 ms 306 ms i-41.traglobal.bx.telstraglobal.net []
11 840 ms 3069 ms 305 ms i-0-0-0-3.tlot02.bi.telstraglobal.net []
12 594 ms 306 ms 241 ms l3-peer.tlot02.pr.telstraglobal.net []
13 523 ms 813 ms 614 ms ae-118-3504.edge3.London15.Level3.net []
14 790 ms 508 ms 1022 ms ae-118-3504.edge3.London15.Level3.net []
15 * * * Request timed out.
16 * * * Request timed out.
17 675 ms 368 ms 398 ms

I'll keep using DO, but these reliability problems have got to evaporate if I'm ever going to recommend this tool to others.


Have another answer? Share your knowledge.