{"id":33142,"date":"2019-10-31T21:50:58","date_gmt":"2019-10-31T18:50:58","guid":{"rendered":"https:\/\/prohoster.info\/blog\/printsipy-raboty-protokola-pim\/"},"modified":"2019-10-31T21:50:58","modified_gmt":"2019-10-31T18:50:58","slug":"printsipy-raboty-protokola-pim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","title":{"rendered":"Die Prinzipien des PIM-Protokolls","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Das PIM-Protokoll ist eine Sammlung von Protokollen zur \u00dcbertragung von Multicast in Netzwerken zwischen Routern. Die Nachbarschaftsbeziehungen werden \u00e4hnlich aufgebaut wie bei dynamischen Routing-Protokollen. PIMv2 sendet alle 30 Sekunden Hello-Nachrichten an die reservierte Multicast-Adresse 224.0.0.13 (All-PIM-Routers). Die Nachricht enth\u00e4lt Hold Timers, die normalerweise 3,5 * Hello Timer betragen, also standardm\u00e4\u00dfig 105 Sekunden.
\n\"Die<\/a><\/noindex>
\n PIM verwendet zwei Hauptbetriebsmodi \u2013 Dense und Sparse mode. Lassen Sie uns mit dem Dense mode beginnen. <\/a><\/noindex>
\nQuellbasierte Verteilung B\u00e4ume.<\/b>
\nDer Dense-Mode ist sinnvoll, wenn eine gro\u00dfe Anzahl von Clients verschiedener Multicast-Gruppen vorhanden ist. Wenn der Router Multicast-Verkehr erh\u00e4lt, \u00fcberpr\u00fcft er zun\u00e4chst die RPF-Regel. RPF \u2013 diese Regel wird verwendet, um die Quelle des Multicasts mit der Unicast-Routing-Tabelle zu \u00fcberpr\u00fcfen. Der Verkehr muss an das Interface kommen, hinter dem dieser Host gem\u00e4\u00df der Unicast-Routing-Tabelle verborgen ist. Dieser Mechanismus l\u00f6st das Problem von Schleifenbildung bei der \u00dcbertragung von Multicast.
\n \"Die<\/a><\/noindex>
\nR3 erf\u00e4hrt aus der Multicast-Nachricht die Multicast-Quelle (Source IP) und \u00fcberpr\u00fcft zwei Str\u00f6me von R1 und R2 anhand seiner Unicast-Routing-Tabelle. Der Strom von dem Interface, auf das die Tabelle verweist (R1 an R3), wird weitergeleitet, w\u00e4hrend der Strom von R2 verworfen wird, da die Pakete \u00fcber S0\/1 gesendet werden m\u00fcssen, um die Multicast-Quelle zu erreichen.
\nDie Frage ist, was passiert, wenn Sie zwei \u00e4quivalente Wege mit der gleichen Metrik haben? In diesem Fall w\u00e4hlt der Router den n\u00e4chster-Hop der angegebenen Routen aus. Derjenige mit der h\u00f6heren IP-Adresse setzt sich durch. Wenn dieses Verhalten ge\u00e4ndert werden soll, kann ECMP verwendet werden. Weitere Informationen. hier<\/a><\/noindex>.
\nNach \u00dcberpr\u00fcfung der RPF-Regel sendet der Router das Multicast-Paket an alle seine PIM-Nachbarn, mit Ausnahme desjenigen, von dem das Paket empfangen wurde. Die anderen PIM-Router wiederholen diesen Prozess. Der Weg, den das Multicast-Paket von der Quelle zu den endg\u00fcltigen Empf\u00e4ngern zur\u00fcckgelegt hat, bildet einen Baum, der als quellbasierter Verteilungsbaum, k\u00fcrzester Pfadbaum (SPT) oder Quellbaum bezeichnet wird. Drei verschiedene Namen, w\u00e4hlen Sie einen aus.
\nWie geht man mit der Situation um, dass einige Router einen bestimmten Multicast-Strom nicht akzeptiert haben und ihm niemand senden kann, w\u00e4hrend ihn ein \u00fcbergeordneter Router sendet? Daf\u00fcr wurde der Prune-Mechanismus entwickelt.
\nPrune-Nachricht.<\/b>
\nZum Beispiel wird R2 weiterhin R3 Multicast senden, obwohl R3 gem\u00e4\u00df der RPF-Regel das ignoriert. Warum die Bandbreite belasten? R3 sendet eine PIM Prune-Nachricht, und R2 entfernt bei Erhalt dieser Nachricht die Schnittstelle S0\/1 aus der Liste der ausgehenden Schnittstellen f\u00fcr diesen Datenstrom, der Schnittstellenliste, von denen der Verkehr gesendet werden soll. <\/p>\n

Die folgende Definition einer PIM Prune-Nachricht ist formeller:
\nDie PIM Prune-Nachricht wird von einem Router an einen zweiten Router gesendet, um den zweiten Router zu veranlassen, die Verbindung, \u00fcber die das Prune empfangen wird, von einem bestimmten (S,G) SPT zu entfernen.<\/p><\/blockquote>\n

\nNach Erhalt der Prune-Nachricht setzt R2 den Prune-Timer auf 3 Minuten. Nach drei Minuten wird er wieder mit dem Senden des Verkehrs beginnen, bis er eine weitere Prune-Nachricht erh\u00e4lt. Das gilt f\u00fcr PIMv1.
\nIn PIMv2 wurde ein State Refresh-Timer hinzugef\u00fcgt (standardm\u00e4\u00dfig 60 Sekunden). Sobald eine Prune-Nachricht von R3 gesendet wurde, wird der Timer auf R3 gestartet. Nach Ablauf dieses Timers wird R3 eine State Refresh-Nachricht senden, die den 3-min\u00fctigen Prune-Timer auf R2 f\u00fcr diese Gruppe zur\u00fccksetzt.
\nGr\u00fcnde f\u00fcr das Senden einer Prune-Nachricht:<\/p>\n