Snooping IGMP e endereços de multicast local de link

Eu tenho uma rede que possui muitos dispositivos enviando dados para 224.0.0.225 em uma VLAN que abrange vários comutadores. Cada dispositivo (aproximadamente 12 deles) está enviando dados de relatórios a aproximadamente 500-600 kbps. Cada porta na VLAN, independentemente de o receptor enviar ou não uma junção, está sendo inundada com aproximadamente 6 Mbps de tráfego multicast.

A espionagem IGMP é ativada em todos os comutadores e na VLAN local.
O modo esparso pim é configurado no gateway do mrouter / padrão.

Se eu fizer um show ip igmp snooping groupsno switch, não há entrada na tabela de espionagem.

Eu sei que 224.0.0.1 - 224.0.0.255 se enquadram no intervalo de multicast IP reservado local do link, o que significa que um roteador não encaminhará pacotes dentro desse intervalo. Esses intervalos também são usados ​​para o roteamento do protocolo. por exemplo) EIGRP, OSPF, HSRP ... etc

Tenho duas perguntas:
1) Acho que a resposta é SIM - para 224.0.0.1 224.0.0.255 ... o IGMPv2 ignora esse intervalo para bisbilhotar e o switch apenas encaminha isso para todas as portas?
2) Existe uma maneira de forçar o IGMP a bisbilhotar esse tráfego de difusão seletiva e enviá-lo apenas para as portas que o solicitam com uma junção IGMP?

Sinto que esse é um daqueles casos em que os aplicativos / programadores precisam projetar seus dispositivos e aplicativos para respeitar redes não consumidoras escaláveis. Portanto, eles devem usar um endereço multicast no intervalo 239.0.0.0/8.

Continuei pesquisando na internet ... e acho que respondi minha própria pergunta.
Agora preciso voltar aos desenvolvedores do aplicativo / dispositivo e ver o que podemos fazer ou bloquear ainda mais esses dispositivos na sua própria VLAN.

Deixe comentários ou respostas com mais conselhos.

RFC 4541 2.1.2 :

1) Pacotes com um endereço IP de destino fora de 224.0.0.X que não sejam IGMP devem ser encaminhados de acordo com as tabelas de associação de portas baseadas em grupo e também devem ser encaminhados nas portas do roteador.

  This is the main IGMP snooping functionality for the data path.
  One approach that an implementation could take would be to
  maintain separate membership and multicast router tables in
  software and then "merge" these tables into a forwarding cache.

2) Pacotes com um endereço IP de destino (DIP) no intervalo 224.0.0.X que não sejam IGMP devem ser encaminhados em todas as portas.

  This recommendation is based on the fact that many host systems do
  not send Join IP multicast addresses in this range before sending
  or listening to IP multicast packets.  Furthermore, since the
  224.0.0.X address range is defined as link-local (not to be
  routed), it seems unnecessary to keep the state for each address
  in this range.  Additionally, some routers operate in the
  224.0.0.X address range without issuing IGMP Joins, and these
  applications would break if the switch were to prune them due to
  not having seen a Join Group message from the router.

Há outra ressalva: dependendo da plataforma, o switch direcionará todo o multicast local de link para a CPU. Isso inclui, por exemplo, tráfego OSPF.

Notei isso no Ciscos Catalyst 4500, que enviará todo o tráfego 224.0.0.x para a CPU. Quando a CPU está ocupada, ela descarta os pacotes, incluindo os pacotes OSPF. Divirta-se depurando por que suas sessões OSPF são interrompidas.

Também desativar o rastreamento de igmp na plataforma não ajuda. Em algum momento, a Cisco notou que essa provavelmente não é a melhor ideia e apresentou o comando:

access-list hardware capture mode vlan

Isso fará a ponte dos pacotes multicast no hardware.

Consulte http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/secure.html#wp1128851 para obter detalhes