Neuerstellen der Multicast-Einträge mit Änderungen der CGMP- und Spanning Tree-Topologie

Einführung

In diesem Dokument wird erläutert, wie das Cisco Group Management Protocol (CGMP) auf den Cisco Catalyst Switches und den Cisco IOS® Routern im Hinblick auf die Neuerstellung der Multicast-Einträge für CGMP nach einer Änderung der Spanning-Tree-Topologie funktioniert.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über Kenntnisse in folgenden Bereichen zu verfügen:

• Basisbetrieb von Switches, Routern und Multicasting

• Basisbetrieb von Spanning Tree, CGMP und Internet Group Management Protocol (IGMP)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf den folgenden Software- und Hardwareversionen:

• Catalyst 3550 Version 12.1(9)EA1c

• Catalyst 2900/3500XL, Version 12.0(5)WC3b

• Catalyst 4000 Supervisor Engine III Version 12.1(11b)EW

• Catalyst 4000 Supervisor Engine I/II, Version 7.2(2)

• Catalyst 6500 Supervisor Engine Cisco IOS Software, Version 12.1(11b)EX

• Catalyst 6500 Catalyst OS (CatOS) Version 7.2(2)

• Catalyst 5500 CatOS Version 4.5(13a)

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps zu Konventionen von Cisco).

CGMP- und Topologieänderungen

In diesem Abschnitt wird Schritt für Schritt beschrieben, was geschieht und welche Probleme auftreten können, wenn eine Änderung der Spanning-Tree-Topologie in einem VLAN erkannt wird, in dem der CGMP verwendet wird, um den Multicast-Datenverkehr an allen Ports vor Flooding zu schützen. Wie dieses Beispiel zeigt, besteht das in diesem Dokument beschriebene Netzwerk aus einem Router, einem Switch und vier PCs:

• Port 1 - Empfänger PC 1

• Port 2 - Empfänger PC 2

• Port 3 - Empfänger PC 3

• Port 4 - kein Empfänger-PC 4

• Port 5 - anderer Switch (keine Empfänger oder Router auf diesem Switch)

• Port 48 - Cisco IOS-Router mit IGMP und CGMP

Für die Zwecke dieses Dokuments wird davon ausgegangen, dass die Empfänger-PCs IGMP verwenden und der Switch CGMP ausführt. Der Cisco IOS-Router führt IGMP und CGMP aus, die einen Multicast-Stream von einem Videoserver auf einer anderen Schnittstelle empfangen. Diese Schnittstelle sendet an die IP-Multicast-Gruppe 239.100.100.100.

Stabiler Zustand

Wenn alle Geräte hochgefahren sind und die Empfänger-PCs ihre IGMP-Join-Nachrichten für die Gruppe 239.100.100.100 gesendet haben, werden sie alle vom CGMP zur entsprechenden Layer-2-Gruppe hinzugefügt, die durch die MAC-Adresse 01-00-5e-64-64-64 dargestellt wird.

Diese Liste zeigt, welche Ports am Switch fett markiert sind und den Multicast-Stream empfangen, der über den Cisco IOS-Router übertragen wird.

• Port 1 - Empfänger PC 1

• Port 2 - Empfänger PC 2

• Port 3 - Empfänger PC 3

• Port 4 - kein Empfänger-PC 4

• Port 5 - anderer Switch (keine Empfänger oder Router auf diesem Switch)

• Port 48 - Cisco IOS-Router, der IGMP und CGMP ausführt

Hinweis: Der Cisco IOS-Router wird ebenfalls der Multicast-Gruppe hinzugefügt, aber da er die Quelle ist, empfängt er keine eigenen Pakete.

In jedem Abfrageintervall sendet der Cisco IOS-Router eine generelle IGMP-Abfrage (die an die Multicast-Gruppe 224.0.0.1 gesendet und daher an alle anderen Komponenten geflutet wird). In diesem Fall erstellen alle Empfänger einen IGMP-Bericht für die Gruppe 239.100.100.100. Die Empfänger senden diesen Bericht zurück an die IP-Multicast-Gruppe 239.100.100.100 mit der MAC-Adresse für Layer 2 mit der Adresse 01-00-5E-64-64-64. Da diese an die Gruppenadresse gesendet wird, erhalten alle Empfänger die von anderen Empfängern gesendeten Berichte sowie den Bericht, den der erste Empfänger zurückgesendet hat. Dies veranlasst die anderen Empfänger-PCs, ihren Bericht für diese Gruppe zu stornieren. Dies bedeutet, dass für diese Gruppe nur eine CGMP-Join-Nachricht mit der Quell-MAC-Adresse des PCs gesendet wird, der als Erster antwortet. Dies wird über einen langen Zeitraum fortgesetzt, und alle Empfänger-PCs erhalten die Videoübertragung.

