PIM-Prinzipien

Das PIM-Protokoll ist eine Reihe von Protokollen zum Übertragen von Multicast in einem Netzwerk zwischen Routern. Nachbarschaftsbeziehungen werden auf die gleiche Weise aufgebaut wie bei dynamischen Routing-Protokollen. PIMv2 sendet alle 30 Sekunden Hello-Nachrichten an die reservierte Multicast-Adresse 224.0.0.13 (All-PIM-Router). Die Nachricht enthält Hold-Timer - normalerweise 3,5 * Hallo Timer, das sind standardmäßig 105 Sekunden.

PIM verwendet zwei Hauptbetriebsarten - Dense- und Sparse-Modus. Beginnen wir mit dem Dichtemodus.
Quellbasierte Verteilungsbäume.
Der Dense-Mode-Modus empfiehlt sich bei einer großen Anzahl von Clients verschiedener Multicast-Gruppen. Wenn ein Router Multicast-Verkehr empfängt, überprüft er ihn zunächst auf die RPF-Regel. RPF - Diese Regel wird verwendet, um die Quelle eines Multicasts mit einer Unicast-Routing-Tabelle zu überprüfen. Es ist erforderlich, dass der Datenverkehr an die Schnittstelle gelangt, hinter der dieser Host gemäß der Version der Unicast-Routing-Tabelle versteckt ist. Dieser Mechanismus löst das Problem des Auftretens von Schleifen während der Multicast-Übertragung.

R3 aus der Multicast-Nachricht erkennt die Quelle des Multicast (Quell-IP) und überprüft die beiden Streams von R1 und R2 aus seiner Unicast-Tabelle. Der Stream von der in der Tabelle angegebenen Schnittstelle (R1 bis R3) wird weiter übertragen, und der Stream von R2 wird gelöscht, da zum Senden an die Quelle des Multicasts Pakete über S0 / 1 gesendet werden müssen.
Die Frage ist, was passiert, wenn Sie zwei äquivalente Routen mit derselben Metrik haben? In diesem Fall wählt der Router den nächsten Hop für diese Routen. Wer eine höhere IP-Adresse hat, hat gewonnen. Wenn Sie dieses Verhalten ändern müssen, können Sie ECMP verwenden. Weitere Details hier .
Nach Überprüfung der RPF-Regel sendet der Router ein Multicast-Paket an alle seine PIM-Nachbarn, mit Ausnahme desjenigen, von dem das Paket empfangen wurde. Andere PIM-Router wiederholen diesen Vorgang. Der Pfad, den ein Multicast-Paket von der Quelle an die endgültigen Empfänger übergeben hat, bildet einen Baum, der als quellenbasierter Verteilungsbaum, SPT (Shortest Path Tree) und Quellbaum bezeichnet wird. Drei verschiedene Namen, wählen Sie einen.
So lösen Sie das Problem mit der Tatsache, dass einige Router keinen Multicast-Stream aufgegeben haben und niemand ihn senden kann und der übergeordnete Router ihn sendet. Dafür wurde der Prune-Mechanismus erfunden.
Nachricht beschneiden.
Zum Beispiel sendet R2 weiterhin R3-Multicast, obwohl R3 es nach der RPF-Regel löscht. Warum den Kanal laden? R3 sendet eine PIM-Prune-Nachricht und R2 entfernt beim Empfang dieser Nachricht die S0 / 1-Schnittstelle aus der Liste der ausgehenden Schnittstellen für diesen Stream, der Liste der Schnittstellen, von denen dieser Datenverkehr gesendet werden soll.

Das Folgende ist eine formellere Definition einer PIM Prune-Nachricht:
Die PIM-Prune-Nachricht wird von einem Router an einen zweiten Router gesendet, damit der zweite Router die Verbindung entfernt, über die der Prune von einem bestimmten (S, G) SPT empfangen wird.

Nach dem Empfang der Prune-Nachricht setzt R2 den Prune-Timer auf 3 Minuten. Nach drei Minuten wird erneut Datenverkehr gesendet, bis die nächste Prune-Nachricht empfangen wird. Dies ist in PIMv1.
In PIMv2 wird der Statusaktualisierungs-Timer hinzugefügt (standardmäßig 60 Sekunden). Sobald eine Prune-Nachricht von R3 gesendet wurde, startet dieser Timer auf R3. Nach Ablauf dieses Timers sendet R3 eine Statusaktualisierungsnachricht, die den 3-Minuten-Prune-Timer für diese Gruppe auf R2 zurücksetzt.
Gründe für das Senden einer Prune-Nachricht:

• Wenn ein Multicast-Paket eine RPF-Prüfung nicht bestanden hat.
• Wenn keine lokal verbundenen Clients eine Multicast-Gruppe (IGMP-Join) angefordert haben und keine PIM-Nachbarn vorhanden sind, an die Multicast-Verkehr (Non-Prune-Schnittstelle) gesendet werden kann.

Transplantationsnachricht.
Stellen Sie sich vor, R3 wollte keinen Datenverkehr von R2, hat Prune gesendet und Multicast von R1 empfangen. Aber plötzlich fiel der Kanal zwischen R1-R3 und R3 ohne Multicast. Sie können 3 Minuten warten, bis der Prune Timer auf R2 abläuft. 3 Minuten, um eine lange Zeit zu warten, um nicht zu warten, müssen Sie eine Nachricht senden, die diese Schnittstelle S0 / 1 auf R2 sofort aus dem beschnittenen Zustand anzeigt. Diese Nachricht ist eine Transplantationsnachricht. Nach dem Empfang der Graft-Nachricht sendet R2 als Antwort eine Graft-ACK.
Prune Override.

Schauen wir uns dieses Schema an. R1 sendet Multicast in einem Segment mit zwei Routern. R3 empfängt und sendet Verkehr, R2 empfängt, aber es gibt niemanden, der Verkehr sendet. Es sendet eine Prune-Nachricht an R1 in diesem Segment. R1 sollte Fa0 / 0 aus der Liste entfernen und die Übertragung in diesem Segment beenden, aber was passiert mit R3? Und R3 ist im selben Segment, er erhielt auch diese Nachricht von Prune und erkannte die Tragödie der Situation. Bevor R1 die Übertragung beendet, stellt es den Timer auf 3 Sekunden ein und beendet die Übertragung nach 3 Sekunden. 3 Sekunden - nur so viel Zeit für R3, um Ihren Multicast nicht zu verlieren. Daher sendet R3 so schnell wie möglich eine Pim Join-Nachricht für diese Gruppe, und R1 denkt nicht mehr daran, die Übertragung zu beenden. Über Beiträge unten beitreten.
Nachricht bestätigen.

Stellen Sie sich diese Situation vor: Zwei Router senden gleichzeitig an dasselbe Netzwerk. Sie empfangen denselben Stream von der Quelle und senden ihn beide an dasselbe Netzwerk hinter der e0-Schnittstelle. Daher müssen sie bestimmen, wer der einzige einzelne Sender für dieses Netzwerk sein wird. Hierfür werden Assert-Meldungen verwendet. Wenn R2 und R3 eine Verdoppelung des Multicast-Verkehrs erkennen, dh Multicast, den sie auf R2 und R3 senden, die sie selbst senden, verstehen die Router, dass hier etwas nicht stimmt. In diesem Fall senden die Router Assert-Nachrichten, die die administrative Entfernung und die Routenmetrik enthalten, über die die Multicast-Quelle erreicht wird - 10.1.1.10. Der Gewinner wird wie folgt ermittelt:

1. Der mit niedrigerem AD.
2. Wenn AD gleich ist, wer hat dann die niedrigere Metrik?
3. Wenn es Gleichheit gibt, dann die mit einer höheren IP in dem Netzwerk, an das sie diesen Multicast senden.

Wenn Sie diese Abstimmung gewinnen, wird der Router zum Designated Router. Pim Hello wird auch zur Auswahl von DR verwendet. Zu Beginn des Artikels wurde eine PIM-Hallo-Nachricht angezeigt, dort können Sie das DR-Feld erkennen. Der Gewinner ist derjenige mit einer höheren IP-Adresse auf diesem Link.
Nützlicher Teller:

MROUTE-Tabelle.
Nach der ersten Überprüfung der Funktionsweise des PIM-Protokolls müssen wir herausfinden, wie mit der Multicast-Routing-Tabelle gearbeitet wird. In der Mroute-Tabelle werden Informationen darüber gespeichert, welche Streams von Clients angefordert wurden und welche Streams von Multicast-Servern stammen.
Wenn Sie beispielsweise auf einer Schnittstelle einen IGMP-Mitgliedschaftsbericht oder einen PIM-Join erhalten, wird der Routing-Tabelle ein Eintrag vom Typ (*, G) hinzugefügt:

Dieser Eintrag bedeutet, dass eine Verkehrsanforderung mit der Adresse 238.38.38.38 empfangen wurde. Das DC-Flag bedeutet, dass der Multicast im dichten Modus arbeitet, und C bedeutet, dass der Empfänger direkt mit dem Router verbunden ist, dh der Router hat den IGMP-Mitgliedschaftsbericht und PIM Join erhalten.
Wenn es einen Datensatz wie (S, G) gibt, bedeutet dies, dass wir einen Multicast-Stream haben:

Im Feld S - 192.168.1.11 haben wir die IP-Adresse der Multicast-Quelle registriert, diese wird von der RPF-Regel überprüft. Bei Problemen überprüfen Sie zunächst die Unicast-Tabelle auf die Route zur Quelle. Im Feld Eingehende Schnittstelle wird die Schnittstelle angegeben, an der der Multicast ankommt. In der Unicast-Routing-Tabelle muss sich die Route zur Quelle auf die hier angegebene Schnittstelle beziehen. Die ausgehende Schnittstelle gibt an, wohin der Multicast umgeleitet wird. Wenn es leer ist, gab es keine Anforderungen für diesen Datenverkehr an den Router. Weitere Informationen zu allen Flags finden Sie hier .
PIM Sparse-Modus.
Die Sparse-Mode-Strategie ist das Gegenteil von Dense-Mode. Wenn der Sparse-Modus Multicast-Verkehr empfängt, sendet er Verkehr nur über die Schnittstellen, an denen Anforderungen für diesen Stream aufgetreten sind, z. B. Pim Join- oder IGMP-Berichtsnachrichten, die diesen Verkehr anfordern.
Ähnliche Elemente für SM und DM:

• Nachbarschaftsbeziehungen werden auf die gleiche Weise wie in PIM DM aufgebaut.
• Die RPF-Regel funktioniert.
• Die Wahl von DR ist ähnlich.
• Die Prune Overrides-Engine und die Assert-Meldungen sind ähnlich.

Um zu steuern, wer wo, wo und welchen Multicast-Verkehr im Netzwerk benötigt wird, wird ein gemeinsames Informationszentrum benötigt. Ein solches Zentrum haben wir Rendezvous Point (RP). Jeder, der eine Art Multicast-Verkehr wünscht oder jemand hat begonnen, Multicast-Verkehr von der Quelle zu empfangen, sendet ihn dann an das RP.
Wenn der RP Multicast-Verkehr empfängt, sendet er ihn an die Router, die diesen Verkehr zuvor angefordert haben.

Stellen Sie sich eine solche Topologie vor, in der RP R3 ist. Sobald R1 Verkehr von S1 empfängt, kapselt es dieses Multicast-Paket in eine Unicast-PIM-Registernachricht und sendet es an RP. Woher weiß er, wer RP ist? In diesem Fall ist es statisch konfiguriert, und wir werden später über die dynamische RP-Optimierung sprechen.

IP-PIM-RP-Adresse 3.3.3.3

RP wird schauen - gab es irgendwelche Informationen von jemandem, der diesen Verkehr erhalten möchte? Angenommen, es war nicht so. Dann sendet RP R1 eine PIM-Register-Stop-Nachricht, was bedeutet, dass niemand diesen Multicast benötigt. Die Registrierung wird abgelehnt. R1 sendet keine Multicasts. Die Multicast-Quelle sendet sie jedoch, sodass R1 nach dem Empfang von Register-Stop den Register-Suppression-Timer startet, der 60 Sekunden beträgt. 5 Sekunden vor Ablauf des Timers sendet R1 eine leere Registernachricht mit einem Null-Register-Bit (dh ohne ein gekapseltes Multicast-Paket) an die RP-Seite. RP wird sich wiederum so verhalten:

• Wenn es keine und keine Empfänger gab, antwortet es mit einer Register-Stop-Nachricht.
• Wenn die Empfänger erschienen sind, wird er ihm in keiner Weise antworten. R1, der innerhalb von 5 Sekunden keine Ablehnung seiner Registrierung erhalten hat, wird begeistert sein und eine Nachricht mit dem gekapselten Multicast an RP senden.

Wenn der Multicast das RP erreicht, scheint er aussortiert zu sein. Versuchen wir nun, die Frage zu beantworten, wie das RP den Empfängern Datenverkehr bringt. Hier müssen Sie ein neues Konzept einführen - Root-Path Tree (RPT). Ein RPT ist ein Baum mit einer Wurzel im RP, die zu den Empfängern wächst, die auf jedem PIM-SM-Router verzweigen. RP erstellt es durch Empfang von PIM Join-Nachrichten und fügt dem Baum einen neuen Zweig hinzu. Und jeder nachgeschaltete Router auch. Die allgemeine Regel sieht folgendermaßen aus:

• Wenn ein PIM-SM-Router auf einer beliebigen Schnittstelle eine PIM-Join-Nachricht empfängt, mit Ausnahme der Schnittstelle, hinter der der RP verborgen ist, fügt er dem Baum einen neuen Zweig hinzu.
• Ein Zweig wird auch hinzugefügt, wenn der PIM-SM-Router einen IGMP-Mitgliedschaftsbericht von einem direkt verbundenen Host empfängt.

Stellen Sie sich vor, wir haben einen Multicast-Client auf dem R5-Router für Gruppe 228.8.8.8. Sobald R5 einen IGMP-Mitgliedschaftsbericht vom Host erhält, sendet R5 einen PIM-Join in Richtung RP und fügt dem Baum selbst eine Schnittstelle hinzu, die den Host betrachtet. Als nächstes empfängt R4 einen PIM-Join von R5, fügt die Gi0 / 1-Schnittstelle zum Baum hinzu und sendet den PIM-Join in Richtung RP. Schließlich empfängt RP (R3) einen PIM-Join und fügt dem Baum Gi0 / 0 hinzu. Somit wird die Registrierung des Multicast-Empfängers erhalten. Wir bauen einen Baum mit der Wurzel R3-Gi0 / 0 → R4-Gi0 / 1 → R5-Gi0 / 0.
Danach wird PIM Join an R1 gesendet und R1 beginnt mit dem Senden von Multicast-Verkehr. Es ist wichtig zu beachten, dass, wenn der Host vor Beginn der Multicast-Übertragung Datenverkehr angefordert hat, der RP keinen PIM-Join sendet und überhaupt nichts an die R1-Seite sendet.
Wenn der Host plötzlich während des Sendens eines Multicasts aufhört, ihn zu empfangen, sobald der RP PIM Prune auf der Gi0 / 0-Schnittstelle empfängt, sendet er sofort den PIM Register-Stop direkt an R1 und dann die PIM Prune-Nachricht über die Gi0 / 1-Schnittstelle. PIM Register-Stop wird von Unicast an die Adresse gesendet, von der das PIM Register angekommen ist.
Wie bereits erwähnt, wird R4 ein Eintrag hinzugefügt, sobald der Router einen PIM-Join an einen anderen sendet, z. B. R5 auf R4:

Und der Timer startet, dass R5 zum Zurücksetzen dieses Timers ständig PIM-Join-Nachrichten senden muss, sonst wird R4 von der ausgehenden Liste ausgeschlossen. R5 sendet alle 60 PIM Join-Nachrichten.
Baumumschaltung mit kürzestem Pfad.
Wir werden eine Schnittstelle zwischen R1 und R5 hinzufügen, um zu sehen, wie der Verkehr mit dieser Topologie fließen wird.

Angenommen, der Datenverkehr wurde gemäß dem alten Schema R1-R2-R3-R4-R5 gesendet und empfangen, und hier haben wir die Schnittstelle zwischen R1 und R5 verbunden und konfiguriert.
Zunächst müssen wir die Unicast-Routing-Tabelle auf R5 neu erstellen, und jetzt wird das Netzwerk 192.168.1.0/24 über die R5 Gi0 / 2-Schnittstelle erreicht. Wenn R5 nun einen Multicast auf der Gi0 / 1-Schnittstelle empfängt, versteht er, dass die RPF-Regel nicht erfüllt ist und es logischer wäre, einen Multicast auf Gi0 / 2 zu empfangen. Es sollte die Verbindung zum RPT trennen und einen kürzeren Baum erstellen, der als Shortest-Path Tree (SPT) bezeichnet wird. Zu diesem Zweck sendet er über Gi0 / 2 einen PIM-Join an R1 und R1 beginnt, Multicasts auch über Gi0 / 2 zu senden. Jetzt muss sich R5 vom RPT abmelden, um nicht zwei Kopien zu erhalten. Dazu sendet er eine Prune-Nachricht, die die IP-Adresse der Quelle angibt und ein spezielles Bit einfügt - RPT-Bit. Dies bedeutet, dass ich keinen Datenverkehr senden muss. Ich habe hier einen besseren Baum. Der RP sendet auch Nachrichten an die R1 PIM Prune-Seite, sendet jedoch keine Register-Stop-Nachricht. Ein weiteres Feature: R5 sendet nun ständig PIM Prune an RP, da R1 weiterhin jede Minute PIM Register an RP sendet. RP, bis es neue Leute gibt, die diesen Verkehr wünschen, wird ihn ablehnen. R5 benachrichtigt den RP, dass er weiterhin Multicast über SPT empfängt.
Dynamische RP-Suche.
Auto-RP
Diese Technologie ist proprietär von Cisco und nicht besonders beliebt, aber noch am Leben. Auto-RP besteht aus zwei Hauptschritten:
1) RP sendet RP-Announce-Nachrichten an die reservierte Adresse - 224.0.1.39 und deklariert sich selbst als RP für alle oder für bestimmte Gruppen. Diese Nachricht wird jede Minute gesendet.
2) Es ist ein RP-Mapping-Agent erforderlich, der RP-Discovery-Nachrichten sendet, die angeben, für welche Gruppen welche RP abgehört werden sollen. Aus dieser Nachricht bestimmen gewöhnliche PIM-Router den RP für sich. Der Mapping Agent kann entweder der RP-Router selbst oder ein separater PIM-Router sein. RP-Discovery wird mit einem Timer von einer Minute an die Adresse 224.0.1.40 gesendet.
Schauen wir uns den Prozess genauer an:
Stellen Sie R3 als RP ein:

IP PIM Send-RP-Announce Loopback 0 Bereich 10

R2 als Mapping-Agent:

IP PIM Send-RP-Discovery Loopback 0 Bereich 10

Und bei allen anderen erwarten wir RP durch Auto-RP:

IP PIM Autorp Listener

Sobald wir R3 konfiguriert haben, wird RP-Announce gesendet:

Und R2 wartet nach dem Einrichten des Mapping-Agenten auf die RP-Announce-Nachricht. Erst wenn er mindestens ein RP findet, sendet er RP-Discovery:

Sobald reguläre Router (PIM RP Listener) diese Nachricht erhalten, wissen sie, wo sie nach dem RP suchen müssen.
Eines der Hauptprobleme von Auto-RP besteht darin, dass Sie zum Empfangen von RP-Announce- und RP-Discovery-Nachrichten PIM Join an die Adressen 224.0.1.39-40 senden müssen und zum Senden wissen müssen, wo sich das RP befindet. Das klassische Problem von Huhn und Eiern. Um dieses Problem zu lösen, wurde der PIM Sparse-Dense-Mode erfunden. Wenn der Router RP nicht kennt, arbeitet er im Dichtemodus, wenn er es weiß, im Sparse-Modus. Wenn der PIM-Sparse-Modus und der Befehl ip pim autorp listener auf den Schnittstellen normaler Router konfiguriert sind, arbeitet der Router im Dense-Modus nur für das Multicast-Direkt-Auto-RP-Protokoll (224.0.1.39-40).
BootStrap Router (BSR).
Diese Funktion funktioniert ähnlich wie Auto-RP. Jeder RP sendet eine Mapping-Agent-Nachricht, die Mapping-Informationen sammelt und dann alle anderen Router informiert. Wir beschreiben den Prozess ähnlich wie bei Auto-RP:
1) Sobald wir R3 als Kandidaten für ein RP konfiguriert haben, lautet der Befehl:

ip pim rp-Kandidat Loopback 0

Daß R3 nichts unternimmt, um spezielle Nachrichten zu senden, muss er zunächst einen Mapping-Agenten finden. Damit gehen wir zum zweiten Schritt über.
2) Konfigurieren Sie R2 als Mapping-Agent:

ip pim bsr-Kandidat Loopback 0

R2 beginnt mit dem Senden von PIM-Bootstrap-Nachrichten, wobei es sich als Mapping-Agent ausgibt:

Diese Nachricht wird an die Adresse 224.0.013 gesendet, die das PIM-Protokoll für seine anderen Nachrichten verwendet. Er schickt sie in alle Richtungen und daher gibt es kein Problem mit Hühnchen und Eiern, wie es bei Auto-RP der Fall war.
3) Sobald der RP eine Nachricht vom BSR des Routers empfängt, sendet er sofort eine Unicast-Nachricht an die Adresse des BSR des Routers:

