Cisco 300-410: Multicast-Routing und -Verteilung — Lernleitfaden

By Laurynas Brazys · 16 August 2026 · #cisco #300-410 #certification #exam-prep #study-guide

Teil des Cisco CCNP Enterprise 300-410 ENARSI — Lernleitfaden. Üben Sie mit verifizierten Antworten im Cisco-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Multicast-Routing liefert einen einzelnen Datenstrom von einer oder mehreren Quellen an mehrere Empfänger, mit effizienter Replikation an Verzweigungspunkten im Netzwerk. Der korrekte Betrieb hängt von der Gruppenadressierung und der Signalisierung der Empfängermitgliedschaft (IGMP), einem Multicast-Routing-Protokoll zum Aufbau von Verteilungsbäumen (PIM) und einer sorgfältigen Kontrolle von Grenzen, RPs und Richtlinien ab. Designs müssen Konvergenz, Zustands-Skalierung (State Scale), Ausfallsicherheit und Einfachheit abwägen und dabei häufige Fehlerquellen wie Reverse Path Forwarding (RPF)-Verletzungen, RP-Blackholes oder L2-Flooding durch Snooping-Probleme vermeiden.

Adressierung, IGMP und Layer-2-Interaktion

• Adressierung und Geltungsbereich:

  • 224.0.0.0/4 ist der IPv4-Multicast-Bereich.
  • 224.0.0.x ist Link-Local (wird niemals geroutet) für Kontrollprotokolle.
  • 239.0.0.0/8 ist administrativ begrenzt (administratively scoped); wird üblicherweise an Domänengrenzen eingeschränkt.
  • Das MAC-Mapping verwendet 01:00:5e:0/25 plus die unteren 23 Bits der Gruppe; Aliasing kann dazu führen, dass mehrere Gruppen sich eine MAC teilen, daher basiert die L2-Filterung auf IGMP-Snooping und nicht allein auf MAC-Adressen.

• IGMP-Empfängermitgliedschaft:

  • IGMPv1: einfache Joins, kein explizites Leave; langsames Pruning.
  • IGMPv2: fügt Leave- und Group-Specific/Last-Member-Queries hinzu; Querier-Wahl (niedrigste IP).
  • IGMPv3: Quellenfilterung für Include/Exclude-Listen; erforderlich für Source-Specific Multicast (SSM).
  • Querier-Verhalten: In einem VLAN muss genau ein Querier periodische Anfragen senden, um den Mitgliedschaftsstatus aufrechtzuerhalten. Wenn kein L3-Interface eines Routers vorhanden ist, aktivieren Sie einen IGMP-Snooping-Querier auf dem Switch, um das Altern der Gruppen (Aging) und Flooding zu verhindern.

• IGMP-Snooping (L2):

  • Switches inspizieren IGMP, um Multicast auf Empfänger-Ports zu beschränken und Router-Ports (mrouter) zu identifizieren. Die Erkennung erfolgt über PIM Hellos, IGMP-Queries oder die statische Konfiguration von mrouter-Ports.
  • Fehlermodi:
    • Kein Querier vorhanden: Snooping-Tabellen veralten (age out), der Datenverkehr wird geflutet (flooded) oder verworfen.
    • Snooping ohne mrouter-Port: Empfänger treten bei, aber die Daten werden auf L2 blockiert; konfigurieren Sie PIM auf dem SVI oder definieren Sie statisch einen mrouter-Port.
    • IGMPv3 und SSM: Stellen Sie sicher, dass Snooping v3 und SSM unterstützt; eine Fehlausrichtung kann zu unerwartetem Flooding oder Paketverlusten führen.

Kurze, nützliche Beispiele:

• PIM und IGMP v3 auf Router-Interfaces aktivieren:

undefined

• Switch-seitiger L2-Querier, wenn kein L3-Gateway vorhanden ist:

undefined

PIM-Modi, Bäume und RPF-Verhalten

