3

I recently noticed that my IPv6 multicast traffic was being broadcasted to all hosts connected to a switch, even those that had not subscribed to the traffic.

To fix this, I enabled MLD snooping on the switch, and this fixed the issue - now only those hosts that have subscribed to a given multicast group receive traffic for it, great.

However this broke basic IPv6 functionality on the network, and I could no longer connect to (or even ping) hosts connected to the same switch.

The problem turned out to be that the IPv6 neighbour solicitation packets are sent to a multicast address of the form ff02::1:xxxx:xxxx which the switch was not forwarding as it seemed to decide that nobody had subscribed to those multicast groups.

My question is, is this a bug in the switch's IPv6 firmware, is it because I haven't configured MLD snooping properly, or is it because I need to configure each host to send MLD subscriptions for those particular multicast groups?

I am not sure what the correct behaviour is for MLD snooping and these IPv6 messages. Are hosts meant to subscribe to those groups, or are switches meant to forward on those requests regardless? If they are meant to be forwarded always, are all packets addressed to ff02::/16 meant to be forwarded without subscription, or only ICMP6 traffic? The switch does forward on packets for ff02::1 and similar addresses without any subscription which leads me to think you're not supposed to subscribe to this traffic, but then I find it hard to believe that something that almost immediately breaks all IPv6 traffic would go unnoticed for so long.

The switch unfortunately is long out of support and no longer getting firmware updates (Cisco 2975), but before I go to the effort of replacing it I'd like to make sure it's actually a firmware bug and not something I have just misconfigured that will remain even with a new switch!

Improve this question
8
  • It's possible MLD isn't setup correctly (post your config) It's also possible the hosts aren't doing what they should.
    – Ricky
    Nov 21, 2021 at 5:21
  • I don't have any MLD config as such - it's just a bunch of Linux machines connected to the switch, the switch only has an option for MLD snooping on/off. The Linux machines send join messages automatically which the switch is picking up. Asking the switch to show its membership list shows the correct multicast groups for my custom traffic, but it only lists my custom groups - no ND groups or anything else. I tried this on a Mikrotik switch and it automatically adds the ND multicast groups to its membership list, so I'm thinking it's a missing firmware implementation on the old Cisco.
    – Malvineous
    Nov 21, 2021 at 8:16
  • RFC 4541, Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches has been around for over 15 years. Snooping switches should not block link-local multicast.
    – Ron Maupin ♦
    Nov 21, 2021 at 14:28
  • @RonMaupin: I can't see any mention in the RFC of not blocking link-scope multicast, only that MLD is mandatory for it, with a specific exception for ff02::1. This matches the behaviour of my old Cisco switch. Newer Cisco documentation says that ff02:0:0:0:0:1:ff00::/104 is the "solicited-node multicast group" and is implicitly subscribed, which seems to be the workaround for the problem. I can't see this mentioned in the RFC either.
    – Malvineous
    Nov 22, 2021 at 2:12
  • For IGMP, it says, "Packets with a destination IP (DIP) address in the 224.0.0.X range which are not IGMP must be forwarded on all ports." For MLD, "The control and data forwarding rules in the IGMP section can, with a few considerations, also be applied to MLD. This means that the basic functionality of intercepting MLD packets, and building membership lists and multicast router lists, is the same as for IGMP."
    – Ron Maupin ♦
    Nov 22, 2021 at 2:33

1 Answer 1

Reset to default
3

So after doing some more research, it looks like this is a bit of a known issue with IPv6 and MLD snooping as designed is somewhat incompatible with ND.

Switches have always implicitly subscribed each client to certain multicast groups such as ff02::1 however since this issue was discovered, they now also implicitly subscribe each client to another multicast group based on its MAC address as used by IPv6 ND. This ensures that even with MLD snooping active, IPv6 neighbour solicitation messages make it to the intended hosts (and no others, as originally intended by the ND protocol).

In my case it looks like my switch is of sufficient age that this problem did not surface until after the last firmware release.

As the switch allows me to add static multicast groups, I could work around the issue by adding the IPv6 ND multicast address to each port manually, but as this is based on MAC address, it would effectively lock each port to a specific MAC address and would be a headache to maintain.

Looks like it's finally time to replace this switch.

Improve this answer
2
  • Or turn off MLD snooping. Or change the kernel on your linux hosts to include ND/NS addresses in their membership reports.
    – Ricky
    Nov 21, 2021 at 17:37
  • MLD snooping was off to begin with but the traffic was beginning to overwhelm some of the older 100Mbps devices which is why I wanted to turn it on. Modifying the kernel could be done for the Linux hosts, but would mean anything else on the network not running Linux would lose IPv6. For the moment I moved the high traffic streams back to IPv4 so IGMP snooping took care of those, so I could leave MLD snooping disabled without overloading the old devices.
    – Malvineous
    Nov 22, 2021 at 2:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.