I’m wondering if it is something wrong with my understanding or…
I have simple LAB setup like this:
hap ax3: ether2 - PC A; ether3 - PC B
Default configuration, version 7.14.2. When I set the “STP Protocol Mode” on the bridge to none, I can capture with Wireshark on PC B all traffic that goes from PC A to Mikrotik and vice versa. Every DNS query, all HTTPS, etc. I mean, broadcast traffic also, but there is a lot more than just broadcast. However, when I switch back Bridge settings to xSTP, traffic from PC A is no longer visible.
I’ve tried same settings on RB951 with the same RoS 7.14.2 and there is no such behaviour. Could you please explain me what is going on with this ax3 device?
In theory that has nothing to do with bridge mode (none, STP, RSTP, MSTP). Bridge mode is about loop detection (and blocking ports where loops are detected).
What you see is likely effect of improper FDB[*] handling and/or L2 hardware offload. The basic functionality of a bridge (or switch) is that it only forwards frames to ports where destination is reachable. Only if destination whereabouts are not known then frames are “flooded” to all bridge/switch ports.
[*] FDB (a.k.a. Forwarding DataBase) contains mapping between destination MAC address and port which connects towards that MAC address. Until bridge/switch sees a frame with src-mac-address and notes ingress port, FDB doesn’t have matching entry. After receiving it, FDB gets updated and frame “flooding” stops.
L2 HW offload can affect the “visibility” as well, bot not exactly the traffic direction you mention. If L2 HW offload is enabled, then traffic between a pair of bridge/switch port will not pass CPU (it’ll be handled by switch chip), so sniffer or torch will not see such traffic. However this doesn’t affect visibility of traffic between external port and device CPU.
But anyway, changing configuration of bridge (e.g. mode) can flush buffers/tables/etc. and intermittently bridge/switch may seem to operate in a completely different manner. Another possibility (rare, but seen a few times) is that bridge/switch config is improperly applied to hardware (in case of L2 HW offload) … sometimes cold boot (i.e. power off device for a few minutes) fixes it, sometimes it’s actually ROS configuration database (internal binary blob) which gets corrupt and in that case some radical configuration cleansing needs to be done (e.g. netinstall and reconfiguration by using CLI/GUI, without restoring binary backup).
Thank you so much, mkx. Your answer is very helpful.
Yes, I suspected that. It was very weird to me, so I asked for help.
And you are 100% right. When I disable HW offload on one of those two ports, traffic is no longer visible on other bridge ports.
So can I fixed it somehow? Besides not using HW offloading. I mean, this is a new device, default configuration and it has pretty risky behavior I would say… Should I report this to the Mikrotik?
The Qualcomm PPE engine has the potential to dramatically improve the performance of not only the hAP ax2/ax3/Chateau AX but also future Qualcomm IPQ based routers.
How is progress on Mikrotik using the PPE for its various offloads ?: