Snooping IGMP y direcciones de multidifusión local de enlace

Tengo una red que tiene muchos dispositivos que envían datos a 224.0.0.225 en una VLAN que abarca múltiples conmutadores. Cada dispositivo (aproximadamente 12 de ellos) envía datos de informes a aproximadamente 500-600 kbps. Cada puerto en la VLAN, ya sea que el receptor envíe una unión o no, se inunda con aproximadamente 6 Mbps de tráfico de multidifusión.

La inspección IGMP está habilitada en todos los conmutadores y la VLAN local.
pim sparse-mode está configurado en el mrouter / gateway predeterminado.

Si hago un show ip igmp snooping groupsen el interruptor, no hay entrada en la tabla de espionaje.

Sé que 224.0.0.1 - 224.0.0.255 cae dentro del rango de multidifusión de IP reservado local de enlace, lo que significa que un enrutador no reenviará paquetes dentro de este rango. Estos rangos también se utilizan para el enrutamiento del protocolo de charla. por ejemplo) EIGRP, OSPF, HSRP ... etc.

Tengo dos preguntas:
1) Creo que la respuesta es SÍ: para 224.0.0.1 224.0.0.255 ... ¿IGMPv2 ignora este rango para espiar y el conmutador simplemente reenvía esto a todos los puertos?
2) ¿Hay alguna forma de obligar a IGMP a espiar este tráfico de multidifusión y solo enviarlo a los puertos que lo solicitan con una unión IGMP?

Tengo la sensación de que este es uno de esos casos en los que las aplicaciones / programadores necesitan diseñar sus dispositivos y aplicaciones para respetar las redes escalables que no son de consumo. Por lo tanto, deberían usar una dirección de multidifusión en el rango 239.0.0.0/8.

Seguí buscando en Internet ... y creo que he respondido a mi propia pregunta.
Ahora necesito volver a los propietarios / desarrolladores de aplicaciones / dispositivos y ver qué podemos hacer o bloquear aún más estos dispositivos en su propia VLAN.

Por favor, deje comentarios o respuestas con cualquier otro consejo.

RFC 4541 2.1.2 :

1) Los paquetes con una dirección IP de destino fuera de 224.0.0.X que no son IGMP deben enviarse de acuerdo con las tablas de pertenencia de puertos basadas en grupos y también deben enviarse a los puertos del enrutador.

  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) Los paquetes con una dirección IP de destino (DIP) en el rango 224.0.0.X que no son IGMP deben enviarse a todos los puertos.

  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.

Hay otra advertencia: según la plataforma, el conmutador eliminará todas las multidifusión de enlace local a la CPU. Esto incluye, por ejemplo, el tráfico OSPF.

Me di cuenta de esto en Ciscos Catalyst 4500 que enviará todo el tráfico 224.0.0.x a la CPU. Cuando la CPU está ocupada, descartará los paquetes, incluidos los paquetes OSPF. Diviértete depurando por qué caen tus sesiones OSPF.

Tampoco ayuda apagar igmp snooping en la plataforma. En algún momento Cisco notó que probablemente esta no sea la mejor idea e introdujo el comando:

access-list hardware capture mode vlan

Esto unirá los paquetes de multidifusión en el hardware.

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