Change VLAN MAC address - which is the current recommended way?

RouterOS Beginner Basics
1

Hello,

I hope you are well.

As far as I skimmed the forum and help, it looks like there are two up-to-date ways to change the VLAN MAC address

  1. create a bridge with a custom MAC and slave VLAN to it - VLAN will inherit the MAC address of the new bridge
  2. manually mangle MAC address in ingress and egress packets using /interface bridge nat

I’ve read advice around the forum and help that it’s no longer recommended to create several logical bridges if the device has one physical bridge, otherwise L2 offloading will suffer, and instead, manage VLANs via VLAN filtering. Will the logical bridge in the first approach harm performance in the same way? Will it hurt L3 offloading capabilities? Or does the advice against several bridges only correspond to physical topology vs logical, not fully virtual bridges? I’m not sure how to check if there is harm empirically.

Regarding the second approach, I worry that I will forget/don’t know how to exclude some edge cases where this mangling should be skipped. I’m not sure whether to apply mangling to the VLAN virtual device or the physical port with the relevant traffic. Etc. I haven’t found any how-to about that, only mentions this should work for the purpose.

The device in question is CRS309-1G-8S±IN.

DHCP Client on tagged interface
2

I haven’t tested it, but the following might work.

You could add a macvlan to the vlan interface.
And set the mac address on the macvlan.
(Though it likely will get handled by the cpu so slow on a crs)

3

Adding a second bridge will involve CPU processing traffic as well (AFAIK ROS still has limit of offloading single bridge per switch chip and CRS3xx in general have single switch chip per device). It is questionable whether bridge nat is actually HW offloaded on this particular device, so performance problems are possible with this solution as well.

What kind of traffic is served by that VLAN? Is it used for management of device (so traffic should not be large and is bound to CPU anyway) oris it used to route traffic (in which case it should be L3HW offloaded not to overwhelm CPU and one really has to care to keep all kinds of HW offload effective.

4

Second type of traffic, unfortunately - performance sensitive.