Preamble and disclaimer:
The following is a set of Rules that are intended as advice useful to avoid the most common errors observed in configuration posted on this forum.
It is my personal take on the matter, and in no way approved, endorsed or recommended, officially or unofficially, by Mikrotik or their partners or by anyone else.
In other words you are perfectly free to ignore them, though they represent (IMHO) a sort of (good) cheat sheet/reminder for people starting to use these devices.
Experts already know all these issues (and many more) and they already have their own ways to avoid them.


The twelve Rules of the Mikrotik Club:

1. You do not use VLAN1.
2. You DO NOT use VLAN1.
3. You remove default user admin and set a strong password before connecting to the internet.
4. You do not use Quickset.
5. You do not use detect-internet.
6. You manually set admin-mac=<MAC> and auto-mac=no on bridge(s).
7. You take a port out of any bridge and VLAN, give it a static IP and reserve it for management, in any case you don't lock yourself out.
8. You use the default Mikrotik firewall for Soho devices, unless you really know better.
9. You keep routerboard firmware upgraded to the same release as Ros software update.
10. You don't update unless really needed or for experimenting.
11. You don't behave as a jerk on the forum.
12. You appreciate the interconnectedness of all things and settings and contemplate the configuration holistically.

Corollaries:
[1] Really, you shouldn't. VLAN1 is used internally in some parts of the RoS and it can also cause conflicts with other manufacturers devices.
[2] Ok, you can use VLAN1, but only if you understand the implications.
[3] No exceptions. This includes when performing netinstall. Disconnect ALL ports but the one you are using for netinstall AND make sure proper firewall rules are created BEFORE connecting to the internet. For LTE routers disconnect means remove SIM.
[4] You can actually use it, but only once and only starting from a reset configuration.
[5] It serves nothing, and it can create issues, just don't use it.
[6] Strongly advised, it prevents the MAC address of the bridge to be changed in case of other configuration changes.
[7] Particularly if you are going to fiddle with VLANS and firewall, it is very, very easy to lock yourself out of the Mikrotik device you are working on. You should also allow mac-winbox, activate its server but only on LAN and/or on an added interface list "Trusted". mac-winBox allows to access the device if you lock access with IP. Remember that most changes take effect immediately, "Safe mode" is your all time & forever friend. Use it.
[8] The firewall is your only defense against the bad guys out there, think twice before changing anything in the default one, which is good enough in most cases. Only some Mikrotik devices come with a default configuration including the firewall, and even on those in some cases of reset or netinstall it is possible that these firewall rules are deleted, so better check and double check their existence before connecting to the internet. Even if not strictly speaking part of the firewall, the default settings make use of the categorization of interfaces (WAN and LAN in /interface list and actually used interfaces in /interface list member) and these should be checked to be correct and reflecting the actual WAN and LAN status of the interfaces, failing to do so may result in exposing the network to the outside and/or preventing access to the device. For those devices shipped with no default configuration, the first step should be to copy to them the default configuration taken from one of the Soho devices and published on the forum: viewtopic.php?p=856824#p856824 , such configuration will need of course to be adapted to the device number of interfaces and settings of the bridge(s) if any.
[9] Just do it.
[10] Translated from Mikrotikish, Beta means pre-alpha, RC means early Beta, stable means RC, rinse and repeat on a newer version, now you know. (if it ain't broken, don't fix it)
[11] Please, don't. We already have enough of them.
[12] A set of rules without a small reference to Douglas Adams seemed inadequate, but really, Mikrotik settings are often spread in several places, snippets of configurations are often not enough to understand what the problem may be, or, if you prefer, there are reasons why people looking for help are asked to post their COMPLETE configuration (anonymized).

Obviously these 12 Rules are only the tip of the iceberg , Good Practrice and Common Sense Advice numbered from 13 onwards here :
viewtopic.php?p=1128345

13. Don't buy a router with 16BMiB of RAM. You might be okay if it's a switch.

Be aware that the router phones home:
a. when auto timezone detect is enabled [ System --> Clock --- Tab: Time ]
b. when update time is enabled [ IP Cloud --> Tab: Cloud ]

13. Don't buy a router with 16BMiB of RAM. You might be okay if it's a switch.

A. Devices with 16MB of flash are forbidden.
B. Activate MAC-WinBox server but only on LAN side. MAC-WinBox help to access device if you lock access with IP [7]

14. Create a binary backup before any next adventure and practice restore using netinstall and binary backup before other adventures.

Binary backup should be forbidden as it lets restore configuration only on the device where it was created with proper ROS version installed. Use "/export terse file= ....".

Clarified..............

13. Don't buy a router with 16BMiB of RAM. You might be okay if it's a switch.

A. Devices with 16MB of flash are forbidden.
B. Activate MAC-WinBox server but only on LAN side and only to Trusted Interface List entry. MAC-WinBox help to access device if you lock access with IP [7]

Accepted

You made a basic cup, I added the handle, now it can be used for drinking ;-P
Twas a rhetorical addition, no acceptance required.

0: Remove "defconf" comments everywhere

0: Remove "defconf" comments everywhere

+1

0: Remove "defconf" comments everywhere

If I had my way, any configuration edit affecting an entry with a defconf comment would automatically remove that comment.

At the same time, if you've left a given defconf element unchanged, the comment should be left untouched. It's telling you something useful: "This is as MT shipped it. You haven't touched it yet."

Thus why there should be automatic removal of these comments on an as-changed basis.

As a newbie, this thread scares me. Great, now I have to go research the MAC things you mentioned, and I have other things to do today!

Amended corollary to Rule #7 including mac-winbox settings.
Whether buying or not 16 Mb devices is out of the scope of the basic rules, though it is a generic good advice.
That when an entry commented as "defconf" is changed also the comment should be changed is also extremely good advice, but - like the above - is beyond the scope of the basic rules.
I will add it to a new, separate list, something like "good practice" or "common sense", like the time zone/cloud time phoning home.
Making binary backups suggestion won't enter any list of mine, sorry.

Disconnect/block internet/untrusted network to the router when performing netinstall until proper firewall rules are created (if netinstall is done without config) and admin user strong password is set or admin replaced with other user. For LTE routers disconnect means remove SIM or netinstall with script that disables lte interface on first boot.

Disconnect/block internet/untrusted network to the router when performing netinstall until proper firewall rules are created (if netinstall is done without config) and admin user strong password is set or admin replaced with other user. For LTE routers disconnect means remove SIM or netinstall with script that disables lte interface on first boot.

Now included in Rule #3 corollary.

OMG ... there is no rule:

Nth. Remember that "Safe mode" is your all time & forever friend. Use it.

[Nth] There is no CISCO-like running and stored configuration. Changes are applied and stored immediately that is why [7] happens.

OMG ... there is no rule:

Nth. Remember that "Safe mode" is your all time & forever friend. Use it.

[Nth] There is no CISCO-like running and stored configuration. Changes are applied and stored immediately that is why [7] happens.

Added in corollary to #7.

On the contrary, I would even make it a rule: Do not trust "safe mode."

@infabo, a post without any reasoning, that is contrary to Bartosz' input ( whether I agree with it or not ) is GARBAGE. If you have some logic/reasoning to add please do so.

...Added in corollary to #7.

I'd add a distinct point on that as corollary #7 suggest "safe mode" beeing strongly linked with rule #7 what is IMHO not good as it should be a general advice.
However it's your list so you decide

0: Remove "defconf" comments everywhere

+1

@anav where was the reasoning for this? Anyway, I have a reason for this proposal. More on it later.

I'd add a distinct point on that as corollary #7 suggest "safe mode" beeing strongly linked with rule #7 what is IMHO not good as it should be a general advice.
However it's your list so you decide

I am a bit dubious on this one, the present Rules are (in my perverted mind) recommendations to avoid common errors, not suggestions on how to make anyway the errors and get away with them.
In the context of not locking oneself out it makes sense to mention that changes are immediate as a further warning, in the more general way Safe Mode belongs IMHO to the other GP and CSA list.

EDIT: Added in viewtopic.php?t=215018 as point #20 with (hopefully) a balanced view between the two extremes.

On the contrary, I would even make it a rule: Do not trust "safe mode."

As Forest Gump's Mommy might say:

Forest, if you have safety belts built-in then use them even if they cannot be fully trusted and used as a panacea for everything.

She was very clever Mum

On 7) don't get locked out. RoMON is a great tool , and MAC Telnet is another good one, if you ever change a remote IP network,

(Maybe not for everyone. Just my experience)

Binary backup should be forbidden as it lets restore configuration only on the device where it was created with proper ROS version installed. Use "/export terse file= ....".

True, but for snapshot and quick return point it’s excellent. I haven’t tried in years, but IIRC textual export was not guaranteed to restore correctly as lines in it were not ordered by dependencies.

Restoring to the different device is a topic of Rule15: if restoring to the different hardware 1) create textual export on old device 2) study block diagram of a new device 3) modify old textual export to fit the new device 4) reset new device without config, connect using MAC and apply your new configuration.

There won't be any rule 0, 13, 14 or 15, the twelve rules are 12, numbered from 1 to 12.

GP and CSA list items #17 and #18, JFYI:
viewtopic.php?t=215018

+1

@anav where was the reasoning for this? Anyway, I have a reason for this proposal. More on it later.

You will have to ask the originator, Patrick who Posted the Entry, mine was only a +1, LOL. The reason I gave it a +1 is the amount of time
I spend deleting default config remarks from many responses....... From looking at many configs, its clear that those that dont understand RoS dont understand the comments either, so they really dont help much.

3. You remove default user admin and set a strong password before connecting to the internet.

I have written in the past NOT to remove the admin user, but to leave it there harmless, without right, with a random very long password.

Now that the CVE is public, you can learn the reasons. In the past I refused to explain why, now you know why.

Off topic discussion is there: viewtopic.php?t=215057

Off topic discussion is there: viewtopic.php?t=215057

The requested topic does not exist.

Off topic discussion is there: viewtopic.php?t=215057

The requested topic does not exist.

...adn now is there
viewtopic.php?t=214751

was consolidated on a previous related topic already addressed it

According to:

(6) Is there any procedure suggested how to choose that MAC? The lowest interface MAC, the highest? Private? Multi- or unicast? https://www.shiksha.com/online-courses/ ... and-types/
(8) I'd mention that not all devices after reset have default firewall installed&ready. Existance of firewall rules should be always checked&verified as some could reset/netinstall device with no default configuration.

@BartoszP
#6 There are a few posts by mkx and rextended that go rather deep on the matter, I'll see if I can understand the written or non-written implications and produce something easy to understand and replicate.
viewtopic.php?t=209850
viewtopic.php?t=209275


#8 working on it

As not only Wiki says that

Addresses can either be universally administered addresses (UAA) or locally administered addresses (LAA).
To define LAA MAC the U/L bit of the first octet (bit 1 ) has to be set to 1.
To define Unicast packet the I/G bit of the first octet (bit 0) has to be set to 0 - we need unicast as we expect one-to-one communication with the bridge be possible.

Therefore the first octet should be formatted as ( b=0|1):

bbbbbb10

that gives us 4 posiible types of MAC groups

x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
xA-xx-xx-xx-xx-xx
xE-xx-xx-xx-xx-xx

I prefer using EE as the first octet as it clearly shows that MAC address is "unusual" however it's only a matter of "visual taste". Any other combination is also good.

EDIT:
It should be considered if the "highest" 'EE' octet should be used or the "lowest" '02' as if STP comes into play then it has to be chosen properly

... if STP comes into play then it has to be chosen properly

if STP comes into play, then one really should set bridge priorities according to topology. One never knows when some "genious" will set MAC 01:00:00:00:00:00 to his bridge while bridge ports are set to default value of edge=auto.

[11] You don't behave as a jerk on the forum.

• "Google is your friend: search before posting."
• "Use code tags around configuration and commands."
• "Mark a topic as 'solved' when the original question has been answered."

"If you ask LLM for help then be consistent asking it untill you solve the problem. Do not ask forum users to correct LLM."

