Eu trabalho em um produto que consiste em várias caixas Linux sem cabeçalho que funcionam juntas como um cluster.
Essas caixas sincronizam seu estado umas com as outras enviando pacotes multicast IPv6 de link proprietário de formato proprietário (para ff12::xxxx%en0 ). Esses pacotes podem ocupar uma quantidade não trivial de largura de banda quando o estado do sistema está mudando rapidamente, mas tudo bem, porque as caixas do Linux estão rodando sobre uma LAN Gigabit Ethernet e há muita largura de banda disponível.
O problema acontece quando um cliente decide que gostaria de usar seu laptop (ou iPad) como cliente para o sistema enquanto faz roaming no prédio, e então o cliente adiciona um ponto de acesso WiFi à LAN e configura seu laptop para se comunicar (via unicast) com uma das caixas do Linux sobre o WiFi.
Isso geralmente funciona, mas o problema é que todos os pacotes de sincronização multicast enviados pelas caixas Linux estão sendo enviados via Wi-Fi, mesmo que o cliente não precise deles nem os use. Como resultado, a largura de banda de Wi-Fi é freqüentemente afetada, às vezes em um estado inutilizável, e o cliente reclama que nosso sistema não está funcionando corretamente.
Poderíamos, é claro, apenas dizer ao cliente "não faça isso", mas o WiFi é muito útil e eu gostaria de encontrar uma solução mais construtiva para esse problema do que proibir o WiFi. Existe alguma maneira (razoavelmente simples) de configurar um ponto de acesso WiFi para filtrar esses pacotes multicast de sincronização? Simplesmente obter o ponto de acesso WiFi para não lidar com pacotes IPv6 seria suficiente para nossos propósitos, já que o software cliente pode ser executado sobre IPv4 se necessário, mas uma filtragem mais sutil que não impeça todo o tráfego IPv6 seria melhor.
Observe que o ponto de acesso mais comum instalado por nossos clientes é o Aeroporto da Apple, mas se houver outro produto de ponto de acesso WiFi (mais configurável) que funcione melhor, substituir o ponto de acesso por um modelo diferente é uma opção.
Se o seu switch (ou, mais precisamente, o switch do cliente) é capaz de filtrar os pacotes multicast por endereço (bloqueando o prefixo multicast), esta seria minha primeira sugestão.
Exceto que você pode colocar um dispositivo de filtro simples (firewall) entre o WAP e a rede principal que acaba de enviar quaisquer pacotes para / do intervalo de endereços multicast ...
Não bloqueie o tráfego multicast para o IPv6! Funções básicas como o Neighbor Discovery (ARP no mundo IPv4) são multicast e a descoberta do roteador é multicast. Você bloqueia que sua conexão IPv6 não funcione corretamente?
Ter o tráfego de cluster para servidores na mesma vlan como tráfego de acesso do cliente não parece uma boa ideia para mim. Eu acho que separar o tráfego de controle / estado do cluster do tráfego de acesso seria a solução construtiva. Talvez os servidores tenham várias interfaces de rede, tornando simples (e mais barato que os switches gerenciados).
Parece que seus clientes estão colmatando o tráfego Ethernet e WiFi. O material multicast pode funcionar melhor se eles usarem um roteador WiFi ou usarem o dispositivo que eles têm no modo roteador.
Claro que o material do link local não funcionará. Terá que mudar para usar um endereço multicast roteável.