Das PIM-Protokoll ist eine Reihe von Protokollen zur Übertragung 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 gleich 3.5*Hello Timer, also standardmäßig 105 Sekunden.
PIM verwendet zwei Hauptbetriebsmodi – den Dense- und den Sparse-Modus. Beginnen wir mit dem Dense-Modus.
Quellenbasierte Verteilungsbäume.
Bei einer großen Anzahl von Clients verschiedener Multicast-Gruppen empfiehlt sich die Verwendung des Dense-Mode-Modus. Wenn ein Router Multicast-Verkehr empfängt, prü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 notwendig, dass der Datenverkehr an der Schnittstelle ankommt, hinter der sich dieser Host entsprechend der Version der Unicast-Routing-Tabelle verbirgt. Dieser Mechanismus löst das Problem einer Schleife, die während der Multicast-Übertragung auftritt.
R3 erkennt die Multicast-Quelle (Quell-IP) anhand der Multicast-Nachricht und überprüft die beiden Flüsse von R1 und R2 mithilfe seiner Unicast-Tabelle. Der Stream von der Schnittstelle, auf die die Tabelle zeigt (R1 bis R3), wird weiter übertragen und der Stream von R2 wird verworfen, da Sie Pakete über S0/1 senden müssen, um zur Multicast-Quelle zu gelangen.
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 aus diesen Routen aus. Wer die höhere IP-Adresse hat, gewinnt. Wenn Sie dieses Verhalten ändern müssen, können Sie ECMP verwenden. Mehr Details .
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 zu den Endempfängern genommen hat, bildet einen Baum, der als quellenbasierter Verteilungsbaum, Shortest-Path-Tree (SPT) oder Quellbaum bezeichnet wird. Drei verschiedene Namen, wählen Sie einen beliebigen.
So lösen Sie das Problem, dass einige Router einen Multicast-Stream nicht aufgegeben haben und es niemanden gibt, an den er ihn senden kann, der Upstream-Router ihn jedoch an ihn sendet. Dafür wurde der Prune-Mechanismus erfunden.
Nachricht beschneiden.
Beispielsweise sendet R2 weiterhin einen Multicast an R3, obwohl R3 ihn gemäß der RPF-Regel verwirft. Warum den Kanal laden? R3 sendet eine PIM-Prune-Nachricht und R2 entfernt nach Erhalt dieser Nachricht die Schnittstelle S0/1 aus der Liste der ausgehenden Schnittstellen für diesen Fluss, der Liste der Schnittstellen, von denen dieser Datenverkehr gesendet werden soll.
Im Folgenden finden Sie eine formellere Definition einer PIM-Prune-Nachricht:
Die PIM Prune-Nachricht wird von einem Router an einen zweiten Router gesendet, um den zweiten Router zu veranlassen, den Link zu entfernen, auf dem die Prune von einem bestimmten (S,G) SPT empfangen wird.
Nach dem Empfang der Prune-Nachricht stellt R2 den Prune-Timer auf 3 Minuten ein. Nach drei Minuten wird der Datenverkehr erneut gesendet, bis eine weitere Prune-Nachricht eingeht. Dies ist in PIMv1.
Und in PIMv2 wurde ein State Refresh-Timer hinzugefügt (standardmäßig 60 Sekunden). Sobald eine Prune-Nachricht von R3 gesendet wurde, wird dieser Timer auf R3 gestartet. Nach Ablauf dieses Timers sendet R3 eine State Refresh-Nachricht, die den 3-Minuten-Prune-Timer auf R2 für diese Gruppe zurücksetzt.
Gründe für das Senden einer Prune-Nachricht:
- Wenn ein Multicast-Paket die RPF-Prüfung nicht besteht.
- Wenn keine lokal verbundenen Clients vorhanden sind, die eine Multicast-Gruppe angefordert haben (IGMP-Beitritt) und keine PIM-Nachbarn vorhanden sind, an die Multicast-Verkehr gesendet werden kann (Non-Prune-Schnittstelle).
Graft-Nachricht.
Stellen wir uns vor, dass R3 keinen Verkehr von R2 wollte, Prune sendete und einen Multicast von R1 empfing. Doch plötzlich fiel der Kanal zwischen R1-R3 aus und R3 blieb ohne Multicast. Sie können 3 Minuten warten, bis der Prune-Timer auf R2 abläuft. 3 Minuten sind eine lange Wartezeit. Um nicht zu warten, müssen Sie eine Nachricht senden, die diese Schnittstelle S0/1 zu R2 sofort aus dem bereinigten Zustand bringt. Bei dieser Nachricht handelt es sich um eine Graft-Nachricht. Nach Erhalt der Graft-Nachricht antwortet R2 mit einem Graft-ACK.
Prune-Überschreibung.
Schauen wir uns dieses Diagramm an. R1 sendet Multicast an ein Segment mit zwei Routern. R3 empfängt und sendet Datenverkehr, R2 empfängt, hat aber niemanden, an den er Datenverkehr senden kann. In diesem Segment wird eine Prune-Nachricht an R1 gesendet. R1 sollte Fa0/0 aus der Liste entfernen und die Ausstrahlung in diesem Segment einstellen, aber was passiert mit R3? Und R3 ist im selben Segment, hat diese Nachricht auch von Prune erhalten und die Tragödie der Situation verstanden. Bevor R1 die Übertragung beendet, stellt es einen Timer von 3 Sekunden ein und stoppt die Übertragung nach 3 Sekunden. 3 Sekunden – genau so viel Zeit hat R3, um seinen 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 stoppen. Über die Beitrittsnachrichten unten.
Nachricht bestätigen.
Stellen wir uns diese Situation vor: Zwei Router senden gleichzeitig an ein Netzwerk. Sie empfangen denselben Stream von der Quelle und senden ihn beide an dasselbe Netzwerk hinter der Schnittstelle e0. Daher müssen sie festlegen, wer der einzige Sender für dieses Netzwerk sein wird. Hierzu werden Assert-Nachrichten verwendet. Wenn R2 und R3 eine Duplizierung des Multicast-Verkehrs erkennen, also ein Multicast bei R2 und R3 ankommt, den sie selbst senden, verstehen die Router, dass hier etwas nicht stimmt. In diesem Fall senden Router Assert-Nachrichten, die die administrative Entfernung und die Routenmetrik enthalten, mit der die Multicast-Quelle erreicht wird – 10.1.1.10. Der Gewinner wird wie folgt ermittelt:
- Der mit niedrigerem AD.
- Wenn AD gleich sind, wer hat dann die niedrigere Metrik?
- Wenn hier Gleichheit herrscht, dann derjenige, der in dem Netzwerk, an das er diesen Multicast sendet, die höhere IP hat.
Der Gewinner dieser Abstimmung wird zum Designated Router. Pim Hello wird auch zur Auswahl von DRs verwendet. Am Anfang des Artikels wurde die PIM-Hello-Nachricht angezeigt, dort ist das DR-Feld zu sehen. Derjenige mit der höchsten IP-Adresse auf diesem Link gewinnt.
Nützliches Zeichen:
MROUTE-Tabelle.
Nach einem ersten Blick auf die Funktionsweise des PIM-Protokolls müssen wir verstehen, wie man mit einer Multicast-Routing-Tabelle arbeitet. In der Mroute-Tabelle werden Informationen darüber gespeichert, welche Streams von Clients angefordert wurden und welche Streams von Multicast-Servern fließen.
Wenn beispielsweise ein IGMP-Mitgliedschaftsbericht oder ein PIM-Beitritt über eine Schnittstelle empfangen wird, wird der Routing-Tabelle ein Datensatz 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 Dense-Modus arbeitet, und C bedeutet, dass der Empfänger direkt mit dem Router verbunden ist, d. h. der Router hat den IGMP-Mitgliedschaftsbericht und den PIM-Beitritt erhalten.
Wenn ein Datensatz vom Typ (S,G) vorhanden ist, bedeutet dies, dass wir einen Multicast-Stream haben:
Im S-Feld – 192.168.1.11 – haben wir die IP-Adresse der Multicast-Quelle eingetragen, diese wird von der RPF-Regel überprüft. Bei Problemen müssen Sie zunächst die Unicast-Tabelle auf die Route zur Quelle überprüfen. Gibt im Feld „Eingehende Schnittstelle“ die Schnittstelle an, an der der Multicast empfangen wird. In einer 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, hat der Router keine Anfragen für diesen Datenverkehr erhalten. Weitere Informationen zu allen Flaggen finden Sie hier .
PIM Sparse-Modus.
Die Strategie des Sparse-Modus ist das Gegenteil des Dense-Modus. Wenn der Sparse-Modus Multicast-Verkehr empfängt, wird er nur Verkehr über die Schnittstellen senden, für die es Anfragen für diesen Fluss gab, zum Beispiel Pim-Join- oder IGMP-Report-Nachrichten, 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 DR-Auswahl ist ähnlich.
- Der Mechanismus von Prune Overrides und Assert-Nachrichten ist ähnlich.
Um zu steuern, wer, wo und welche Art von Multicast-Verkehr im Netzwerk benötigt wird, ist ein gemeinsames Informationszentrum erforderlich. Unser Zentrum wird der Rendezvous Point (RP) sein. Jeder, der eine Art Multicast-Verkehr möchte oder jemand begonnen hat, Multicast-Verkehr von der Quelle zu empfangen, sendet ihn an RP.
Wenn der RP Multicast-Verkehr empfängt, sendet er ihn an die Router, die diesen Verkehr zuvor angefordert haben.
Stellen wir uns eine Topologie vor, in der RP R3 ist. Sobald R1 Datenverkehr von S1 empfängt, kapselt es dieses Multicast-Paket in eine Unicast-PIM-Registernachricht und sendet es an RP. Woher weiß er, wer der RP ist? In diesem Fall ist es statisch konfiguriert, und wir werden später über die dynamische RP-Konfiguration sprechen.
IP-PIM-RP-Adresse 3.3.3.3
RP wird nachschauen – gab es Informationen von jemandem, der diesen Traffic gerne erhalten würde? Nehmen wir an, dass dies nicht der Fall war. Dann sendet RP R1 eine PIM-Register-Stop-Nachricht, was bedeutet, dass niemand diesen Multicast benötigt und die Registrierung verweigert wird. R1 sendet kein Multicast. Der Multicast-Quellhost wird es jedoch senden, sodass R1 nach dem Empfang von Register-Stop einen Register-Unterdrückungs-Timer von 60 Sekunden startet. 5 Sekunden vor Ablauf dieses Timers sendet R1 eine leere Registernachricht mit einem Null-Register-Bit (d. h. ohne gekapseltes Multicast-Paket) an RP. RP wiederum wird sich wie folgt verhalten:
- Wenn keine Empfänger vorhanden sind, wird mit einer Register-Stop-Nachricht geantwortet.
- Wenn Empfänger auftauchen, wird er in keiner Weise darauf reagieren. Da R1 innerhalb von 5 Sekunden keine Registrierungsverweigerung erhalten hat, wird er zufrieden sein und eine Registrierungsnachricht mit einem gekapselten Multicast an RP senden.
Wir scheinen herausgefunden zu haben, wie Multicast RP erreicht. Versuchen wir nun, die Frage zu beantworten, wie RP den Datenverkehr an die Empfänger weiterleitet. Hier ist es notwendig, ein neues Konzept einzuführen – Root-Path-Tree (RPT). RPT ist ein in RP verwurzelter Baum, der in Richtung der Empfänger wächst und sich auf jedem PIM-SM-Router verzweigt. RP erstellt es durch den Empfang von PIM-Join-Nachrichten und fügt dem Baum einen neuen Zweig hinzu. Und das gilt auch für jeden Downstream-Router. Die allgemeine Regel sieht so aus:
- Wenn ein PIM-SM-Router eine PIM-Join-Nachricht auf einer anderen Schnittstelle als der Schnittstelle empfängt, 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 wir uns vor, dass wir auf dem R5-Router einen Multicast-Client für die Gruppe 228.8.8.8 haben. Sobald R5 den IGMP-Mitgliedschaftsbericht vom Host erhält, sendet R5 einen PIM-Join in Richtung des RP und fügt selbst eine Schnittstelle zum Baum hinzu, die den Host betrachtet. Als nächstes empfängt R4 PIM Join von R5, fügt die Schnittstelle Gi0/1 zum Baum hinzu und sendet PIM Join in Richtung RP. Schließlich empfängt RP (R3) den PIM-Join und fügt Gi0/0 zum Baum hinzu. Somit ist der Multicast-Empfänger registriert. Wir erstellen einen Baum mit der Wurzel R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Danach wird ein PIM-Join an R1 gesendet und R1 beginnt mit dem Senden von Multicast-Verkehr. Es ist wichtig zu beachten, dass RP keinen PIM-Join und überhaupt nichts an R1 sendet, wenn der Host vor Beginn der Multicast-Übertragung Datenverkehr angefordert hat.
Wenn der Host beim Senden eines Multicasts plötzlich aufhört, ihn zu empfangen, sendet RP, sobald er einen PIM Prune auf der Gi0/0-Schnittstelle empfängt, sofort einen PIM Register-Stop direkt an R1 und dann einen PIM Prune Nachricht über die Gi0/1-Schnittstelle. PIM Register-Stop wird per Unicast an die Adresse gesendet, von der das PIM Register stammt.
Wie bereits erwähnt, wird, sobald ein Router einen PIM-Join an einen anderen Router sendet, beispielsweise R5 an R4, ein Datensatz zu R4 hinzugefügt:
Und ein Timer wird gestartet, R5 muss diesen Timer ständig zurücksetzen. PIM-Join-Nachrichten müssen ständig zurückgesetzt werden, sonst wird R4 aus der Ausgangsliste ausgeschlossen. R5 sendet alle 60 PIM-Join-Nachrichten.
Kürzeste-Pfad-Baumumschaltung.
Wir werden eine Schnittstelle zwischen R1 und R5 hinzufügen und sehen, wie der Datenverkehr mit dieser Topologie fließt.
Nehmen wir an, dass der Datenverkehr nach dem alten Schema R1-R2-R3-R4-R5 gesendet und empfangen wurde, 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 aufbauen und nun wird das Netzwerk 192.168.1.0/24 über die R5-Gi0/2-Schnittstelle erreicht. Jetzt erkennt R5, der Multicast auf der Schnittstelle Gi0/1 empfängt, dass die RPF-Regel nicht erfüllt ist und es logischer wäre, Multicast auf Gi0/2 zu empfangen. Es sollte sich von RPT trennen und einen kürzeren Baum namens Shortest-Path Tree (SPT) erstellen. Dazu sendet er PIM Join über Gi0/2 an R1 und R1 beginnt, ebenfalls über Gi0/2 einen Multicast zu senden. Jetzt muss sich R5 von RPT abmelden, um nicht zwei Exemplare zu erhalten. Dazu sendet er Prune eine Nachricht, die die Quell-IP-Adresse angibt und ein spezielles Bit einfügt – das RPT-Bit. Das bedeutet, dass Sie mir keinen Datenverkehr senden müssen, ich habe hier einen besseren Baum. RP sendet auch PIM Prune-Nachrichten an R1, sendet jedoch keine Register-Stop-Nachricht. Eine weitere Funktion: R5 sendet nun kontinuierlich PIM Prune an RP, während R1 weiterhin jede Minute PIM Register an RP sendet. Solange es keine neuen Leute gibt, die diesen Datenverkehr wollen, wird RP ihn ablehnen. R5 benachrichtigt RP, dass es weiterhin Multicast über SPT empfängt.
Dynamische RP-Suche.
Auto-RP.
Diese Technologie ist proprietär von Cisco und nicht besonders beliebt, aber immer noch am Leben. Der Auto-RP-Betrieb besteht aus zwei Hauptphasen:
1) RP sendet RP-Announce-Nachrichten an die reservierte Adresse – 224.0.1.39 und erklärt sich selbst als RP entweder 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. Anhand dieser Nachricht ermitteln reguläre PIM-Router den RP selbst. 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:
Lassen Sie uns R3 als RP konfigurieren:
IP PIM Send-RP-Announce Loopback 0 Scope 10
R2 als Mapping-Agent:
IP PIM Send-RP-Discovery Loopback 0 Bereich 10
Und bei allen anderen erwarten wir RP über Auto-RP:
IP-PIM-AutoRP-Listener
Sobald wir R3 konfiguriert haben, beginnt es mit dem Senden von RP-Announce:
Und R2 beginnt nach dem Einrichten des Mapping-Agenten, auf die RP-Announce-Nachricht zu warten. Erst wenn mindestens ein RP gefunden wird, beginnt das Senden von RP-Discovery:
Auf diese Weise wissen reguläre Router (PIM RP Listener), sobald sie diese Nachricht erhalten, wo sie nach dem RP suchen müssen.
Eines der Hauptprobleme bei Auto-RP besteht darin, dass Sie zum Empfang 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 die Nachrichten liegen RP befindet sich. Klassisches Henne-Ei-Problem. Um dieses Problem zu lösen, wurde der PIM Sparse-Dense-Mode erfunden. Wenn der Router RP nicht kennt, arbeitet er im Dense-Modus; wenn ja, dann im Sparse-Modus. Wenn der PIM-Sparse-Modus und der Befehl ip pim autorp listener auf den Schnittstellen regulärer Router konfiguriert sind, arbeitet der Router im Dense-Modus nur für Multicasting direkt vom Auto-RP-Protokoll (224.0.1.39-40).
BootStrap-Router (BSR).
Diese Funktion funktioniert ähnlich wie Auto-RP. Jeder RP sendet eine Nachricht an den Mapping-Agent, der Mapping-Informationen sammelt und diese dann allen anderen Routern mitteilt. Beschreiben wir den Prozess ähnlich wie bei Auto-RP:
1) Sobald wir R3 als Kandidaten für RP konfiguriert haben, mit dem Befehl:
IP PIM RP-Kandidat Loopback 0
Dann wird R3 nichts unternehmen; um mit dem Versenden spezieller Nachrichten beginnen zu können, muss er zunächst einen Mapping-Agenten finden. Somit 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, in denen es sich als Mapping-Agent angibt:
Diese Nachricht wird an die Adresse 224.0.013 gesendet, die das PIM-Protokoll auch für seine anderen Nachrichten verwendet. Es sendet sie in alle Richtungen und daher gibt es kein Henne-Ei-Problem wie bei Auto-RP.
3) Sobald der RP eine Nachricht vom BSR-Router empfängt, sendet er sofort eine Unicast-Nachricht an die BSR-Router-Adresse:
Nachdem der BSR Informationen über die RPs erhalten hat, sendet er diese per Multicast an die Adresse 224.0.0.13, die von allen PIM-Routern abgehört wird. Daher ein Analogon des Befehls IP-PIM-AutoRP-Listener für normale Router, die nicht in BSR sind.
Anycast RP mit Multicast Source Discovery Protocol (MSDP).
Mit Auto-RP und BSR können wir die Last auf RP wie folgt verteilen: Jede Multicast-Gruppe hat nur einen aktiven RP. Es ist nicht möglich, die Last für eine Multicast-Gruppe auf mehrere RPs zu verteilen. MSDP erreicht dies, indem es RP-Routern dieselbe IP-Adresse mit der Maske 255.255.255.255 zuweist. MSDP lernt Informationen mit 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. Beim RP-Announce melden sich beide Router unter Bezugnahme auf diese Adresse an. Nachdem der Auto-RP-Mapping-Agent die Informationen erhalten hat, sendet er RP-Discovery über den RP mit der Adresse 172.16.1.1/32. Wir informieren Router über das Netzwerk 172.16.1.1/32 mithilfe von IGP und entsprechend. Daher fordern oder registrieren PIM-Router Datenflüsse von dem RP, der als nächster Hop auf der Route zum Netzwerk 172.16.1.1/32 angegeben ist. Das MSDP-Protokoll selbst ist dafür konzipiert, dass die RPs selbst Nachrichten über Multicast-Informationen austauschen können.
Betrachten Sie diese Topologie:
Switch6 sendet Datenverkehr an die Adresse 238.38.38.38 und bisher weiß nur RP-R1 davon. Switch7 und Switch8 haben diese Gruppe angefordert. Die Router R5 und R4 senden PIM Join an R1 bzw. R3. Warum? Die Route zu 13.13.13.13 für R5 bezieht sich auf R1 unter Verwendung der IGP-Metrik, genau wie für R4.
RP-R1 weiß von dem Stream und wird ihn an R5 senden, aber R4 weiß nichts davon, da R1 ihn nicht einfach senden wird. Daher ist MSDP notwendig. Wir konfigurieren es auf R1 und R5:
IP-MSDP-Peer 3.3.3.3 Connect-Source Loopback1 auf R1
IP-MSDP-Peer 1.1.1.1 Connect-Source Loopback3 auf R3
Sie gründen eine Sitzung untereinander und melden den Empfang eines Flows ihrem RP-Nachbarn.
Sobald RP-R1 einen Stream von Switch6 empfängt, sendet er sofort eine Unicast-MSDP-Source-Active-Nachricht, die Informationen wie (S, G) enthält – Informationen über die Quelle und das Ziel des Multicasts. Da RP-R3 nun weiß, dass eine Quelle wie Switch6, wenn sie eine Anfrage von R4 für diesen Fluss erhält, PIM-Join an Switch6 sendet, geleitet von der Routing-Tabelle. Folglich beginnt R1, nachdem es einen solchen PIM-Join erhalten hat, Datenverkehr an RP-R3 zu senden.
MSDP läuft über TCP, RPs senden sich gegenseitig Keepalive-Nachrichten, um die Lebendigkeit zu überprüfen. Der Timer beträgt 60 Sekunden.
Die Funktion der Aufteilung von MSDP-Peers in verschiedene Domänen bleibt unklar, da Keepalive- und SA-Nachrichten keine Zugehörigkeit zu einer Domäne anzeigen. Außerdem haben wir in dieser Topologie eine Konfiguration getestet, die verschiedene Domänen anzeigt – es gab keinen Unterschied in der Leistung.
Wenn jemand etwas klären kann, würde ich mich freuen, es in den Kommentaren zu lesen.
Source: habr.com
