Zum Hauptinhalt springen

2. Empfehlungen für IGMP-Snooping (IGMP Snooping Recommendations)

Die folgenden Abschnitte listen die Empfehlungen für einen Switch mit IGMP-Snooping auf. Die Empfehlung wird genannt und anschließend durch die Beschreibung einer möglichen Umsetzung ergänzt. Alle Umsetzungsdiskussionen sind nur Beispiele, und es gibt sicherlich andere Wege, dieselbe Funktionalität zu erreichen.

2.1. Weiterleitungsregeln (Forwarding Rules)​

Die IGMP-Snooping-Funktionalität gliedert sich in einen Steuerungsteil (IGMP-Weiterleitung) und einen Datenteil (Datenweiterleitung).

2.1.1. IGMP-Weiterleitungsregeln (IGMP Forwarding Rules)​

  1. Ein Snooping-Switch SOLLTE (SHOULD) IGMP-Mitgliedschaftsberichte nur an die Ports weiterleiten, an denen Multicast-Router angeschlossen sind.

Anders ausgedrückt: Ein Snooping-Switch SOLLTE (SHOULD NOT) IGMP-Mitgliedschaftsberichte nicht an Ports weiterleiten, an denen nur Hosts angeschlossen sind. Es kann eine administrative Steuerung vorgesehen werden, die diese Einschränkung außer Kraft setzt und das Fluten der Berichtsnachrichten an andere Ports erlaubt.

Dies ist die Hauptfunktionalität von IGMP-Snooping für den Steuerungspfad.

Bei IGMPv1 und IGMPv2 kann das Senden von Mitgliedschaftsberichten an andere Hosts unbeabsichtigt dazu führen, dass ein Host einem bestimmten Multicast-Gruppe nicht beitreten kann. Wenn ein IGMPv1- oder IGMPv2-Host einen Mitgliedschaftsbericht für eine Gruppenadresse empfängt, der er beitreten möchte, unterdrückt der Host seinen eigenen Mitgliedschaftsbericht für dieselbe Gruppe. Diese Beitritts- bzw. Nachrichtenunterdrückung ist eine Anforderung für IGMPv1- und IGMPv2-Hosts. Empfängt der Switch jedoch keinen Mitgliedschaftsbericht von dem Host, leitet er keine Multicast-Daten an ihn weiter.

In einem reinen IGMPv3-Netzwerk ist dies kein Problem, da dort keine Unterdrückung von IGMP-Mitgliedschaftsberichten stattfindet.

Die administrative Steuerung ermöglicht es, dass IGMP-Mitgliedschaftsberichte von Netzwerküberwachungsgeräten wie Paketanalysatoren oder Port-Replikatoren verarbeitet werden.

Der Switch, der IGMP-Snooping unterstützt, MUSS (MUST) eine Liste der Multicast-Router und der Ports, an denen sie angeschlossen sind, führen. Diese Liste kann durch eine beliebige Kombination der folgenden Verfahren aufgebaut werden:

  • a) Diese Liste SOLLTE (SHOULD) aufgebaut werden, indem der Snooping-Switch Multicast Router Solicitation-Nachrichten sendet, wie in der IGMP Multicast Router Discovery [MRDISC] beschrieben. Er darf auch Multicast Router Advertisement-Nachrichten snoopen, die von und an andere Knoten gesendet werden.

  • b) Der Eingangsport für IGMP-Anfragen (von Multicast-Routern gesendet), deren Quelladresse nicht 0.0.0.0 ist. Die Adresse 0.0.0.0 stellt einen Sonderfall dar, in dem der Switch IGMP-Anfragen für eine schnellere Netzkonvergenz weiterleitet (Proxying), selbst aber nicht der Querier ist. Der Switch verwendet nicht seine eigene IP-Adresse (auch wenn er eine hat), da dies dazu führen würde, dass die Anfragen als von einem neu gewählten Querier stammend angesehen werden. Die Adresse 0.0.0.0 wird verwendet, um anzuzeigen, dass die Anfragepakete NICHT von einem Multicast-Router stammen.

  • c) Ports, die durch die Verwaltung ausdrücklich als IGMP-Weiterleitungsports konfiguriert wurden, zusätzlich zu oder anstelle einer der oben genannten Methoden zur Erkennung von Router-Ports.

  1. IGMP-Netzwerke können auch Geräte enthalten, die „Proxy-Reporting“ implementieren, bei dem von nachgelagerten Hosts empfangene Berichte zusammengefasst und zum Aufbau interner Mitgliedschaftszustände verwendet werden. Solche Proxy-Reporting-Geräte dürfen beim Weiterleiten zusammengefasster Berichte stromaufwärts die IP-Quelladresse „alle Null“ verwenden. Aus diesem Grund DÜRFEN (MUST NOT) vom Snooping-Switch empfangene IGMP-Mitgliedschaftsberichte nicht deshalb zurückgewiesen werden, weil die IP-Quelladresse auf 0.0.0.0 gesetzt ist.

  2. Der Switch, der IGMP-Snooping unterstützt, MUSS (MUST) alle nicht erkannten IGMP-Nachrichten an alle anderen Ports fluten und DARF (MUST NOT) nicht versuchen, Informationen jenseits des Endes des Netzwerkschicht-Headers zu nutzen.

