3

I work on a product that consists of a number of headless Linux boxes that work together as a cluster.
These boxes synchronize their state with each other by sending proprietary-format link-local IPv6 multicast packets (to ff12::xxxx%en0). These packets can take up a non-trivial amount of bandwidth when the system state is changing quickly, but that's okay because the Linux boxes are running over a Gigabit Ethernet LAN and there is plenty of bandwidth to spare.

The problem happens when a customer decides he'd like to use his laptop (or iPad) as a client to the system while roaming the building, and so the customer adds a WiFi access point to the LAN and sets up his laptop to communicate (via unicast) with one of the Linux boxes over the WiFi.

This typically "sort of" works, but the problem is that all the multicast synchronization packets sent by the Linux boxes are now being sent over WiFi, even though the client(s) don't need them or use them. As a result, WiFi bandwidth is often impacted, sometimes to an unusable state, and the customer complains that our system isn't working properly.

We could, of course, just tell the customer "don't do that", but WiFi is very useful and I'd like to find a more constructive solution to this problem than just forbidding WiFi. Is there some (reasonably simple) way to configure a WiFi access point to filter out these synchronization multicast-packets? Simply getting the WiFi access point to not handle IPv6 packets would be sufficient for our purposes, since the client software can run over IPv4 if necessary, but some more nuanced filtering that doesn't preclude all IPv6 traffic would be nicer.

Note that the most common access point installed by our customers is Apple's Airport, but if there is another (more configurable) WiFi access point product that would work better, replacing the access point with a different model is an option.

voretaq7
  • 79,345
  • 17
  • 128
  • 213
Jeremy Friesner
  • 1,311
  • 1
  • 14
  • 25
  • 1
    Is it an option to have the wireless run on a separate broadcast domain, or does the IPv4 communication depend on that too? – Shane Madden Sep 07 '11 at 16:15
  • Shane, I think this is IPv6 multicast traffic - In IPv6 there are no "broadcast domains" – jdkoftinoff Sep 07 '11 at 16:17
  • 1
    Not only that but the typical default for wireless access points is to reduce the data rate to 1Mbps for multicast packets. – jdkoftinoff Sep 07 '11 at 17:07
  • @jdkoftinoff: Although there are no broadcasts in IPv6, "broadcast domain" is a L2 term and thus still appropriate regardless of the L3 protocol. – bahamat Sep 07 '11 at 18:09
  • 1
    @bahamat - I see http://en.wikipedia.org/wiki/Broadcast_domain and http://en.wikipedia.org/wiki/MAC_address and the appropriate function/term on L2 is 'multicast' in the destination mac address. BTW shutting off multicast traffic would also break ipv6 since ipv6 requires multicast for link local address assignment. – jdkoftinoff Sep 07 '11 at 18:23
  • @jdkoftinoff Just because IPv6 doesn't use broadcast packets doesn't mean that a non-v6 broadcast can't be sent. You're confusing the layers. Layer 3 is not layer 2. The term "broadcast domain" is similar to what you may think of as a VLAN, but is more generic. – bahamat Sep 07 '11 at 18:51
  • Broadcast packets are not the problem here, ipv6 multicast is, and the question is about blocking ipv6 multicast yet (ideally) keeping ipv6 non-multicast messages. – jdkoftinoff Sep 07 '11 at 23:58
  • If it is multicast packets then why is the wifi sending them? It should only be sending a multicast packet to a network if there is someone listening for it on that network. – Zan Lynx Oct 28 '11 at 09:11
  • @Zan ideally you would be correct. In practice, however, a lot of devices seem to fall back to dumb broadcast mode, because they don't want to be bothered to keep track of which clients are subscribed to what multicast groups. :( – Jeremy Friesner Feb 13 '12 at 21:10

4 Answers4

4

Don't block multicast traffic for IPv6! Basic functions like Neighbor Discovery (ARP in the IPv4 world) is multicast and Router Discovery is multicast. Is you block that your IPv6 connection will not work correctly.

Sander Steffann
  • 7,572
  • 18
  • 29
  • Okay, then how *should* I deal with the issue? – Jeremy Friesner Sep 07 '11 at 21:55
  • Access points limit the amount of multicast traffic, so using up all bandwith is not a problem. It might block other multicast traffic though. You can filter on those specific multicast addresses. You would need a more advanced access point, like a Cisco. – Sander Steffann Sep 09 '11 at 06:16
2

Having clustering traffic for servers on the same vlan as client access traffic does not sound like a good idea to me. I'd think separating the cluster control/state traffic from access traffic would be the constructive solution. Maybe the servers have multiple network interfaces making this simple (and cheaper than managed switches).

Koos van den Hout
  • 1,086
  • 6
  • 9
1

If your switch (or more accurately the client's switch) is capable of filtering the multicast packets by address (blocking the multicast prefix) that would be my first suggestion.

Barring that you can put a simple filter device (firewall) between the WAP and the main network that just drops any packets to/from the multicast address range...

voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • Just for the record, I've found a solution for Apple's Airport Extreme access point is to set its router mode setting to "DHCP and NAT", and connect it to the network switch via its uplink port. In that mode it will not forward unsolicited UDP packets from the network switch onto the WiFi, and thus the multicast packets are kept off of the air. – Jeremy Friesner Feb 17 '12 at 22:27
  • @JeremyFriesner If you mean the WAN port you're potentially creating a double-NAT situation (the Airport will be handing out DHCP addresses on a private network to wireless clients) - if your internal network is also NAT'ed you may experience some odd behavior. Just something to be aware of. – voretaq7 Feb 17 '12 at 23:03
0

It sounds like your customers are bridging the Ethernet and WiFi traffic. The multicast stuff might work better if they used a WiFi router or used what device they have in a router mode instead.

Of course then the link-local stuff will not work. It will have to change to be using a routable multicast address.

Zan Lynx
  • 886
  • 5
  • 13