PIM Dense Mode

Einführung

Dieser Artikel setzt die Serie über IP-Multicast fort. Wir werfen einen Blick darauf, wie IP-Multicast grundsätzlich funktioniert. Anschließend werden wir uns ansehen, wie PIM Dense Mode (PIM-DM) funktioniert, wie man es konfiguriert und wie man Fehler behebt. Dies soll uns aufwärmen, bevor wir uns in einem späteren Artikel mit dem etwas komplexeren und besser skalierbaren PIM Sparse Mode beschäftigen.

Der ursprüngliche Multicast-Artikel enthält am Ende Links zu den wichtigsten IETF-Arbeitsgruppen. Er ist zu finden unter The Protocols of IP Multicast.

Understanding IP Multicast Forwarding

Der Zweck eines Multicast-Routing-Protokolls ist es, Routern zu ermöglichen, zusammenzuarbeiten, um Kopien von Multicast-Paketen effizient an interessierte Empfänger zu liefern. Dabei stellt das Multicast-Routing-Protokoll wahrscheinlich auch einen Mechanismus zur Verfügung, mit dem benachbarte Router, die ebenfalls das Multicast-Routing-Protokoll verwenden, entdeckt und verfolgt werden können.

Wie wir im letzten Artikel gesehen haben, verwenden die Computer, die am Empfang eines Multicast-Paketstroms interessiert sind, IGMP, um benachbarte Router zu benachrichtigen. Die Router sorgen dann mit Hilfe des Multicast-Protokolls dafür, dass ihnen eine Kopie des Multicast-Paketstroms geschickt wird, damit sie ihn an das LAN weiterleiten können, in dem sich der Empfänger befindet. Wir haben nicht erwähnt, was am Quellende des Paketstroms geschieht. Beim IP-Multicast gibt es kein Protokoll, mit dem die Quelle kommunizieren oder sich registrieren oder die Router benachrichtigen muss. Die Quelle beginnt einfach, IP-Multicast-Pakete zu senden, und es liegt an den benachbarten Routern, das Richtige zu tun. (Was das „Richtige“ ist, hängt vom Multicast-Routing-Protokoll ab).

Das folgende Bild zeigt eine Quelle, die ein Multicast-Paket in Rot sendet, und nachgelagerte Router, die das Paket duplizieren und es an andere Router und schließlich an alle LAN-Segmente weiterleiten. Wie wir gleich sehen werden, ist dies das anfängliche (und regelmäßige) Verhalten von Ciscos Protocol Independent Multicast (PIM) Multicast-Routing-Protokoll, wenn es im Dense Mode arbeitet.

Beachten Sie in der obigen Abbildung, dass die blauen Pfeile die Kopien der Multicast-Pakete auf organisierte Weise weiterleiten. Bei einigen Routern oder LAN-Segmenten können zwei Kopien eines Pakets ankommen. Aber die Router leiten die Pakete nicht „rückwärts“ weiter. Das ist auch gut so: Stellen Sie sich vor, was passieren würde, wenn Router E eine Kopie des Pakets, das er von C erhalten hat, an Router B weiterleiten würde. Würde B das Paket dann an A weiterleiten, der es wiederum an C weiterleiten würde, und so weiter, in einer Weiterleitungsschleife? Dies wäre eine Art Layer-3-Äquivalent zu dem, was auf Layer 2 passiert, wenn der Spanning Tree in einer Schleifentopologie deaktiviert ist: eine gute Möglichkeit, viel Bandbreite und Routerkapazität zu verschwenden.

Um Multicast-Weiterleitungsschleifen zu verhindern, führt IP-Multicast immer eine RPF-Prüfung durch, auf die wir gleich noch eingehen werden.

Zusätzlich zur RPF-Prüfung können Multicast-Routing-Protokolle wie PIM auch dazu dienen, Ineffizienz zu verhindern. Beispielsweise muss Router E in der Abbildung nicht zwei Kopien jedes Multicast-Pakets empfangen (eine von B, eine von C).

Das Multicast-Routing-Protokoll legt fest, welche Schnittstellen Kopien aussenden (oder nicht aussenden) sollen. Wie die obige Abbildung zeigt, erfolgt die Multicast-Weiterleitung entlang logischer Bäume, also verzweigter Pfade durch das Netz. Alle Informationen über die Multicast-Weiterleitung werden in der Multicast-Statustabelle gespeichert, die von manchen auch als Multicast-Routing-Tabelle bezeichnet wird. Diese Informationen können mit dem sehr nützlichen Befehl show ip mroute angezeigt werden. Werfen wir einen kurzen Blick auf die Beispielausgabe des Befehls show ip mroute (bei laufendem PIM Dense Mode).

Router# show ip mroute 233.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned R - RP-bit set, F - Register flag, T - SPT-bit setTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 233.1.1.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC Incoming interface: Null, RPF neighbor 0.0.0.0 Outgoing interface list: Ethernet0, Forward/Dense, 0:57:31/0:02:52 FastEthernet1, Forward/Dense, 0:56:55/0:01:28 FastEthernet2, Forward/Dense, 0:56:45/0:01:22(172.16.16.1/32, 233.1.1.1), uptime 20:20:00, expires 0:02:55, flags: C Incoming interface: FastEthernet1, RPF neighbor 10.20.30.1 Outgoing interface list: Ethernet0, Forward/Dense, 20:20:00/0:02:52

Zum Verständnis ist zu beachten, dass Adressen, die mit 224-239 beginnen, IP-Multicast-Adressen oder Gruppen sind. (Die Gruppe bezieht sich auf die Gruppe von Empfängern für diese Multicast-Zieladresse).

Der Eintrag, der mit (*, 233.1.1.1) beginnt, ist ein gemeinsamer Multicast-Baumeintrag, der manchmal auch als (*, G) Eintrag bezeichnet wird. (G ist hier nur 223.1.1.1). PIM-DM verwendet diese nicht für die Weiterleitung von Paketen, listet aber Schnittstellen mit einer Rolle im Multicast (bekannter IGMP-Empfänger oder PIM-Nachbar) als ausgehende Schnittstellen unter solchen Einträgen auf.

Der Eintrag, der mit (172.16.16.1, 233.1.1.1) beginnt, wird als (S, G) Eintrag bezeichnet. S steht für die Quelle, G für die Gruppe. Wenn Sie es vorziehen, können Sie sich dies als Quelle und Ziel im IP-Header vorstellen (da sie dort tatsächlich in den Paketen erscheinen). Dieser Eintrag ist ein quellenspezifischer Multicast-Baum für eine bestimmte Multicast-Gruppe. Im Allgemeinen gibt es einen solchen Eintrag für jede Quelle und Gruppe. Beachten Sie, dass der nächste Hop des Unicast-Routings als RPF-Nachbar angezeigt wird und die eingehende Schnittstelle die RPF-Schnittstelle ist, die vom Unicast-Routing zur Quelle 172.16.16.1 verwendet wird. Die Liste der ausgehenden Schnittstellen zeigt, dass jedes Paket von 172.16.16.1 mit dem Ziel 233.1.1.1, das auf FastEthernet1 empfangen wird, auf Ethernet0 kopiert wird.

Sie können den Multicast-Weiterleitungsbaum für ein bestimmtes (S, G) zu Zwecken der Fehlerbehebung zeichnen. Führen Sie dazu auf jedem Router den Befehl show ip mroute aus. Nehmen Sie eine Kopie Ihres Netzwerkplans und zeichnen Sie einen ausgehenden Pfeil für jede Schnittstelle in der Liste der ausgehenden Schnittstellen („OIL“ oder „OILIST“). Am Ende erhalten Sie ein Diagramm ähnlich dem obigen Bild.

Zustandsflags, die Sie in der PIM-DM show ip mroute Ausgabe sehen können:

• D = Dense Mode. Erscheint nur bei (*, G) Einträgen. Die Gruppe arbeitet im Dense-Modus.
• C = Directly Connected Host (IGMP!)
• L = Local (Router ist als Mitglied der Multicast-Gruppe konfiguriert).
• P = Pruned (Alle OILIST-Schnittstellen sind auf Prune eingestellt). Der Router sendet in der Regel Prune an seinen RPF-Nachbarn, wenn dies der Fall ist.
• T = Forwarding via Shortest Path Tree (SPT), zeigt an, dass mindestens ein Paket empfangen / weitergeleitet wurde.
• J = Join SPT. Immer an im (*,G) Eintrag in PIM-DM, bedeutet nicht viel.

Was ist die RPF-Prüfung und warum?

IP-Multicast-Weiterleitung führt immer eine RPF-Prüfung durch. RPF steht für Reverse Path Forwarding. Das Ziel der RPF-Prüfung ist es, auf einfache Weise eine Weiterleitungsschleife für Multicast-Pakete zu verhindern. Für jeden Multicast-Stream prüft der Multicast-Router die Quelladresse, also welches Gerät den Multicast gesendet hat. Dann sucht er den Absender in der Unicast-Routing-Tabelle und bestimmt die Schnittstelle, über die er Unicast-Pakete an die Multicast-Quelle senden würde. Diese Schnittstelle ist die RPF-Schnittstelle, diejenige, auf der der Router den Empfang von Multicasts „erwartet“. Man kann es sich als die „offiziell zugelassene“ Schnittstelle für den Empfang von Multicasts von dieser bestimmten Quelle vorstellen. Der Router speichert die RPF-Schnittstelle als Teil der Multicast-Statusinformationen für diese bestimmte Quelle und dieses bestimmte Multicast-Ziel (Gruppe).

Wenn ein Multicast-Paket vom Router empfangen wird, verfolgt der Router, über welche Schnittstelle das Paket eingegangen ist. Wenn das Paket das erste Paket von einer neuen Quelle ist, wird das RPF-Interface bestimmt und in der mroute-Tabelle gespeichert, wie gerade besprochen. Andernfalls sucht der Router nach der Quelle und der Multicast-Gruppe in der mroute-Tabelle. Wenn das Paket auf der RPF-Schnittstelle empfangen wurde, wird das Paket kopiert und an jede in der mroute-Tabelle aufgeführte ausgehende Schnittstelle weitergeleitet. Wurde das Paket auf einer Nicht-RPF-Schnittstelle empfangen, wird es verworfen. Wäre der Router eine Person, wäre dies das Äquivalent zu „Warum schickt mir diese Person das? Sie muss verwirrt sein, ich werde ignorieren, was sie mir gerade geschickt hat.“

Der Router sendet auch keine Kopie eines Pakets über die Schnittstelle zurück, über die es eingegangen ist (die RPF-Schnittstelle). Mit anderen Worten: Selbst wenn der benachbarte Router an der RPF-Schnittstelle Kopien eines Multicast-Streams anfordert, wird der Router die RPF-Schnittstelle nicht in die Liste der ausgehenden Schnittstellen aufnehmen, die Kopien des Multicast-Streams erhalten. Dies schützt vor jeder Art von Protokollfehler, der zwei Nachbarn in eine enge Multicast-Weiterleitungsschleife bringt.

Router E ignoriert wahrscheinlich auch einen der beiden Paketströme, je nachdem, ob B oder C mit der RPF-Schnittstelle verbunden ist. Selbst bei Routen mit gleichen Kosten wird normalerweise nur eine Schnittstelle als RPF-Schnittstelle gewählt. Wenn Sie also zwei Links haben, die zwei Router verbinden, wird typischerweise nur einer für Multicast von einem beliebigen Quell-Subnetz verwendet.

Siehe jedoch den Befehl ip multicast multipath (neu in Cisco IOS Version 12.0(8) T, 12.0(5) S). Mit diesem Befehl kann bei richtiger Anwendung ein Lastausgleich für verschiedene Quellen für eine bestimmte Multicast-Gruppe erreicht werden. Da dies pro Quelle und nicht pro Stream geschieht, ist es eher eine Art Lastaufteilung.

Der Lastausgleich für einen Paketstrom (eine Quelle und eine Gruppe) über zwei Links zwischen zwei Routern kann auch mit GRE-Tunneln zwischen Loopback-Schnittstellen erfolgen, obwohl ich mir Sorgen über die Auswirkungen auf die Leistung bei einem Strom mit hoher Bandbreite machen würde.

Dieser Befehl sagt uns übrigens auch, wie wir IP-Multicast über Links unserer Wahl leiten können. Wir kontrollieren, wohin der Multicast-Verkehr geht, indem wir die RPF-Prüfung kontrollieren. Wenn ein Router keine Routen zurück zu einer Multicast-Quelle auf einer Schnittstelle lernt, dann wird diese Schnittstelle nicht die RPF-Schnittstelle sein. Mit Distanzvektorprotokollen und „route starvation“ (keine Bekanntgabe einer Route an einen Nachbarn) können wir also Multicast steuern oder lenken.

