Any one know what is up with /ip cloud (the mt DDNS and “update time” cloud service) and “Error: request Timed out”? Ive been seeing this over the past 12 months at just about every install i have done (installs on various ISPs ). usually, by hitting Force Update several times i can get a request/post to go through, but just about always i get Error: Request Timed out.
What kind of cloud service has this poor of up-time / reach-ability (over this long of time)? or is it that cloudflare (or similar) is in-front of these cloud servers and causing issues?
(im aware that there may be some type of brute force detection in place, thus x# of attempts in y# of seconds = blocked, but i always try to allow the 1st, initial request to go through on its own, and it almost always comes back with “Error: request timed out”.
Search this forum and join similar topics that already exist here. The cloud features are so unreliable for real usage, that I am always disabling them fully. Maybe they are a bit useful for some individual home users because they don’t care how it works. But that’s all.
Just wrote to support@mikrotik.com about that too.
From my investigation on the issue, it looks like the DDNS service connects to 82.198.87.240 or 91.188.51.139. However, 91.188.51.139 is unreachable due to network loop on their (or their provider’s) side:
output: in:(unknown 0) out:wan proto UDP, 92.247.143.243:35737 -> 91.188.51.139:15252, len 548
.
$ traceroute -n 91.188.51.139
traceroute to 91.188.51.139 (91.188.51.139), 30 hops max, 60 byte packets
1 10.133.254.3 1.865 ms 1.893 ms 1.853 ms
2 108.170.233.180 14.918 ms 14.903 ms 14.901 ms
3 209.85.249.133 14.688 ms 209.85.249.135 14.956 ms 209.85.249.133 14.656 ms
4 62.115.50.246 14.677 ms 14.877 ms 14.957 ms
5 213.155.135.82 14.946 ms 213.155.135.84 14.943 ms 213.155.135.80 14.706 ms
6 80.91.249.9 32.678 ms 213.155.136.142 28.461 ms 27.694 ms
7 62.115.118.237 36.462 ms 62.115.118.241 38.616 ms 62.115.118.245 38.497 ms
8 62.115.12.146 38.720 ms 34.662 ms 39.725 ms
9 78.154.154.162 38.663 ms 34.647 ms 38.431 ms
10 89.201.51.214 34.538 ms 34.524 ms 38.177 ms
11 89.201.51.214 39.171 ms 33.767 ms 33.594 ms
12 * 89.201.51.213 40.921 ms 39.873 ms
13 * 89.201.51.214 39.510 ms 33.689 ms
14 * * *
15 89.201.51.214 38.696 ms 34.112 ms 33.987 ms
16 * * *
17 89.201.51.214 38.860 ms 34.374 ms 39.930 ms
18 89.201.51.213 34.733 ms * *
19 * 89.201.51.214 40.342 ms *
20 89.201.51.213 34.842 ms * *
21 89.201.51.214 34.827 ms 40.456 ms 39.313 ms
22 * * *
23 89.201.51.214 35.317 ms 39.850 ms 35.317 ms
24 89.201.51.213 41.074 ms * *
25 89.201.51.214 35.305 ms 35.402 ms 35.292 ms
26 89.201.51.213 35.873 ms * *
27 * 89.201.51.214 35.434 ms *
28 * * *
29 89.201.51.214 35.544 ms 35.378 ms 41.051 ms
30 * 89.201.51.213 35.407 ms *
The traffic bounces back-forth between 89.201.51.213 and 89.201.51.214, and of course expires in transit. This explains the time-out we are seeing. After some unsuccessful retries, DDNS tries with 81.198.87.240 and it succeeds.
output: in:(unknown 0) out:wan proto UDP, 92.247.143.243:35737 -> 81.198.87.240:15252, len 548
When did you guys remove 91.188.51.139 from the DNS server? Yesterday I rebooted 2 routers because of upgrade to 6.41.2 (which should have cleared the DNS cache) and the routers were still making attempts to 91.188.51.139.
We Still constantly see Error: request timed out (although some times it works, but its realisticlly 80-90% of time fails).
Im testing this on Various ISPs (different customer installs), its constant (ie not just one day, or one week, past 6-12 months). the only way i can get it to work, some times, is by hitting force update for about 2-5 minutes (re-hit each time after it shows error).
One user replying that it worked for him once, does not mean this issue is solved / resovled. (if you search forums, others have this issue very often).
Not only that, but the system time obtained from this ip cloud is often so far off that it really isn’t acceptable.
MikroTik’s position is that it is good enough to set the approximate time of a router (maybe for things like certificates)
but is should be easy to keep a cloud server to within a second of accurate time using NTP, instead of 10 minutes as it is now.
So: untick those checkmarks under /ip cloud and use something better.
(e.g. set the SNTP client to use DNS name pool.ntp.org)
Just had a reason to use this feature as I have a router on an ADSL connection and the user (aka my boss) wants a fixed name to access it. Thought no problem, I can use the cloud option, then just set him a nice dns entry under our domain with a cname to xyz.mynetname.net.
Tried it on my home router first which is on the end of 70Mbps “fibre-to-the-cabinet” in the UK. Took me at least 8 attempts to not get a timeout which is why I ended up here. It does seem that I can ping cloud.mikrotik.com from the device though so doesn’t seem to be a connectivity or dns issue accessing the cloud service.
I’m very reluctant to now use this as I have absolutely no confidence that it will update successfully when he has an address change. I’m actually shocked at how bad it is considering my usual experience with routeros.
(Note that I wouldn’t rely on this for time regardless of how well it works. NTP is a far better choice)