Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
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 '11 at 16:15
    
Shane, I think this is IPv6 multicast traffic - In IPv6 there are no "broadcast domains" –  jdkoftinoff Sep 7 '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 7 '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 7 '11 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 '11 at 18:23

4 Answers 4

up vote 1 down vote accepted

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...

share|improve this answer
    
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

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.

share|improve this answer

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).

share|improve this answer

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.

share|improve this answer
    
Okay, then how should I deal with the issue? –  Jeremy Friesner Sep 7 '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 9 '11 at 6:16

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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