(On the support portal, my tickets are somehow being ignored, one has been hanging for a month and a half without a response, so I’ll write here)
For those who have a hap ax2 - please check, do you also have hw-offload not working correctly ?
- "Traffic mirroring":
- hap ax2, it has a computer connected to port 4, the WAN port of the provider to port 5, and port 2 is the “downlink” to a regular switch for the LAN;
- ports 2 and 4 are combined into a bridge and hw-offload is enabled for them, on ports 2 and 4 in the bridge port settings, the checkboxes for "unknown unicast flood", "broadcast flood", and "hw offload" are enabled; stp setting - "none";
- when the computer is actively sending something (lots of small packets) to the internet (to the MAC address of the LAN interface of the router configured on this bridge) - RX traffic from port 4 is just mirrored (checked with a sniffer and via the torch function) as TX to port 2 ! All packets that are addressed to the internet, not the LAN.
Disabling fast forward doesn’t help, but disabling hw-offload (for the bridge) does help.
- Bug with unknown unicast flood:
if I try, to solve the hw-offload issue, to disable "unknown unicast flood" specifically on port 2 (so that if hwoffload on hap ax2 incorrectly identifies the MAC address and floods traffic, the 'unknown' traffic from the PC doesn’t go to the switch via port 2) - after disabling the "unknown unicast flood" checkbox for port 2 (!!!) - my hap ax2 disconnects from the PC, meaning IPv4 packet exchange between port 4 (!) and the router CPU breaks.
All settings are default (no port mirroring or other hardware features besides hw-offload), firmware 7.24.5;
please check and confirm (and maybe open a support ticket - if they don’t ignore you) if you have such bugs:
-
bug with mirroring to other bridge ports (when hw-offload is enabled) for traffic addressed to the router CPU (to the IP/mac that's set up on the bridge in the router itself and used as the gateway address for the PC)
-
bug with traffic stopping (to restore access to the router if that happens, use "mac winbox server" and connect via MAC address instead of IP) for IPv4 traffic between a port that's part of a bridge (when hw-offload is on) and the CPU when you uncheck the "unknown unicast flood" checkbox for another (!) port on the same bridge
P.S. Yeah, I read the warning:
Using protocol-mode=none on IPQ-PPE enables HW offloaded bridge and can cause issues.
It is recommended to use a non-HW offloaded bridge by keeping the default protocol-mode=rstp setting or by manually setting hw=no under /interface/bridge/port.
on the documentation website
So that means the "hw-offload" feature in HAP AX2 (more precisely, for IPQ-PPE) technically exists, but in reality, even the vendor does NOT recommend using it ??
P.P.S. I don't know how right he is, but Google's AI gave me this answer about the situation:
When MikroTik was developing Hardware Offloading support for the v7 branch, they ran into a fundamental architectural problem:
- By standard, if you configure a pure hardware switch (
protocol-mode=none), the chip is supposed to route frames between ports entirely at the hardware level without ever involving the CPU.- However, in IPQ-PPE chips, when STP/RSTP is disabled, the synchronization of MAC/FDB tables breaks down between the hardware PPE engine and the Linux software bridge. The PPE engine starts acting independently—it stops informing the OS kernel about which MAC address is located behind which physical port.
- This leads exactly to what you caught with your sniffer: the PPE engine went "blind," treated your computer's outgoing frames as unknown packets (Unknown Unicast), and replicated a copy of them to all physical ports, including the uplink to your second switch.