Adresses de surveillance IGMP et de multidiffusion en liaison locale

J'ai un réseau qui a beaucoup d'appareils envoyant des données au 224.0.0.225 sur un VLAN qui s'étend sur plusieurs commutateurs. Chaque appareil (environ 12 d'entre eux) envoie des données de rapport à environ 500-600 kbps. Chaque port du VLAN, que le récepteur envoie une jointure ou non, est inondé d'environ 6 Mbps de trafic de multidiffusion.

L'espionnage IGMP est activé sur tous les commutateurs et le VLAN local.
pim sparse-mode est configuré sur le mrouter / passerelle par défaut.

Si je fais un show ip igmp snooping groupssur l'interrupteur, il n'y a pas d'entrée dans la table d'espionnage.

Je sais que 224.0.0.1 - 224.0.0.255 se situent dans la plage de multidiffusion IP réservée au lien local, ce qui signifie qu'un routeur ne transmettra pas les paquets dans cette plage. Ces plages sont également utilisées pour le routage de bavardage de protocole. par exemple) EIGRP, OSPF, HSRP ... etc

J'ai deux questions:
1) Je pense que la réponse est OUI - pour 224.0.0.1 224.0.0.255 ... IGMPv2 ignore-t-il cette plage pour l'espionnage et le commutateur le transmet-il simplement à tous les ports?
2) Existe-t-il un moyen de forcer IGMP à espionner ce trafic de multidiffusion et à ne l'envoyer qu'aux ports qui le demandent avec une jointure IGMP?

J'ai le sentiment que c'est l'un de ces cas où l'application / les programmeurs doivent concevoir leurs appareils et leur application pour respecter les réseaux non grand public évolutifs. Ainsi, ils devraient utiliser une adresse de multidiffusion dans la plage 239.0.0.0/8.

J'ai continué à fouiller sur Internet ... et je pense avoir répondu à ma propre question.
Maintenant, je dois revenir aux propriétaires / développeurs d'applications / d'appareils et voir ce que nous pouvons faire ou verrouiller davantage ces appareils sur leur propre VLAN.

Veuillez laisser des commentaires ou des réponses avec d'autres conseils.

RFC 4541 2.1.2 :

1) Les paquets avec une adresse IP de destination en dehors de 224.0.0.X qui ne sont pas IGMP doivent être transférés conformément aux tables d'appartenance de port basées sur le groupe et doivent également être transférés sur les ports du routeur.

  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) Les paquets avec une adresse IP de destination (DIP) dans la plage 224.0.0.X qui ne sont pas IGMP doivent être transmis sur tous les ports.

  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.

Il y a une autre mise en garde: selon la plate-forme, le commutateur enverra toutes les multidiffusions de liaison locale vers le processeur. Cela inclut par exemple le trafic OSPF.

J'ai remarqué cela sur Ciscos Catalyst 4500 qui enverra tout le trafic 224.0.0.x au CPU. Lorsque le CPU est occupé, il abandonne les paquets, y compris vos paquets OSPF. Amusez-vous à déboguer les raisons de la perte de vos sessions OSPF.

De plus, la désactivation de l'espionnage igmp sur la plate-forme n'aide pas. À un moment donné, Cisco a remarqué que ce n'était probablement pas la meilleure idée et a introduit la commande:

access-list hardware capture mode vlan

Cela pontera les paquets de multidiffusion dans le matériel.

Voir http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/secure.html#wp1128851 pour plus de détails