Page 1 of 1

Understanding acmin-mac (mtik devices mac changes after reboot)

Posted: Mon Sep 09, 2019 10:32 am
by ashpri
I have 20-30 Mikrotik devices in my network, APs and Switches. I use tool>netwatch to monitor their up/down status.

The issue is on some (not all) of the devices, from time to time for what seems to be no reason at all, when the AP/Switch reboots, their bridge mac changes and therefore it would get a new ip address, and be marked as down in netwatch.

What is the correct process to prevent this? Do I simply copy the existing bridge mac into the admin-mac field as so:

2019-09-09 15_28_57-Window.png

Thank you

Re: Understanding acmin-mac (mtik devices mac changes after reboot)

Posted: Mon Sep 09, 2019 11:38 am
by mkx
In CLI definition of bridge has also option called "auto-mac" and if set to "no" (together with static setting of "admin-mac") MAC doesn't change over reboots. WebFig doesn't show "auto-mac" option explicitly, might be set implicitly when one unfolds the "Admin. MAC Address" window and sets the MAC there. I'm not sure about winbox though.

By default, bridge assumes MAC address of the first member port when it starts to assemble. Interface initialization delay might scramble the order, configuration changes (e.g. removal of an interface from bridge) might do even more serious damage (broken connection due to bridge changing its MAC address).
When setting bridge MAC address by hand, you should not blindly copy current MAC due to the possibility of configuration changes mentioned above. But you can assign any locally administered MAC address, just be careful it is unique inside your ethernet network. A good guess is to take current MAC address and change second most significant octet (second digit of the MAC address). Just verify there are not virtual APs defined on same unit that might select the same MAC address.

Re: Understanding acmin-mac (mtik devices mac changes after reboot)

Posted: Tue Sep 10, 2019 5:36 am
by ashpri
Thank you for your reply. It seems to be hugely impractical to manually enter the admin-mac for each device in a large network. I must be missing something. How do other admins with a large number of mtik devices monitor their device up/down status reliably.


This is an example of my netwatch for a Powerbox-Pro switch:

2019-09-10 10_21_34-Window.png

Last night after a reboot, the mac changes, therefore the dhcp ip changes and the status is marked as down. The device is up, but its ip is now

It can't be this difficult to monitor a large number of mikrotik devices in one's network (without resorting to static ip). Am I not implementing something correctly?

Re: Understanding acmin-mac (mtik devices mac changes after reboot)

Posted: Tue Sep 10, 2019 8:49 am
by mkx
I'm afraid that if admin wants to have any kind of supervision, device needs constant IP address. Either set statically or set by DHCP but then one has to assure constant MAC. With ROS versatility it is impossible to come up with MAC addressing scheme which would persist over all the configuration variants. Ii.e. one could argue that each RB should come with an extra MAC allocated to bridge. What about cases where more than one bridge is needed? Same goes with MACs for virtual wlan interfaces ... that case is easier though because those are bound to physical wlan interfaces and setup tends to remain fairly static. Hence MT implemented current scheme which, at boot time, takes MAC address of the first member interface alive to be bridge's MAC address (this scheme works for most cases regardless the number of bridges).

If potentially changing MAC address is not desirable (as it is in your case), admin has to set static MAC address to bridge.

There might be a work-around if you don't want to set MAC addresses on hundreds of devices: abuse MAC discovery mechanism (used by winbox and alike) to get MAC address and try to fetch serial number of device. Then you'll know which device uses which MAC and you will be able to find its current IP address (from DHCP lease database). It's not pretty, I know, but total auto-configuration comes with a cost.