Wenn der BSR danach Informationen über den RP empfängt, sendet er diese mit Multicast an die Adresse 224.0.0.13, die alle PIM-Router abhören. Daher gibt es kein Analogon zum Befehl ip pim autorp listener für reguläre Router in BSR.
Anycast RP mit Multicast Source Discovery Protocol (MSDP).
Mit Auto-RP und BSR können wir die Last auf das RP wie folgt verteilen: Jede Multicast-Gruppe hat nur ein aktives RP. Es funktioniert nicht, die Lastverteilung für eine Multicast-Gruppe auf mehrere RP zu beschränken. MSDP gibt dazu RP-Routern dieselbe IP-Adresse mit einer Maske von 255.255.255.255 aus. MSDP erkennt Informationen mithilfe einer der folgenden Methoden: statisch, Auto-RP oder BSR.

Im Bild haben wir eine Auto-RP-Konfiguration mit MSDP. Beide RPs sind mit der IP-Adresse 172.16.1.1/32 auf der Loopback 1-Schnittstelle konfiguriert und werden für alle Gruppen verwendet. Bei RP-Announce sprechen beide Router über sich selbst und beziehen sich auf diese Adresse. Nachdem der Auto-RP-Mapping-Agent Informationen erhalten hat, sendet er RP-Discovery über das RP mit der Adresse 172.16.1.1/32. Über das Netzwerk 172.16.1.1/32 teilen wir Routern mit, die IGP bzw. verwenden. Somit fordern oder registrieren PIM-Router Flüsse von dem RP, der als nächster Sprung auf der Route zum Netzwerk 172.16.1.1/32 angegeben ist. Das MSDP-Protokoll selbst ist so konzipiert, dass die RPs selbst Multicast-Informationsnachrichten austauschen.
Betrachten Sie die folgende Topologie:

Switch6 sendet Datenverkehr an die Adresse 238.38.38.38, und bisher weiß nur RP-R1 davon. Hier haben Switch7 und Switch8 diese Gruppe angefordert. Die Router R5 und R4 senden PIM Join an R1 bzw. R3. Warum? Die Route bis 13.13.13.13 auf R5 bezieht sich auf R1 gemäß der IGP-Metrik wie auf R4.
RP-R1 kennt den Stream und sendet ihn in Richtung R5, aber R4 weiß nichts darüber, da R1 ihn einfach nicht sendet. Daher ist MSDP erforderlich. Wir konfigurieren es auf R1 und R5:

ip msdp peer 3.3.3.3 Verbindungsquelle Loopback1 auf R1

ip msdp peer 1.1.1.1 Verbindungsquelle Loopback3 auf R3

Sie werden eine Sitzung untereinander auslösen und beim Empfang eines Streams dies ihrem RP-Nachbarn melden.
Sobald RP-R1 den Stream von Switch6 empfängt, sendet es Unicast MSDP Source-Active sofort eine Nachricht, die Informationen wie (S, G) enthält - Informationen über die Quelle und das Ziel des Multicasts. Wenn RP-R3 weiß, dass eine Quelle wie Switch6 eine Anforderung von R4 für diesen Stream empfängt, sendet sie an Switch6 PIM Join, basierend auf der Routing-Tabelle. Daher beginnt R1, nachdem es einen solchen PIM-Join erhalten hat, Verkehr in Richtung RP-R3 zu senden.
MSDP wird über TCP ausgeführt. RPs senden sich gegenseitig Keepalive-Nachrichten, um die Lebensfähigkeit zu überprüfen. Der Timer beträgt 60 Sekunden.
Die Funktion der Aufteilung von MSDP-Peers in verschiedene Domänen bleibt unverständlich, da die Keepalive- und SA-Nachrichten keine Zugehörigkeit zu einer Domäne anzeigen. Auch in dieser Topologie wurde die Konfiguration unter Angabe verschiedener Domänen getestet - es gab keinen Unterschied im Betrieb.
Wenn jemand klarstellen kann, lesen Sie gerne die Kommentare.

Daran denke ich, um den Artikel zu beenden. Im Folgenden finden Sie nützliche Materialien und Links, die verwendet wurden:

1. CCIE Routing and Switching v5.0 Offizieller Zertifizierungsleitfaden, Band 2, 5. Auflage, Narbik Kocharians, Terry Vinson.
2. Netzwerke für die Kleinsten. Teil neun. Multicast