Then the max. 250 - 300 s lag can be expected, as explained previously.
The fdb for any bridge, hardware or software, by design is only fed (learning) from the downstream ports but not the upstream ports.
The switch’s upstream CPU facing ports (5 & 6 in this case) are:
- not DSA ports (check with
ethtool -i eth0|ethtool -i eth1) - not part of the hardware bridge
- not learning ports that feed into the switch’s fdb
The software bridge that eventually enslaves the WLan port and the DSA port has it is own fdb which the switch knows nothing about and equally the software bridge is unaware of the switch’s fdb.
Not sure whether creating a multicast group (bridge mdb) could be a potential workaround.
Afaik that is the case. Some switches provide QoS but that is then an upper protocol layer.