Doubts on mac-address on bridge, uniqueness, LAA etc.

A known recommendation when setting up a Mikrotik device is to NOT have the bridge(s) configured with auto-mac=yes, but rather assigning manually a MAC and set auto-mac=no.
The “default-default” (i.e. no configuration like after a reset or netinstall and on devices that have not a default configuration from Mikrotik) is auto-mac=yes, which implies that the automatically assigned MAC is the same as the first ethernet port added to bridge.
With a change of configuration involving changes in the port(s) assigned to the bridge this MAC can (silently and automatically) change, which may cause issues.

The default configuration of a SoHo device does instead through a script that assigns a MAC address and sets auto-mac=no.
Some details on the procedure is given here:
http://forum.mikrotik.com/t/error-in-gateway-non-zero-ip-address-expected-when-using-quick-set/181665/1

The MAC assigned to the bridge is anyway a duplication of the first ethernet port found in the bridge.

So, when/if that port is (for whatever reasons) taken out of the bridge, there will be a duplicate MAC address on the device.

While this is unlikely to cause issues in most “simple” configurations, it may on some more complex one or when references to the bridge interface are used in scripts, etc.

It is good practice (IMHO) to consider the MAC addresses in a device as if they were UIDs (highlighting the unique in Unique IDentifier), with two features:

  1. immutability
  2. uniqueness

And here comes the questions/topics to debate on:

How to “invent” a MAC to manually assign to bridge with these characteristics?

Is this a correct way to quickly list all MAC addresses assigned to all the interfaces?

:foreach i in [/interface print detail as-value] do { :put ( $i -> "name" . " = \t" . $i ->"mac-address")}

On a hap lite that I have handy, the above script (in 6.49.17) has the output:
ether1 = CC:2D:E0:7A:D5:33
ether2 = CC:2D:E0:7A:D5:34
ether3 = CC:2D:E0:7A:D5:35
ether4 = CC:2D:E0:7A:D5:36
pwr-line1 = CC:2D:E0:7A:D5:37
wlan1= CC:2D:E0:7A:D5:38
bridge1= CC:2D:E0:7A:D5:40

(I believe I have changed manually the bridge MAC at the time I configured it)

The first three values, CC-2D-E0 are OUI (Organizationally Unique_Identifier
https://en.wikipedia.org/wiki/Organizationally_unique_identifier
and “identify” Routerboard.com:
https://maclookup.app/macaddress/cc2de0

Doing as above (adding arbitrarily a MAC with the last value greater than all the ones present on the device and assigning it to the bridge) is - in theory “wrong” as - while it is safe from duplication on the same device, it has a probability (very low[1]) to create a conflict with another device on the same network (and of course it depends on the size of this network, in my case, the hap lite is the only Mikrotik device so I am pretty much certain that the probability is 0).

On the other hand, using LAA (Local Administered Address):
http://forum.mikrotik.com/t/new-mac-address-on-the-bridge-after-the-update/177812/1
http://forum.mikrotik.com/t/the-twelve-rules-of-mikrotik-club/182164/1
I.e. taking one of the existing addresses (let’s say ether1 as it is the interface that exists on all or almost all Mikrotik devices for the sake of the reasoning) and changing the rightmost value of its first byte to any of 2,6 A or E:
C2
C6
CA
CE
while creating a unique address makes (obviously) the OUI m00t, which may (or may not) have other consequences.
At this point the first C could also be changed, as an example BartoszP suggests EE as being distinctive and easy to remember, so that these “invented” MAC’s are easy to recognize.

What do you think of the one (or the other) approach?

All this said, is it the case of putting together a script to make this configuration setting easier to make for a beginner?

Something like the scripts talked about here:
http://forum.mikrotik.com/t/script-for-setting-locally-administered-mac-address-on-bridges/177344/1





[1] if the number of reserved OUI is correct, roughly 1/(2^24-6) or 1/16777210

I’ve written post there: http://forum.mikrotik.com/t/the-twelve-rules-of-mikrotik-club/182164/35 and I quote it here just to keep discussion in one thread


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

To be honest, I am not really seeing the issue with bridge MAC address changing because of config changes with respect to attached ports ?

As long as it is unique (which is the case for any normal physical port), what’s the possible problem ?
Maybe this needs to be clarified first before diving into the complexity of creating your own MAC addresses ?
Because I think for the majority of devices, it’s a non-issue.

Just asking:

A. STP relies on MAC so if you change MAC then STP is/could be recalulated.
B. What about “IP Firewal” for bridges where MACs are used to to distinquish packets?
C. When you move an interface out of bridge what happens to ARP? Is it cleared or some packets go to the interfeace instead of a bridge untill the MAC:IP binding get updated?

Good questions.

1- shouldn’t be a problem on itself. STP gets recalculated all the time with adding and removing of devices, no ?
2- true but now we’re already far from normal use. Besides in most cases I encountered, it’s the MAC address of client being used ? Not the one from the connected port. I could be wrong here.
3- Does it matter much if it first goes to interface instead of bridge until updates are being done ?

Ad. 1. Only if that devices are STP enabled. Doubt that adding a PC to the network triggers recalculation.
Ad 2. If we are on the “Simple rules of thumbs” territories then changes to the admin MAC are also out of scope.
Ad 3. No matter where it goes, packets “flow over” or “end their life” using a different “object” that means possibility of a different set of rules be obeyed.