Once the Neighbor entry for this client times out, and the client tries to establish a connection using IPv6, it fails.
In the screenshot you can see the configuration of the bridge and the port the client is connected to (via another smart switch).
The traffic capture shows the traffic when the client tries to ping google.com.
Simple network diagram:
CCR1009 (br.master) -- Port "combo" (vlan 22 tagged) ----- (vlan22 tagged) Port 1 -- Netgear GS105 -- Port 2 (vlan 22 untagged) -- PC
When ROS tries find out the mac-address of the client by sending a Neighbor Solicitation Message, from the router's perspective no client (bridge port) has joined that specific multicast group, and since igmp snooping is enabled on the bridge, the NS won't leave the bridge.
As a result the router won't get a Neighbor Advertisement back, the client's mac address is shown as 00-00-00-00-00-00 in the neighbor list and communication fails.
To me the problem seems to be that the bridge at some point removes the multicast group of the client from the mdb table, while Windows has still joined that group.
GROUP VID PORTS BRIDGE ff02::1:ff0c:bfd5 22 combo br.master
No firewall rules, no bridge filters were active during the test.
Is there an error in the (multicast) configuration of the bridge, or anything else I could check?
This problem exists for a long time and is not version specific. I'm currently using ROS 6.46.6 on the CCR.
This only seems to affect Windows Clients. Linux somehow manages that the group doesn't get removed from the mdb table.