[11] You don't behave as a jerk on the forum.

• "Google is your friend: search before posting."
• "Use code tags around configuration and commands."
• "Mark a topic as 'solved' when the original question has been answered."

...

"If you ask LLM for help then be consistent asking it untill you solve the problem. Do not ask forum users to correct LLM."

I don't know , these seem to me more like "use some common sense [1]", I had in mind something more along the lines of "be polite, don't be senselessly argumentative, respect other members and their ideas, etc."

What you suggest is more along the lines of the classic:
http://www.catb.org/esr/faqs/smart-questions.html




[1] one of the less common things around, usually

# Set high scope value for default gateways to prevent unwanted recursion

As not only Wiki says that

Addresses can either be universally administered addresses (UAA) or locally administered addresses (LAA).
To define LAA MAC the U/L bit of the first octet (bit 1 ) has to be set to 1.
To define Unicast packet the I/G bit of the first octet (bit 0) has to be set to 0 - we need unicast as we expect one-to-one communication with the bridge be possible.

Therefore the first octet should be formatted as ( b=0|1):

bbbbbb10

that gives us 4 posiible types of MAC groups

x2-xx-xx-xx-xx-xx
x6-xx-xx-xx-xx-xx
xA-xx-xx-xx-xx-xx
xE-xx-xx-xx-xx-xx

I prefer using EE as the first octet as it clearly shows that MAC address is "unusual" however it's only a matter of "visual taste". Any other combination is also good.

EDIT:
It should be considered if the "highest" 'EE' octet should be used or the "lowest" '02' as if STP comes into play then it has to be chosen properly

I propose that one of the Rules of Mikrotik Club is that all rules must be comprehensible to anyone with at least: (1) a Masters degree or higher from an accredited univeristy, (2) at least 2 years of actively managing MT devices, (3) at least 30 years old, or (4) of at least average intelligence.

Seeing as I qualify on all (and not just any 1 of those conditions, which would be sufficient), and do not fully understand the above MAC address discussion, then this topic or rule should not be included in the RoMC (Rules of Mikrotik Club).

Seeing as I qualify on all (and not just any 1 of those conditions, which would be sufficient), and do not fully understand the above MAC address discussion, then this topic or rule should not be included in the RoMC (Rules of Mikrotik Club).

Well, it seems to me like - notwithstanding your otherwise impressive qualifications - you missed that there is not any discussion above, just a proposal, the actual discussion takes place here:
viewtopic.php?t=215082
The final scope is to find agreement on a simple, basic, suggestion/method on how in practice one should implement Rule #6, to be added to the relative corollary.
Once determined (apodictically and axiomatically) that auto-mac=yes is not good, besides setting auto-mac=no a MAC has to be manually assigned.

There are at the moment three somewhat diverging opinions/theories, each one with its pro and cons (and possibly more, niot yet expressed ones) :
1) use the same MAC of the first ethernet port belonging to the bridge (usually ether2), this is what the Mikrotik configuration normally does (risk of duplication if ether2 is taken off the bridge)
2) use the same first 5 bytes (already common to all interfaces on a single device) but change the last one to one not already used (very low risk of duplication with another Mikrotik device)
3) use the last 5 bytes of the address of first port on the bridge but change the first one to any of x2, x6, xA or xE (very, very, very low risk of duplication but losing the "Mikroitik MAC signature")

On simple enough networks, and without changes to the configuration, any of them would do nicely, so "normal" users can choose any of them, but the intended scope of Rules of this kind is to provide a single recommended method, not to provide a catalog of options, at the end "there can be only one".

As always, you have quickly and precisely identified the problem and thoroughly and clearly addressed it. Thank you!

Seems like each of those 3 possible recommended procedures would be wise.

While the phrase "Mikrotik MAC signature" (MMS) is new to me, the idea and usefullness of it stood out from near first-encouter. That is, I like the ease of identifying MT devices. Perhaps, then, the question is comparing (1) the real-world usefulness of the MMS with (2) the real-world difference between "very low risk of duplication" and "very, very, very low risk of duplication."