Wir werden später sehen, dass alle PIM-Grafts oder Joins über die RPF-Schnittstelle zurück zur Quelle (oder RP im PIM Sparse Mode) gesendet werden. Indem wir kontrollieren, wo diese Aktivität stattfindet, kontrollieren wir, über welche Links der Multicast weitergeleitet wird. Statische mroute-Einträge (statische Routen zurück zur Quelle zum Zweck der Multicast-RPF-Prüfung) sind eine weitere Möglichkeit, den Multicast-Verkehr zu steuern. Wenn wir über Multicast MBGP (Multiprotocol BGP for Multicast) sprechen, werden wir sehen, dass MBGP uns auch eine Möglichkeit bietet, die vom Multicast-Verkehr genutzten Links zu steuern oder zu kontrollieren. Beachten Sie auch, dass der Router Pakete erwartet, die er nicht empfangen kann, wenn auf der RPF-Schnittstelle kein IP-Multicast aktiviert ist. Die RPF-Schnittstelle sollte immer eine sein, auf der IP-Multicast aktiviert ist.

PIM Dense Mode – Übersicht

Protocol Independent Multicast hat zwei Modi, Dense Mode und Sparse Mode. In diesem Artikel ist nur Platz für den ersten Modus. Wir werden uns im nächsten Artikel mit PIM-SM befassen.

PIM Dense Mode (PIM-DM) verwendet einen recht einfachen Ansatz für das IP-Multicast-Routing. Die Grundannahme hinter PIM-DM ist, dass der Multicast-Paketstrom an den meisten Orten Empfänger hat. Ein Beispiel hierfür könnte eine Unternehmenspräsentation durch den CEO oder Präsidenten eines Unternehmens sein. Im Gegensatz dazu geht der PIM Sparse Mode (PIM-SM) von relativ wenigen Empfängern aus. Ein Beispiel wäre das Einführungsvideo für neue Mitarbeiter.

Dieser Unterschied zeigt sich im anfänglichen Verhalten und den Mechanismen der beiden Protokolle. PIM-SM sendet Multicasts nur dann, wenn es dazu aufgefordert wird. PIM-DM hingegen beginnt mit dem Fluten des Multicast-Verkehrs und stoppt ihn dann auf jeder Verbindung, auf der er nicht benötigt wird, mit einer Prune-Nachricht. Ich stelle mir die Prune-Nachricht so vor, dass ein Router einem anderen mitteilt: „Wir brauchen diesen Multicast hier gerade nicht“.

In älteren Cisco IOS-Versionen flutete PIM-DM den gesamten Multicast-Verkehr alle drei Minuten neu. Das ist gut für Multicast mit geringem Volumen, aber nicht für Multicast-Paketströme mit höherer Bandbreite. Neuere Cisco IOS-Versionen unterstützen seit 12.1(5)T eine neue Funktion namens PIM Dense Mode State Refresh. Diese Funktion verwendet eine PIM-Zustandsaktualisierungsnachricht, um den Prune-Zustand auf ausgehenden Schnittstellen zu aktualisieren. Ein weiterer Vorteil ist, dass Topologieänderungen schneller erkannt werden. Standardmäßig werden die PIM-Statusaktualisierungsnachrichten alle 60 Sekunden gesendet.

Betrachten Sie die Router E und F in der obigen Abbildung. Wenn zwei PIM-DM-Router eine Verbindung zu einem LAN herstellen, sehen sie die Multicast-Pakete des jeweils anderen. Einer sollte Pakete an das LAN weiterleiten, der andere nicht. Sie senden beide Assert-Nachrichten. Die beste Routing-Metrik gewinnt, wobei die höhere IP-Adresse den Ausschlag gibt. Wenn sie unterschiedliche Routing-Protokolle verwenden, entscheidet ein gewichtetes Routing-Metrik-Schema, ähnlich wie bei der administrativen Distanz, welcher Router der Forwarder sein soll (der die Multicast-Pakete an das LAN weiterleitet). Der Forwarder kann durch einen Prune von einem Downstream-Router ohne Empfänger zum Schweigen gebracht werden, wenn es auch keine Empfänger auf dem LAN-Segment gibt. Downstream-Router müssen unter Umständen ihren RPF-Nachbarn anpassen, um den Gewinner des Assert-Prozesses widerzuspiegeln.

