IGMP konfigurieren
Grundlegendes zu Gruppenmitgliedschaftsprotokollen
Es gibt einen großen Unterschied zwischen den Multicast-Protokollen, die zwischen Host und Routing-Gerät verwendet werden, und zwischen den Multicast-Routing-Geräten selbst. Hosts in einem bestimmten Subnetzwerk müssen ihr Routing-Gerät nur darüber informieren, ob sie daran interessiert sind, Pakete von einer bestimmten Multicast-Gruppe zu empfangen oder nicht. Der Quellhost muss seine Routinggeräte nur darüber informieren, dass er die Quelle des Datenverkehrs für eine bestimmte Multicastgruppe ist. Mit anderen Worten, keine Hosts benötigen detaillierte Kenntnisse des Distributionsbaums; Es ist lediglich ein Gruppenmitgliedschaftsprotokoll erforderlich, um Routing-Geräte über ihre Teilnahme an einer Multicast-Gruppe zu informieren. Zwischen benachbarten Routing-Geräten hingegen müssen die Multicast-Routing-Protokolle Schleifen vermeiden, da sie ein detailliertes Gefühl der Netzwerktopologie und des Verteilungsbaums von der Quelle bis zum Leaf vermitteln. Daher werden unterschiedliche Multicast-Protokolle für den Host-Router-Teil und den Router-Router-Teil des Multicast-Netzwerks verwendet.
Mithilfe von Multicast-Gruppenmitgliedschaftsprotokollen kann ein Routinggerät erkennen, wenn ein Host in einem direkt angeschlossenen Subnetz, in der Regel einem LAN, Datenverkehr von einer bestimmten Multicast-Gruppe empfangen möchte. Selbst wenn mehr als ein Host im LAN Datenverkehr für diese Multicast-Gruppe empfangen möchte, sendet das Routing-Gerät aufgrund der inhärenten Broadcast-Natur von LANs nur eine Kopie jedes Pakets für diese Multicast-Gruppe an diese Schnittstelle. Wenn das Multicast-Gruppenmitgliedschaftsprotokoll das Routinggerät darüber informiert, dass es keine interessierten Hosts im Subnetz gibt, werden die Pakete zurückgehalten, und dieses Leaf wird aus der Verteilungsstruktur entfernt.
Das Internet Group Management Protocol (IGMP) und das Multicast Listener Discovery (MLD)-Protokoll sind die standardmäßigen IP-Multicast-Gruppenmitgliedschaftsprotokolle: IGMP und MLD haben mehrere Versionen, die von Hosts und Routing-Geräten unterstützt werden:
IGMPv1 – Das ursprüngliche Protokoll, das in RFC 1112 definiert ist. Eine explizite Beitrittsnachricht wird an das Routing-Gerät gesendet, aber es wird eine Zeitüberschreitung verwendet, um zu bestimmen, wann Hosts eine Gruppe verlassen. Dieser Prozess verschwendet Verarbeitungszyklen auf dem Fräsgerät, insbesondere auf älteren oder kleineren Fräsgeräten.
IGMPv2 – Definiert in RFC 2236. IGMPv2 fügt der Beitrittsnachricht unter anderem eine explizite Abwesenheitsnachricht hinzu, sodass Routing-Geräte leichter feststellen können, wenn eine Gruppe keine interessierten Zuhörer in einem LAN hat.
IGMPv3 – Definiert in RFC 3376. IGMPv3 optimiert unter anderem die Unterstützung für eine einzelne Inhaltsquelle für eine Multicast-Gruppe oder Source-Specific Multicast (SSM).
MLDv1 – Definiert in RFC 2710. MLDv1 ähnelt IGMPv2.
MLDv2 – Definiert in RFC 3810. MLDv2 ähnlich IGMPv3.
Die verschiedenen Versionen von IGMP und MLD sind abwärtskompatibel. Es ist üblich, dass auf einem Routing-Gerät mehrere Versionen von IGMP und MLD auf LAN-Schnittstellen ausgeführt werden. Die Abwärtskompatibilität wird erreicht, indem auf die einfachste aller Versionen zurückgegriffen wird, die in einem LAN ausgeführt werden. Wenn beispielsweise auf einem Host IGMPv1 ausgeführt wird, kann jedes Routing-Gerät, das an das LAN angeschlossen ist und auf dem IGMPv2 ausgeführt wird, auf den IGMPv1-Betrieb zurückgesetzt werden, wodurch die Vorteile von IGMPv2 effektiv zunichte gemacht werden. Durch das Ausführen mehrerer IGMP-Versionen wird sichergestellt, dass sowohl IGMPv1- als auch IGMPv2-Hosts Peers für ihre Versionen auf dem Routing-Gerät finden.
Auf Plattformen der MX-Serie können IGMPv2 und IGMPv3 zusammen auf derselben Schnittstelle konfiguriert werden, abhängig von der Junos OS-Version bei Ihrer Installation. Wenn Sie beide zusammen konfigurieren, kann dies zu unerwartetem Verhalten bei der Weiterleitung von Multicastdatenverkehr führen.
Siehe auch
IGMP verstehen
Das Internet Group Management Protocol (IGMP) verwaltet die Mitgliedschaft von Hosts und Routing-Geräten in Multicast-Gruppen. IP-Hosts verwenden IGMP, um ihre Multicast-Gruppenmitgliedschaften an alle unmittelbar benachbarten Multicast-Routing-Geräte zu melden. Multicast-Routing-Geräte verwenden IGMP, um für jedes angeschlossene physische Netzwerk zu lernen, welche Gruppen Mitglieder haben.
IGMP wird auch als Transport für mehrere verwandte Multicast-Protokolle verwendet (z. B. Distance Vector Multicast Routing Protocol [DVMRP] und Protocol Independent Multicast Version 1 [PIMv1]).
Ein Routinggerät empfängt explizite Verknüpfungs- und Bereinigungsnachrichten von benachbarten Routinggeräten, die nachgeschaltete Gruppenmitglieder haben. Wenn PIM das verwendete Multicast-Protokoll ist, beginnt IGMP den Prozess wie folgt:
Um einer Multicast-Gruppe, G, beizutreten, übermittelt ein Host seine Mitgliedschaftsinformationen über IGMP.
Das Routinggerät leitet dann Datenpakete, die an eine Multicast-Gruppe G adressiert sind, nur an die Schnittstellen weiter, auf denen explizite Join-Nachrichten empfangen wurden.
Ein designierter Router (Designated Router, DR) sendet für jede Gruppe, für die er aktive Mitglieder hat, regelmäßige Beitritts- und Bereinigungsnachrichten an einen gruppenspezifischen Rendezvouspunkt (RP). Ein oder mehrere Routing-Geräte werden automatisch oder statisch als RP festgelegt, und alle Routing-Geräte müssen explizit über die RP beitreten.
Jedes Routinggerät entlang des Pfads zur RP erstellt einen Platzhalterstatus (beliebige Quelle) für die Gruppe und sendet Join- und Prune-Nachrichten an die RP.
Der Begriff Routeneintrag wird verwendet, um sich auf den Zustand zu beziehen, der in einem Routing-Gerät verwaltet wird, um die Verteilungsstruktur darzustellen.
Ein Routeneintrag kann Felder wie die folgenden enthalten:
Quelladresse
Gruppenadresse
eingehende Schnittstelle, von der Pakete angenommen werden
Liste der ausgehenden Schnittstellen, an die Pakete gesendet werden
Zeitmesser
Flag-Bits
Die eingehende Schnittstelle des Platzhalter-Routeneintrags zeigt auf den RP.
Die ausgehenden Schnittstellen verweisen auf die benachbarten Downstream-Routinggeräte, die Join- und Prune-Nachrichten an die RP gesendet haben, sowie auf die direkt verbundenen Hosts, die die Mitgliedschaft in Gruppe G angefordert haben.
Durch diesen Status wird eine freigegebene, RP-zentrierte Verteilungsstruktur erstellt, die alle Gruppenmitglieder erreicht.
IGMP wird auch als Transport für mehrere verwandte Multicast-Protokolle verwendet (z. B. Distance Vector Multicast Routing Protocol [DVMRP] und Protocol Independent Multicast Version 1 [PIMv1]).
Ab Junos OS Version 15.2 wird PIMv1 nicht mehr unterstützt.
IGMP ist ein integraler Bestandteil von IP und muss auf allen Routing-Geräten und Hosts aktiviert werden, die IP-Multicast-Datenverkehr empfangen müssen.
Für jedes angeschlossene Netzwerk kann ein Multicast-Routinggerät entweder ein Querier oder ein Nicht-Querier sein. Das Querier-Routing-Gerät sendet in regelmäßigen Abständen allgemeine Abfragemeldungen, um Informationen zur Gruppenmitgliedschaft anzufordern. Hosts im Netzwerk, die Mitglieder einer Multicastgruppe sind, senden Berichtsnachrichten. Wenn ein Host eine Gruppe verlässt, sendet er eine Nachricht zum Verlassen der Gruppe.
IGMP Version 3 (IGMPv3) unterstützt Ein- und Ausschlusslisten. Mit Aufnahmelisten können Sie angeben, welche Quellen an eine Multicastgruppe senden können. Diese Art von Multicastgruppe wird als quellenspezifische Multicastgruppe (SSM) bezeichnet, und ihre Multicastadresse lautet 232/8.
IGMPv3 bietet Unterstützung für die Quellfilterung. Ein Routinggerät kann z. B. bestimmte Routinggeräte angeben, von denen es Datenverkehr annimmt oder ablehnt. Mit IGMPv3 kann ein Multicast-Routing-Gerät lernen, welche Quellen für benachbarte Routing-Geräte von Interesse sind.
Der Ausschlussmodus funktioniert genau wie eine Aufnahmeliste. Es ermöglicht jeder Quelle außer den aufgeführten, an die SSM-Gruppe zu senden.
IGMPv3 arbeitet mit den Versionen 1 und 2 des Protokolls zusammen. Um jedoch mit älteren IGMP-Hosts und Routing-Geräten kompatibel zu bleiben, müssen IGMPv3-Routing-Geräte auch die Versionen 1 und 2 des Protokolls implementieren. IGMPv3 unterstützt die folgenden Datensatztypen für Mitgliedschaftsberichte: Modus ist zulässig, Neue Quellen zulassen und Alte Quellen blockieren.
Siehe auch
IGMP konfigurieren
Bevor Sie beginnen:
Bestimmen Sie, ob der Router direkt mit Multicastquellen verbunden ist. Die Empfänger müssen in der Lage sein, diese Quellen zu lokalisieren.
Bestimmen Sie, ob der Router direkt mit Multicast-Gruppenempfängern verbunden ist. Wenn Empfänger vorhanden sind, wird IGMP benötigt.
Bestimmen Sie, ob Multicast für die Verwendung des Sparse-, Dense- oder Sparse-Dense-Modus konfiguriert werden soll. Für jeden Modus gelten unterschiedliche Konfigurationsüberlegungen.
Bestimmen Sie die Adresse der RP, wenn der Modus "Sparse" oder "Sparse-Dense" verwendet wird.
Bestimmen Sie, ob die RP mit der statischen Konfigurations-, BSR- oder Auto-RP-Methode gesucht werden soll.
Bestimmen Sie, ob Multicast so konfiguriert werden soll, dass eine eigene RPF-Routingtabelle verwendet wird, wenn PIM im Modus "Sparse", "Dense" oder "Sparse-Dense" konfiguriert wird.
Konfigurieren Sie die SAP- und SDP-Protokolle so, dass auf Multicast-Sitzungsankündigungen gewartet wird. Weitere Informationen finden Sie unter Konfigurieren des Sitzungsankündigungsprotokolls.
Um das Internet Group Management Protocol (IGMP) zu konfigurieren, fügen Sie die igmp folgende Anweisung ein:
igmp { accounting; interface interface-name { disable; (accounting | no-accounting); group-policy [ policy-names ]; immediate-leave; oif-map map-name; promiscuous-mode; ssm-map ssm-map-name; static { group multicast-group-address { exclude; group-count number; group-increment increment; source ip-address { source-count number; source-increment increment; } } } version version; } query-interval seconds; query-last-member-interval seconds; query-response-interval seconds; robust-count number; traceoptions { file filename <files number> <size size> <world-readable | no-world-readable>; flag flag <flag-modifier> <disable>; } }
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[edit protocols][edit logical-systems logical-system-name protocols]
Standardmäßig ist IGMP auf allen Schnittstellen aktiviert, auf denen Sie PIM (Protocol Independent Multicast) konfigurieren, sowie auf allen Broadcast-Schnittstellen, auf denen Sie das Distance Vector Multicast Routing Protocol (DVMRP) konfigurieren.
Sie können IGMP auf einer Schnittstelle konfigurieren, ohne PIM zu konfigurieren. PIM wird auf nachgeschalteten IGMP-Schnittstellen in der Regel nicht benötigt. Daher wird nur eine "Pseudo-PIM-Schnittstelle" erstellt, die alle nachgeschalteten IGMP-Schnittstellen (nur IGMP) auf dem Router repräsentiert. Dadurch wird die Menge an Routerressourcen, wie z. B. Arbeitsspeicher, reduziert, die verbraucht werden. Sie müssen PIM auf Upstream-IGMP-Schnittstellen konfigurieren, um Multicast-Routing zu aktivieren, Reverse-Path-Weiterleitung für Multicast-Datenpakete durchzuführen, die Multicast-Weiterleitungstabelle für Upstream-Schnittstellen zu füllen und im Fall von bidirektionalem PIM und PIM-Sparse-Modus IGMP-Gruppenmitgliedschaften in die Multicast-Routing-Domäne zu verteilen.
IGMP aktivieren
Das Internet Group Management Protocol (IGMP) verwaltet Multicastgruppen durch Einrichten, Verwalten und Entfernen von Gruppen in einem Subnetz. Multicast-Routing-Geräte verwenden IGMP, um zu erkennen, welche Gruppen Mitglieder in jedem ihrer angeschlossenen physischen Netzwerke haben. IGMP muss aktiviert sein, damit der Router IPv4-Multicast-Pakete empfangen kann. IGMP wird nur für IPv4-Netzwerke benötigt, da Multicast in IPv6-Netzwerken anders gehandhabt wird. IGMP wird automatisch auf allen IPv4-Schnittstellen aktiviert, auf denen Sie PIM konfigurieren, und auf allen IPv4-Broadcast-Schnittstellen, wenn Sie DVMRP konfigurieren.
Wenn IGMP auf einer Schnittstelle nicht ausgeführt wird – entweder weil PIM und DVMRP auf der Schnittstelle nicht konfiguriert sind oder weil IGMP auf der Schnittstelle explizit deaktiviert ist – können Sie IGMP explizit aktivieren.
So aktivieren Sie IGMP explizit:
Siehe auch
Ändern des IGMP-Hostabfrage-Nachrichtenintervalls
Das Ziel von IGMP besteht darin, Router mit der Gruppenmitgliedschaft des gesamten Subnetzes auf dem neuesten Stand zu halten. Router müssen nicht wissen, wer alle Mitglieder sind, sondern nur, dass Mitglieder existieren. Jeder Host verfolgt, welche Multicast-Gruppen abonniert sind. Auf jeder Verbindung wird ein Router zum Querier gewählt. Der IGMP-Abfragerouter sendet in regelmäßigen Abständen allgemeine Hostabfragenachrichten an jedes angeschlossene Netzwerk, um Informationen zur Mitgliedschaft abzurufen. Die Nachrichten werden an die Multicast-Gruppenadresse 224.0.0.1 für alle Systeme gesendet.
Das Abfrageintervall, das Antwortintervall und die Robustheitsvariable sind insofern miteinander verbunden, als es sich um Variablen handelt, die zum Berechnen des Timeouts für die Gruppenmitgliedschaft verwendet werden. Das Zeitlimit für die Gruppenmitgliedschaft ist die Anzahl der Sekunden, die vergehen müssen, bevor ein Multicastrouter feststellt, dass keine Mitglieder einer Hostgruppe mehr in einem Subnetz vorhanden sind. Das Timeout für die Gruppenmitgliedschaft wird wie folgt berechnet: (Robustheitsvariable x Abfrageintervall) + (Abfrageantwortintervall). Wenn vor Ablauf des Zeitlimits für die Gruppenmitgliedschaft keine Berichte für eine bestimmte Gruppe eingehen, beendet das Routinggerät die Weiterleitung von remote stammenden Multicastpaketen für diese Gruppe an das angeschlossene Netzwerk.
Standardmäßig werden Hostabfragenachrichten alle 125 Sekunden gesendet. Sie können dieses Intervall ändern, um die Anzahl der im Subnetz gesendeten IGMP-Nachrichten zu ändern.
So ändern Sie das Abfrageintervall:
Siehe auch
Ändern des Antwortintervalls für IGMP-Abfragen
Das Abfrageantwortintervall ist die maximale Zeitspanne, die zwischen dem Senden einer Hostabfragenachricht durch den Abfragerouter und dem Empfang einer Antwort von einem Host vergehen kann. Wenn Sie dieses Intervall konfigurieren, können Sie die Burst-Spitzen von IGMP-Nachrichten im Subnetz anpassen. Legen Sie ein größeres Intervall fest, damit der Datenverkehr weniger stark ist. Bursty Traffic bezieht sich auf ein ungleichmäßiges Muster der Datenübertragung: manchmal eine sehr hohe Datenübertragungsrate, während zu anderen Zeiten eine sehr niedrige Datenübertragungsrate.
Das Abfrageantwortintervall, das Hostabfrageintervall und die Robustheitsvariable sind insofern miteinander verbunden, als es sich um Variablen handelt, die zum Berechnen des Timeouts für die Gruppenmitgliedschaft verwendet werden. Das Zeitlimit für die Gruppenmitgliedschaft ist die Anzahl der Sekunden, die vergehen müssen, bevor ein Multicastrouter feststellt, dass keine Mitglieder einer Hostgruppe mehr in einem Subnetz vorhanden sind. Das Timeout für die Gruppenmitgliedschaft wird wie folgt berechnet: (Robustheitsvariable x Abfrageintervall) + (Abfrageantwortintervall). Wenn vor Ablauf des Zeitlimits für die Gruppenmitgliedschaft keine Berichte für eine bestimmte Gruppe eingehen, beendet das Routinggerät die Weiterleitung von remote erstellten Multicastpaketen für diese Gruppe an das angeschlossene Netzwerk.
Das Standardintervall für die Beantwortung von Abfragen beträgt 10 Sekunden. Sie können ein Intervall von unter einer Sekunde bis zu einer Stelle rechts vom Dezimaltrennzeichen konfigurieren. Der konfigurierbare Bereich beträgt 0,1 bis 0,9, dann in 1-Sekunden-Intervallen 1 bis 999.999.
So ändern Sie das Abfrageantwortintervall:
Siehe auch
Festlegen der Entfernung des Hosts mit sofortigem Verlassen für IGMP
Die Einstellung für den sofortigen Urlaub ist nützlich, um die Abwesenheitslatenz von IGMP-Mitgliedschaften zu minimieren. Wenn diese Einstellung aktiviert ist, verlässt das Routinggerät die Multicast-Gruppe unmittelbar nach dem letzten Host, der die Multicast-Gruppe verlässt.
Die Einstellung "Immediate-Leave" aktiviert das Host-Tracking, was bedeutet, dass das Gerät die Hosts verfolgt, die Join-Nachrichten senden. Auf diese Weise kann IGMP bestimmen, wann der letzte Host eine Abwesenheitsnachricht für die Multicastgruppe sendet.
Wenn die Einstellung "Sofortiger Austritt" aktiviert ist, entfernt das Gerät eine Schnittstelle aus dem Weiterleitungstabelleneintrag, ohne zuvor IGMP-gruppenspezifische Abfragen an die Schnittstelle zu senden. Die Schnittstelle wird aus der Multicaststruktur für die Multicastgruppe bereinigt, die in der IGMP-Leave-Nachricht angegeben ist. Die Einstellung "Immediate Leave" gewährleistet eine optimale Bandbreitenverwaltung für Hosts in einem Switched-Netzwerk, selbst wenn mehrere Multicast-Gruppen gleichzeitig verwendet werden.
Wenn der sofortige Abschied deaktiviert ist und ein Host eine Abwesenheitsgruppennachricht sendet, sendet das Routinggerät zunächst eine Gruppenabfrage, um festzustellen, ob ein anderer Empfänger antwortet. Wenn kein Empfänger antwortet, entfernt das Routinggerät alle Hosts auf der Schnittstelle aus der Multicastgruppe. Der sofortige Urlaub ist sowohl für IGMP Version 2 als auch für IGMP Version 3 standardmäßig deaktiviert.
Obwohl die Hostverfolgung für IGMPv2 und MLDv1 aktiviert ist, wenn Sie den sofortigen Austritt aktivieren, verwenden Sie den sofortigen Austritt mit diesen Versionen nur, wenn ein Host auf der Schnittstelle vorhanden ist. Der Grund dafür ist, dass IGMPv2 und MLDv1 einen Mechanismus zur Unterdrückung von Berichten verwenden, bei dem nur ein Host auf einer Schnittstelle als Antwort auf eine Mitgliedschaftsabfrage einen Gruppenbeitrittsbericht sendet. Die anderen interessierten Gastgeber unterdrücken ihre Meldungen. Der Zweck dieses Mechanismus besteht darin, eine Flut von Berichten für dieselbe Gruppe zu vermeiden. Es stört aber auch das Host-Tracking, da der Router nur über den einen interessierten Host Bescheid weiß und nicht über die anderen.
So aktivieren Sie den sofortigen Urlaub auf einer Schnittstelle:
Siehe auch
Filtern unerwünschter IGMP-Berichte auf IGMP-Schnittstellenebene
Angenommen, Sie müssen die Subnetze einschränken, die einer bestimmten Multicastgruppe beitreten können. Die group-policy Anweisung ermöglicht es Ihnen, unerwünschte IGMP-Berichte auf Schnittstellenebene zu filtern. Wenn diese Anweisung auf einem Router aktiviert ist, auf dem IGMP Version 2 (IGMPv2) oder Version 3 (IGMPv3) ausgeführt wird, vergleicht der Router, nachdem der Router einen IGMP-Bericht erhalten hat, die Gruppe mit der angegebenen Gruppenrichtlinie und führt die in dieser Richtlinie konfigurierte Aktion aus (z. B. lehnt den Bericht ab, wenn die Richtlinie mit der definierten Adresse oder dem definierten Netzwerk übereinstimmt).
Sie definieren die Richtlinie so, dass sie nur mit IGMP-Gruppenadressen (für IGMPv2) übereinstimmt, indem Sie die route-filter Anweisung der Richtlinie verwenden, um die Gruppenadresse abzugleichen. Sie definieren die Richtlinie so, dass sie IGMP-Adressen (Quell-, Gruppenadressen) (für IGMPv3) abgleicht, indem Sie die Anweisung der Richtlinie route-filter verwenden, um die Gruppenadresse abzugleichen, und die Anweisung der Richtlinie, source-address-filter um mit der Quelladresse übereinzustimmen.
Auf Plattformen der MX-Serie können IGMPv2 und IGMPv3 zusammen auf derselben Schnittstelle konfiguriert werden, abhängig von der Junos OS-Version bei Ihrer Installation. Wenn Sie beide zusammen konfigurieren, kann dies zu unerwartetem Verhalten bei der Weiterleitung von Multicastdatenverkehr führen.
So filtern Sie unerwünschte IGMP-Berichte:
Siehe auch
Akzeptieren von IGMP-Nachrichten von entfernten Subnetzen
Standardmäßig akzeptieren IGMP-Schnittstellen IGMP-Nachrichten nur aus demselben Subnetz. Durch das Einfügen der promiscuous-mode Anweisung kann das Routing-Gerät IGMP-Nachrichten aus indirekt verbundenen Subnetzen akzeptieren.
Wenn Sie IGMP auf einer nicht nummerierten Ethernet-Schnittstelle aktivieren, die eine / 32-Loopback-Adresse als Spenderadresse verwendet, müssen Sie den Promiscuous-Modus von IGMP so konfigurieren, dass die auf dieser Schnittstelle empfangenen IGMP-Pakete akzeptiert werden.
Wenn Sie den Promiscuous-Mode aktivieren, müssen alle Router im Ethernet-Segment mit der Promiscuous-Mode-Anweisung konfiguriert werden. Andernfalls fungiert nur die Schnittstelle, die mit der niedrigsten IPv4-Adresse konfiguriert ist, als Abfrage für IGMP für dieses Ethernet-Segment.
So aktivieren Sie den IGMP-Promiscuous-Modus auf einer Schnittstelle:
Siehe auch
Ändern des IGMP-Abfrageintervalls für das letzte Mitglied
Das Abfrageintervall für das letzte Mitglied ist die maximale Zeitspanne zwischen gruppenspezifischen Abfragenachrichten, einschließlich derjenigen, die als Antwort auf Nachrichten der verlassenen Gruppe gesendet werden. Sie können dieses Intervall konfigurieren, um die Zeit zu ändern, die ein Routinggerät benötigt, um den Verlust des letzten Mitglieds einer Gruppe zu erkennen.
Wenn das Routing-Gerät, das als Abfrager dient, eine Leave-Group-Nachricht von einem Host empfängt, sendet das Routing-Gerät mehrere gruppenspezifische Abfragen an die Gruppe, die verlassen wird. Der Abfrager sendet eine bestimmte Anzahl dieser Abfragen in einem bestimmten Intervall. Die Anzahl der gesendeten Abfragen wird als Anzahl der Abfragen des letzten Mitglieds bezeichnet. Das Intervall, in dem die Abfragen gesendet werden, wird als Abfrageintervall für das letzte Mitglied bezeichnet. Da beide Einstellungen konfigurierbar sind, können Sie die Abwesenheitslatenz anpassen. Die IGMP-Verlassungslatenz ist die Zeit zwischen einer Anforderung zum Verlassen einer Multicast-Gruppe und dem Empfang des letzten Datenbytes für die Multicast-Gruppe.
Der Abfragezähler für das letzte Mitglied x (mal) das Abfrageintervall für das letzte Mitglied = (gleich) der Zeitspanne, die ein Routinggerät benötigt, um festzustellen, dass das letzte Mitglied einer Gruppe die Gruppe verlassen hat, und um die Weiterleitung des Gruppendatenverkehrs zu beenden.
Das standardmäßige Abfrageintervall für das letzte Mitglied beträgt 1 Sekunde. Sie können ein Intervall von unter einer Sekunde bis zu einer Stelle rechts vom Dezimaltrennzeichen konfigurieren. Der konfigurierbare Bereich beträgt 0,1 bis 0,9, dann in 1-Sekunden-Intervallen 1 bis 999.999.
So ändern Sie dieses Intervall:
Sie können die Anzahl der Abfragen für das letzte Mitglied konfigurieren, indem Sie die Variable robustness konfigurieren. Beides ist immer gleich.
Siehe auch
Ändern der IGMP-Robustheitsvariablen
Feinabstimmung der IGMP-Robustheitsvariablen, um den erwarteten Paketverlust in einem Subnetz zu berücksichtigen. Der robuste Zähler ändert automatisch bestimmte IGMP-Nachrichtenintervalle für IGMPv2 und IGMPv3. Eine Erhöhung der robusten Anzahl ermöglicht mehr Paketverluste, erhöht jedoch die Leave-Latenz des Subnetzwerks.
Wenn der Abfragerouter in einem gemeinsam genutzten Netzwerk, in dem IGMPv2 ausgeführt wird, eine IGMP-Abwesenheitsnachricht empfängt, muss der Abfragerouter eine IGMP-Gruppenabfragenachricht eine bestimmte Anzahl von Malen senden. Die Anzahl der gesendeten IGMP-Gruppenabfragenachrichten wird durch die robuste Anzahl bestimmt.
Der Wert der Variablen robustness wird auch bei der Berechnung der folgenden IGMP-Nachrichtenintervalle verwendet:
Gruppenmitgliederintervall: Zeitspanne, die vergehen muss, bevor ein Multicast-Router feststellt, dass sich keine weiteren Mitglieder einer Gruppe in einem Netzwerk befinden. Dieses Intervall wird wie folgt berechnet: (Robustheitsvariable x Abfrageintervall) + (1 x Abfrage-Antwort-Intervall).
Anderes verfügbares Abfrageintervall: Die robuste Anzahl wird verwendet, um die Zeit zu berechnen, die vergehen muss, bevor ein Multicast-Router feststellt, dass kein anderer Multicast-Router mehr vorhanden ist, der der Abfrager ist. Dieses Intervall wird wie folgt berechnet: (Robustheitsvariable x Abfrageintervall) + (0,5 x Abfrage-Antwort-Intervall).
Anzahl der Abfragen des letzten Mitglieds: Anzahl der gruppenspezifischen Abfragen, die gesendet wurden, bevor der Router davon ausgeht, dass keine lokalen Mitglieder einer Gruppe vorhanden sind. Die Anzahl der Abfragen entspricht dem Wert der Robustheitsvariablen.
In IGMPv3 bewirkt eine Änderung des Schnittstellenstatus, dass das System sofort einen Statusänderungsbericht von dieser Schnittstelle überträgt. Falls der Statusänderungsbericht von einem oder mehreren Multicast-Routern übersehen wird, wird er erneut übertragen. Die Häufigkeit, mit der es erneut übertragen wird, ist die robuste Anzahl minus eins. In IGMPv3 ist die robuste Anzahl auch ein Faktor bei der Bestimmung des Gruppenmitgliedschaftsintervalls, des Abfrageintervalls der älteren Version und des anderen Abfrageintervalls.
Standardmäßig ist die Variable robustness auf 2 festgelegt. Sie können diesen Wert erhöhen, wenn Sie erwarten, dass ein Subnetz Pakete verliert.
Die Zahl kann zwischen 2 und 10 liegen.
So ändern Sie den Wert der Variablen robustheit:
Siehe auch
Begrenzung der maximalen IGMP-Nachrichtenrate
In diesem Abschnitt wird beschrieben, wie Sie das Limit für die maximale Anzahl von IGMP-Paketen ändern, die vom Router in 1 Sekunde übertragen werden.
Die Erhöhung der maximalen Anzahl von IGMP-Paketen, die pro Sekunde übertragen werden, kann auf einem Router mit einer großen Anzahl von Schnittstellen, die an IGMP teilnehmen, nützlich sein.
Um das Limit für die maximale Anzahl von IGMP-Paketen zu ändern, die der Router in 1 Sekunde übertragen kann, fügen Sie die maximum-transmit-rate Anweisung ein und geben Sie die maximale Anzahl der zu übertragenden Pakete pro Sekunde an.
Siehe auch
Ändern der IGMP-Version
Standardmäßig wird auf dem Routinggerät IGMPv2 ausgeführt. Routing-Geräte, auf denen verschiedene IGMP-Versionen ausgeführt werden, ermitteln die niedrigste gemeinsame IGMP-Version, die von Hosts in ihrem Subnetz unterstützt wird, und arbeiten in dieser Version.
Um die Source-Specific Multicast-Funktionalität (SSM) zu aktivieren, müssen Sie Version 3 auf dem Host und dem direkt verbundenen Routing-Gerät des Hosts konfigurieren. Wenn eine Quelladresse in einer statisch konfigurierten Multicastgruppe angegeben wird, muss die Version auf IGMPv3 festgelegt werden.
Wenn eine statische Multicast-Gruppe mit definierter Quelladresse konfiguriert ist und die IGMP-Version als Version 2 konfiguriert ist, wird die Quelle ignoriert und nur die Gruppe hinzugefügt. In diesem Fall wird die Verknüpfung als IGMPv2-Gruppenverknüpfung behandelt.
Wenn Sie die IGMP-Versionseinstellung auf der Ebene der einzelnen Schnittstellenhierarchien konfigurieren, wird die interface all Anweisung überschrieben. Das heißt, die neue Schnittstelle erbt nicht die Versionsnummer, die Sie mit der interface all Anweisung angegeben haben. Standardmäßig ist diese neue Schnittstelle mit version 2aktiviert. Sie müssen beim Hinzufügen einer neuen Schnittstelle explizit a version number angeben. Wenn Sie z. B. mit interface allangegeben version 3 haben, müssen Sie die version 3 Anweisung für die neue Schnittstelle konfigurieren. Wenn Sie eine Schnittstelle für eine Multicastgruppe auf Hierarchieebene [edit interface interface-name static group multicast-group-address] konfigurieren, müssen Sie außerdem a version number sowie die anderen Gruppenparameter angeben. Andernfalls wird die Schnittstelle mit der Standardeinstellung version 2.
Wenn Sie das Routinggerät bereits für die Verwendung von IGMP Version 1 (IGMPv1) konfiguriert haben und es dann für die Verwendung von IGMPv2 konfigurieren, verwendet das Routinggerät IGMPv1 bis zu 6 Minuten lang und verwendet dann IGMPv2.
So wechseln Sie zu IGMPv3 für SSM-Funktionen:
Auf Plattformen der MX-Serie können IGMPv2 und IGMPv3 zusammen auf derselben Schnittstelle konfiguriert werden, abhängig von der Junos OS-Version bei Ihrer Installation. Wenn Sie beide zusammen konfigurieren, kann dies zu unerwartetem Verhalten bei der Weiterleitung von Multicastdatenverkehr führen.
Siehe auch
Aktivieren der statischen IGMP-Gruppenmitgliedschaft
Sie können eine statische IGMP-Gruppenmitgliedschaft erstellen, um die Multicastweiterleitung ohne Empfängerhost zu testen. Wenn Sie die statische IGMP-Gruppenmitgliedschaft aktivieren, werden Daten an eine Schnittstelle weitergeleitet, ohne dass diese Schnittstelle Mitgliedschaftsberichte von nachgeschalteten Hosts empfängt. Der Router, auf dem Sie die statische IGMP-Gruppenmitgliedschaft aktivieren, muss der designierte Router (DR) für das Subnetz sein. Andernfalls fließt der Datenverkehr nicht flussabwärts.
Wenn Sie die statische IGMP-Gruppenmitgliedschaft aktivieren, können Sie nicht mehrere Gruppen mit den Anweisungen group-count, group-increment, source-count und source-increment konfigurieren, wenn die Option all als IGMP-Schnittstelle angegeben ist.
Die Class-of-Service-Anpassung (CoS) wird bei statischer IGMP-Gruppenmitgliedschaft nicht unterstützt.
In diesem Beispiel erstellen Sie die statische Gruppe 233.252.0.1.
Wenn Sie statische IGMP-Gruppeneinträge auf Punkt-zu-Punkt-Verbindungen konfigurieren, die Routing-Geräte mit einem Rendezvous Point (RP) verbinden, generieren die statischen IGMP-Gruppeneinträge keine Join-Nachrichten an die RP.
Wenn Sie eine statische IGMP-Gruppenmitgliedschaft erstellen, um die Multicast-Weiterleitung auf einer Schnittstelle zu testen, auf der Sie Multicast-Datenverkehr empfangen möchten, können Sie angeben, dass automatisch eine Reihe statischer Gruppen erstellt werden. Dies ist nützlich, wenn Sie die Weiterleitung an mehrere Empfänger testen möchten, ohne jeden Empfänger separat konfigurieren zu müssen.
In diesem Beispiel erstellen Sie drei Gruppen.
Konfigurieren Sie in der Notfallwiederherstellung die Anzahl der zu erstellenden statischen Gruppen, indem Sie die
group-countAnweisung einschließen und die Anzahl der zu erstellenden Gruppen angeben.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3
Nachdem Sie die Konfiguration bestätigt haben, verwenden Sie den
show configuration protocol igmpBefehl, um die IGMP-Protokollkonfiguration zu überprüfen.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { static { group 233.252.0.1 { group-count 3; } } }Nachdem Sie die Konfiguration bestätigt haben und die Quelle Datenverkehr sendet, verwenden Sie den
show igmp groupBefehl, um zu überprüfen, ob die statischen Gruppen 233.252.0.1, 233.252.0.2 und 233.252.0.3 erstellt wurden.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.2 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Wenn Sie eine statische IGMP-Gruppenmitgliedschaft erstellen, um die Multicast-Weiterleitung auf einer Schnittstelle zu testen, auf der Sie Multicast-Datenverkehr empfangen möchten, können Sie auch die Gruppenadresse so konfigurieren, dass sie für jede erstellte Gruppe automatisch erhöht wird. Dies ist nützlich, wenn Sie die Weiterleitung an mehrere Empfänger testen möchten, ohne jeden Empfänger separat konfigurieren zu müssen, und wenn Sie nicht möchten, dass die Gruppenadressen fortlaufend sind.
In diesem Beispiel erstellen Sie drei Gruppen und erhöhen die Gruppenadresse für jede Gruppe um zwei Inkremente.
Konfigurieren Sie in der Notfallwiederherstellung das Inkrement der Gruppenadresse, indem Sie die
group-incrementAnweisung einschließen und die Zahl angeben, um die die Adresse für jede Gruppe erhöht werden soll. Das Inkrement wird in gepunkteter Dezimalschreibweise angegeben, ähnlich wie bei einer IPv4-Adresse.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 group-count 3 group-increment 0.0.0.2
Nachdem Sie die Konfiguration bestätigt haben, verwenden Sie den
show configuration protocol igmpBefehl, um die IGMP-Protokollkonfiguration zu überprüfen.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { group-increment 0.0.0.2; group-count 3; } } }Nachdem Sie die Konfiguration festgeschrieben haben und die Quelle Datenverkehr sendet, verwenden Sie den
show igmp groupBefehl, um zu überprüfen, ob die statischen Gruppen 233.252.0.1, 233.252.0.3 und 233.252.0.5 erstellt wurden.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.3 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.5 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Wenn Sie eine statische IGMP-Gruppenmitgliedschaft erstellen, um die Multicastweiterleitung auf einer Schnittstelle zu testen, auf der Sie Multicastdatenverkehr empfangen möchten, und Ihr Netzwerk im quellenspezifischen Multicastmodus (SSM) arbeitet, können Sie auch angeben, dass die Multicast-Quelladresse akzeptiert werden soll. Dies ist nützlich, wenn Sie die Weiterleitung an Multicastempfänger von einer bestimmten Multicastquelle testen möchten.
Wenn Sie eine Gruppenadresse im SSM-Bereich angeben, müssen Sie auch eine Quelle angeben.
Wenn eine Quelladresse in einer statisch konfigurierten Multicastgruppe angegeben ist, muss die IGMP-Version auf der Schnittstelle auf IGMPv3 festgelegt werden. IGMPv2 ist der Standardwert.
In diesem Beispiel erstellen Sie die Gruppe 233.252.0.1 und akzeptieren die IP-Adresse 10.0.0.2 als einzige Quelle.
Konfigurieren Sie in der DR die Quelladresse, indem Sie die
sourceAnweisung einschließen und die IPv4-Adresse des Quellhosts angeben.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2
Nachdem Sie die Konfiguration bestätigt haben, verwenden Sie den
show configuration protocol igmpBefehl, um die IGMP-Protokollkonfiguration zu überprüfen.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2; } } }Nachdem Sie einen Commit für die Konfiguration ausgeführt haben und die Quelle Datenverkehr sendet, verwenden Sie den
show igmp groupBefehl, um zu überprüfen, ob die statische Gruppe 233.252.0.1 erstellt und die Quelle 10.0.0.2 akzeptiert wurde.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Wenn Sie eine statische IGMP-Gruppenmitgliedschaft erstellen, um die Multicast-Weiterleitung auf einer Schnittstelle zu testen, auf der Sie Multicast-Datenverkehr empfangen möchten, können Sie angeben, dass eine Reihe von Multicast-Quellen automatisch akzeptiert werden. Dies ist nützlich, wenn Sie die Weiterleitung an Multicastempfänger von mehr als einer angegebenen Multicastquelle testen möchten.
In diesem Beispiel erstellen Sie die Gruppe 233.252.0.1 und akzeptieren die Adressen 10.0.0.2, 10.0.0.3 und 10.0.0.4 als Quellen.
Konfigurieren Sie in der Notfallwiederherstellung die Anzahl der zu akzeptierenden Multicast-Quelladressen, indem Sie die
source-countAnweisung einschließen und die Anzahl der zu akzeptierenden Quellen angeben.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3
Nachdem Sie die Konfiguration bestätigt haben, verwenden Sie den
show configuration protocol igmpBefehl, um die IGMP-Protokollkonfiguration zu überprüfen.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; } } } }Nachdem Sie einen Commit für die Konfiguration ausgeführt haben und die Quelle Datenverkehr sendet, verwenden Sie den
show igmp groupBefehl, um zu überprüfen, ob die statische Gruppe 233.252.0.1 erstellt wurde und ob die Quellen 10.0.0.2, 10.0.0.3 und 10.0.0.4 akzeptiert wurden.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.3 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static
Wenn Sie statische Gruppen auf einer Schnittstelle konfigurieren, auf der Sie Multicastdatenverkehr empfangen möchten, und angeben, dass eine Anzahl von Multicastquellen automatisch akzeptiert wird, können Sie auch die Anzahl angeben, um die die Adresse für jede akzeptierte Quelle erhöht werden soll. Dies ist nützlich, wenn Sie die Weiterleitung an mehrere Empfänger testen möchten, ohne jeden Empfänger separat konfigurieren zu müssen, und wenn Sie nicht möchten, dass die Quelladressen sequenziell sind.
In diesem Beispiel erstellen Sie die Gruppe 233.252.0.1 und akzeptieren die Adressen 10.0.0.2, 10.0.0.4 und 10.0.0.6 als Quellen.
Konfigurieren Sie das Inkrement der Multicast-Quelladresse, indem Sie die
source-incrementAnweisung einschließen und die Zahl angeben, um die die Adresse für jede Quelle inkrementiert werden soll. Das Inkrement wird in gepunkteter Dezimalschreibweise angegeben, ähnlich wie bei einer IPv4-Adresse.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 source 10.0.0.2 source-count 3 source-increment 0.0.0.2
Nachdem Sie die Konfiguration bestätigt haben, verwenden Sie den
show configuration protocol igmpBefehl, um die IGMP-Protokollkonfiguration zu überprüfen.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { source 10.0.0.2 { source-count 3; source-increment 0.0.0.2; } } } }Nachdem Sie einen Commit für die Konfiguration ausgeführt haben und die Quelle Datenverkehr sendet, verwenden Sie den
show igmp groupBefehl, um zu überprüfen, ob die statische Gruppe 233.252.0.1 erstellt wurde und ob die Quellen 10.0.0.2, 10.0.0.4 und 10.0.0.6 akzeptiert wurden.user@host> show igmp group Interface: fe-0/1/2 Group: 233.252.0.1 Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.4 Last reported by: Local Timeout: 0 Type: Static Group: 233.252.0.1 Source: 10.0.0.6 Last reported by: Local Timeout: 0 Type: Static
Wenn Sie statische Gruppen auf einer Schnittstelle konfigurieren, auf der Sie Multicast-Datenverkehr empfangen möchten, und Ihr Netzwerk im quellenspezifischen Multicastmodus (SSM) arbeitet, können Sie angeben, dass bestimmte Multicast-Quelladressen ausgeschlossen werden sollen.
Standardmäßig arbeitet die Multicast-Quelladresse, die in einer statischen Gruppe konfiguriert ist, im Include-Modus. Im Include-Modus wird der Multicast-Datenverkehr für die Gruppe von der konfigurierten Quelladresse akzeptiert. Sie können die statische Gruppe auch so konfigurieren, dass sie im Ausschlussmodus ausgeführt wird. Im Ausschlussmodus wird der Multicast-Datenverkehr für die Gruppe von einer anderen Adresse als der konfigurierten Quelladresse akzeptiert.
Wenn eine Quelladresse in einer statisch konfigurierten Multicastgruppe angegeben ist, muss die IGMP-Version auf der Schnittstelle auf IGMPv3 festgelegt werden. IGMPv2 ist der Standardwert.
In diesem Beispiel schließen Sie die Adresse 10.0.0.2 als Quelle für die Gruppe 233.252.0.1 aus.
Konfigurieren Sie in der Notfallwiederherstellung eine statische Multicastgruppe für den Betrieb im Ausschlussmodus, indem Sie die
excludeAnweisung einschließen und angeben, welche IPv4-Quelladresse ausgeschlossen werden soll.[edit protocols igmp] user@host# set interface fe-0/1/2 static group 233.252.0.1 exclude source 10.0.0.2
Nachdem Sie die Konfiguration bestätigt haben, verwenden Sie den
show configuration protocol igmpBefehl, um die IGMP-Protokollkonfiguration zu überprüfen.user@host> show configuration protocol igmp
interface fe-0/1/2.0 { version 3; static { group 233.252.0.1 { exclude; source 10.0.0.2; } } }Nachdem Sie einen Commit für die Konfiguration ausgeführt haben und die Quelle Datenverkehr sendet, verwenden Sie den
show igmp group detailBefehl, um zu überprüfen, ob die statische Gruppe 233.252.0.1 erstellt wurde und ob die statische Gruppe im Ausschlussmodus ausgeführt wird.user@host> show igmp group detail Interface: fe-0/1/2 Group: 233.252.0.1 Group mode: Exclude Source: 10.0.0.2 Last reported by: Local Timeout: 0 Type: Static
Siehe auch
Aufzeichnen von IGMP-Beitritts- und -Austrittsereignissen
Um zu bestimmen, ob eine IGMP-Optimierung in einem Netzwerk erforderlich ist, können Sie das Routing-Gerät so konfigurieren, dass IGMP-Beitritts- und -verlassensereignisse aufgezeichnet werden. Sie können Ereignisse global für das Routing-Gerät oder für einzelne Schnittstellen aufzeichnen.
In Tabelle 1 werden die aufzeichnftigen IGMP-Ereignisse beschrieben.
ERRMSG-Tag |
Definition |
|---|---|
RPD_IGMP_JOIN |
Zeichnet IGMP-Beitrittsereignisse auf. |
RPD_IGMP_LEAVE |
Zeichnet IGMP-Abwesenheitsereignisse auf. |
RPD_IGMP_ACCOUNTING_ON |
Zeichnet auf, wenn die IGMP-Abrechnung auf einer IGMP-Schnittstelle aktiviert ist. |
RPD_IGMP_ACCOUNTING_OFF |
Zeichnet auf, wenn die IGMP-Abrechnung auf einer IGMP-Schnittstelle deaktiviert ist. |
RPD_IGMP_MEMBERSHIP_TIMEOUT |
Zeichnet Zeitüberschreitungsereignisse für IGMP-Mitglieder auf. |
So aktivieren Sie die IGMP-Kontoführung:
Siehe auch
Begrenzen der Anzahl von IGMP-Multicast-Gruppenverläufen auf logischen Schnittstellen
Mit dieser group-limit Anweisung können Sie die Anzahl der IGMP-Multicast-Gruppenverknüpfungen für logische Schnittstellen begrenzen. Wenn diese Anweisung auf einem Router aktiviert ist, auf dem IGMP Version 2 (IGMPv2) oder Version 3 (IGMPv3) ausgeführt wird, wird der Grenzwert nach Erhalt des Gruppenberichts angewendet. Sobald das Gruppenlimit erreicht ist, werden nachfolgende Beitrittsanfragen abgelehnt.
Beachten Sie bei der Konfiguration von Grenzwerten für IGMP-Multicast-Gruppen Folgendes:
Jede Any-Source-Gruppe (*,G) zählt als eine Gruppe für den Grenzwert.
Jede quellenspezifische Gruppe (S,G) zählt als eine Gruppe für den Grenzwert.
Gruppen im IGMPv3-Ausschlussmodus werden auf das Limit angerechnet.
Mehrere quellenspezifische Gruppen werden einzeln auf das Gruppenlimit angerechnet, auch wenn sie für dieselbe Gruppe gelten. Beispielsweise würden (S1, G1) und (S2, G1) als zwei Gruppen für den konfigurierten Grenzwert gezählt.
Kombinationen aus beliebigen Quellengruppen und quellenspezifischen Gruppen werden einzeln auf das Gruppenlimit angerechnet, auch wenn sie für dieselbe Gruppe gelten. Beispielsweise würden (*, G1) und (S, G1) als zwei Gruppen für den konfigurierten Grenzwert gezählt.
Das Konfigurieren und Festlegen eines Gruppenlimits in einem Netzwerk, das niedriger ist als das, was bereits im Netzwerk vorhanden ist, führt dazu, dass alle Gruppen aus der Konfiguration entfernt werden. Die Gruppen müssen dann beantragen, dem Netzwerk wieder beizutreten (bis zum neu konfigurierten Gruppenlimit).
Sie können Multicastgruppen auf logischen IGMP-Schnittstellen mithilfe dynamischer Profile dynamisch einschränken.
Ab Junos OS Version 12.2 können Sie optional einen Schwellenwert für Systemprotokollwarnungen für IGMP-Multicast-Gruppenbeitritts konfigurieren, die über die logische Schnittstelle empfangen werden. Es ist hilfreich, die Systemprotokollmeldungen zur Fehlerbehebung zu überprüfen und zu erkennen, ob eine übermäßige Anzahl von IGMP-Multicast-Gruppenbeitritten auf der Schnittstelle empfangen wurde. Diese Protokollmeldungen übermitteln, wenn der konfigurierte Gruppengrenzwert überschritten wurde, wenn der konfigurierte Schwellenwert überschritten wurde und wenn die Anzahl der Gruppen unter den konfigurierten Schwellenwert fällt.
Mit dieser group-threshold Anweisung können Sie den Schwellenwert konfigurieren, ab dem eine Warnmeldung protokolliert wird. Der Bereich liegt zwischen 1 und 100 Prozent. Der Warnschwellenwert ist ein Prozentsatz des Gruppengrenzwerts, daher müssen Sie die group-limit Anweisung so konfigurieren, dass ein Warnschwellenwert konfiguriert wird. Wenn z. B. die Anzahl der Gruppen den Schwellenwert für konfigurierte Warnungen überschreitet, aber unter dem konfigurierten Gruppengrenzwert bleibt, werden Multicastgruppen weiterhin akzeptiert, und das Gerät protokolliert die Warnmeldung. Darüber hinaus protokolliert das Gerät eine Warnmeldung, wenn die Anzahl der Gruppen unter den konfigurierten Warnschwellenwert fällt. Sie können die Zeitspanne (in Sekunden) zwischen den Protokollmeldungen weiter angeben, indem Sie die log-interval Anweisung konfigurieren. Der Bereich liegt zwischen 6 und 32.767 Sekunden.
Sie können die Drosselung von Protokollmeldungen in Betracht ziehen, da für jeden Eintrag, der nach dem konfigurierten Schwellenwert hinzugefügt wird, und für jeden Eintrag, der nach dem konfigurierten Grenzwert abgelehnt wird, eine Warnmeldung protokolliert wird. Durch die Konfiguration eines Protokollintervalls können Sie die Anzahl der Systemprotokoll-Warnmeldungen drosseln, die für IGMP-Multicast-Gruppenbeitritte generiert werden.
Bei Routern der ACX-Serie beträgt die maximale Anzahl von Multicast-Routen 1024.
Gehen Sie wie folgt vor, um Multicast-Gruppenverknüpfungen auf einer logischen IGMP-Schnittstelle einzuschränken:
Verwenden Sie den Befehl, um show protocols igmp Ihre Konfiguration zu bestätigen. Verwenden Sie den Befehl, um den Betrieb von IGMP auf der Schnittstelle zu überprüfen, einschließlich der konfigurierten Gruppenbegrenzung und des optionalen Warnschwellenwerts und des Intervalls zwischen Protokollmeldungen show igmp interface .
Siehe auch
Ablaufverfolgung des IGMP-Protokolldatenverkehrs
Bei Ablaufverfolgungsvorgängen werden detaillierte Meldungen über den Betrieb von Routingprotokollen aufgezeichnet, z. B. die verschiedenen Typen von gesendeten und empfangenen Routingprotokollpaketen sowie Routingrichtlinienaktionen. Sie können angeben, welche Ablaufverfolgungsvorgänge protokolliert werden, indem Sie bestimmte Ablaufverfolgungsflags einschließen. In der folgenden Tabelle werden die Flags beschrieben, die Sie einschließen können.
Flagge |
Beschreibung |
|---|---|
alle |
Verfolgen Sie alle Vorgänge. |
client-benachrichtigung |
Trace-Benachrichtigungen. |
Allgemein |
Verfolgen Sie den allgemeinen Fluss. |
Gruppe |
Verfolgen Sie Gruppenvorgänge. |
host-benachrichtigung |
Trace-Host-Benachrichtigungen. |
verlassen |
Trace-Leave-Gruppennachrichten (nur IGMPv2). |
mtrace |
Verfolgen Sie mtrace-Pakete. Verwenden Sie den |
normal |
Verfolgen Sie normale Ereignisse. |
Pakete |
Verfolgen Sie alle IGMP-Pakete. |
Politik |
Verarbeitung von Ablaufverfolgungsrichtlinien. |
Frage |
Verfolgen Sie IGMP-Mitgliedschaftsabfragemeldungen, einschließlich allgemeiner und gruppenspezifischer Abfragen. |
Bericht |
Verfolgen Sie Mitgliedschaftsberichtsnachrichten. |
Route |
Trace-Routing-Informationen. |
Zustand |
Verfolgen Sie Zustandsübergänge. |
Aufgabe |
Verfolgen Sie die Aufgabenverarbeitung. |
Zeitschaltuhr |
Trace-Timer-Verarbeitung. |
Im folgenden Beispiel ist die Ablaufverfolgung für alle Routingprotokollpakete aktiviert. Anschließend wird die Ablaufverfolgung eingegrenzt, um sich nur auf IGMP-Pakete eines bestimmten Typs zu konzentrieren. So konfigurieren Sie Ablaufverfolgungsvorgänge für IGMP:
Siehe auch
Deaktivieren von IGMP
Um IGMP auf einer Schnittstelle zu deaktivieren, fügen Sie die disable folgende Anweisung ein:
disable;
Sie können diese Anweisung auf den folgenden Hierarchieebenen einbinden:
[edit protocols igmp interface interface-name][edit logical-systems logical-system-name protocols igmp interface interface-name]Anmerkung:Router der ACX-Serie unterstützen keine Hierarchieebenen
[edit logical-systems logical-system-name protocols].
Siehe auch
IGMP und Nonstop Active Routing
NSR-Konfigurationen (Nonstop Active Routing) umfassen zwei Routing-Engines , die Informationen gemeinsam nutzen, sodass das Routing während eines Routing-Engine-Failovers nicht unterbrochen wird. Diese NSR-Konfigurationen beinhalten die passive Unterstützung mit IGMP in Verbindung mit PIM. Die primäre Routing-Engine verwendet IGMP, um ihren PIM-Multicast-Status zu bestimmen, und diese von IGMP abgeleiteten Informationen werden auf die Backup-Routing-Engine repliziert. IGMP auf der neuen primären Routing-Engine (nach dem Failover) lernt die Statusinformationen durch IGMP-Betrieb schnell neu. In der Zwischenzeit behält die neue primäre Routing-Engine den IGMP-abgeleiteten PIM-Status bei, wie er vom Replikationsprozess von der alten primären Routing-Engine empfangen wurde. Bei diesen Statusinformationen tritt eine Zeitüberschreitung auf, es sei denn, sie wird von IGMP auf der neuen primären Routing-Engine aktualisiert. Es ist keine zusätzliche IGMP-Konfiguration erforderlich.
Siehe auch
Tabelle "Änderungshistorie"
Die Funktionsunterstützung hängt von der Plattform und der Version ab, die Sie verwenden. Verwenden Sie den Feature-Explorer , um festzustellen, ob ein Feature auf Ihrer Plattform unterstützt wird.