Während und nach der Topologieänderung

An diesem Punkt löst der andere Switch eine Topologieänderung im Netzwerk aus. Gemäß der CGMP-Spezifikation löscht der Switch beim Empfang der Topologieänderung alle Multicast-Einträge, die er über den CGMP gelernt hatte. Der Multicast-Datenverkehr vom Router wird an alle Ports am Switch geleitet.

Diese Liste zeigt an, welche Ports auf dem Switch fett markiert sind und den Multicast-Stream empfangen, der über den Cisco IOS-Router gesendet wird:

• Port 1 - Empfänger PC 1

• Port 2 - Empfänger PC 2

• Port 3 - Empfänger PC 3

• Port 4 - kein Empfänger-PC 4

• Port 5 - anderer Switch (keine Empfänger oder Router auf diesem Switch)

• Port 48 - Cisco IOS-Router, der IGMP und CGMP ausführt

Da der Datenverkehr an alle Ports fließt, bemerken die Empfänger-PCs keinen Unterschied und empfangen weiterhin die Videoübertragung. Da der Datenverkehr jedoch an alle Ports geleitet wird, wird PC 4, der kein Empfänger ist, vom anderen Switch auch der Multicast-Stream empfangen, obwohl er nicht angefordert wurde. Dies wird fortgesetzt, bis der Cisco IOS-Router seine periodische allgemeine IGMP-Anfrage erneut sendet. Der Standardwert hierfür ist 60 Sekunden auf Cisco IOS-Routern (konfiguriert mit einem IP IGMP-Abfrageintervall).

Zwei allgemeine IGMP-Abfragen nach der Benachrichtigung über die Topologieänderung

Wenn der Cisco IOS-Router die erste allgemeine IGMP-Abfrage sendet, beginnen alle Empfänger-PCs, ihren IGMP-Bericht für die Gruppe 239.100.100.100 zu erstellen. Einer von ihnen (in diesem Dokument ist es PC 3) ist der erste, der seinen IGMP-Bericht zurücksendet. Da der Switch noch keinen Multicast-Eintrag enthält, wird er von allen PCs empfangen, und die anderen Empfänger-PCs brechen ihren IGMP-Bericht ab. Der Cisco IOS-Router empfängt den Bericht und sendet die folgende CGMP-Join-Nachricht mit der Quelladresse des Empfängers PC 3.

Der Switch erstellt erneut einen Multicast-Eintrag für die Gruppe 01-00-5e-64-64-64 und fügt ihm Port 3 hinzu, da dies die Quelladresse im CGMP-Join-Paket ist. Da Port 5 der Multicast-Router-Port ist, wird er auch der Multicast-Gruppe hinzugefügt. Daher empfängt nur der Empfänger PC 3 den Video-Stream, während der Video-Stream auf PC 1 und PC 2 still steht.

Diese Liste zeigt, welche Ports auf dem Switch fett markiert sind und den Multicast-Stream empfangen, der über den Cisco IOS-Router übertragen wird:

• Port 1 - Empfänger PC 1

• Port 2 - Empfänger PC 2

• Port 3 - Empfänger PC 3

• Port 4 - kein Empfänger-PC 4

• Port 5 - anderer Switch (keine Empfänger oder Router auf diesem Switch)

• Port 48 - Cisco IOS-Router mit IGMP und CGMP

Am Ende eines IGMP-Abfrageintervalls sendet der Cisco IOS-Router eine weitere allgemeine IGMP-Abfrage. Beim Empfang der Abfrage erstellen alle Empfänger-PCs einen Bericht für die Gruppe 239.100.100.100. Diesmal werden die Berichte der anderen PCs jedoch nur vom Empfänger PC 3 und dem Cisco IOS-Router empfangen. (Der Router-Port wird automatisch jeder Multicast-Gruppe hinzugefügt.)

Da die Empfänger PC 1 und PC 2 keinen Bericht von einem anderen Empfänger sehen, senden sie beide ihre Berichte. Der Cisco IOS-Router sendet anschließend eine CGMP-Join-Nachricht mit der Quell-MAC-Adresse der jeweiligen PCs. Daher werden diese hinzugefügt und empfangen den Multicast-Stream erneut über den Cisco IOS-Router.