Darüber hinaus sollten frühere Versionen von IGMP die IGMP-Felder so interpretieren, wie sie für ihre Version definiert sind, und diese Felder beim Weiterleiten der Nachricht NICHT (MUST NOT) verändern. Beim Erzeugen neuer Nachrichten sollte eine gegebene IGMP-Version die Felder auf die für ihre eigene Version geeigneten Werte setzen. Sind Felder für eine gegebene IGMP-Version reserviert oder nicht definiert, sollten sie beim Parsen der Nachricht ignoriert und beim Erzeugen neuer Nachrichten durch Implementierungen dieser IGMP-Version auf Null gesetzt werden (MUST). Eine Ausnahme kann auftreten, wenn der Switch eine Spoofing-Funktion ausführt und die Einstellungen für neue oder reservierte Felder kennt, die erforderlich sind, um für eine andere IGMP-Version korrekt zu spoofen.

Der Grund, sich mit diesen Feinheiten zu befassen, ist, dass IGMPv3 die alte IGMP-Anfragenachricht mit derselben Typnummer (0x11), aber einem erweiterten Header überlädt. Daher besteht das Risiko, dass IGMPv3-Anfragen beispielsweise von IGMPv2-Snooping-Switches als Anfragen älterer Versionen interpretiert werden. Dies wurde bereits gemeldet [IETF56] und wird in Abschnitt 2.2 erörtert.

  1. Ein IGMP-Snooping-Switch SOLLTE (SHOULD) sich der Änderungen der Topologie der Sicherungsschicht bewusst sein, die durch den Spanning-Tree-Betrieb verursacht werden. Wenn ein Port durch Spanning Tree aktiviert oder deaktiviert wird, kann zur Verkürzung der Netzkonvergenzzeit eine General Query auf allen aktiven Nicht-Router-Ports gesendet werden. Nicht-Querier-Switches SOLLTEN (SHOULD) wissen, ob sich der Querier im IGMPv3-Modus befindet. Ist dies der Fall, SOLLTE (SHOULD NOT) der Switch keine General Queries spoofen, es sei denn, er kann eine IGMPv3-Anfrage senden, die den zuletzt vom echten Querier gesendeten Informationen entspricht. In keinem Fall darf ein Switch eine gespoofte IGMPv2-Anfrage in ein IGMPv3-Netzwerk einbringen, da dies zu erheblichen Netzstörungen führen kann.

Ist der Switch nicht der Querier, SOLLTE (SHOULD) er in diesen Proxy-Anfragen die IP-Quelladresse „alle Null“ verwenden (auch wenn einige Hosts sich dafür entscheiden, Anfragen mit der IP-Quelladresse 0.0.0.0 nicht zu verarbeiten). Werden solche Proxy-Anfragen empfangen, DÜRFEN (MUST NOT) sie nicht in den Querier-Wahlprozess einbezogen werden.

  1. Ein IGMP-Snooping-Switch DARF (MUST NOT) keine Informationen aus IGMP-Paketen verwenden, deren IP- oder IGMP-Header Prüfsummen- oder Integritätsfehler aufweisen. Der Switch SOLLTE (SHOULD NOT) solche Pakete nicht fluten; wenn er es dennoch tut, SOLLTE (SHOULD) er das Ereignis vermerken (z. B. einen Zähler erhöhen). Diese Fehler und ihre Behandlung werden in [IGMPv3], [MLD] und [MLDv2] weiter erörtert.

  2. Der Snooping-Switch DARF (MUST NOT) sich nicht ausschließlich auf das Erscheinen von IGMP Group-Leave-Ankündigungen verlassen, um zu bestimmen, wann Einträge aus der Weiterleitungstabelle entfernt werden sollten. Er SOLLTE (SHOULD) auf allen seinen Nicht-Router-Ports einen Mitgliedschafts-Timeout-Mechanismus implementieren, wie die routerseitige Funktionalität des IGMP-Protokolls, die in den IGMP- und MLD-Spezifikationen beschrieben ist (siehe Abschnitt „Normative Referenzen“ für IGMPv1-3 und MLDv1-2). Dieser Timeout-Wert SOLLTE (SHOULD) konfigurierbar sein.

