Clients lose IPv6-Connectivity after a few minutes

RouterOS General
1

I have a few clients in a dmz (vlan 22) that use IPv6 for internet connectivity. After a machine boots, it gets the prefix and gateway via SLAAC, connectivity works without issues.
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

IGMP Snooping is disabled on the Netgear switch, and I don’t think the Netgear is causing the problem here.

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

Unplugging and plugging back the network cable restores connectivity for a few minutes.

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.

EDIT:
This only seems to affect Windows Clients. Linux somehow manages that the group doesn’t get removed from the mdb table.
MT.png

2

My brief experience is that on Mikrotik IGMP snooping and IPv6 don’t go together.
It’s RPITA to properly configure IGMP snooping even when there’s a proper multicast upstream router and one can set up multicast-router on apropriate port. However with IPv6 any device can (rightfully) send out multicast packets and those will likely be dropped by ROS with IGMP snooping enabled.
And my experience is that linux hosts suffer as well (even if they have static IPv6 address set … routing breaks though).

Other vendors had similar problems and most (but seemingly not all) have solved the problem.

3

Thank you for your reply.
I have disabled igmp-snooping and now it works.
I hope Mikrotik support is aware of this problem and already working on a fix.

4

Your (and my) problem touches two fields where Mikrotik has larger-than-usual share of problems: IGMP snooping and IPv6 … so I’ll keep my fingers crossed in hope to see improvements in both fields. Not holding my breathe meanwhile …

5

I’m still experiencing this problem in 6.49.2: loss of non-link-local IPv6 connectivity after some time that is suspiciously close to the IGMP Snooping’s Membership Interval.
Packet sniffing shows that an attempt is made on the router side (an appropriate multicast message is “sent”), but it never shows up on actual device.

Have anyone tried IGMP Snooping on v7?

6

I think the igmp-snooping code hasn’t been touched since v6. I had 7.1 running on a CRS328 which caused various problems with multicast - incuding the one I described in my first post.
I moved to SwOS on that device and these kind of problems went away. I’m really not sure what exactly is causing igmp-snooping to stop working correctly sometimes, and at that point I think ROS devs don’t know either. These issues exist since this feature was introduced in 6.4X.
It may be related to other hardware connected to the network, like devices running swos-lite 2.14. There were some complaints in the release thread. No solution so far, it’s really frustrating.

7

same problem.

ipv6 slaac in RB750Gr2, RB3011, it worked in the ROSv6. Since upgrading to v7 , I have always encountered problems with windows, android and linux. From time to time, the ipv6 address successfully obtained before will disappear.

This problem has been bothering since v7, and I rolled back to v6 many times until RB5009, and I can’t use v6.

I found here. After IGMP Snooping of Bridge is turned off, everything seems to be normal!!!

In addition, there seems to be a problem with the Connection State of ipv6 of ROS v7. I hope mikrotik engineers will pay attention to solve it.

8

For RB5009 you can enable “Multicast Querier” http://forum.mikrotik.com/t/rb5009-ros-7-1-1-igmp-snooping-issue-with-l2-hw-offload/155045/5 or disable L2 hardware offloading.
Both methods work with igmp snooping.

9

https://help.mikrotik.com/docs/pages/viewpage.action?pageId=59277403#BridgeIGMP/MLDsnooping-BasicIGMPsnoopingconfiguration
“Bridge IGMP querier implementation can only send untagged IGMP queries. In case tagged IGMP queries should be sent or IGMP queries should be generated in multiple VLANs, it is possible to install a multicast package, add a VLAN interface and configure a PIM interface on VLAN. The PIM interface can be used as an IGMP querier.”

ROSv7 no “multicast package” in extra packages. It seems introduce for ROSv6.

Vlans are used in my ROSv7, so i haven’t tested yet.

10

In ROSv7 an additional multicast package isn’t required, igmp-proxy and pim are included in the base system. However pim is still not functioning in 7.1.3 / 7.2rcX and the igmp part of pim is not yet implemented.
I’m currently using mrouted on a rpi for multicast routing, together with avahi for mdns reflection.