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.

Improve this question
9
  • 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 7, 2011 at 16:15
  • Shane, I think this is IPv6 multicast traffic - In IPv6 there are no "broadcast domains"
    – jdkoftinoff
    Sep 7, 2011 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 7, 2011 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 7, 2011 at 18:09
  • 1
    @bahamat - I see en.wikipedia.org/wiki/Broadcast_domain and 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 7, 2011 at 18:23

4 Answers 4

Reset to default
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...

Improve this answer
2
  • 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, 2012 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, 2012 at 23:03
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.

Improve this answer
2
  • Okay, then how should I deal with the issue?
    – Jeremy Friesner
    Sep 7, 2011 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 9, 2011 at 6: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).

Improve this answer
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .