New IP cloud is coming.

RouterOS General
1

Starting since 6.43rc21 new ip-cloud implementation is available for the first adopters. The feature set for now is the same as in older versions however that is about to change. It has improvements in security, responsiveness and expandability.

Current upgrade path:

  1. disable ip-cloud /ip cloud set ddns-enabled=no
    this is to remove your entry from the old database, so when you decide to not use the feature in newer version, it would not return your old address.
  2. upgrade to verion 6.43rc21 or newer
  3. enable the ip-cloud /ip cloud set ddns-enabled=yes
Need to remove DNS record from sn.mynetname.net (kind of urgently)
dynDNS SCRIPT THAT WORKS
2

/ip cloud set sdwan-enabled=yes

:wink:

3

Ugh. Just, ugh.

4

Multi-WAN support for DDNS pretty please?

5

Will we get IPv6 Support?

6

Will we get CHR support? :slight_smile:

7

Will the cloud time accuracy be more reasonable?
I mean, I could live with a 2 second error and a 1 second resolution but more than that is really sub-par.
(especially as NTP and SNTP work OK but are not enabled by default as the cloud time option is)

8

It was maintained backward compatibility with previous versions or the BugFix or Current versions? with the problems kept?

How does MK release a new Cloud that works better only with RC firmware?

I can not put the RC in production.

I prefer to disable the cloud of MK and use a DDNS own that I have configurate.

9

What problems?

Any feature is first released in RC. Then it becomes ‘current’.

You must not do this. Use RC only in controlled test environments.

10

You would need to find something else than serial number to use for hostname. There’s System ID, but it seems to be generated randomly, so it might not be unique. It also seems to make a difference between case of letters, so it would not work well with dns either. But I’m sure something could be invented, at least for licensed instances.

Btw, with security being a big topic lately, it would be interesting to know, how this whole thing works. I mean, when there’s regular DDNS service, it depends on username/password. Nobody else can know it, so it’s not possible to send fake requests for updates. But what is here? I don’t see any unique secret unknown to anyone else. If I learn someone’s RB serial number, is there anything else than so far unknown algorithm how to generate a valid request?

11

md5sum of the license number? Kinda big, but…

12

Maybe a little elaboration on this, so I can decide if I care? I use this feature only to locate MikroTik routers I have installed that don’t have static IP addresses.


Sent from my iPhone using Tapatalk

13

old cloud was v4 only, w/o any theoretic chance for ipv6 support.

cy-bear:~ bat$ host cloud.mikrotik.com
cloud.mikrotik.com has address 81.198.87.240

but RCs use cloud2…

cy-bear:~ bat$ host cloud2.mikrotik.com
cloud2.mikrotik.com has address 159.148.147.201
cloud2.mikrotik.com has address 159.148.172.251
cloud2.mikrotik.com has IPv6 address 2a02:610:7501:1000::201
cloud2.mikrotik.com has IPv6 address 20a2:610:7501:4000::251

now putting it to the test:
a box w/o ipv4 address, but full access to ipv6 internet supposed to be able to connect the v6 hosts.

[admin@tgcpe2] /ip cloud> /ip dns cache print 
Flags: S - static 
 #   NAME          ADDRESS                                         TTL         
 0 S router.lan    192.168.88.1                                    1d          
 1   ttt0-cegle... 2001:4c48:xxxxx::1                             40s         
 2   tgcpenms.d... 2001:4c48:xxxxx::3                               20m6s       
 3   cloud2.mik... 159.148.172.251                                 1h16m16s    
 4   cloud2.mik... 159.148.147.201                                 1h16m16s  

[admin@tgcpe2] /ip cloud> /ip cloud print 
    ddns-enabled: yes
     update-time: no
  public-address: 188.6.129.21
          status: connecting...

we’re not there yet.

14

To give more authoritative weight behind some excellent answers given by other users:

  1. do not put RC in production - all new features come to RC, then get into current and only then it is placed into bugfix.
  2. backwards compatibility was considered and then removed. So no, to use this, you will need to wait for stable and/or bugfix release to use in production
  3. the new cloud works much faster, so the precision will be better - this is for setups where you cannot run NTP/SNTP or don’t need the time so precise. This is enabled by default to get some, any time for logs where a user could benefit from seeing a time of occurrence. The moment you get NTP/SNTP time IP-cloud time service stops even if enabled.
  4. it is not possible to send fake updates to the IP-cloud. To the IP-cloud your router is unique.
  5. CHR - it is complicated. There is a lot of things that have to be resolved for this to become a reality.

I use this feature only to locate MikroTik routers I have installed that don’t have static IP addresses.
this is the intended use - you are our target audience for the IP-cloud’s DDNS feature

Will we get IPv6 Support?
Yes.

15

I completely understand that the cloud time is based on a http timestamp so it offers only 1-second resolution and cannot set the clock very accurately, but that was never an excuse for serving time that is wrong by 10 minutes.
It is important that the cloud servers themselves are well synchronized to NTP time and that this situation is actively monitored by MikroTik and action is taken when the served time is noticed to be drifting away from correct time.
This is already true for the IP cloud as it exists now. At this moment the cloud time is ahead by 6 seconds! Why?? By configuring NTP on the servers you can easily keep it within 10 milliseconds so the actually served time is well within the 1 second resolution of the method used.

16

OK… so, as I don’t really care about using it for NTP or on IPV6, does this new implementation give me anything superior for my needs that would give me incentive to turn it on? Maybe I have overlooked an explanation, but I don’t think one has yet been presented.

17

It’s nice to hear. I just hoped we could get a little “peek under the hood”, how it works. And please don’t say “secret algorithm”, because when it has to be on every single router, one bored person with decompiler could be all what’s needed to make it not secret anymore.

Don’t take me wrong, I’m not trying to insinuate anything. I can imagine some possible ways how it could be done. E.g. if each router had some unique secret (password) stored on flash, and if you had database with =, that would be good enough, because nobody could get the secret from someone else’s router. But it would have to be something you had even before DDNS was introduced, because it works even on older RBs. Knowing that you have something like that (or even better) would help us sleep better.

And you missed this one:

If it would be possible to add multiple DDNS clients (with some reasonable limit), something like (just a quick thought, there might be better way):

/ip cloud ddns
add name=wan1 routing-table=isp1
add name=wan2 routing-table=isp2

which would give us wan1..sn.mynetname.net, etc.., it would be fantastic. Or it could be directly linked to DHCP or PPPoE client.

18

ok, thanks..

@chupaka: Chupa essa!!!

19

Huh?

20

Literal translation: “Suck this”.