2.1.2. Datenweiterleitungsregeln (Data Forwarding Rules)​

  1. Pakete mit einer Ziel-IP-Adresse außerhalb von 224.0.0.X, die nicht IGMP sind, SOLLTEN (SHOULD) gemäß den gruppenbasierten Port-Mitgliedschaftstabellen weitergeleitet werden und MÜSSEN (MUST) zusätzlich auf Router-Ports weitergeleitet werden.

Dies ist die Hauptfunktionalität von IGMP-Snooping für den Datenpfad. Ein möglicher Ansatz besteht darin, Mitgliedschafts- und Multicast-Router-Tabellen getrennt in Software zu führen und diese Tabellen dann in einem Weiterleitungs-Cache zu „verschmelzen“.

  1. Pakete mit einer Ziel-IP-Adresse (DIP) im Bereich 224.0.0.X, die nicht IGMP sind, MÜSSEN (MUST) auf allen Ports weitergeleitet werden.

Diese Empfehlung beruht auf der Tatsache, dass viele Hostsysteme vor dem Senden oder Empfangen von IP-Multicast-Paketen keinen Beitritt (Join) für Multicast-Adressen dieses Bereichs senden. Da der Adressbereich 224.0.0.X zudem als link-lokal (nicht routbar) definiert ist, erscheint es unnötig, für jede Adresse dieses Bereichs Zustand zu halten. Darüber hinaus arbeiten einige Router im Adressbereich 224.0.0.X, ohne IGMP-Beitritte zu senden; diese Anwendungen würden brechen, wenn der Switch sie aus dem Grund ausblenden würde, dass er keine Join-Group-Nachricht vom Router gesehen hat.

  1. Ein nicht registriertes Paket ist definiert als ein IPv4-Multicast-Paket, dessen Zieladresse mit keiner der in früheren IGMP-Mitgliedschaftsberichten angekündigten Gruppen übereinstimmt.

Empfängt ein Switch ein nicht registriertes Paket, MUSS (MUST) er dieses Paket auf allen Ports weiterleiten, an denen ein IGMP-Router angeschlossen ist. Ein Switch kann standardmäßig nicht registrierte Pakete auf allen Ports weiterleiten. Switches, die nicht registrierte Pakete nicht an alle Ports weiterleiten, MÜSSEN (MUST) eine Konfigurationsoption bieten, um das Fluten nicht registrierter Pakete auf festgelegten Ports zu erzwingen.

In einer Umgebung, in der IGMPv3-Hosts mit Snooping-Switches gemischt sind, die IGMPv3 noch nicht unterstützen, kann das Ausbleiben des Flutens nicht registrierter Ströme dazu führen, dass v3-Hosts ihren Verkehr nicht erhalten. Umgekehrt kann in Umgebungen, in denen der Snooping-Switch alle vorhandenen IGMP-Versionen unterstützt, das Fluten nicht registrierter Ströme dazu führen, dass IGMP-Hosts von Multicast-Verkehr überwältigt werden, bis hin dazu, dass sie keine Anfragen mehr empfangen und keine neuen Mitgliedschaftsberichte für ihre eigenen Gruppen mehr aussenden.

Snooping-Switches werden ermutigt, zumindest IGMPv3-Join-Berichte zu erkennen und zu verarbeiten, auch wenn diese Verarbeitung auf das Verhalten für IGMPv2-Joins beschränkt ist, d. h. ohne Berücksichtigung zusätzlicher Filterung nach „include source“ oder „exclude source“. Werden IGMPv3-Joins nicht erkannt, kann ein Snooping-Switch die nicht registrierten Datenströme dieser Gruppen fälschlich ausblenden (wie oben erwähnt); alternativ kann er es versäumen, die Weiterleitung an neue IGMPv3-Hosts hinzuzufügen, wenn die Gruppe zuvor als IGMPv2 beigetreten wurde (da der Datenstrom dann als bereits registriert gilt).

  1. Alle Nicht-IPv4-Multicast-Pakete SOLLTEN (SHOULD) weiterhin gemäß normalem IEEE-Bridging an alle übrigen Ports im Weiterleitungszustand geflutet werden.