• PIM Dense Mode (PIM-DM):

  • Flood-and-Prune: Flutet anfangs den Verkehr; nachgelagerte Router (Downstreams) führen ein Pruning durch, wenn keine Empfänger vorhanden sind; periodische Zustandsaktualisierung.
  • Vorteile: einfach, kein RP.
  • Nachteile: gesprächig (chatty), nicht domänenweit skalierbar; nur für kleine Segmente mit hoher Empfängerdichte geeignet.

• PIM Sparse Mode (PIM-SM):

  • Verwendet einen Rendezvous Point (RP) für einen Shared Tree (*,G). Quellen registrieren sich beim RP; Empfänger senden Joins in Richtung des RP.
  • Register-Nachrichten: Der First-Hop Router (FHR) kapselt Daten zum RP (Register). Der RP kann mit einer Register-Stop-Nachricht antworten, sobald das native Forwarding etabliert ist.
  • Shortest-Path Tree (SPT) Switchover: Die DRs der Empfänger können zur Pfadoptimierung direkt der Quelle beitreten (S,G). Steuerung über

undefined

. infinity zwingt den Verkehr, auf dem Shared Tree zu bleiben.

• Sparse-Dense Mode:

  • Pro-Gruppen-Modus: Verhält sich wie Sparse-Mode, wenn ein RP-Mapping existiert; andernfalls wie Dense-Mode. Wurde historisch verwendet, um Auto-RP zu bootstrappen, bevor die RPs bekannt sind. Moderne Designs bevorzugen reinen Sparse-Mode mit BSR oder statischen RPs.

• Source-Specific Multicast (SSM):

  • Eliminiert den RP und den Shared Tree; Empfänger signalisieren (S,G) direkt mittels IGMPv3 Include. Empfohlen für One-to-Many-Streaming in großem Umfang.
  • SSM-Bereich definieren (üblicherweise 232.0.0.0/8):

undefined

• Für ältere IGMPv2-Hosts kann SSM-Mapping (G) mittels Access-Listen in (S,G) übersetzen.

• RPF-Prüfungen:

  • Jeder (S,G)- oder (*,G)-Zustand validiert das Upstream-Interface gegen die MRIB (normalerweise die Unicast-RIB/CEF). Eine Nichtübereinstimmung führt zum Verwerfen des Traffics (Incoming RPF Fail).
  • Häufige Ursachen:
    • Asymmetrisches Unicast-Routing, eine ECMP-Auswahl, die nicht mit dem PIM-Nachbarn übereinstimmt.
    • Fehlende Route zur Quelle/zum RP oder eine rekursive Route zu Null0.
    • Fehler beim VRF-Leakage oder falscher VRF-Lookup.
  • Tools:

undefined

• Gegenmaßnahmen: Korrektur des Unicast-Routings, Bevorzugung eines Nachbarn mit

undefined

in LANs, statische mroutes für Control Planes oder

undefined

, wo erforderlich.

Betriebliche Feinheiten:

• DR-Wahl pro Multi-Access-Netzwerk (höchste PIM DR-Priorität, dann höchste IP).
• PIM Assert in Multi-Access-Netzwerken, um einen einzelnen Forwarder für ein (S,G) in ein LAN auszuwählen (niedrigste Metrik zur Quelle; bei Gleichstand höchste IP). Falsche Metriken können zu doppelter Unterdrückung (Duplicate Suppression) oder Blackholes führen.

Rendezvous-Punkte: Statisch, Auto-RP, BSR, Anycast RP mit MSDP

• RP-Rolle:

  • Control-Plane-Root für die Gruppenerkennung und den Aufbau des Shared Tree in PIM-SM.
  • Muss für sowohl Quellen (über FHR-Register) als auch Empfänger (über Joins) erreichbar und RPF-korrekt sein.

• RP-Optionen:

  • Statischer RP:

undefined

