Quite some people referenced this page (I did as well) , it's advanced thinking on on failover scenario's. Search found 90 matches: https://wiki.mikrotik.com/wiki/Advanced ... _Scripting


https://wiki.mikrotik.com/wiki/Advanced ... _Scripting


Is this part of a cleanup, or moving information to another place?

We are lucky to still have this: viewtopic.php?f=23&t=157048

I noticed another page missing a few days ago. Don't recall which one. I also discovered https://help.mikrotik.com/docs/. The main page states "While the documentation is still being migrated, many additional articles are located in our old documentation portal."

Before moving stuff to new documentation (you found the link), we deleted pages that are outdated, incorrect or have non-working examples. Such articles existed, because a long time ago, anyone could add articles, even wrong ones.

OK Normis. I checked the new location before, it was not there (it's in the Forum, but that's not an official documentation spot for me)

This explaination (collaboration of your users and presentation at MUM) is a highly non trivial, non intuitive, but an excellent working way of having failover without the need for scripting.
Mostly in the forum users ask: how does this work? The usage of recursive routie calculation and well chosen "scope" settings is not easy to understand.
Documentation of this is crucial not to loose the magic combination. Mikrotik docs is too often about the possible parameter values (reference manual) , not how things work or should/could be used (operation guide). It's improving though.

I very frequently use that solution, to choose the right upstream router that has internet access, but it is only a variation because it's only for outgoing connections, and I don't even need that "mark route" for ingress requests or for load balancing. Now it is difficumt to point other users to that solution.

IMHO "the new documentation" (just like the old Wiki) has the same problem that there is no way to select a version of RouterOS and get the documentation relevant to that version.
I don't think it is necessary to maintain a complete historic overview of every version that has ever been available, but there should be separate documentation versions/views related to the release channels currently available!
If only to encourage the employees to IMMEDIATELY update documentation for every change they make in the testing version (which then later gets renamed to current then to stable) and have no excuse to postpone that until the testing version becomes current.

In the Wiki, there still are features that have never been documented and other things that never got cleaned up (good that you are attempting that now), and when there is no standard working procedure of having a documentation update for every new release version (even when only a candidate in testing) it will always remain that way.

Also when working on a new documentation system, there should be some tool that shows you all the release notes published between two versions that you select.
(by selecting all notes that have been stored for all versions between those)

We don't plan to rewrite all the documentation for every change, simply because there are also new features and changes in one v6 between sub versions too.

I would have hoped that there is some support for version control and branches in your new flashy documentation system...
The fact that there are small changes that have effect on the documentation is precisely the reason that it would be better to do it that way.
Without such tracking, there tends do be documentation scattered over manuals, release notes, forum posts etc which is hard to search when you are deploying some feature and are unaware of its history.