{"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 der Funktionsweise des PIM-Protokolls","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Das PIM-Protokoll ist eine Gruppe von Protokollen zur \u00dcbertragung von Multicast im Netzwerk zwischen Routern. Die Nachbarschaftsbeziehungen werden \u00e4hnlich wie bei dynamischen Routing-Protokollen aufgebaut. 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-mal so lange wie der Hello Timer sind, also standardm\u00e4\u00dfig 105 Sekunden.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/AqjQmPR.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/f2e0c7dbdb8d7640671440289fbcd91f.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n PIM verwendet zwei Hauptarbeitsmodi: Dense und Sparse mode. Beginnen wir mit dem Dense mode. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><br \/>\n<b>Source-Based Distribution Trees.<\/b><br \/>\nDer Dense-Mode ist sinnvoll, wenn es viele Clients in verschiedenen Multicast-Gruppen gibt. Wenn ein Router Multicast-Verkehr empf\u00e4ngt, pr\u00fcft er zun\u00e4chst das RPF-Regelwerk. RPF \u2014 diese Regel wird verwendet, um die Quelle des Multicasts mit der Unicast-Routing-Tabelle zu \u00fcberpr\u00fcfen. Der Verkehr muss an dem Interface ankommen, 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.<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/RE54lnP.png\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/4d855ea59c6329c7e727cc70a79367b2.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nR3 erf\u00e4hrt aus der Multicast-Nachricht die Quelle des Multicasts (Source IP) und \u00fcberpr\u00fcft zwei Streams von R1 und R2 anhand seiner Unicast-Tabelle. Der Stream von dem Interface, auf das die Tabelle verweist (R1 zu R3), wird weitergeleitet, w\u00e4hrend der Stream von R2 verworfen wird, da zur Erreichung der Multicast-Quelle Pakete \u00fcber S0\/1 gesendet werden m\u00fcssen.<br \/>\nDie Frage ist, was passiert, wenn Sie zwei \u00e4quivalente Routen mit derselben Metrik haben? In diesem Fall w\u00e4hlt der Router basierend auf dem Next-Hop dieser Routen. Der Router mit der h\u00f6heren IP-Adresse gewinnt. Wenn dieses Verhalten ge\u00e4ndert werden soll, kann ECMP verwendet werden. Mehr erfahren <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1yiam4-OwlDoXrfdfdienMN_nQaOJGi29\/view?usp=sharing\">hier<\/a><\/noindex>.<br \/>\nNachdem die RPF-Regel \u00fcberpr\u00fcft wurde, sendet der Router das Multicast-Paket an alle seine PIM-Nachbarn, mit Ausnahme desjenigen, von dem das Paket empfangen wurde. Die \u00fcbrigen PIM-Router wiederholen diesen Prozess. Der Pfad, den das Multicast-Paket von der Quelle zu den endg\u00fcltigen Empf\u00e4ngern durchlaufen hat, bildet einen Baum, der als source-based distribution tree, shortest-path tree (SPT) oder source tree bezeichnet wird. Drei verschiedene Namen, w\u00e4hlen Sie beliebigen aus.<br \/>\nWie man das Problem l\u00f6st, dass einigen Routern ein bestimmter Multicast-Stream nicht gelungen ist und es niemanden gibt, an den er gesendet werden kann, w\u00e4hrend der \u00fcbergeordnete Router ihn weiterhin sendet. Zu diesem Zweck wurde der Prune-Mechanismus entwickelt. <br \/>\n<b>Prune-Nachricht.<\/b><br \/>\nZum Beispiel wird R2 weiterhin Multicast an R3 senden, obwohl R3 ihn laut der RPF-Regel verwirft. Warum den Kanal belasten? R3 sendet eine PIM Prune-Nachricht, und R2 entfernt, beim Empfang dieser Nachricht, das Interface S0\/1 aus der Liste (Outgoing Interface List) f\u00fcr diesen Stream, also aus der Liste der Interfaces, von denen der Traffic gesendet werden soll. <\/p>\n<blockquote><p>Die folgende Definition einer PIM Prune-Nachricht ist formeller:<br \/>\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, aus einem bestimmten (S,G) SPT zu entfernen.<\/p><\/blockquote>\n<p>\nNach dem Empfang der Prune-Nachricht stellt R2 den Prune-Timer auf 3 Minuten ein. Nach drei Minuten beginnt er wieder, Traffic zu senden, bis er eine weitere Prune-Nachricht erh\u00e4lt. Dies gilt f\u00fcr PIMv1.<br \/>\nIn PIMv2 wurde der State Refresh-Timer hinzugef\u00fcgt (standardm\u00e4\u00dfig 60 Sekunden). Sobald eine Prune-Nachricht von R3 gesendet wurde, wird dieser 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. <br \/>\nGr\u00fcnde f\u00fcr das Versenden einer Prune-Nachricht:<\/p>\n<ul>\n<li> Wenn ein Multicast-Paket die RPF-Pr\u00fcfung nicht bestanden hat.<\/li>\n<li> Wenn keine lokal verbundenen Clients vorhanden sind, die eine Multicast-Gruppe (IGMP Join) angefordert haben, und es keine PIM-Nachbarn gibt, an die Multicast-Verkehr (Non-prune Interface) gesendet werden kann.<\/li>\n<\/ul>\n<p>\n<b>Graft-Nachricht.<\/b><br \/>\nAngenommen, R3 wollte keinen Verkehr von R2 und hat ein Prune gesendet, w\u00e4hrend es Multicast von R1 empfangen hat. Pl\u00f6tzlich fiel die Verbindung zwischen R1 und R3, sodass R3 ohne Multicast blieb. Man k\u00f6nnte 3 Minuten warten, bis der Prune-Timer auf R2 abl\u00e4uft. 3 Minuten sind lang, um nicht warten zu m\u00fcssen, sollte eine Nachricht gesendet werden, die diesen S0\/1-Port auf R2 sofort aus dem pruned Zustand holt. Diese Nachricht w\u00e4re eine Graft-Nachricht. Nach Erhalt der Graft-Nachricht sendet R2 im Gegenzug eine Graft-ACK.<br \/>\n<b>Prune-Override.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zfo0Dx5.png\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/72e368905d2e37ba9b9d46101ebcd8ae.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nWerfen wir einen Blick auf dieses Schema. R1 sendet Multicast in ein Segment mit zwei Routern. R3 empf\u00e4ngt und sendet den Datenverkehr, R2 empf\u00e4ngt, hat aber niemanden, an den er den Verkehr senden kann. Er sendet eine Prune-Nachricht an R1 in dieses Segment. R1 muss Fa0\/0 aus der Liste entfernen und aufh\u00f6ren, in dieses Segment zu senden, aber was passiert mit R3? R3 befindet sich im selben Segment, hat ebenfalls diese Prune-Nachricht erhalten und versteht die Tragik der Situation. Bevor R1 aufh\u00f6rt zu senden, stellt er einen Timer auf 3 Sekunden ein und wird in 3 Sekunden aufh\u00f6ren zu senden. 3 Sekunden \u2013 genau so viel Zeit hat R3, um seinen Multicast nicht zu verlieren. Daher sendet R3 so schnell wie m\u00f6glich eine Pim Join-Nachricht f\u00fcr diese Gruppe, und R1 denkt nicht daran, das Senden einzustellen. Zu den Join-Nachrichten unten.<br \/>\n<b>Assert-Nachricht.<\/b><br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/rliwmNF.png\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/f7cc9c247cd26a8f9567b170f9b61bbb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nStellen Sie sich folgendes Szenario vor: In dasselbe Netzwerk senden zwei Router gleichzeitig. Sie empfangen denselben Datenstrom von einer Quelle und beide \u00fcbertragen diesen \u00fcber das Interface e0 in ein und dasselbe Netzwerk. Daher m\u00fcssen sie bestimmen, welcher von ihnen der einzige Sender f\u00fcr dieses Netzwerk sein wird. Hierf\u00fcr kommen Assert-Nachrichten zum Einsatz. Wenn R2 und R3 eine Duplikation des Multicast-Traffics erkennen, d.h. sowohl R2 als auch R3 empfangen den Multicast, den sie selbst \u00fcbertragen, verstehen die Router, dass etwas nicht stimmt. In diesem Fall senden die Router Assert-Nachrichten, die die Administrative Distance und die Metrik der Route enthalten, \u00fcber die der Multicast-Quell erreicht wird \u2013 10.1.1.10. Der Gewinner wird folgenderma\u00dfen bestimmt:<\/p>\n<ol>\n<li>Derjenige mit der niedrigeren AD.<\/li>\n<li>Wenn die AD gleich sind, dann derjenige mit der niedrigeren Metrik.<\/li>\n<li>Wenn auch hier Gleichstand herrscht, entscheidet derjenige mit der h\u00f6heren IP-Adresse im Netzwerk, in das sie diesen Multicast senden.<\/li>\n<\/ol>\n<p>\nDer Siegertyp in dieser Abstimmung wird der Designated Router. Auch zur Auswahl des DR werden Pim Hello-Nachrichten verwendet. Zu Beginn des Artikels wurde eine PIM Hello-Nachricht gezeigt, in der das DR-Feld zu erkennen ist. Derjenige mit der h\u00f6heren IP-Adresse auf diesem Link gewinnt.<br \/>\nN\u00fctzliche Tabelle:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/Et1kP7h.png\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/d450c9fac2b6d74c5b7414d85910bca4.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\n<b>MROUTE-Tabelle.<\/b><br \/>\nNach der ersten \u00dcberpr\u00fcfung der Funktionsweise des PIM-Protokolls m\u00fcssen wir kl\u00e4ren, wie wir mit der Multicast-Routing-Tabelle umgehen. In der mroute-Tabelle werden Informationen gespeichert, welche Streams von den Clients angefordert wurden und welche Streams von den Multicast-Servern flie\u00dfen. <br \/>\nZum Beispiel wird beim Erhalt eines IGMP Membership Reports oder eines PIM Join auf einem bestimmten Interface ein Eintrag des Typs (*, G) zur Routing-Tabelle hinzugef\u00fcgt:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/ufXsgnR.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/094d96f36512c3b1b8d179044f354ac1.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDieser Eintrag bedeutet, dass eine Anfrage f\u00fcr den Traffic mit der Adresse 238.38.38.38 empfangen wurde. Das DC-Flag zeigt an, dass Multicast im Dense Mode betrieben wird, und das C bedeutet, dass der Empf\u00e4nger direkt mit dem Router verbunden ist, d.h. der Router hat den IGMP Membership Report und das PIM Join erhalten.<br \/>\nWenn es einen Eintrag des Typs (S,G) gibt, bedeutet das, dass wir einen Multicast-Stream haben:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/QJCZZwf.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/56f2e8376a7f89f3fd3082a098ce42e5.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nIm Feld S \u2014 192.168.1.11 geben wir die IP-Adresse des Multicast-Quells an, die Regel RPF wird an dieser Adresse \u00fcberpr\u00fcft. Bei Problemen sollten Sie zuerst die Unicast-Tabelle auf eine Route zur Quelle \u00fcberpr\u00fcfen. Im Feld Incoming Interface geben Sie das Interface an, \u00fcber das der Multicast empfangen wird. In der Unicast-Routing-Tabelle sollte die Route zur Quelle auf das hier angegebene Interface verweisen. Im Feld Outgoing Interface wird angegeben, wohin der Multicast weitergeleitet wird. Wenn es leer ist, bedeutet dies, dass keine Anfragen f\u00fcr diesen Datenverkehr an den Router gesendet wurden. Weitere Informationen zu allen Flags finden Sie. <noindex><a rel=\"nofollow\" href=\"https:\/\/drive.google.com\/file\/d\/1ArBLFJdyN8tCangB5GL2JaS47FEZaad-\/view?usp=sharing\">hier<\/a><\/noindex>.<br \/>\n<b>PIM Sparse-mode.<\/b><br \/>\nDie Sparse-mode-Strategie ist das Gegenteil des Dense-mode. Wenn der Sparse-mode Multicast-Datenverkehr empf\u00e4ngt, wird der Datenverkehr nur \u00fcber die Interfaces gesendet, an denen Anfragen f\u00fcr diesen Datenstrom vorhanden sind, z. B. Pim Join oder IGMP Report-Nachrichten mit Anfragen f\u00fcr diesen Datenverkehr.<br \/>\n\u00c4hnliche Elemente in SM und DM:<\/p>\n<ul>\n<li> Nachbarschaftsbeziehungen werden genauso aufgebaut wie im PIM DM.<\/li>\n<li> Die RPF-Regel funktioniert.<\/li>\n<li> Die Auswahl des DR ist \u00e4hnlich.<\/li>\n<li> Der Mechanismus Prune Overrides und die Assert-Nachrichten sind \u00e4hnlich.<\/li>\n<\/ul>\n<p>\nUm zu kontrollieren, wer, wo und welchen Multicast-Verkehr im Netzwerk ben\u00f6tigt, ist ein zentrales Informationszentrum erforderlich. Dieses Zentrum wird unser Rendezvous Point (RP) sein. Alle, die einen Multicast-Verkehr anfordern oder von einer Quelle empfangen wollen, senden diesen an das RP.<br \/>\nSobald das RP den Multicast-Verkehr erh\u00e4lt, leitet es diesen an die Router weiter, die zuvor nach diesem Verkehr gefragt haben. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/5AErtbS.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/35646434f8b80a8a05253111864de2da.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nStellen wir uns eine Topologie vor, in der RP R3 ist. Sobald R1 Verkehr von S1 empf\u00e4ngt, kapselt es dieses Multicast-Paket in eine Unicast-PIM-Register-Nachricht ein und sendet es an das RP. Wie wei\u00df es, wo das RP ist? In diesem Fall ist es statisch konfiguriert, und wir werden sp\u00e4ter \u00fcber die dynamische Konfiguration des RP sprechen. <\/p>\n<blockquote><p>ip pim rp-address 3.3.3.3<\/p><\/blockquote>\n<p>\nRP wird pr\u00fcfen \u2013 gab es Informationen von jemandem, der diesen Traffic erhalten m\u00f6chte? Nehmen wir an, das gab es nicht. Dann wird RP R1 eine Nachricht PIM Register-Stop senden, was bedeutet \u2013 niemand ben\u00f6tigt diesen Multicast, die Registrierung ist abgelehnt. R1 wird den Multicast nicht senden. Aber die Host-Quelle des Multicast wird ihn weiter senden, sodass R1 nach Erhalt von Register-Stop einen Register-Suppression-Timer von 60 Sekunden startet. F\u00fcnf Sekunden vor Ablauf dieses Timers wird R1 eine leere Register-Nachricht mit dem Null-Register-Bit (also ohne inkapsuliertes Multicast-Paket) in Richtung RP senden. RP wird in der Folge so agieren:<\/p>\n<ul>\n<li> Wenn es keine Empf\u00e4nger gegeben hat und immer noch keine gibt, wird er mit einer Register-Stop-Nachricht antworten.<\/li>\n<li> Wenn Empf\u00e4nger erschienen sind, wird er nicht darauf reagieren. R1, der innerhalb von f\u00fcnf Sekunden keine Ablehnung seiner Registrierung erh\u00e4lt, wird sich freuen und eine Register-Nachricht mit inkapsuliertem Multicast an RP senden.<\/li>\n<\/ul>\n<p>\nNachdem wir verstanden haben, wie der Multicast zum RP gelangt, wollen wir nun die Frage beantworten, wie das RP den Verkehr zu den Empf\u00e4ngern bringt. Hierbei ist es wichtig, ein neues Konzept einzuf\u00fchren \u2013 den Root-Path-Baum (RPT). Der RPT ist ein Baum, der seinen Ursprung im RP hat und sich in Richtung der Empf\u00e4nger erstreckt, wobei er an jedem PIM-SM-Router verzweigt. Das RP erstellt diesen Baum, indem es PIM Join-Nachrichten empf\u00e4ngt und einen neuen Zweig hinzuf\u00fcgt. Dies geschieht dann auch bei jedem nachgeschalteten Router. Die allgemeine Regel lautet wie folgt:<\/p>\n<ul>\n<li> Wenn ein PIM-SM-Router eine PIM Join-Nachricht an einem beliebigen Interface empf\u00e4ngt, mit Ausnahme des Interfaces, das das RP verbirgt, f\u00fcgt er dem Baum einen neuen Zweig hinzu.<\/li>\n<li> Ein Zweig wird auch hinzugef\u00fcgt, wenn der PIM-SM-Router einen IGMP Membership Report von einem direkt angeschlossenen Host erh\u00e4lt. <\/li>\n<\/ul>\n<p>\nStellen wir uns vor, wir haben einen Multicast-Kunden am Router R5 f\u00fcr die Gruppe 228.8.8.8. Sobald R5 den IGMP Membership Report vom Host erh\u00e4lt, sendet R5 einen PIM Join in Richtung RP und f\u00fcgt den Interface, der zum Host zeigt, zum Baum hinzu. Danach erh\u00e4lt R4 den PIM Join von R5, f\u00fcgt den Interface Gi0\/1 zum Baum hinzu und sendet den PIM Join in Richtung RP. Schlie\u00dflich erh\u00e4lt RP (R3) den PIM Join und f\u00fcgt Gi0\/0 zum Baum hinzu. Damit wird der Multicast-Empf\u00e4nger registriert. Es entsteht ein Baum mit R3-Gi0\/0 \u2192 R4-Gi0\/1 \u2192 R5-Gi0\/0.<br \/>\nDaraufhin wird ein PIM Join an R1 gesendet, und R1 beginnt, Multicast-Traffic zu senden. Es ist wichtig zu beachten, dass, wenn der Host den Traffic angefordert hat, bevor das Multicast-Streaming begann, RP keinen PIM Join senden und generell nichts an R1 senden wird.<br \/>\nWenn der Host w\u00e4hrend des Multicast-Streamings pl\u00f6tzlich aufh\u00f6rt, ihn empfangen zu wollen, wird RP, sobald es einen PIM Prune auf dem Interface Gi0\/0 erh\u00e4lt, sofort einen PIM Register-Stop direkt an R1 senden und anschlie\u00dfend die PIM Prune-Nachricht \u00fcber das Interface Gi0\/1. PIM Register-Stop wird unicast an die Adresse gesendet, von der das PIM Register empfangen wurde.<br \/>\nWie bereits erw\u00e4hnt, sobald der Router PIM Join an einen anderen Router, wie zum Beispiel R5 an R4, sendet, wird auf R4 ein Eintrag hinzugef\u00fcgt:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/msZjbr8.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/d1d621bee37e4b912a672690c581617a.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nEin Timer wird gestartet, und R5 muss st\u00e4ndig PIM Join-Nachrichten senden, da sonst R4 R5 aus der Ausgabeliste ausschlie\u00dft. R5 wird alle 60 Sekunden PIM Join-Nachrichten senden.<br \/>\n<b>Wechsel des k\u00fcrzesten Pfades.<\/b><br \/>\nWir f\u00fcgen eine Schnittstelle zwischen R1 und R5 hinzu und beobachten, wie der Datenverkehr bei dieser Topologie flie\u00dft. <br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/wLKEyyg.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/4b15057a1d30f3b2d6246b8f3b6263eb.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nAngenommen, der Datenverkehr wurde gem\u00e4\u00df dem alten Schema R1-R2-R3-R4-R5 gesendet und erhalten, und jetzt haben wir die Schnittstelle zwischen R1 und R5 angeschlossen und konfiguriert.<br \/>\nZuerst m\u00fcssen wir die Unicast-Routing-Tabelle auf R5 umstellen, sodass das Netzwerk 192.168.1.0\/24 nun \u00fcber das Interface R5 Gi0\/2 erreichbar ist. Da R5 Multicast \u00fcber das Interface Gi0\/1 erh\u00e4lt, erkennt er, dass die RPF-Regel nicht erf\u00fcllt ist, und es sinnvoller w\u00e4re, Multicast \u00fcber Gi0\/2 zu empfangen. Er sollte sich von der RPT abmelden und einen k\u00fcrzeren Baum aufbauen, der als Shortest-Path Tree (SPT) bekannt ist. Dazu sendet er \u00fcber Gi0\/2 eine PIM Join-Nachricht an R1, und R1 beginnt, Multicast auch \u00fcber Gi0\/2 zu senden. Jetzt muss sich R5 von der RPT abmelden, um keine doppelten Kopien zu erhalten. Daf\u00fcr sendet er eine Prune-Nachricht, die die IP-Adresse des Quellger\u00e4ts angibt und ein spezielles Bit - RPT-Bit - einf\u00fcgt. Das bedeutet, dass ich keinen Traffic mehr empfangen m\u00f6chte, da ich hier einen besseren Baum habe. Der RP sendet ebenfalls PIM Prune-Nachrichten in Richtung R1, allerdings kein Register-Stop-Nachricht. Eine weitere Besonderheit: R5 wird nun st\u00e4ndig PIM Prune an den RP senden, da R1 weiterhin jede Minute PIM Register an den RP sendet. Solange es keine neuen Interessenten f\u00fcr diesen Traffic gibt, wird der RP ihm eine Ablehnung schicken. R5 informiert den RP, dass er weiterhin Multicast \u00fcber SPT empf\u00e4ngt.<br \/>\n<b>Dynamische Suche nach RP. <br \/>\nAuto-RP.<\/b><br \/>\nDiese Technologie ist propriet\u00e4r von Cisco und erfreut sich nicht allzu gro\u00dfer Beliebtheit, ist jedoch nach wie vor pr\u00e4sent. Die Funktionsweise von Auto-RP besteht aus zwei Hauptphasen:<br \/>\n1) Der RP sendet RP-Announce-Nachrichten an die reservierte Adresse \u2014 224.0.1.39 und erkl\u00e4rt sich entweder f\u00fcr alle oder f\u00fcr bestimmte Gruppen als RP. Diese Nachricht wird jede Minute gesendet.<br \/>\n2) Es wird ein RP-Mapping-Agent ben\u00f6tigt, der RP-Discovery-Nachrichten sendet, in denen angegeben wird, f\u00fcr welche Gruppen welcher RP geh\u00f6rt. Anhand dieser Nachricht werden normale PIM-Router ihren RP bestimmen. Der Mapping-Agent kann sowohl der RP-Router selbst als auch ein separater PIM-Router sein. RP-Discovery wird an die Adresse 224.0.1.40 mit einem Timer von einer Minute gesendet.<br \/>\nLassen Sie uns den Prozess genauer betrachten:<br \/>\nKonfigurieren wir R3 als RP:<\/p>\n<blockquote><p>ip pim send-rp-announce loopback 0 scope 10<\/p><\/blockquote>\n<p>\nR2 als Mapping-Agent:<\/p>\n<blockquote><p>ip pim send-rp-discovery loopback 0 scope 10<\/p><\/blockquote>\n<p>\nUnd auf allen anderen Routern warten wir auf RP \u00fcber Auto-RP:<\/p>\n<blockquote><p>ip pim autorp listener<\/p><\/blockquote>\n<p>\nSobald wir R3 konfiguriert haben, wird er beginnen, RP-Announce-Nachrichten zu senden:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/6c4WucN.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/3077778bb47731bb02a8e7fc6945aa63.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nUnd R2 wird nach der Konfiguration als Mapping-Agent beginnen, auf RP-Announce-Nachrichten zu warten. Erst wenn er mindestens einen RP findet, beginnt er, RP-Discovery zu senden:<br \/>\n <noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/lw2JuDD.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/37eff65f3c359cd3091c47af22220a6b.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSobald herk\u00f6mmliche Router (PIM RP Listener) diese Nachricht erhalten, wissen sie, wo sie den RP suchen m\u00fcssen.<br \/>\nEin zentrales Problem von Auto-RP ist, dass zur Empf\u00e4ngnis der RP-Announce- und RP-Discovery-Nachrichten PIM Join auf die Adressen 224.0.1.39-40 gesendet werden muss, aber daf\u00fcr muss bekannt sein, wo sich der RP befindet. Es handelt sich um ein klassisches Huhn-und-Ei-Problem. Um dieses Problem zu l\u00f6sen, wurde der PIM Sparse-Dense-Mode entwickelt. Wenn der Router den RP nicht kennt, arbeitet er im Dense-Mode, wenn er ihn kennt, im Sparse-Mode. Wenn auf den Schnittstellen der herk\u00f6mmlichen Router PIM Sparse-Mode und der Befehl ip pim autorp listener eingestellt sind, arbeitet der Router nur f\u00fcr das Multicast-Auto-RP-Protokoll (224.0.1.39-40) im Dense-Mode.<br \/>\n<b>BootStrap Router (BSR).<\/b><br \/>\nDiese Funktion \u00e4hnelt Auto-RP. Jeder RP sendet eine Nachricht an den Mapping-Agent, der die Mapping-Informationen sammelt und dann allen anderen Routern mitteilt. Lassen Sie uns den Prozess analog zu Auto-RP beschreiben:<br \/>\n1) Sobald wir R3 als Kandidaten f\u00fcr den RP konfigurieren, mit dem Befehl:<\/p>\n<blockquote><p>ip pim rp-candidate loopback 0<\/p><\/blockquote>\n<p>\nDer R3 wird nichts tun, um spezielle Nachrichten zu senden. Zun\u00e4chst muss er einen Mapping-Agent finden. Somit gehen wir zum zweiten Schritt \u00fcber.<br \/>\n2) Richten Sie R2 als Mapping-Agent ein:<\/p>\n<blockquote><p>ip pim bsr-candidate loopback 0<\/p><\/blockquote>\n<p>\nR2 beginnt, PIM Bootstrap-Nachrichten zu versenden, in denen er sich als Mapping-Agent angibt:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/uAj49oT.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/2b05ffd64bd33ee5380aa24d5f76df67.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDiese Nachricht wird an die Adresse 224.0.0.13 gesendet, die das PIM-Protokoll auch f\u00fcr andere Nachrichten verwendet. Diese werden in alle Richtungen gesendet, sodass das Problem von Huhn und Ei, wie bei Auto-RP, nicht besteht.<br \/>\n3) Sobald der RP eine Nachricht vom BSR-Router erh\u00e4lt, sendet er sofort eine Unicast-Nachricht an die Adresse des BSR-Routers:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/qwtXY88.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/38547a114a2bca74131c95b95e535fdc.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDaraufhin sendet der BSR, nachdem er die Informationen \u00fcber den RP erhalten hat, diese per Multicast an die Adresse 224.0.0.13, die von allen PIM-Routern abgeh\u00f6rt wird. Daher gibt es keinen direkten Befehl von <i>ip pim autorp listener<\/i> f\u00fcr herk\u00f6mmliche Router im BSR.<br \/>\n<b>Anycast RP mit Multicast Source Discovery Protocol (MSDP).<\/b><br \/>\nAuto-RP und BSR erm\u00f6glichen es uns, die Last auf RP wie folgt zu verteilen: Jede Multicast-Gruppe hat nur einen aktiven RP. Eine Lastverteilung auf mehrere RPs f\u00fcr eine einzige Multicast-Gruppe ist nicht m\u00f6glich. MSDP erreicht dies, indem es den RPs die gleiche IP-Adresse mit der Maske 255.255.255.255 zuweist. MSDP erfasst Informationen durch einen der Methoden: Statische Konfiguration, Auto-RP oder BSR.<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/U4aDz5H.png\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/c0352b5fbc5780f667c6c97ea6dde26d.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nDas Bild zeigt unsere Auto-RP-Konfiguration mit MSDP. Beide RPs sind mit der IP-Adresse 172.16.1.1\/32 am Loopback-Interface 1 konfiguriert und werden f\u00fcr alle Gruppen verwendet. Bei RP-Announce informieren beide Router \u00fcber sich selbst und verweisen auf diese Adresse. Der Auto-RP-Mapping-Agent, der diese Informationen erh\u00e4lt, verteilt die RP-Discovery \u00fcber den RP mit der Adresse 172.16.1.1\/32. Den Routern vermitteln wir Informationen \u00fcber das Netzwerk 172.16.1.1\/32 mithilfe von IGP. Somit fordern PIM-Router Streams vom RP an, der als n\u00e4chster Hop f\u00fcr die Route zum Netzwerk 172.16.1.1\/32 angegeben ist. Das Protokoll MSDP selbst ist daf\u00fcr gedacht, dass sich die RPs untereinander austauschen und Informationen \u00fcber Multicast-Streams kommunizieren.<br \/>\nBetrachten wir eine solche Topologie:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/i.imgur.com\/zgkGDOP.jpg\"><img decoding=\"async\" alt=\"Die Prinzipien der Funktionsweise des PIM-Protokolls\" src=\"\/wp-content\/uploads\/2019\/05\/e4823362e7a2abc9b4ee9ba954d709b8.jpg\" style=\"display:block;margin: 0 auto;\" \/><\/a><\/noindex><br \/>\nSwitch6 sendet den Verkehr an die Adresse 238.38.38.38, und nur RP-R1 ist dar\u00fcber informiert. Switch7 und Switch8 haben diese Gruppe angefordert. Die Router R5 und R4 werden PIM Join an R1 und R3 senden, entsprechend. Warum? Die Route zu 13.13.13.13 wird f\u00fcr R5 auf R1 mit dem IGP-Metrik verweisen, genauso wie f\u00fcr R4.<br \/>\nRP-R1 ist \u00fcber den Datenstrom informiert und wird ihn in Richtung R5 weiterleiten, w\u00e4hrend R4 nichts dar\u00fcber wei\u00df, da R1 ihn nicht einfach so senden wird. Daher ist MSDP erforderlich. Wir konfigurieren es auf R1 und R5:<\/p>\n<blockquote><p>ip msdp peer 3.3.3.3 connect-source Loopback1 auf R1<\/p><\/blockquote>\n<p><\/p>\n<blockquote><p>ip msdp peer 1.1.1.1 connect-source Loopback3 auf R3<\/p><\/blockquote>\n<p>\nSie werden eine Sitzung zwischen einander aufbauen und bei Erhalt eines Datenstroms diesem ihrem benachbarten RP mitteilen.<br \/>\nSobald RP-R1 den Datenstrom von Switch6 empf\u00e4ngt, wird er sofort eine unicast MSDP Source-Active Nachricht senden, die Informationen in der Art von (S, G) \u2014 Informationen \u00fcber Quelle und Ziel des Multicast enth\u00e4lt. Jetzt, wo RP-R3 wei\u00df, dass es eine Quelle wie Switch6 gibt, wird er bei Erhalt der Anfrage von R4 zu diesem Datenstrom PIM Join in Richtung Switch6 senden, basierend auf der Routing-Tabelle. Folglich wird R1, nachdem er einen solchen PIM Join erh\u00e4lt, beginnen, den Verkehr in Richtung RP-R3 zu senden.<br \/>\nMSDP arbeitet \u00fcber TCP, RP senden sich gegenseitig Keepalive-Nachrichten zur \u00dcberpr\u00fcfung der Lebensf\u00e4higkeit. Der Timer betr\u00e4gt 60 Sekunden.<br \/>\nDie Funktion der Trennung von MSDP-Peers in verschiedene Dom\u00e4nen bleibt unklar, da in den Keepalive- und SA-Nachrichten keine Zuordnung zu einer bestimmten Dom\u00e4ne angegeben wird. In dieser Topologie wurde auch eine Konfiguration mit verschiedenen Dom\u00e4nen getestet \u2013 dabei gab es keine Unterschiede im Betrieb. <br \/>\nWenn jemand Klarheit schaffen kann, freue ich mich \u00fcber Kommentare.<br \/>\n<br \/>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/450582\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438. PIMv2 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u0442 \u043a\u0430\u0436\u0434\u044b\u0435 30 \u0441\u0435\u043a\u0443\u043d\u0434 Hello \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043d\u0430 \u0437\u0430\u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442 \u0430\u0434\u0440\u0435\u0441 224.0.0.13 ( All-PIM-Routers ). \u0421\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u0432 \u0441\u0435\u0431\u0435 Hold Timers \u2014 \u043e\u0431\u044b\u0447\u043d\u043e \u0440\u0430\u0432\u0435\u043d 3.5*Hello Timer, \u0442\u043e \u0435\u0441\u0442\u044c 105 \u0441\u0435\u043a\u0443\u043d\u0434 \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-33142","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438. PIMv2 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u0442 \u043a\u0430\u0436\u0434\u044b\u0435 30 \u0441\u0435\u043a\u0443\u043d\u0434 Hello \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043d\u0430 \u0437\u0430\u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442 \u0430\u0434\u0440\u0435\u0441 224.0.0.13 ( All-PIM-Routers ). \u0421\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u0432 \u0441\u0435\u0431\u0435 Hold Timers \u2014 \u043e\u0431\u044b\u0447\u043d\u043e \u0440\u0430\u0432\u0435\u043d 3.5*Hello Timer, \u0442\u043e \u0435\u0441\u0442\u044c 105 \u0441\u0435\u043a\u0443\u043d\u0434 \u043f\u043e\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 PIM | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438. PIMv2 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u0442 \u043a\u0430\u0436\u0434\u044b\u0435 30 \u0441\u0435\u043a\u0443\u043d\u0434 Hello \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043d\u0430 \u0437\u0430\u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442 \u0430\u0434\u0440\u0435\u0441 224.0.0.13 ( All-PIM-Routers ). \u0421\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u0432 \u0441\u0435\u0431\u0435 Hold Timers \u2014 \u043e\u0431\u044b\u0447\u043d\u043e \u0440\u0430\u0432\u0435\u043d 3.5*Hello Timer, \u0442\u043e \u0435\u0441\u0442\u044c 105 \u0441\u0435\u043a\u0443\u043d\u0434 \u043f\u043e\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/printsipy-raboty-protokola-pim\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:50:58+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:50:58+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Funktionsprinzipien des PIM-Protokolls | ProHoster","description":"Das PIM-Protokoll ist eine Sammlung von Protokollen zur \u00dcbertragung von Multicast in Netzwerken zwischen Routern. Die Nachbarschaftsbeziehungen werden \u00e4hnlich wie bei dynamischen Routingprotokollen hergestellt. 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 \u2013 normalerweise betr\u00e4gt dieser 3,5 * Hello Timer, also 105 Sekunden.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041f\u0440\u0438\u043d\u0446\u0438\u043f\u044b \u0440\u0430\u0431\u043e\u0442\u044b \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u0430 PIM | ProHoster","og:description":"\u041f\u0440\u043e\u0442\u043e\u043a\u043e\u043b PIM \u2014 \u044d\u0442\u043e \u043d\u0430\u0431\u043e\u0440 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u0434\u043b\u044f \u043f\u0435\u0440\u0435\u0434\u0430\u0447\u0438 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442\u0430 \u0432 \u0441\u0435\u0442\u0438 \u043c\u0435\u0436\u0434\u0443 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u043c\u0438. \u041e\u0442\u043d\u043e\u0448\u0435\u043d\u0438\u044f \u0441\u043e\u0441\u0435\u0434\u0441\u0442\u0432\u0430 \u0441\u0442\u0440\u043e\u0438\u0442\u0441\u044f \u0430\u043d\u0430\u043b\u043e\u0433\u0438\u0447\u043d\u043e \u043a\u0430\u043a \u0438 \u0432 \u0441\u043b\u0443\u0447\u0430\u0435 \u0434\u0438\u043d\u0430\u043c\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043f\u0440\u043e\u0442\u043e\u043a\u043e\u043b\u043e\u0432 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0446\u0438\u0438. PIMv2 \u043e\u0442\u043f\u0440\u0430\u0432\u043b\u044f\u0435\u0442 \u043a\u0430\u0436\u0434\u044b\u0435 30 \u0441\u0435\u043a\u0443\u043d\u0434 Hello \u0441\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u044f \u043d\u0430 \u0437\u0430\u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u043c\u0443\u043b\u044c\u0442\u0438\u043a\u0430\u0441\u0442 \u0430\u0434\u0440\u0435\u0441 224.0.0.13 ( All-PIM-Routers ). \u0421\u043e\u043e\u0431\u0449\u0435\u043d\u0438\u0435 \u0441\u043e\u0434\u0435\u0440\u0436\u0438\u0442 \u0432 \u0441\u0435\u0431\u0435 Hold Timers \u2014 \u043e\u0431\u044b\u0447\u043d\u043e \u0440\u0430\u0432\u0435\u043d 3.5*Hello Timer, \u0442\u043e \u0435\u0441\u0442\u044c 105 \u0441\u0435\u043a\u0443\u043d\u0434 \u043f\u043e","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/printsipy-raboty-protokola-pim","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:50:58+00:00","article:modified_time":"2019-10-31T18:50:58+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"33142","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 14:06:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:46:23","updated":"2026-01-21 14:06:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/33142","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=33142"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/33142\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/24886"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=33142"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=33142"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=33142"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}