Diese Empfehlung ergibt sich aus der Tatsache, dass Gruppen aus IPv4-Hosts und Gruppen aus IPv6-Hosts völlig getrennte und unterschiedliche Gruppen sind. Folglich sind die aus der Topologie zwischen Mitgliedern einer IPv4-Gruppe gewonnenen Informationen bei der Bildung der Topologie zwischen Mitgliedern einer IPv6-Gruppe nicht anwendbar.

  1. IGMP-Snooping-Switches dürfen Weiterleitungstabellen auf Basis von MAC-Adressen oder IP-Adressen führen. Unterstützt ein Switch beide Arten von Weiterleitungstabellen, SOLLTE (SHOULD) das Standardverhalten die Verwendung von IP-Adressen sein. Die Weiterleitung auf Basis von IP-Adressen ist vorzuziehen, weil die Abbildung zwischen IP-Multicast-Adressen und Multicast-Adressen der Sicherungsschicht mehrdeutig ist. Bei Ethernet entspricht eine Ethernet-Adresse 32 IP-Adressen [RFC1112].

  2. Switches, die sich auf Informationen im IP-Header verlassen, SOLLTEN (SHOULD) prüfen, dass die IP-Header-Prüfsumme korrekt ist. Schlägt die Prüfsumme fehl, DÜRFEN (MUST NOT) die Informationen des Pakets nicht in die Weiterleitungstabelle übernommen werden. Außerdem SOLLTE (SHOULD) das Paket verworfen werden.

  3. Werden IGMPv3-Mitgliedschaftsberichte vom Typ „include source“ und „exclude source“ auf gemeinsam genutzten Segmenten empfangen, muss der Switch die Obermenge aller empfangenen Mitgliedschaftsberichte an das gemeinsame Segment weiterleiten. Die Weiterleitung von Verkehr einer bestimmten Quelle S an eine Gruppe G MUSS (MUST) erfolgen, wenn mindestens ein Host auf dem gemeinsamen Segment eine IGMPv3-Mitgliedschaft vom Typ INCLUDE(G, Slist1) oder EXCLUDE(G, Slist2) meldet, wobei S ein Element von Slist1 und kein Element von Slist2 ist.

Die praktische Umsetzung der auf (G,S1,S2,...) basierenden Datenweiterleitungstabellen liegt außerhalb des Rahmens dieses Dokuments. Eine Möglichkeit besteht jedoch darin, zwei (G,S)-Weiterleitungslisten zu führen: eine für den INCLUDE-Filter, bei dem eine Übereinstimmung mit einem bestimmten (G,S) Voraussetzung für die Weiterleitung ist, und eine für den EXCLUDE-Filter, bei dem eine Übereinstimmung mit einem bestimmten (G,S) dazu führt, dass nicht weitergeleitet wird.

Ein besonderes Problem tritt in Netzwerken auf, die aus IGMPv3-Routern sowie aus IGMPv2- und IGMPv3-Hosts bestehen, die über einen IGMPv2-Snooping-Switch miteinander verbunden sind, wie kürzlich berichtet wurde [IETF56]. Der Router wird IGMPv3 auch bei Anwesenheit von IGMPv2-Hosts weiterhin aufrechterhalten, sodass das Netzwerk nicht auf IGMPv2 konvergiert. Es ist jedoch wahrscheinlich, dass der IGMPv2-Snooping-Switch die IGMPv3-Mitgliedschaftsberichte weder erkennt noch verarbeitet. Die Gruppen für diese nicht erkannten Berichte werden dann entweder geflutet (mit allen Problemen, die dies für Hosts in einem Netzwerk mit hoher Multicast-Last schaffen kann) oder vom Snooping-Switch ausgeblendet.

Daher wird empfohlen, in einem solchen Netzwerk den Multicast-Router so zu konfigurieren, dass er IGMPv2 verwendet. Ist dies nicht möglich und kann der Snooping-Switch die IGMPv3-Mitgliedschaftsberichte nicht erkennen und verarbeiten, wird stattdessen empfohlen, die IGMP-Snooping-Funktionalität des Switches zu deaktivieren, da es für dieses Problem keine klare Lösung gibt.