Diese Liste zeigt, welche Ports auf dem Switch fett markiert sind und den Multicast-Stream empfangen, der über den Cisco IOS-Router übertragen wird:

• Port 1 - Empfänger PC 1

• Port 2 - Empfänger PC 2

• Port 3 - Empfänger PC 3

• Port 4 - kein Empfänger-PC 4

• Port 5 - anderer Switch (keine Empfänger oder Router auf diesem Switch)

• Port 48 - Cisco IOS-Router mit IGMP und CGMP

Die Konfiguration ist wieder im ursprünglichen stabilen Zustand, und alles funktioniert wieder einwandfrei. Dies ist eine Aufschlüsselung der Ereignisse:

1. Eine Topologieänderung tritt auf.

   Tipp: Wenn "portfast" in einem Host-Port nicht aktiviert ist, jedes Mal, wenn ein Host neu gestartet wird oder eine Verbindung mit/vom Port getrennt wird, löst eine Änderung des Linkstatus eine Benachrichtigung über die Topologieänderung im VLAN aus. Wenn das Debuggen des CGMP zum Zeitpunkt der Topologieänderung aktiviert ist, wird diese Debugmeldung angezeigt:

   CGMP SHIM: got short age timer

2. Flooding beginnt an allen Ports.

3. Die erste allgemeine IGMP-Abfrage wird gesendet.

4. Überflutungsstopps.

5. Nicht alle Empfänger empfangen den Multicast-Stream.

6. Die zweite allgemeine IGMP-Abfrage wird gesendet.

7. Alle Empfänger werden hinzugefügt und empfangen den Multicast-Stream erneut.

CGMP-Erweiterungen

Da der Verlust eines Multicast-Streams für einen PC in einer Minute (das standardmäßige IGMP-Abfrageintervall) nicht immer akzeptabel ist, wurden einige Verbesserungen sowohl für die Router als auch für die Switches vorgenommen, auf denen CGMP ausgeführt wird.

Kommunikation zwischen Switch und Router

Da es sich bei Routern um Layer-3-Geräte handelt und sie daher im Allgemeinen nicht über Spanning Tree- und Topologieänderungen informiert sind, müssen die Switches im Netzwerk den Router über diese Topologieänderung informieren. Hierfür wird eine globale IGMP-Urlaubsmeldung definiert.

Diese globale IGMP-Abbruchmeldung ist ein IGMP-Überlauf, der von einem Switch übertragen werden kann und bei dem der Verlassen der Gruppe 0.0.0.0 angefordert wird.

Um sicherzustellen, dass der Router nicht mit globalen IGMP-Urlaubsmeldungen überlastet wird, ist nur der Root-Switch in einer Spanning Tree-Domäne für das Senden dieser globalen IGMP-Urlaubsmeldung verantwortlich, wenn die Topologieänderung vorbei ist.

Router-Verhalten

Wenn der Router diese globale IGMP-Urlaubsmeldung auf einer Schnittstelle erhält, auf der die Cisco IOS-Software ausgeführt wird, erkennt er, dass an dieser Schnittstelle eine Änderung der Spanning-Tree-Topologie vorgenommen wurde, und ergreift die folgenden Maßnahmen, um den Verlust von Multicast-Datenverkehr für die Multicast-Empfänger zu begrenzen:

1. Sendet CGMP-Batch-Join-Nachrichten nach dem Empfang der globalen IGMP-Urlaubsmeldung. Der Router sendet eine CGMP-Join-Nachricht mit einer eigenen MAC-Adresse als Quelladresse für jede Multicast-Gruppe, die er im IGMP-Cache für diese Schnittstelle hat. Durch das Senden dieser CGMP-Self-Join-Meldungen erstellen die CGMP-Switches automatisch einen Eintrag für jede Gruppe, in der nur der Router-Port enthalten ist.

   Diese Liste zeigt das in diesem Dokument verwendete Netzwerk nach dem Beitritt zum CGMP-Stapel. Es wurde nur der Cisco IOS-Router zur Multicast-Gruppe hinzugefügt (fett dargestellt).

   Hinweis: Während in den vorherigen Beispielen in diesem Dokument die Ports, die Datenverkehr vom Multicast-Router empfangen, fett dargestellt wurden, zeigt dieses Beispiel alle Ports, die dem Switch zur Multicast-Gruppe hinzugefügt wurden.

   • Port 1 - Empfänger PC 1

   • Port 2 - Empfänger PC 2

   • Port 3 - Empfänger PC 3

   • Port 4 - kein Empfänger-PC 4

   • Port 5 - anderer Switch (keine Empfänger oder Router auf diesem Switch)

   • Port 48 - Cisco IOS-Router mit IGMP und CGMP