. Deterministisch, einfach, aber ein Single Point, es sei denn, er wird mit Anycast RP kombiniert.

• Auto-RP: Candidate-RPs kündigen sich bei 224.0.1.39 an; der RP-Mapping-Agent gibt die Zuweisung an 224.0.1.40 bekannt. Erfordert Sparse-Dense-Mode oder einen separaten Bootstrap-Prozess während der Inbetriebnahme. Anfällig für Filterung über Domänengrenzen hinweg; stellen Sie sicher, dass an den Grenzen entsprechende Freigaben existieren oder verwenden Sie filter-autorp.

• Bootstrap Router (BSR): Integrierter PIMv2-Mechanismus; Candidate-RPs und ein BSR erstellen ein RP-Set und die Zuweisungen (Mappings). Robuster als Auto-RP; für neue Implementierungen empfohlen.

• Anycast RP mit MSDP:

  • Mehrere RPs teilen sich dieselbe Loopback-IP; das IGP kündigt den nächstgelegenen RP an. MSDP-Peering zwischen den RPs tauscht Source-Active (SA)-Nachrichten aus, sodass alle RPs von aktiven Quellen erfahren.
  • Design-Praktiken:
    • Verwenden Sie MSDP-Mesh-Groups, um das Fluten von SA-Nachrichten zu reduzieren.
    • Behalten Sie das Anycast-RP-Loopback im IGP mit einer konsistenten Policy und RPF-Korrektheit bei.
    • Schützen Sie den RP mit ip pim accept-register list <acl>, um einzuschränken, welche Quellen sich registrieren dürfen.
  • Fehlermodi:
    • MSDP ausgefallen: Entfernte Quellen werden nicht an allen RPs gelernt; Empfänger in der Nähe des isolierten RPs erleiden einen Blackhole, bis ein Failover stattfindet.
    • Asymmetrisches IGP zum Anycast-Loopback: Empfänger senden Joins an einen anderen RP als den, bei dem sich der FHR registriert, was zu einer Verzögerung bis zur SA-Weitergabe führt.

• SSM versus RP:

  • SSM vermeidet die Komplexität von RPs vollständig und reduziert so den Control-Plane-Status und die Ausfalldomänen. Bevorzugen Sie SSM für neue Anwendungen, die zur Quellensignalisierung fähig sind.

Richtlinien, Grenzen, VRFs, Tunnel und WAN-Überlegungen

• Grenzkontrollen und Gruppenrichtlinien:

  • Administrativen Geltungsbereich und unerwünschte Gruppen mit Interface-Multicast-Grenzen einschränken:
    • interface ip multicast boundary 10
    • ip access-list standard 10 deny 239.0.0.0 0.255.255.255 permit any
  • Auto-RP-Nachrichten bei Bedarf filtern: ip multicast boundary 20 filter-autorp
  • Einschränken, welche Quellen sich bei einem RP registrieren können:
    • ip pim accept-register list RP-SOURCES
  • SSM-only-Richtlinie für 232/8 erzwingen, um RP-Abhängigkeit zu vermeiden.

• Multicast über VRFs hinweg:

  • Pro-VRF-Multicast aktivieren: ip multicast-routing vrf und PIM auf VRF-Interfaces konfigurieren.
  • Jede VRF hat ihre eigenen PIM-Nachbarschaften, RPF-Lookups und möglicherweise separate RPs/SSM-Bereiche.
  • Inter-VRF-Multicast erfordert einen Trägermechanismus (z. B. mVPN auf MPLS, dediziertes GRE zwischen VRFs oder eine Fusion-Routing-Firewall). Einfaches Leaking ist für die Replikation der Datenebene unzureichend.

