I am new owner of a hEX S, so I never saw this until this month.
Bridge Hardware Offloading has the following in footnote 3.
HW vlan-filtering was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. The switch does not support other ether-type 0x88a8 or 0x9100 (only 0x8100 is supported) and no tag-stacking. Using these features will disable HW offload.
At this time, the MT7621 and RTL8367 can do some things the Atheros/Qualcomm chips can’t (Bridge vlan offloading) but they can’t do Bridge dhcp snooping. For me, the vlan offloading is a much more useful feature.
And the v7.2 testing versions have added more bug/feature fixes for bridge hardware offloading. I just updated to the bleeding edge v7.2rc5 about 4 hours ago on my hEX S. More info about v7.2 fixes here Testing release tree Some bridge highlights follow:
What’s new in 7.2rc5 (2022-Mar-23 12:04):
*) bridge - fixed firewall “ingress-priority” matcher and “new-priority=from-ingress” action settings from VLAN tagged frames;
What’s new in 7.2rc4 (2022-Feb-22 13:37):
*) bridge - fixed FastPath when using “frame-types=admit-only-untagged-and-priority-tagged” setting;
*) bridge - fixed IP address on untagged bridge interface when vlan-filtering is enabled (introduced in v7.2rc2);
*) bridge - fixed PPPoE packet forwarding when using “use-ip-firewall-for-pppoe” setting;
*) bridge - fixed destination NAT when using “use-ip-firewall” setting;
*) bridge - fixed filter and NAT “set-priority” on ARM64 devices;
*) bridge - fixed filter rules when using interface lists;
*) bridge - fixed priority tagged frame forwarding when using “frame-types=admit-only-untagged-and-priority-tagged” setting;
What’s new in 7.2rc3 (2022-Jan-28 16:33):
) bridge - fixed filter and NAT “set-priority” action;
What’s new in 7.2rc2 (2022-Jan-28 11:00):
*) bridge - added fast-path and inter-VLAN routing FastTrack support when vlan-filtering is enabled;
I am a big proponent of configuring the bridge if you are using vlans, and since v7.1rc5 the bridge on the MT7621A devices (RB750Gr3 and RB760iGS) will do this without a significant performance penalty.
Before hardware offloading for the bridge was available, trying to use the hEX as a replacement for the ER-X was a non-starter for me, because I use vlans heavily. Now the hEX has some switching features that ER-X doesn’t, but I haven’t tried them all yet (I haven’t tried using the mirror feature or port isolation features on the hEX). The ER-X evidently allows setting up a mirror port using the undocumented /bin/switch utility, but there is no way to configure this in /config/config.boot, so the only way to get reboot persistence would be a script. And I am not aware of any way to do port isolation on the ER-X (at switch-port level). There are a lot more knobs to turn in RouterOS than on the ER-X, so for some things RouterOS is more flexible, but more complex than EdgeOS.
@HandyDutchGuy If you never plan to use ether3 or ether4, then it really makes no difference, but if the bridge is configured, it makes it very easy to “attach” an unused ethernet port to any vlan you want. It essentially turns the hEX bridge ports into a mini-vlan-aware switch.
So for example, if you wanted to test what the guest Wifi had access to, you could add ether3 as an access port for vlan 30, and if you plugged a Raspberry Pi into the port it would be on the guest network. It can also be a big advantage when something isn’t working on the managed switch connected to ether2.
It probably isn’t worth changing (unless it is currently in a lab situation), but using the bridge has few downsides once you get past the hurdle of wrapping your head around how the bridge works.
The links in this post were helpful to me, when I was trying to learn the new “language” of RouterOS bridges, coming from knowledge about how vlans work on EdgeOS and the vlan-aware switch0 on the ER-X.