2. Sendet eine allgemeine IGMP-Abfrage. Alle Empfänger erhalten diese allgemeine IGMP-Abfrage und erstellen einen Bericht für jede Gruppe, der sie beigetreten sind. Da der CGMP-Switch bereits einen Multicast-Eintrag für jede Gruppe erstellt hat, bei dem nur der Router als Empfänger fungiert, werden alle Berichte nur an den Router gesendet. Der Router sendet nachfolgende CGMP-Join-Nachrichten, um alle Empfänger zu den entsprechenden Gruppen hinzuzufügen.

   Nachdem alle Empfänger ihren IGMP-Bericht zurückgesendet und der Router die entsprechenden CGMP-Join-Nachrichten gesendet hat, sollten alle Empfänger wieder der Multicast-Gruppe hinzugefügt worden sein.

3. Nach 10 Sekunden (IGMP max-response-time) wird eine weitere allgemeine IGMP-Abfrage gesendet, um sicherzustellen, dass alle Empfänger hinzugefügt werden. Dieser Schritt wird mehrfach wiederholt, um sicherzustellen, dass alle Empfänger wieder der Multicast-Gruppe angehören.

   Alle Ports, die der Multicast-Gruppe hinzugefügt werden sollten, wurden, wie in diesem Beispiel fett dargestellt:

   • Port 1 - Empfänger PC 1

   • Port 2 - Empfänger PC 2

   • Port 3 - Empfänger PC 3

   • Port 4 - kein Empfänger-PC 4

   • Port 5 - anderer Switch (keine Empfänger oder Router auf diesem Switch)

   • Port 48 - Cisco IOS-Router mit IGMP und CGMP

Catalyst Switch-Verhalten

Im Bereich der Catalyst Switches gibt es einige Unterschiede im Verhalten. Jeder CGMP-fähige Switch entspricht den Anweisungen im Abschnitt CGMP- und Topologieänderungen in diesem Dokument. Die Erweiterungen für CGMP werden jedoch nicht auf allen Plattformen implementiert. Diese Tabelle enthält eine Liste der Catalyst Switches und ihre Reaktion auf CGMP:

	CGMP-Switch	CGMP-Router	Sendet Global Leave wenn STP Root (Spanning Tree Protocol)
Catalyst 6500 mit Cisco IOS Software	N	J	J
Catalyst 6500 mit CatOS	N	N	N
Catalyst 5500, Catalyst 2926/2926G	J	N	J
Catalyst 4000 Supervisor Engine I/II, Catalyst 2948G/2980G, Catalyst 4912G	J	N	J
Catalyst 4000/4500 Supervisor Engine III/IV	N	J	J
Catalyst 2900XL/3500XL	J	N	J
Catalyst 2940	N	N	N
Catalyst 2950	N	N	N
Catalyst 2970	N	N	N
Catalyst 3550	N	J	J
Catalyst 3750	N	J	J

Hinweis: Auf dem Catalyst 4000/4500 mit Supervisor Engine III/IV ist das Verhalten in Bezug auf Topologieänderungen und CGMP konfigurierbar. Geben Sie diesen Befehl ein, um den Catalyst 4000 so zu konfigurieren, dass er eine IGMP-globale Urlaubsmeldung sendet oder nicht sendet, wenn es sich nicht um den Spanning Tree Root handelt:

• ip igmp snooping tcn query anfordern

Hinweis: Geben Sie dieses "Nein"-Formular für den Befehl aus, um ihn zu deaktivieren:

• no ip igmp snooping tcn query anfordern

Zugehörige Informationen

• Verstehen von Änderungen der Spanning Tree Protocol-Topologie
• Multicast in einem Campus-Netzwerk: CGMP- und IGMP-Snooping
• Beschränkung des Multicast-Datenverkehrs mit Quell- und Receivern im selben VLAN auf Catalyst Switches mit Catalyst OS
• Konfigurationsleitfaden für die Cisco IOS Software Catalyst 4000: Verständnis und Konfiguration von IGMP-Snooping
• Seite für den technischen Support für Spanning Tree
• Support-Seiten für LAN-Produkte
• Support-Seite für LAN-Switching
• Technischer Support und Dokumentation - Cisco Systems