• Tunnel und WAN-Transport:

  • Natives IPsec kann kein Multicast übertragen; verwenden Sie GRE über IPsec (oder DMVPN mGRE), um PIM- und Multicast-Daten zu transportieren.
  • PIM auf Tunnel-Interfaces für die Baumstruktur über das Overlay konfigurieren. Beispiel:
    • interface Tunnel10 ip address 10.0.10.1 255.255.255.0 tunnel source Gig0/0 tunnel destination 198.51.100.1 ip pim sparse-mode
  • Auf DMVPN PIM auf mGRE-Tunneln aktivieren. ip nhrp shortcuts für die Optimierung des Unicast-Pfads in Betracht ziehen; Multicast folgt den PIM-Bäumen unabhängig von NHRP, profitiert aber von Spoke-to-Spoke-Tunneln.
  • Über Provider-MPLS mVPN für skalierbare Replikation verwenden; oder wenn der Provider kein Multicast anbietet, GRE-over-WAN zwischen Kundenstandorten nutzen.

• Abwägungen bei WAN und NBMA:

  • Dense-Mode über NBMA verursacht unnötige Replikation; verwenden Sie Sparse-Mode oder SSM.
  • Den SPT-Switchover auf Verbindungen mit geringer Bandbreite mit spt-threshold steuern, um suboptimale, aber bandbreitenschonende Shared Trees zu minimieren.
  • MTU entlang der Tunnel überprüfen, um verworfene PIM-Register-Kapselungen zu vermeiden.

• Verifizierungs- und Fehlerbehebungs-Workflow:

  • Empfänger-Edge: show ip igmp groups, show ip igmp interface; Querier und Version bestätigen. Bei Bedarf ip igmp join-group <G> auf einem Test-Interface ausführen.
  • PIM-Adjazenz: show ip pim neighbor; nicht übereinstimmende Modi oder ACL-Filter können Hellos blockieren.
  • RP-Status: show ip pim rp mapping; Auswahl der Gruppe-zu-RP validieren; MSDP mit show ip msdp sa-cache überprüfen.
  • Bäume und Weiterleitung: show ip mroute [G | S G] für eingehendes Interface (RPF) und ausgehende Interfaces (OIL). Auf Flags (S, J, T, R) achten, die den SPT-/Shared-/Register-Status anzeigen.
  • RPF: show ip rpf <S oder RP>; Unicast-Routing oder statische Mroutes korrigieren.
  • Datenpfad: mtrace oder Tests auf Anwendungsebene; Aufzeichnungen für IGMP-Reports, PIM-Joins/Prunes, Registers durchführen.
  • Häufige Korrekturen: einen Querier auf L2 wiederherstellen, RP-Erreichbarkeit korrigieren, SSM-Bereich und IGMPv3-Unterstützung abstimmen und spt-threshold für die Link-Auslastung anpassen.

Praktisches Problemszenario

Contoso Media betreibt drei Standorte, die über ein IPsec-WAN verbunden sind, das Multicast nicht nativ unterstützt. Sie müssen einen 6-Mbit/s-Live-Videostream von einem Encoder im Rechenzentrum (10.10.10.50) an Empfänger in VLAN 120 an allen Standorten liefern. Gleichzeitig muss das Durchsickern von Multicast in andere VLANs verhindert und die Ausfallsicherheit für den RP gewährleistet werden.

Ansatz:

1. Multicast über GRE auf IPsec zwischen dem Hub im Rechenzentrum und jedem Standort transportieren.

   • Begründung: IPsec allein kann Multicast nicht kapseln; GRE bewahrt Multicast- und PIM-Kontrollpakete. Hub-and-Spoke vereinfacht die Erstbereitstellung und den Aufbau von PIM-Adjazenz.

2. PIM Sparse-Mode auf allen LAN- und GRE-Tunnel-Interfaces ausführen; IGMPv3 auf Empfänger-VLANs aktivieren.

   • Begründung: Sparse-Mode skaliert für Gruppen mit wenigen Empfängern. IGMPv3 ermöglicht eine zukünftige Migration zu SSM und stellt korrektes Quellfilterungsverhalten von den Hosts sicher.