Um das im Detail zu wiederholen: Wenn Multicast-Verkehr auf einer Nicht-RPF-Schnittstelle empfangen wird, wird eine Prune-Nachricht gesendet, sofern es sich um eine Punkt-zu-Punkt-Schnittstelle handelt. Diese Prune-Nachrichten sind ratenbegrenzt, um sicherzustellen, dass die Menge dieser Nachrichten (möglicherweise eine pro empfangenem Multicast) keine weiteren Probleme verursacht.

Ist die Nicht-RPF-Schnittstelle ein LAN, wird eine Assert-Nachricht gesendet. Nicht-Forwarder-Router senden dann ein Prune auf ihrer RPF-Schnittstelle, wenn sie den Multicast-Stream nicht benötigen. Es wird nur ein solches Prune gesendet, und zwar zum Zeitpunkt des Übergangs zu keinen Schnittstellen in der Outgoing Interface List (OILIST). Der LAN Prune-Empfänger verzögert die Reaktion darauf um 3 Sekunden, so dass er, falls ein anderer LAN-Router den Multicast-Stream noch benötigt, eine PIM Join-Nachricht senden kann, um dem Prune entgegenzuwirken (ihn aufzuheben). (

Angenommen, ein Router hat Pruned, und einige Zeit später fordert ein Empfänger den Multicast-Stream mit einer IGMP-Nachricht an. Der Router sendet daraufhin eine Graft-Nachricht. Das folgende Bild veranschaulicht dies, zugegebenermaßen in etwas komprimierter Form.

Erläuterung des Bildes:

(1), vielleicht wählt der Router E B als seinen RPF-Nachbarn, basierend auf Unicast-Routing zurück zur Quelle. Dann empfängt E ein Multicast-Paket auf der Punkt-zu-Punkt-Schnittstelle von C. Er sendet ein ratenbegrenztes Prune an C.

(2), die Router E und F im LAN tauschen Assert-Pakete aus, wenn E oder F das Multicast-Paket von dem anderen der beiden weitergegeben sieht. Angenommen, E gewinnt aufgrund der Unicast-Routing-Metrik oder der Adresse. Dann weiß F, dass er keine Multicasts im LAN weiterleiten darf. Beachten Sie, dass G und H nicht beteiligt sind, da das Ethernet ihre RPF-Schnittstelle ist.

(3) Nehmen wir an, Router G hat keine Empfänger im Downstream. Er kann dann einen LAN Prune an den Forwarder für das LAN, Router E, senden.

(4), wenn Router H lokale oder Downstream-Empfänger hat, kontert er dies mit einem LAN Join.

(5), angenommen, Router D hat keine Downstream- oder lokalen Empfänger und sendet einen Prune an B. Nehmen wir an, irgendwann später sendet einer der PCs rechts von ihm eine IGMP-Nachricht für dieselbe Multicast-Gruppe. Router D kann dann einen PIM Graft an B senden und B auffordern, ihm wieder die angegebene Multicast-Gruppe zu senden.

PIM Protokoll und Pakettypen

PIM ist ein vollständiges Routing-Protokoll mit verschiedenen Arten von Nachrichten. Ich werde nicht weiter auf die verschiedenen Nachrichten eingehen. Aber ich denke, es lohnt sich, einen kurzen Blick darauf zu werfen, da es uns ein wenig über das Protokoll erzählt.

PIM verwendet Hello-Nachrichten, um Nachbarn zu entdecken und Adjacencies zu bilden. Das Hello wird alle 30 Sekunden an die lokale Multicast-Adresse von All-PIM-Routers, 224.0.0.13, gesendet (PIMv1 verwendet AllRouters, 224.0.0.2). Jedes LAN hat einen PIM Designated Router (DR), der im PIM Sparse Mode verwendet wird. Er ist auch der IGMPv1 Querier: die höchste IP-Adresse im LAN. Der Befehl show ip pim neighbor zeigt Nachbarn sowie Adjazenz- und Timer-Informationen an.

Klarstellung hinzugefügt am 11.12.2004: IGMP Querier und Designated Router sind die beiden Rollen, um die es geht. Siehe hier.

In IGMP Version 1 ist der DR für folgende Aufgaben zuständig:

• Senden von PIM-Register- und PIM-Join- und Prune-Nachrichten an den RP, um ihn über die Mitgliedschaft in der Host-Gruppe zu informieren.
• Senden von IGMP-Host-Query-Nachrichten.“

In IGMP Version 2 sind sie entkoppelt. Der IGMP-Querier wird nach der niedrigsten IP im LAN ausgewählt. PIM wählt den DR nach der höchsten IP im LAN aus, um Multicasts an das LAN weiterzuleiten. (

PIM hat auch eine Join/Prune-Nachricht, die wie oben beschrieben verwendet wird. Es gibt auch Graft- und Graft-ACK-Nachrichten, was uns sagt, dass Graft zuverlässig durchgeführt wird (im Gegensatz zur realen Welt?).

Und es gibt die PIM-Assert-Nachricht.

PIM-SM hat 3 weitere Nachrichtentypen: Register, Register-Stop und RP-Reachability (nicht in PIMv2).

Konfiguration von PIM Dense Mode

Die Konfiguration von PIM-DM ist im Vergleich zu all dem oben genannten geradezu einfach.

Global aktivieren Sie Multicast-Routing mit dem Befehl:

ip multicast-routing

Dann aktivieren Sie auf jeder Schnittstelle, die am Multicasting teilnehmen soll, IP-Multicast und PIM mit dem Befehl interface:

interface …
ip pim dense-mode

Eigentlich ist es besser, den sparse-dense mode zu konfigurieren:

interface …
ip pim sparse-dense-mode

Der Grund dafür ist, dass dies Ihnen erlaubt, einige oder alle Multicast-Gruppen einfach in den Sparse-Modus zu migrieren, indem Sie den Router über einen Rendezvous-Punkt informieren. Und Sie können dies sogar tun, ohne viele Router oder Router-Schnittstellen neu zu konfigurieren.

Sie können Stub-Netzwerke für einfachen IP-Multicast konfigurieren. Die Idee ist, PIM der Einfachheit halber nicht für Stub-Teile des Netzwerks, wie kleine entfernte Standorte, auszuführen. Dies ist eine besonders gute Idee für Router, die nicht unter Ihrer Kontrolle stehen: Sie wollen nicht, dass sie Multicast-Routing mit Ihren Routern teilen. Es verhindert auch das PIM-DM-Flooding zu solchen Routern (mit älteren Cisco IOS-Versionen).

Um Stub-Multicast zu konfigurieren, konfigurieren Sie

ip igmp helper-address a.b.c.d

auf allen LAN-Schnittstellen der Stub-Router mit potenziellen Multicast-Empfängern. Die Adresse a.b.c.d ist die Adresse des zentralen PIM-sprechenden Routers. Auf dem zentralen Router konfigurieren Sie einen Filter, um alle PIM-Nachrichten auszuschalten, die der Stub-Nachbar senden könnte, und zwar mit:

ip pim neighbor-filter access-list

Siehe auch den Command Guide unter der URL:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fipr_c/ipcpt3/1cfmulti.htm .

Es gibt mehrere show-Befehle, die bei der Fehlersuche im IP-Multicast helfen. Die, die mir am besten gefallen:

• show ip mroute
• show ip pim interface
• show ip pim neighbor
• show ip rpf

Da der Platz knapp ist, verweise ich für Beispiele auf die Befehlsreferenz.

Eine Anmerkung zur Fehlerbehebung: Wenn Sie Multicast mit hoher Bandbreite in Ihrem Netzwerk haben, stellen Sie sicher, dass Sie den Prune State Refresh in den neueren Cisco IOS-Versionen verwenden, wenn Sie den sparse-dense-Modus verwenden. Ich mache mir Sorgen darüber, dass Router „vergessen“, dass sie einen RP haben und in den Dense Mode zurückkehren, mit periodischem Flooding. Dies mag ein seltenes, zufälliges Ereignis sein, aber es könnte Ihnen wirklich den Morgen verderben! Vielleicht möchten Sie auch Techniken zur Robustheit des RP in Betracht ziehen, ein Thema für unseren späteren Artikel über PIM-SM oder Rendezvous Point.

Zusammenfassend

Das empfohlene Buch für viele Multicast-Themen: Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying CISCO IP Multicast Networks, Beau Williamson.

Einen weiteren sehr guten Cisco Multicast Link finden Sie hier.

Nächster Artikel: Skalierung mit PIM Sparse Mode.