While the phrase "Mikrotik MAC signature" (MMS) is new to me, the idea and usefullness of it stood out from near first-encouter. That is, I like the ease of identifying MT devices. Perhaps, then, the question is comparing (1) the real-world usefulness of the MMS with (2) the real-world difference between "very low risk of duplication" and "very, very, very low risk of duplication."

No surprise it is new, I just invented it [1], the official name is OUI (Organizationally Unique_Identifier):
https://en.wikipedia.org/wiki/Organizat ... identifier


[1] and BTW being myself the dictionary guy , I don't even have to pay the $10 or $20 fee :
https://www.marriedtothesea.com/030807/dictionary.gif

So we are talking about the mac address of the bridge itself.
This only affects non-soho devices, as soho devices by default (pun intended) have auto-mac set to NO, and a unique mac address is already assigned to the bridge.
(by inference it affects all devices for which the soho defaults are not included, or where an admin has declined the defaults on initial setup etc.)

In these cases, (non-soho) the devices now get an auto mac assigned typically from first port assigned to bridge.
Three work arounds have been provided.
Has MT been asked to revise the bridge mac setting from auto to OFF (manual) for all non-soho devices as standard?

The problem is not there.
One must always know what he is doing.
For example, in the default configuration of a hAPax²,
if a novice deletes or deactivates the bridge he immediately loses control of the device and must netisntall it from scratch to access the configuration again...
(out of the bridge MAC telnet/winbox not work, interface do not have any IPs)

RouterOS contains absolutely nothing that prevents "tragic errors" like these two listed above, and many others.

That is strange, I am a complete RoS moron, and dont know 95 % of these quirks, but I never hung myself on that one yet........ or probably didnt even know I had.
Tragic,.... well perhaps if on the front line in Kursk and relying on MT for orders, otherwise, perhaps unfortunate LOL>

On a positive note, I have used the 12 days of xmas, er MT CLub, for the time on a post today.......... viewtopic.php?p=1129825#p1129825

Is OP saying not to use VLAN1 as in PVID1? Not use for what? Forwarding? Admin VLAN? Its confusing...

Is OP saying not to use VLAN1 as in PVID1? Not use for what? Forwarding? Admin VLAN? Its confusing...

See? That's exactly why one should stay away from VLAN 1 in any incarnation (PVID, VID, anything).

...but VLAN1 is usually the main LAN. VLAN1=LAN without presence of other VLAN's. Not using it means MikroTik requires at least one other VLAN, which is silly...

...but VLAN1 is usually the main LAN. VLAN1=LAN without presence of other VLAN's. Not using it means MikroTik requires at least one other VLAN, which is silly...

Sure, it is the Mikrotik default, MIkrotik (not you) made those settings, you leave them alone, do not make any new settings involving VLAN =1 (or PVID=1), i.e. you don't use it.

I think VLAN 1 is the default LAN for most routers supporting VLAN's. Besides, if I try not to use it (as in not assigb any bridges to VLAN1), I get locked out.

I think VLAN 1 is the default LAN for most routers supporting VLAN's. Besides, if I try not to use it (as in not assigb any bridges to VLAN1), I get locked out.

Well, you can do whatever you see fit, as long as you don't lock yourself out and your router or switch configuration works.

I think VLAN 1 is the default LAN for most routers supporting VLAN's. Besides, if I try not to use it (as in not assigb any bridges to VLAN1), I get locked out.

Using VLAN 1 is somehow in same category as using QuickSet: it's fine if left alone. But when you start tinkering with settings, you better stay away from either ... unless you know real good.

As written many times: yes, VLAN ID 1 is perfectly valid VID. The problem is that default settings are not shown (e.g. in export) so it's not obvious how VLAN 1 is used. And if one doesn't know very well what he's doing, it's only too easy to miss some default settings and screw the config. And that goes for other vendors as well.
And no, "native VLAN" (i.e. untagged over UTP cable) doesn't have to be VID 1, it can be anything.

But then: these rules are set so that inexperienced users can avoid as many f*kups as possible. If you know better, you're welcome to ignore these rules and live a long and prosperous life.