3. Anycast RP mit Loopback 172.16.255.254 auf zwei Core-Routern am Hub bereitstellen; MSDP zwischen ihnen einrichten.

   • Begründung: Anycast RP bietet eine deterministische Auswahl des nächstgelegenen RP und RP-Redundanz. MSDP synchronisiert das Wissen über aktive Quellen, sodass jeder RP die Empfänger bedienen kann, wenn der andere ausfällt.

4. Die Bereitstellung auf administrativ begrenzte Gruppen beschränken und nur den Encoder als gültige registrierende Quelle zulassen.

   • Begründung: Die Richtlinie reduziert die Angriffsfläche und versehentliches Flooding. 239.1.1.10 für den Stream verwenden; ip pim accept-register anwenden, um auf 10.10.10.50 zu beschränken.

5. Verhindern, dass Multicast unbeabsichtigt die Empfänger-VLANs verlässt oder Standortgrenzen überschreitet, indem Multicast-Grenzen angewendet werden.

   • Begründung: ip multicast boundary-ACLs auf SVIs stoppen unerwünschte Gruppen und Auto-RP/BSR-Kontrollverkehr, wo er nicht benötigt wird, was das Scoping erzwingt und das „Chatter“ reduziert.

6. Den SPT-Switchover steuern, um WAN-Bandbreite zu sparen, indem der Verkehr auf dem Shared Tree über die GRE-Tunnel gehalten wird.

   • Begründung: spt-threshold infinity an den Campus-DRs setzen, damit Joins zum RP über den Hub bestehen bleiben; Intra-Campus-LANs können bei Bedarf immer noch auf SPT umschalten, um einen Ausgleich zwischen Effizienz und WAN-Einsparung zu schaffen.

7. L2-Mitgliedschaft mit einem IGMP-Snooping-Querier auf Access-Switches validieren, wo kein L3-SVI als Querier fungiert.

   • Begründung: Stellt einen kontinuierlichen Gruppenzustand auf L2 sicher und verhindert unerwünschtes Flooding oder den Verlust von Multicast, wenn Snooping-Tabellen veralten.

8. Überwachung und ein Break/Fix-Runbook mit Kernbefehlen implementieren.

   • Begründung: show ip pim neighbor für Adjazenz, show ip pim rp mapping zur Überprüfung des Anycast RP, show ip msdp sa-cache zur Bestätigung der Source-Advertisement, show ip mroute 239.1.1.10 für den Baumstatus und show ip rpf 10.10.10.50 zur Überprüfung der Upstream-Pfade verwenden. Dies beschleunigt die Fehlerisolierung bei RPF-Fehlern, RP-Erreichbarkeitsproblemen oder Snooping-Fehlkonfigurationen.

Kurze Konfigurations-Highlights:

• SSM-Bereich für zukünftiges Wachstum definieren:
  • ip pim ssm range 232.0.0.0/8
• Anycast RP und MSDP auf jedem Core:
  • interface loopback0 ip address 172.16.255.254 255.255.255.255
  • ip pim rp-address 172.16.255.254 239.0.0.0 0.255.255.255
  • ip msdp peer 172.16.255.254 connect-source loopback0 mesh-group RPs
  • ip pim accept-register list ENCODER-SRC
  • ip access-list standard ENCODER-SRC permit 10.10.10.50
• Campus-DRs, um den Shared Tree über das WAN beizubehalten:
  • ip pim spt-threshold infinity

Dieses Design liefert den Videostream zuverlässig über ein Nicht-Multicast-WAN, beschränkt Multicast auf die vorgesehenen Domänen und bleibt widerstandsfähig gegenüber RP-Ausfällen, während es ein klares Betriebsmodell für die Verifizierung und Fehlerbehebung bietet.

← MPLS · Alle Domänen · Dienstgüte und Control-Plane-Schutz →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →