I gratefully accept my flogging for the ULA suggestion. I was unaware of the issues.
i think the “single bridge” thing is very relevant mostly on new equipment which includes an integrated Switch like ccr2116/2216
i have the same habit of using a bridge for wan interface even when using only a single port as a useful tool to do some L2 trouble-shooting, if you dont enable vlan filtering on that bridge the CPU overhead is very hard to notice
i think that habit will have to disapear when using ccr2116/2216 in favor of single bridge because of integrated switch which affect all interfaces except mangement eth
No flogging needed. The creators of ULA weren’t aware of it either until last year when we spent the better part of 6 months convincing them of the issues outlined in the draft on the IETF v6ops mailing list. 
Joining that mailing list. Thanks again!
No problem.
Another way to solve this is to just ask for an IPv6 block from the RIR. You can use it as common IPv6 space for internal use. A /40 is free from ARIN until 2026.
https://www.arin.net/resources/fees/fee_schedule/
*There is a temporary IPv6 fee waiver for organizations in the 3X-Small service category. A 3X-Small organization may receive registry services for up to a /36 of total IPv6 space and remain in the 3X-Small service category. This waiver will expire 31 December 2026.
It’s a shame that LACNIC’s prices are not so pleasant.
There’s no other way to put this. Even if it’s purely software/CPU. Multiple bridges will perform worse than a single bridge. Just how it is. I never understood who or where did the idea come from, that “Yay, let’s use multiple bridges, sure this is the best and only way to do it right”.
You can still add the mgmt port into the bridge, but segregate it with VLAN filtering. Or do not at all and leave it as a standalone interface. That’s okay too.
When the difference in performance is not noticable (and in my case I did not notice it), it does not matter. Even when in a purist view it does.
For quite some time (when RouterOS still supported it) I have used configurations without any bridge at all, with VLAN configuration in the switch menu, and VLAN subinterfaces on the master-port. That was even more efficient than a VLAN filtering bridge, especially on older hardware like the 2011 and old 750s.
When this possibility went away, and we all had to use a bridge even when it wasn’t really required, “nobody” complained about the loss in performance.
HW accel of VLAN filtered bridges is still only available on selected models, even though all models supported it through switch config.
But now, this loss in performance is suddenly a dealbreaker? I think not.
Conceptually you’re probably right, but did you observe big difference? Personally I don’t see how performance could differ much between setups where bridges are purely SW … and where one setup has single VLAN-enabled bridge where the other setup has multiple “plain” bridges. After all, VLAN operations of bridge (tagging/untagging, VLAN filtering, etc.) do cost s few CPU cycles as well, possibly more than code selecting the right bridge.
@pe1chl OTOH ensured us that performance hit is negligible.
If, OTOH, you had HW offload in mind, then one has to consider what is offloaded to hardware … for example, quite a few people are forgetting that L2HW offload doesn’t help at all when router needs to perform L3 functions (e.g. routing between different VLANs on low-end devices), if such bridge can not really do L2 functions (e.g. because it’s only got one port), it’s only important to configure it such that ROS won’t attempt to HW offload it. If done properly, things won’t really work less optimally in the big picture.
I’ll say again: there are use cases and device models, where common principles don’t work out optimally. A good administrstor will recognise these occasions and by doing “out of the box” configuration use available resources much more optimally. Not every other administrator may appreciate the solution but that doesn’t give them right to trash talk about those solutions.
If you both bothered to read the official MikroTik docs here: Basic VLAN switching - RouterOS - MikroTik Documentation
For older hardware with a switch chip, specifically here:
You’d see, there are different ways to do the “single bridge” configuration for different device models including the older hardware like 2011 etc without losing performance.
In short, there’s no reason to avoid “single bridge” concept like COVID-19.
I don’t see where linked documents contradict what I (or @pe1chl) actually wrote.
If I could be sure google will never direct some unsuspecting user to this thread I’d stop arguing with you long ago. It’s useless to write arguments to you because you’re stubbornly sticking to some concepts in your head and don’t accept MT reality which is “maximum flexibility” and admin is free to configure whatever fits. And only reason why others should speak against it is if person asking has some problem or if it’s very obvious that concept used is a wrong one.
This assumes that maximum data plane performance is the only consideration when building a network. I think this is a case where “it depends” is very relevant.
The ability to abstract physical interface dependencies in config is something that shouldn’t be overlooked. When throughput performance is not the key driver, there is value in making the config easier and more modular.
The ability to abstract would be ideal if it was not an additional CPU overhead (multiple bridges). Something like how JunOS does interface configuration seem better than “multiple bridges” – where the latter (based on official MikroTik docs) either disables hardware offloading at the most or is just additional CPU overhead to begin with and is generally advised against by MikroTik themselves:
“Instead of creating multiple bridges, create one and segregate L2 networks with VLAN filtering.”
Unless, someone here who defends “multiple bridges” can elaborate on why it is harmless with some actual in-depth Linux kernel stack discussion – Bridges are after all a virtual Linux interface. Perhaps, my understanding of the Linux kernel network stack with regard to this discussion is incorrect i.e. more virtual interfaces on top of the physical interfaces = more CPU overhead. Unless of course, the hardware supports multiple bridges hardware offloading, then my opinion no longer matters.
In short, abstraction that adds CPU overhead in my opinion should be avoided.
At this point, I’d be happy to hear some opinions from MikroTik staff themselves, where if they agree multiple bridges = harmless practice, this should be reflected in their official docs.
Come on, STOP IT! It doesn’t matter when it is not noticable. When you do not want additional CPU overhead, you should not use a router that runs Linux.
All this is not even related to the topic “IPv6 - Multiple bridges with only /64 from ISP”, you have been babbling OFFTOPIC all of the time!
Lol what? What do you think Cisco IOS, JunOS Evolved, and Nokia SR runs on? Windows? What matters is support for hardware offloading of whatever you need that for, in this case single/multiple bridge. Of which only one is supported.
You keep playing your broken record…
Nobody in whole thread claimed that using multiple bridges is completely harmless. We’re only arguing that sometimes the harm is much less than gain.
One question: how can you use custom MAC address per port if you use single bridge? (Yes, I know one can change MAC address on interface directly and skip using bridge, but let’s say one needs some bridge functionality as well, e.g. bridge filters).
For the last time: sometimes one must use unorthodox setups (which might involve multiple bridges) that can not be mapped to glorified single-bridge layout. And none of your crusade will change that. I sincerely hope you can stop playing broken record …
I did check this out before answering, and it is interesting, but since you’re both experts. I recommend you go with your “more gain, less harm” solution called “multiple bridges”. Easy, peasy, right?
I think Google might need an IPArchitech talking to about ULA. I didn’t see them mention dual stack, but looks like they treating it as an rfc1918 clone like I was.