IGMP-Snooping und verbindungslokale Multicast-Adressen

Ich habe ein Netzwerk mit vielen Geräten, die Daten an 224.0.0.225 in einem VLAN senden, das mehrere Switches umfasst. Jedes Gerät (ca. 12 davon) sendet Berichtsdaten mit ungefähr 500-600 kbps. Jeder Port im VLAN, unabhängig davon, ob der Empfänger einen Join sendet oder nicht, wird mit ungefähr 6 MBit / s Multicast-Verkehr überflutet.

IGMP-Snooping ist auf allen Switches und im lokalen VLAN aktiviert.
Der PIM-Sparse-Modus ist auf dem mrouter / default-Gateway konfiguriert.

Wenn ich show ip igmp snooping groupsden Schalter einschalte, gibt es keinen Eintrag in der Snooping-Tabelle.

Ich weiß, dass 224.0.0.1 - 224.0.0.255 in den verbindungslokal reservierten IP-Multicast-Bereich fallen, was bedeutet, dass ein Router keine Pakete in diesem Bereich weiterleitet. Diese Bereiche werden auch zum Weiterleiten von Protokoll-Chatter verwendet. zB) EIGRP, OSPF, HSRP ... etc.

Ich habe zwei Fragen:
1) Ich denke, die Antwort lautet JA - für 224.0.0.1 224.0.0.255 ... ignoriert IGMPv2 diesen Bereich zum Snooping und leitet der Switch dies nur an alle Ports weiter?
2) Gibt es eine Möglichkeit, IGMP zu zwingen, diesen Multicast-Verkehr zu überwachen und ihn nur an die Ports zu senden, die ihn mit einem IGMP-Join anfordern?

Ich habe das Gefühl, dass dies einer der Fälle ist, in denen die Anwendung / Programmierer ihre Geräte und Anwendungen so gestalten müssen, dass skalierbare Nicht-Consumer-Netzwerke berücksichtigt werden. Daher sollten sie eine Multicast-Adresse im Bereich 239.0.0.0/8 verwenden.

Ich habe mich immer im Internet umgesehen ... und ich glaube, ich habe meine eigene Frage beantwortet.
Jetzt muss ich zu den Anwendungen / Gerätebesitzern / Entwicklern zurückkehren und sehen, was wir tun können, oder diese Geräte weiter für ihr eigenes VLAN sperren.

Bitte hinterlassen Sie Kommentare oder Antworten mit weiteren Ratschlägen.

RFC 4541 2.1.2 :

1) Pakete mit einer Ziel-IP-Adresse außerhalb von 224.0.0.X, die nicht IGMP sind, sollten gemäß gruppenbasierten Portmitgliedschaftstabellen weitergeleitet werden und müssen auch an Router-Ports weitergeleitet werden.

  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) Pakete mit einer Ziel-IP-Adresse (DIP) im Bereich 224.0.0.X, die nicht IGMP sind, müssen an allen Ports weitergeleitet werden.

  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.

Es gibt noch eine weitere Einschränkung: Je nach Plattform leitet der Switch alle verbindungslokalen Multicasts an die CPU weiter. Dies schließt zum Beispiel OSPF-Verkehr ein.

Ich habe dies auf Ciscos Catalyst 4500 bemerkt, das den gesamten 224.0.0.x-Verkehr an die CPU sendet. Wenn die CPU ausgelastet ist, werden die Pakete einschließlich Ihrer OSPF-Pakete verworfen. Viel Spaß beim Debuggen, warum Ihre OSPF-Sitzung (en) gelöscht werden.

Auch das Ausschalten von igmp-Snooping auf der Plattform hilft nicht. Irgendwann bemerkte Cisco, dass dies wahrscheinlich nicht die beste Idee ist, und führte den Befehl ein:

access-list hardware capture mode vlan

Dadurch werden die Multicast-Pakete in der Hardware überbrückt.

Weitere Informationen finden Sie unter http://www.cisco.com/de/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/secure.html#wp1128851