Kapitel 4. Internet-Multicast über MPLS
Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com
Dieses Kapitel beschreibt Global Internet Multicast, im Gegensatz zu Kapitel 5, das sich mit Multicast VPN beschäftigt. Beginnen wir mit einer grundlegenden Einführung in Multicast, die auch zum besseren Verständnis von Kapitel 5 beitragen soll.
Multicast-Pakete fließen von einer bestimmten Quelle (S) zu einer Gruppe (G) von Empfängern, im Gegensatz zu Unicast-Paketen, die an einen einzigen Empfänger gerichtet sind. Der Weiterleitungspfad für den Transport von Multicast wird in der Regel als Baum modelliert, wobei die Quelle die Wurzel ist und die Empfänger an den Blättern sitzen. In einem Multicast-Baum replizieren die Router den Verkehr an den Verzweigungspunkten. Der Verkehr fließt von der Wurzel zu den Blättern, wie der Saft in einem Baum. In diesem Sinne trotzen die Begriffe Upstream und Downstream der Schwerkraft: Nimm ein Bild von einem Baum und drehe ihn auf den Kopf, mit der Wurzel oben und den Blättern unten, und lass den Verkehr nach unten fließen. Mit diesem Bild vor Augen ist es einfacher zu verstehen, warum Upstream im Multicast-Bereich die Wurzel (die Quelle) und Downstream die Blätter (die Empfänger) bezeichnet. Multicast-Pakete fließen stromabwärts als Punkt-zu-Multipunkt-Verbindung.
Bekommen wir nach dieser kurzen Fantasiereise die Realität wieder in den Griff. Kurz gesagt: Multicast-Technologien ermöglichen es einem Netzwerk, ein einziges Paket an mehrere Ziele zu senden. Eine beliebte und typische Multicast-Anwendung ist das IP-Fernsehen (IPTV), bei dem viele private und mobile Nutzer/innen denselben Live-Kanal zur gleichen Zeit sehen können. Wenn die Quelle für jedes Paket Tausende oder Millionen von Kopien erstellen müsste, wären die Anforderungen an die Rechenleistung und die Netzwerkbandbreite an der Quelle enorm, ganz zu schweigen von den Auswirkungen auf die Latenzzeit. Glücklicherweise ist die IPTV-Quelle in der Regel ein Server (oder ein Cluster), der nur eine Kopie des Multicast-Streams über seine Netzwerkschnittstelle sendet. Aber wie kann dieser Stream alle Empfänger erreichen? Multicast löst das Problem: Das Netzwerk des Dienstanbieters (SP) baut einen Baum auf, der das ursprüngliche Paket repliziert und sicherstellt, dass jeder Empfänger nur eine einzige Kopie davon erhält. Dieser Baum führt eine effiziente Replikation an den Verzweigungspunkten durch, so dass nur eine Kopie jedes Pakets eine bestimmte Netzwerkverbindung durchläuft.
Es gibt viele andere Multicast-Anwendungen mit unterschiedlichen Anforderungen. Einige von ihnen haben niedrige Bitraten und strikt niedrige Latenzzeiten (z. B. die Echtzeitverteilung von Börsentickerdaten an Handelsunternehmen oder die Übertragung von Radarsignalen an Flugsicherungsbetreiber). Andere Multicast-Anwendungen haben ein hohes Verkehrsaufkommen und unterschiedliche Anforderungen an die Latenzzeit, z. B. Videokonferenzen oder die Verteilung von Software und Medien an Repositories und Caches.
Dieses Kapitel behandelt die IPv4-Multicast-Verteilung über einen MPLS-Kern für zwei Arten von Diensten: Internet Multicast (in der Global Routing Table) und Multicast IP VPN. Obwohl IPv6 nicht eingehend behandelt wird, sind die Konfiguration und die Mechanismen sehr ähnlich.
Doch bevor wir uns mit den Diensten beschäftigen, sollten wir erst einmal die Grundlagen von IP Multicast auffrischen.
IP-Multicast
Ein IP-Multicast-Fluss wird oft als (S, G) dargestellt, wobei S und G die Quell- bzw. Ziel-IP-Adressen der Datenpakete sind:
- S
- Dies ist eine Unicast-IP-Adresse (v4 oder v6), die einen einzelnen Host repräsentiert. Dieser Host (S) ist die Quelle des Multicast-Streams.
- G
- Dies ist eine Multicast-IP-Adresse, die eine Gruppe von Hosts (Empfängern) repräsentiert, die den Datenverkehr empfangen möchten.
Was ist der Unterschied zwischen einer Unicast- und einer Multicast-IP-Adresse? Sie sehen beide ähnlich aus, aber es gibt bekannte Adressbereiche, die für Multicast reserviert sind:
-
Der IPv4-Multicast-Adressbereich ist 224/4, oder 224.0.0.0 bis 239.255.255.255
-
Der IPv6-Multicast-Adressbereich ist ff00::/8
Nicht alle Multicast-IP-Adressen sind domänenübergreifend routingfähig. Alle Adressen in den Bereichen 224/24 und ff02::/16 sind link-local und daher nicht routingfähig. Um nur ein Beispiel zu nennen: Nicht zielgerichtete LDP-Helo-Pakete haben die IP-Adresse 224.0.0.2 als Ziel. Eine vollständige Liste der Multicast-Adressbereiche, die für verschiedene Zwecke reserviert sind, findest du in der IPv4 und IPv6 Multicast Address Space Registry auf der IANA-Website.
In Ethernet Layer 2 (L2)-Domänen werden IP-Multicast-Pakete in einen Ethernet-Header eingekapselt. Die Netzwerkkarte, die den Frame in die L2-Domäne einschleust, kopiert einfach ihre eigene MAC-Adresse in das Feld Source MAC address des Ethernet-Headers des Frames; das ist das übliche Ethernet-Geschäft. Die Ziel-MAC-Adresse ist jedoch etwas Besonderes:
- IPv4 Multicast
- Das Address Resolution Protocol (ARP) spielt hier keine Rolle. Die letzten 23 Bits der IPv4-Multicast-Adresse werden an das 01:00:5e MAC-Präfix angehängt, um eine Ziel-MAC-Adresse zu bilden. Zum Beispiel werden IPv4-Pakete, die für 232.1.2.3 bestimmt sind, in einen Ethernet-Header mit der Ziel-MAC-Adresse 01:00:5e:01:02:03 eingekapselt.
- IPv6 Multicast
- Neighbor Discovery (ND) spielt hier keine Rolle. Die letzten 32 Bits der IPv6 Multicast-Adresse werden an das 33:33 MAC-Präfix angehängt. Zum Beispiel haben IPv6-Pakete, die an ff3e::0001:0203 gerichtet sind, die Ziel-MAC-Adresse 33:33:00:01:02:03.
Es gibt tatsächlich eine Gemeinsamkeit zwischen den Präfixen 01:00:5e und 33:33. Das letzte Bit des ersten Oktetts ist in beiden Fällen auf 1 gesetzt. Im Ethernet wird jeder Frame, bei dem dieses Bit auf 1 gesetzt ist, als Multicast-Frame(nicht unbedingt IP) betrachtet. Viele Nicht-IP-Protokolle verwenden solche Ziel-MAC-Adressen. Zum Beispiel werden Intermediate System-to-Intermediate System (IS-IS) Punkt-zu-Punkt- und LAN-Hellos an 09:00:2b:00:00:05 bzw. 01:80:c2:00:00:15 MAC-Adressen gesendet.
Auch bei Unicast-Frames ist das letzte Bit des ersten Oktetts der Ziel-MAC-Adresse auf 0 gesetzt. Normalerweise wird eine Unicast-MAC-Adresse dynamisch über ARP (in IPv4) oder ND (in IPv6) aufgelöst; im Gegensatz zu Multicast-MAC-Adressen, die statisch mit der in den vorherigen Absätzen erläuterten mathematischen Regel berechnet werden.
IP-Multicast-Protokolle
Multicast-Quellen sind zustandslos. Sie senden die Pakete einfach aus einer Netzwerkschnittstelle in ein lokales Netzwerksegment. Dieses Segment kann lokale Empfänger enthalten und, was noch wichtiger ist, auch einen oder mehrere multicastfähige Router, den sogenannten First Hop Router (FHR).
Im Gegensatz dazu sind die Endempfänger zustandsbehaftet und signalisieren ihre Multicast-Abonnements mit Hilfe eines link-local Protokolls: Internet Group Management Protocol (IGMP) für IPv4-Gruppen und Multicast Listener Discovery (MLD) für IPv6-Gruppen. Hoffentlich gibt es einen Multicast-fähigen Router, der lokal mit demselben Segment wie die Empfänger verbunden ist. Ein solches Gerät wird als Last Hop Router (LHR) bezeichnet und verarbeitet die lokalen IGMP- und MLD-Nachrichten.
Was ist, wenn ein FHR und ein LHR mehrere Hops voneinander entfernt sind? Nun, ein Multicast-Baum muss die FHR mit der LHR verbinden, damit alle Segmente mit lokalen Empfängern die Multicast-Pakete empfangen können. Und wie wird ein solcher Baum signalisiert? Das ist die Hauptaufgabe des Protocol Independent Multicast (PIM) Protokolls.
PIM hat zusätzliche Funktionen wie die Erkennung von Multicast-Quellen und bietet außerdem einen Redundanzmechanismus in Topologien mit mehreren FHRs (oder mehreren LHRs) im selben Segment.
IP-Multicast-Modi
PIM kann in zwei Hauptmodi funktionieren:
- Sparsamer Modus
- Im Sparse Mode (RFC 4601, Standards Track) lösen die Empfänger die Signalisierung des Multicast-Baums aus. Mit anderen Worten: Ein Multicast-Fluss wird nur dann weitergeleitet, wenn es Downstream-Empfänger für diesen Fluss gibt. Dies führt zu einer effizienten Nutzung der Bandbreitenressourcen.
- Dichter Modus
- Im Dense Mode (RFC 3973, experimental track) wird der Datenverkehr zunächst über alle möglichen Pfade geflutet, falls es Empfänger gibt. Wenn es auf einem bestimmten Pfad keine Empfänger gibt, wird dieser Zweig aus dem Multicast-Baum gestrichen. Dieser Modus wird nur selten verwendet, da er in Bezug auf Bandbreite und Signalisierung nicht skalierbar ist. Deshalb wird er in diesem Buch nicht behandelt.
Im PIM-Sparse-Modus gibt es drei Untermodi: Any Source Multicast (ASM), Source-Specific Multicast (SSM) und Bidirectional (BIDIR).
Hinweis
In der Dokumentation von Cisco wird der Begriff Sparse Mode oft nur für ASM verwendet. Streng genommen ist der Sparse Mode eine Obermenge, die ASM, SSM und BIDIR umfasst. In diesem Buch wird die Standardterminologie verwendet.
Einige Empfänger abonnieren einfach eine Gruppe G, wenn sie daran interessiert sind, den gesamten Verkehr zu empfangen, der für die Gruppenadresse G bestimmt ist, unabhängig davon, welche Quellen für diese Gruppe aktiv sind. Diese Empfänger erstellen ein (*, G) oder ASM-Abonnement über IGMP oder MLD.
Andere Empfänger geben auch die Quelle S an, von der sie Multicast-Verkehr empfangen wollen. Diese Empfänger erstellen ein (S, G) oder SSM-Abonnement über IGMP oder MLD. RFC 4607 listet alle IP-Multicast-Adressen auf, die für die SSM-Nutzung reserviert sind. Im Falle von IPv4 ist der Standard-SSM-Adressbereich 232/8, also 232.0.0.0 bis 232.255.255.255. Du kannst das Netzwerk auch so konfigurieren, dass es Adressen außerhalb dieses Bereichs für SSM verwendet.
Es gibt keine feste Grenze zwischen ASM und SSM. Selbst wenn ein Empfänger eine ASM (*, G)-Nachricht sendet, kann es passieren, dass das Netzwerk irgendwann den SSM (S, G)-Status direkt an die Quelle (Upstream) signalisiert. Es gibt mehrere Szenarien, in denen das passiert, und du wirst sie später in diesem Kapitel kennenlernen.
Sowohl ASM als auch SSM haben Vor- und Nachteile. Während ASM für den Empfänger einfacher ist, ist SSM einfacher für das Netzwerk. Router finden es viel einfacher, einen Multicast-Baum aufzubauen, wenn die Quellen vorher bekannt sind, als wenn sie die Quellen von Grund auf neu entdecken müssen. Aus diesem Grund wird ASM erst am Ende von Kapitel 5 behandelt.
In ASM und SSM sind Multicast-Bäume unidirektional: Sie transportieren den Verkehr von Quellen zu Empfängern. BIDIR (RFC 5015) hingegen deckt einen speziellen Anwendungsfall ab, bei dem Quellen auch Empfänger sein können und umgekehrt. Für diese Anwendungen ist es sinnvoll, einen bidirektionalen Baum aufzubauen.
Hinweis
Dieses Buch konzentriert sich auf ASM und SSM, die am häufigsten vorkommenden Modi.
Multicast im Allgemeinen und PIM im Besonderen haben eine Menge Terminologie. Anstatt alles von Grund auf zu wiederholen, führen wir sie nach und nach ein, während die Beispiele fortschreiten.
Klassischer Internet-Multicast
Internet Multicast steht für den Transport von globalem IP-Multicast-Verkehr über einen SP-Kern. Die Kanten des Anbieters (PEs) leiten die Pakete im Rahmen der Global Routing Table (GRT) weiter. Mit anderen Worten: Dieser Dienst ist nicht mit einem VPN verbunden. Auf der anderen Seite bedeutet "klassisch" MPLS-frei: Die Ausgangssituation ist daher der in Kapitel 1 sehr ähnlich, und die Notwendigkeit von MPLS (oder IP-Tunneling) wird sich natürlich zeigen.
Multicast-Quellen und -Empfänger starten
Abbildung 4-1 zeigt die Topologie dieses Kapitels. Die IS-IS-Metriken sind zunächst wie folgt konfiguriert: Wert 15 für die Verbindungen PE1-PE2 und PE3-PE4 und der Standardwert (10) für die übrigen Verbindungen (PE-P und P-P). Diese Topologie hat auch Route Reflectors (RRs), auch wenn sie in Abbildung 4-1 nicht angezeigt werden.
H1 und H2 erzeugen aktiv Verkehr in Richtung der SSM-Gruppen 232.1.1.1 bzw. 232.2.2.2. Die Multicast-Empfänger für beide Gruppen sind über das ganze Netzwerk verteilt und abonnieren eine nach der anderen, so dass du sehen kannst, wie der Multicast-Baum entsteht.
Abbildung 4-1. Internet-Multicast-Topologie
Hinweis
Alle Hosts werden in einem einzigen IOS XR-Gerät oder einer virtuellen Maschine (VM) namens H simuliert. Genauer gesagt, ist jeder Host ein VRF-lite innerhalb von H.
Ein einfacher Ping reicht aus, um Multicast-Verkehr zu erzeugen. Lassen wir Host H1 ein Paket pro Sekunde an 232.1.1.1 senden, wie im folgenden Beispiel gezeigt:
Beispiel 4-1. Erzeugen von IP-Multicast-Verkehr mithilfe von ping (IOS XR)
RP/0/0/CPU0:H#ping vrf H1 232.1.1.1 source 10.1.1.10
count 100000 timeout 1
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 232.1.1.1, timeout is 0s:
.............[...]
Tipp
Wenn du Multicast-Pakete von einem Junos-Gerät generierst, stelle sicher, dass du die Optionen bypass-routing, interface und ttl ping verwendest.
Der vorherige Ping schlägt fehl. Das ist zu erwarten, da es noch keine Empfänger gibt: Lass den Ping einfach kontinuierlich im Hintergrund laufen.
Als Nächstes wollen wir einige Hosts in dynamische Multicast-Empfänger verwandeln. Hier ist eine Beispielkonfiguration für den Empfang von Host H11 am Gerät H:
Beispiel 4-2. Multicast-Empfänger an H11 (IOS XR)
router igmp vrf H11 interface GigabitEthernet0/0/0/0.1011 join-group 232.1.1.1 10.1.1.10 !
Dadurch beginnt H11, dynamische IGMP-Berichtsnachrichten zu senden und abonniert damit den (S, G) = (10.1.1.10, 232.1.1.1) Fluss. Nehmen wir an, dass auch H3, H4, H22, H33, H34 und H44 (also alle Hosts außer H2) denselben (S, G)-Fluss abonnieren.
Streng genommen ist das vorherige Beispiel unvollständig. Damit IOS XR einen Multicast-Empfänger simulieren kann, muss die Schnittstelle zunächst auf der Ebene multicast-routing eingeschaltet werden.
Hinweis
In Junos ist diese dynamische Empfängeremulation nur im ASM-Modus verfügbar (protocols sap listen <group>). Außerdem unterstützen sowohl Junos als auch IOS XR statische Abonnements - ASM und SSM - an der Empfängerschnittstelle eines LHR.
Signalisierung des Multicast-Baums
Nachdem Multicast-Quellen und -Empfänger aktiv sind, ist es an der Zeit, den Multicast-Baum zu signalisieren. Und dafür müssen CEs und PEs die hier gezeigten Multicast-Protokolle ausführen:
Beispiel 4-3. Multicast-Routing-Konfiguration bei PE1 (Junos)
protocols {
igmp {
interface ge-2/0/2.1011 version 3;
pim {
interface ge-2/0/2.1011;
interface ge-2/0/1.1010;
}}
Eine ähnliche Konfiguration wird auf PE3, CE1, CE2, BR3 und BR4 angewendet. Im Moment sind nur die Zugangsschnittstellen (PE-H, PE-CE und CE-H) konfiguriert.
In der Standardeinstellung von Junos läuft auf einer für PIM konfigurierten Schnittstelle automatisch auch IGMP. Die Standard-IGMP-Version ist 2 und IGMP-Version 3 ist erforderlich, um (S, G)-Meldungen zu verarbeiten.
PIM ist ein Router-zu-Router-Protokoll. Streng genommen braucht die empfangsseitige Schnittstelle ge-2/0/2.1011 also nicht wirklich PIM. IGMP ist auf der Last-Hop-Schnittstelle ausreichend. Allerdings könnte H11 irgendwann ein Multicast-Sender werden. Wie du in diesem Kapitel noch sehen wirst, ist es außerdem sinnvoll, PIM auf allen IP-Multicast-Zugangsschnittstellen des Routers zu aktivieren, um Redundanz und Schleifenerkennung zu ermöglichen.
Der Multicast-Verkehr fließt nun dank des in Abbildung 4-2 dargestellten Protokollaustauschs von Ende zu Ende.
Abbildung 4-2. IGMP und PIM in Aktion (SSM-Modell)
Schauen wir uns die Multicast-Routing-Konfiguration in IOS XR an:
Beispiel 4-4. Multicast-Routing-Konfiguration auf PE2 (IOS XR)
multicast-routing address-family ipv4 interface GigabitEthernet0/0/0/0.1020 enable interface GigabitEthernet0/0/0/1.1022 enable
Die vorherige Konfiguration aktiviert PIM und IGMP auf den angegebenen PE-CE und PE-H Schnittstellen.
IGMP-Signalisierung
Der Multicast-Baum wird in der Upstream-Richtung signalisiert, also von den Empfängern zur Quelle. Beginnen wir mit dem Baumzweig, dessen Blatt H11 ist. Die folgende Aufnahme von PE1 zeigt den Austausch von IGMP-Paketen zwischen PE1 und H11.
Beispiel 4-5. IGMP-Abfrage (von PE1) und Bericht (von H11)
juniper@PE1> monitor traffic interface ge-2/0/2.1011 no-resolve
size 2000 extensive matching igmp
<timestamp> Out
-----original packet-----
00:50:56:8b:32:4a > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100),
length 54: vlan 1011, p 6, ethertype IPv4, (tos 0xc0, ttl 1,
id 20138, offset 0, flags [none], proto: IGMP (2), length: 36,
optlength: 4 ( RA )) 10.1.11.1 > 224.0.0.1: igmp query v3
<timestamp> In
-----original packet-----
IP (tos 0xc0, ttl 1, id 2772, offset 0, flags [none], proto: IGMP (2), length: 76,
optlength: 4 ( RA )) 10.1.11.11 > 224.0.0.22: igmp v3 report [...]
[gaddr 232.1.1.1 is_in { 10.1.1.10 }]
PE1 sendet die IGMP Query an 224.0.0.1, die link-lokale Multicast-Adresse für alle Hosts. H11 antwortet mit einem IGMP-Report an 224.0.0.22, die All-IGMPv3-Router-Adresse. Die Informationen über die (S, G) Abonnements befinden sich in der Nutzlast des IGMP-Reports.
Umgekehrte Pfadweiterleitung
PE1 verarbeitet den IGMP-Report weiter, indem er sich die S-Adresse (10.1.1.10) ansieht und eine Unicast-IP-Routensuche durchführt. Dieser Prozess der Suche nach der Quelle wird Reverse Path Forwarding (RPF) genannt und ist ein zentrales Konzept in der Multicast-Welt.
Beispiel 4-6. RPF bei PE1 (Junos)
juniper@PE1> show route active-path 10.1.1.10
inet.0: 44 destinations, 53 routes (44 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.0/24 *[BGP/170] 02:32:51, MED 100, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.1.0.0 via ge-2/0/1.1010
juniper@PE1> show multicast rpf 10.1.1.10
Multicast RPF table: inet.0 , 44 entries
10.1.1.0/24
Protocol: BGP
Interface: ge-2/0/1.1010
Neighbor: 10.1.0.0
Kurz gesagt: Multicast-Pakete, die an der Nicht-RPF-Schnittstelle ankommen, werden verworfen.
Standardmäßig liefern der Unicast-IP-Routen-Lookup und der RPF-Lookup genau das gleiche Ergebnis. Die Unicast- und die Multicast-Topologie sind dann kongruent. Wenn du möchtest, dass der Unicast- und der Multicast-Verkehr unterschiedlichen Pfaden folgen, ist es auch möglich, die Topologien nicht kongruent zu machen. Dies wird am Ende von Kapitel 5 näher erläutert.
PIM-Signalisierung
CE1 und PE1 tauschen PIM-Helo-Pakete aus, die für 224.0.0.13, die link-lokale Multicast-Adresse aller PIM-Router, bestimmt sind. Durch diesen Austausch werden sie zu PIM-Nachbarn.
Beispiel 4-7. PIM-Nachbarn bei PE1 (Junos)
juniper@PE1> show pim neighbors B = Bidirectional Capable, G = Generation Identifier H = Hello Option Holdtime, L = Hello Option LAN Prune Delay, P = Hello Option DR Priority, T = Tracking Bit Instance: PIM.master Interface IP V Mode Option Uptime Neighbor addr ge-2/0/1.1010 4 2 HPLGT 02:40:25 10.1.0.0
Aus der Sicht von PE1 ist der PIM-Nachbar CE1 auch der RPF-Upstream-Nachbar auf dem Weg zur Quelle. PE1 sendet also eine PIM (S, G) Join-Nachricht an CE1:
Beispiel 4-8. PIM (S, G) Join-Status von PE1 zu CE1 (Junos)
juniper@PE1> show pim join inet detail
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 232.1.1.1
Source: 10.1.1.10
Flags: sparse,spt
Upstream interface: ge-2/0/1.1010
Downstream neighbors:
Interface: ge-2/0/2.1011
Der PIM (S, G) Join ist eigentlich ein PIM Join/Prune-Paket. Diese Nachrichten enthalten eine Join-Liste(Hinzufügen eines Zweigs) und eine Prune-Liste(Entfernen eines Zweigs). In diesem Beispiel ist der Empfänger eingeschaltet, also sendet PE1 das Join/Prune-Paket mit einer leeren Prune-Liste. Ein solches PIM-Join/Prune-Paket wird gemeinhin als PIM-Join bezeichnet. Beispiel 4-9 zeigt das Paket im Detail.
Beispiel 4-9. PIM (S, G) Join-Paket von PE1 nach CE1 (Junos)
juniper@PE1> monitor traffic interface ge-2/0/1.1010 no-resolve
size 2000 detail matching pim
<timestamp> Out IP (tos 0xc0, ttl 1, id 36704, offset 0, no flags,
proto: PIM (103), length: 54) 10.1.0.1 > 224.0.0.13
Join / Prune, cksum 0xd6dc (correct), upstream-neighbor: 10.1.0.0
1 group(s), holdtime: 3m30s
group #1: 232.1.1.1, joined sources: 1, pruned sources: 0
joined source #1: 10.1.1.10(S)
Hinweis
IGMP und PIM sind daher Soft-State-Protokolle. In der IP-Multicast-Welt werden alle Protokollnachrichten (IGMP Query und Report, PIM Hello und Join/Prune usw.) in regelmäßigen Abständen aufgefrischt. Standardmäßig werden PIM Hello und Join/Prune alle 10 bzw. 60 Sekunden aufgefrischt.
Wie du siehst, sind die PIM-Nachrichten als IP-Pakete mit dem Protokoll #103 und der IP-Adresse 224.0.0.13 gekapselt. Da es sich um eine link-local Multicast-IPv4-Adresse handelt, würden alle PIM-Router im selben VLAN das Paket ebenfalls verarbeiten. PE1 hat nur einen Nachbarn in VLAN 1010, aber was wäre, wenn es noch mehr Nachbarn in der Broadcast Domain gäbe? Wie kann PE1 angeben, dass die Nachricht tatsächlich an CE1 gerichtet ist? Er tut dies über das Upstream-Nachbarn-Feld in der PIM-Nutzlast.
Aber warum wird die PIM Join-Nachricht an 224.0.0.13 gesendet, wenn sie nur an CE1 gerichtet ist? PIM in einem LAN ist ein komplexes Thema, und in manchen Fällen ist es wichtig, dass alle benachbarten PIM-Router im LAN alle ausgetauschten Nachrichten sehen können. Dadurch werden unerwünschte Verkehrsblockaden und Doppelungen verhindert.
Multicast-Weiterleitung
CE1 schließlich ist der FHR und muss nach dem Empfang des PIM Join/Prune-Pakets nur noch den Multicast-Verkehr an PE1 weiterleiten, wie im folgenden Beispiel gezeigt:
Beispiel 4-10. Multicast-Weiterleitungsstatus bei CE1 (Junos)
juniper@CE1> show multicast route inet detail
Instance: master Family: INET
Group: 232.1.1.1
Source: 10.1.1.10/32
Upstream interface: ge-0/0/1.1001
Downstream interface list:
ge-0/0/2.1010
Session description: Source specific multicast
Statistics: 0 kBps, 1 pps, 6064 packets
[...]
Hinweis
Diese Multicast-Route ist nicht wirklich eine Route. Sie ist eher als ein Eintrag im Weiterleitungscache zu sehen.
Da die Quelle (H1) und der Empfänger (H11) nun über den Multicast-Baum verbunden sind, ist der Multicast-Ping erfolgreich: Auf jede Echo-Anfrage, die von H1 an 232.1.1.1 gesendet wird, kommt eine Antwort von H11 (10.1.11.11) zurück. Wenn du die Antworten nicht siehst, könnte es sein, dass die Implementierung des dynamischen Empfängers nicht richtig funktioniert: Versuche, sie neu zu starten, indem du die router igmp vrf H11 Konfiguration bei H löschst und neu anwendest (in zwei Commits).
Klassischer Internet-Multicast - Verbindung von Multicast-Inseln über den Kern
Der Baum hat jetzt eine Wurzel (H1), ein Blatt (H11) und einen einzigen Zweig, der sie verbindet.
Ein-Hop-Transit durch den Kern (PE1-PE2)
Fügen wir dem Baum zwei weitere Blätter hinzu:
-
H22 sendet einen IGMP (S, G) Report an PE2.
-
H2 sendet einen IGMP (S, G) Report an CE2, der einen PIM (S, G) Join an PE2 sendet.
Als Ergebnis hat PE2 den im folgenden Beispiel dargestellten Multicast (S, G) Status:
Beispiel 4-11. Multicast RIB (IOS XR)
RP/0/0/CPU0:PE2#show mrib route 232.1.1.1
[...]
IP Multicast Routing Information Base
(10.1.1.10,232.1.1.1) RPF nbr: 0.0.0.0 Flags: RPF
Up: 01:26:05
Outgoing Interface List
GigabitEthernet0/0/0/0.1020 Flags: F NS, Up: 01:26:00
GigabitEthernet0/0/0/1.1022 Flags: F NS LI, Up: 01:26:05
Der (S, G)-Eintrag ist in der Multicast-RIB (MRIB) von PE2 installiert, aber leider ist der RPF-Nachbar 0.0.0.0. Mit anderen Worten: RPF ist fehlgeschlagen, wie in Beispiel 4-12 gezeigt.
Beispiel 4-12. Fehlgeschlagenes RPF bei PE2 (IOS XR)
RP/0/0/CPU0:PE2#show pim rpf
Table: IPv4-Unicast-default
* 10.1.1.10/32 [200/100]
via Null with rpf neighbor 0.0.0.0
PE2 hat eine gültige BGP-Route zu 10.1.1.10, und sein BGP-Nächster Hop (172.16.0.11) ist über die Schnittstelle Gi 0/0/0/2 erreichbar. Warum schlägt RPF fehl? Weil PIM im Core nicht aktiviert ist, so dass PE1 und PE2 keine PIM-Nachbarn voneinander sind.
In diesem klassischen MPLS-freien Beispiel ist der nächste Schritt die Aktivierung von PIM auf den Core-Schnittstellen. Wenn dies geschehen ist, sind die neuen Empfänger erfolgreich mit der Quelle verbunden.
Beispiel 4-13. Erfolgreiches RPF bei PE2 (IOS XR)
RP/0/0/CPU0:PE2#show pim neighbor GigabitEthernet 0/0/0/2
[...]
Neighbor Address Interface Uptime Expires DR pri
10.0.0.0 GigabitEthernet0/0/0/2 00:00:20 00:01:25 1
10.0.0.1* GigabitEthernet0/0/0/2 00:00:20 00:01:26 1 (DR)
RP/0/0/CPU0:PE2#show pim rpf
Table: IPv4-Unicast-default
* 10.1.1.10/32 [200/100]
via GigabitEthernet0/0/0/2 with rpf neighbor 10.0.0.0
RP/0/0/CPU0:PE2#show mrib route 232.1.1.1
[...]
(10.1.1.10,232.1.1.1) RPF nbr: 10.0.0.0 Flags: RPF
Up: 01:50:26
Incoming Interface List
GigabitEthernet0/0/0/2 Flags: A, Up: 00:01:13
Outgoing Interface List
GigabitEthernet0/0/0/0.1020 Flags: F NS, Up: 01:50:21
GigabitEthernet0/0/0/1.1022 Flags: F NS LI, Up: 01:50:26
Zu diesem Zeitpunkt hat der Multicast-Baum drei Blätter (H11, H22 und H2), die mit der Wurzel (H1) verbunden sind, sodass der Multicast-Ping drei Antworten pro Anfrage erhält, wie in Beispiel 4-14 gezeigt.
Beispiel 4-14. Erfolgreicher Multicast-Ping mit drei Empfängern
RP/0/0/CPU0:H#ping vrf H1 232.1.1.1 source 10.1.1.10 count 100000 Type escape sequence to abort. Sending 100000, 100-byte ICMP Echos to 232.1.1.1, timeout is 2s: Reply to request 0 from 10.1.11.11, 1 ms Reply to request 0 from 10.1.2.20, 1 ms Reply to request 0 from 10.1.22.22, 1 ms Reply to request 1 from 10.1.11.11, 9 ms Reply to request 1 from 10.1.2.20, 9 ms Reply to request 1 from 10.1.22.22, 1 ms [...]
Eine einzelne Kopie jedes Pakets durchläuft jede Verbindung, einschließlich der Verbindung PE1→PE2. Es gibt zwei Replikationsstufen: eine bei PE1 und eine bei PE2.
In Bezug auf den Fluss (10.1.1.10, 232.1.1.1) werden PE1 und PE2 allgemein als Sender-PE bzw. Empfänger-PE bezeichnet. Diese Rolle ist abhängig vom jeweiligen Datenfluss: Ein bestimmtes PE kann für einige Datenflüsse ein Sender-PE und für andere ein Empfänger-PE sein. PE1 wird nicht als Empfänger-PE betrachtet, auch wenn es einen lokalen Empfänger (H11) hat, da der Datenstrom nicht aus dem Kernnetz kommt.
Hinweis
In diesem Kapitel und in Kapitel 5 sind die folgenden Begriffe gleichbedeutend: Root PE, Ingress PE und Sender PE. Ebenso sind diese Begriffe Synonyme: Leaf PE, Egress PE und Receiver PE.
Zwei-Hop-Transit durch den Kern (PE1-P1-PE3)
Lass uns ein weiteres Blatt hinzufügen: H33. Der LHR ist nun PE3, der als PE vollständige Einsicht in die BGP-Routen des Kunden hat. Daher führt PE3 erfolgreich einen RPF-Lookup in Richtung der Quelle (10.1.1.10) durch und sendet einen PIM (S, G) Join an seinen Upstream-PIM-Nachbarn: P1. So weit, so gut. Allerdings hat P1 als reiner P-Router keine Sichtbarkeit der BGP-Routen, so dass ihm die RPF-Suche nach der Multicast-Quelle fehlt:
Beispiel 4-15. Fehlgeschlagenes RPF an P1 (Junos)
juniper@P1> show route 10.1.1.10
inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 2w2d 05:08:19
Discard
juniper@P1> show pim join inet
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 232.1.1.1
Source: 10.1.1.10
Flags: sparse,spt
Upstream interface: unknown (no neighbor)
Aber wie ist es den Empfängern H2 und H22 gelungen, dem Multicast-Baum mit der Wurzel H1 beizutreten? Weil die Multicast-Zweige, die die Wurzel mit H2 und H22 verbinden, keine P-Router durchqueren. Umgekehrt kann die Verbindung zwischen H1 und H33 nur über einen P-Router erfolgen; daher kann der Multicast-Zweig für H33 nicht durchgängig gemeldet werden.
Wie kannst du dieses Problem lösen? Eigentlich gibt es viele Möglichkeiten - wahrscheinlich zu viele! Schauen wir uns die verschiedenen qualitativen Ansätze für diese Herausforderung an.
Signalisierung des Join-Status zwischen entfernten PEs
Ein RPF-Ausfall in einem Transit-Router ist ein sehr ähnliches Problem wie das klassische Problem, das MPLS in Kapitel 1 motivierte. Allerdings hat es keine Auswirkungen auf die Weiterleitung von Unicast-Datenpaketen, sondern auf die Weitergabe von PIM (S, G) Join-Status. Die Quelle S ist ein externer Unicast-Präfix, der zu einem anderen AS gehört und nicht über den IGP erreichbar ist. In Kapitel 1 wurden mehrere Möglichkeiten vorgeschlagen, das Unicast-Weiterleitungsproblem zu lösen (ohne die externen Routen in den IGP umzuverteilen), und alle bestanden darin, die Nutzdatenpakete zu tunneln. Im Fall von Multicast ist es jedoch der PIM (S, G) Join (ein Kontrollpaket ), der getunnelt werden muss, und nicht der Benutzerdatenverkehr. Dies eröffnet eine Vielzahl von Gestaltungsmöglichkeiten. Im Folgenden werden einige mögliche Strategien zur Signalisierung des Join-Status zwischen entfernten PEs vorgestellt.
Hinweis
Dieser Abschnitt befasst sich mit den Möglichkeiten, RPF-Fehler auf Transit-Routern zu beheben. Die Diskussion ist unabhängig von dem Dienst, der entweder Global Internet Multicast oder Multicast VPN (MVPN) sein kann. In der Praxis werden einige der folgenden Ansätze nur für MVPN umgesetzt.
Carrier IP Multicast Flavors
Gehen wir also von klassischem IP Multicast zu Carrier IP Multicast über, das über Tunneling-Fähigkeiten verfügt, um die Herausforderung des Multihop-Core zu lösen.
Tabelle 4-1 listet sechs der vielen Dimensionen auf, die das Multicast-Universum hat.
| Service | Global Internet Multicast (S1), Multicast VPN (S2) |
| C-Multicast Architektur | Keine (A0), Direkt Inter-PE (A1), Hop-by-Hop Inter-PE (A2), Out-of-Band (A3) |
| C-Multicast Inter-PE Signalisierungsprotokoll | Keine (C0), PIM (C1), LDP (C2), BGP (C3) |
| P-Tunnel-Verkapselung | Keine (E0), GRE over IP Unicast (E1), GRE over IP Multicast (E2), MPLS (E3) |
| P-Tunnel Signalisierungsprotokoll | Keine (T0), PIM (T1), LDP (T2), RSVP-TE (T3), Routing-Protokoll mit MPLS-Erweiterungen (T4) |
| P-Tunnel Layout | Keine (Y0), P2P (Y1), MP2P (Y2), P2MP (Y3), MP2MP (Y4) |
Hinweis
Die Präfixe C- und P- stehen für Kunde bzw. Anbieter. Das klassische IP-Multicast-Modell ist ein reines C-Multicast-Modell. Umgekehrt haben Carrier IP Multicast Modelle auch P- Dimensionen.
Jede Carrier-Multicast-Variante hat mindestens ein Element aus jeder Dimension. Wie du dir vorstellen kannst, sind nicht alle Kombinationen sinnvoll und jeder Anbieter unterstützt nur eine Teilmenge davon. Obwohl sich dieses Buch auf die Kombinationen konzentriert, die sowohl von Junos als auch von IOS XR unterstützt werden, werden der Vollständigkeit halber auch die nicht interoperablen Kombinationen kurz besprochen.
Tipp
Drucke eine Kopie von Tabelle 4-1 aus und bewahre sie als Referenz auf, wenn du die Multicast-Kapitel in diesem Buch liest.
Es gibt zwei Arten von Diensten, je nachdem, ob das Multicast-Routing in der globalen Routing-Tabelle oder in einer VRF durchgeführt wird. Dieses Kapitel konzentriert sich auf globale Dienste, greift aber taktisch einige Beispiele auf, die nur für Multicast VPN implementiert sind.
Dieses Buch behandelt drei C-Multicast-Architekturen:
-
Im Direct Inter-PE (A1)-Modell bauen PE1 und PE3 eine C-PIM-Ajacency über einen bidirektionalen Tunnel auf. Dieser Tunnel transportiert Kontroll- und Daten-C-Multicast-Pakete.
-
Im Hop-by-Hop-Modell (A2) wandelt PE3 den Upstream-C-PIM-Join-Status in eine andere Nachricht um, die P1 verarbeiten und an PE1 senden kann, der sie seinerseits in den C-PIM-Join-Status umwandelt. Diese Architektur wird auch als In-Band- oder Proxy-Modell bezeichnet.
-
Im Out-of-Band-Modell (A3) signalisiert PE3 den C-Join-Status an PE1 mit einem nicht getunnelten IP-Protokoll. Wie im A1-Modell übernimmt P1 keine Rolle in der C-Multicast-Kontrollebene.
Mach dir keine Sorgen, wenn diese Definitionen noch nicht viel Sinn ergeben. Behalte sie als Referenz und sie sollten beim Weiterlesen viel klarer werden.
Hinweis
Das klassische IP-Multicast-Modell (siehe Tabelle 4-1) lautet wie folgt: S1, A2, C1, E0, T0, Y0.
Direkte Inter-PE Modell-PE-zu-PE PIM Adjacencies über Unicast IP Tunnels
In den Begriffen der Tabelle 4-1 ist dieses Modell A1, C1, E1, T0, Y1. Es wird sowohl von Junos als auch von IOS XR für S1 und S2 implementiert.
Dieser Ansatz erfordert einen Unicast-IP-Tunnel (z. B. auf GRE-Basis) zwischen jedem Paar PEs. Es gibt nur eine PIM-Instanz, die nur auf den PEs läuft. Dieser PIM-Kontext wird oft als C-PIM bezeichnet.
Konzentrieren wir uns auf die folgenden Tunnel: PE1→PE3 und PE3→PE1. PE1 und PE3 sehen diese beiden GRE-Tunnel als eine Punkt-zu-Punkt-Schnittstelle, die die beiden IP-Multicast-Inseln auf transparente Weise miteinander verbindet. PE1 und PE3 tauschen zwei Arten von Multicast-Verkehr über die GRE-Tunnel aus:
-
Kontrollpakete wie PIM Hello oder (S, G) Join sind für 224.0.0.13 bestimmt, eine Multicast-Adresse (auch wenn sie link-local ist, da der Link der GRE-Tunnel ist)
-
Datenpakete des aktiven Multicast-Benutzerstroms (10.1.1.10→232.1.1.1)
Aus Sicht der GRE-Tunnel gibt es keine Unterscheidung zwischen Control und Data. Wenn PE1 ein Multicast-Paket (Control oder Data) über den GRE-Tunnel PE1→PE3 an PE3 senden muss, fügt er die folgenden Header hinzu:
-
GRE-Header mit Protokolltyp = 0x0800 (IPv4).
-
IPv4-Header mit (Quelle, Ziel) = (172.16.0.11, 172.16.0.33). Mit anderen Worten: Die Endpunkte des GRE-Tunnels sind die primären Loopback-Adressen von PE1 und PE3.
Nachdem PE3 die getunnelten Pakete empfangen hat, entfernt er diese beiden Header. Das Ergebnis ist das ursprüngliche (Kontroll- oder Daten-) Multicast-Paket, das PE1 ursprünglich in den Tunnel geschickt hatte. Die gleiche Logik gilt auch für die Pakete, die in umgekehrter Richtung unterwegs sind: von PE3 zu PE1.
Wie gut ist dieses Modell? Obwohl du es taktisch für begrenzte oder vorübergehende Einsätze nutzen kannst, kannst du es nicht als modernen und skalierbaren Ansatz betrachten, und zwar aus denselben Gründen, warum das Internet nicht über IP-Tunnel läuft. Das Modell unterliegt außerdem den folgenden Multicast-spezifischen Einschränkungen:
-
Wenn PE1 zwei Core-Uplink-Schnittstellen hat, aber ein Multicast-Datenpaket an 1.000 entfernte PEs senden muss, muss PE1 das Paket 999 Mal replizieren und jede der 1.000 Kopien in einen anderen Unicast-GRE-Tunnel senden. Diese Technik wird Ingress Replication genannt und verursacht einen ineffizienten Bandbreitenverbrauch. Wenn die Multicast-Datenpakete in den Kern gesendet werden, geht der Hauptvorteil von Multicast (effizienter Replikationsbaum) einfach verloren.
-
Die PEs bauen PIM-Adjacencies über die GRE-Tunnel auf. Der Soft-State-Charakter von PIM führt dazu, dass alle PIM-Pakete (Hello, Join/Prune usw.) mindestens einmal pro Minute aktualisiert werden müssen. Dieses Hintergrundrauschen belastet die Kontrollebene unnötig. Denke einen Moment darüber nach, wie die PEs Unicast-Routen austauschen: ein BGP-Update über eine zuverlässige TCP-Verbindung, und das war's (eine regelmäßige Aktualisierung der Route ist nicht erforderlich). In diesem Sinne ist das Multicast PE-to-PE Protokoll (PIM) weniger skalierbar als das Unicast Protokoll (BGP).
Wenn Unicast-GRE-Tunnel ins Multicast-Spiel kommen, muss sichergestellt werden, dass nur der Kunden-Multicast-Verkehr durch sie läuft. Der Unicast-Verkehr des Kunden sollte über MPLS laufen. Diese Anforderung der Nichtkongruenz wird am Ende von Kapitel 5 näher analysiert.
Direkte Inter-PE Modell-PE-zu-PE PIM Adjacencies über Multicast IP Tunnels
In den Begriffen der Tabelle 4-1 ist dieses Modell A1, C1, E2, T1, [Y3, Y4]. Es wird sowohl von Junos als auch von IOS XR nur für S2 implementiert.
Er ist im historischen RFC 6037 - Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs beschrieben. Die meisten Leute nennen ihn draft Rosen, weil draft-rosen-vpn-mcast der Vorläufer von RFC 6037 war.
Im Rosen-Entwurf - der nur für IP-VPNs implementiert wurde - ist jeder PE (z. B. PE1) die Wurzel von mindestens einem Multicast-GRE-Tunnel pro VPN, genannt Multicast Distribution Tree (MDT). Warum mindestens einen und nicht nur einen? Überspringen wir diese Frage für einen Moment und stellen uns vor, dass jeder PE die Wurzel eines MDT ist, dem Standard-MDT.
Dieses Modell erfordert zwei verschiedene Instanzen von PIM: C-PIM (wobei C für Customer steht) und P-PIM (wobei P für Provider steht). Beachte, dass C- und P- nur unterschiedliche Kontexte darstellen. PIM wird auf die gleiche Art und Weise implementiert - es handelt sich schließlich um dasselbe Protokoll:
-
C-PIM ist die Dienstinstanz von PIM und läuft an den Kanten: PE-to-CE und PE-to-PE (letzteres über GRE-Tunnel). Er wird verwendet, um den Endnutzern Multicast-Bäume zu signalisieren, in diesem Beispiel (10.1.1.10→232.1.1.1). Bisher war der in diesem Kapitel verwendete PIM-Kontext immer C-PIM. Aus der Sicht von C-PIM ist der Core nur eine LAN-Schnittstelle, die alle PEs miteinander verbindet. Die PEs bauen über den Core einfach PIM-Adjazenzen auf, wie sie es auch über jede andere Schnittstelle tun würden.
-
P-PIM ist die Transportinstanz von PIM und läuft nur auf den Core-Links. Er wird für den Aufbau von Multicast-GRE-Provider-Tunneln oder P-Tunneln verwendet. Der beliebteste P-PIM-Modus ist SSM. Einer der Vorteile von SSM ist, dass es die Zuweisung von Providergruppen (P-G) viel einfacher macht. Nehmen wir an, dass PE1 und PE3 die Wurzeln der P-Tunnel (172.16.0.11→P-G1) bzw. (172.16.0.33→P-G3) sind. P-G1 und P-G3 können unterschiedlich sein, sie können aber auch identisch sein. Solange die Quellen unterschiedlich sind, bleiben die Multicast-Bäume bei SSM getrennt, auch wenn G1 gleich G3 ist. Das ist besonders wichtig für Daten-MDTs, die später in diesem Abschnitt besprochen werden.
Hinweis
P-PIM läuft auf der globalen Routing-Instanz (Standard-VRF), während C-PIM auf einer (nicht standardmäßigen) VRF läuft. Der Dienst wird also im Rahmen eines VPNs bereitgestellt. Und es kann der Internet-Multicast-Dienst sein, solange er innerhalb eines Internet-VPNs bereitgestellt wird.
Ein Blick zurück auf Tabelle 4-1 zeigt, dass P-PIM SSM Y3 und P-PIM ASM Y4 entspricht.
Nehmen wir an, dass jeder der PEs im Core die Root eines P-Tunnels ist, dessen SSM P-Group 232.0.0.100 ist - der Einfachheit halber dieselbe, obwohl es auch eine andere P-Group pro Root sein könnte. PE1 empfängt die folgenden P-PIM (S1, G) Joins von seinen P-PIM-Nachbarn, wobei S1 = 172.16.0.11 und G = 232.0.0.1:
-
PE2 sendet einen (S1, G) Join direkt an PE1.
-
PE3 sendet ein (S1, G) Join-Paket an P1 und P1 sendet dann ein (S1, G) Join-Paket an PE1.
-
PE4 sendet einen (S1, G) Join an P2, woraufhin P2 einen (S1, G) Join an P1 sendet, der bereits (S1, G) Join-Pakete an PE1 sendet.
Auf diese Weise ist PE1 die Wurzel eines Standard-MDT, dessen Blätter PE2, PE3 und PE4 sind.
Ebenso ist PE1 auch ein Blatt der Standard-MDTs der entfernten PEs. PE1 sendet die folgenden P-PIM Joins: (172.16.0.22, 232.0.0.100) an PE2, (172.16.0.33, 232.0.0.100) an P1 auf dem Weg zu PE3 und (172.16.0.44, 232.0.0.100) an P1 auf dem Weg zu PE4.
Durch diesen Prozess wird ein LAN-ähnliches Overlay aufgebaut, das alle PEs miteinander verbindet. PEs tauschen zwei Arten von C-Multicast-Verkehr über das Standard-MDT aus:
-
Kontrollpakete wie C-PIM Hello oder C-PIM (S, G) Join sind für 224.0.0.13 bestimmt, eine Multicast-Adresse (auch wenn sie link-local ist)
-
Datenpakete des aktiven C-Multicast-Benutzerstroms (10.1.1.10→232.1.1.1)
Aus der Sicht des Standard-MDT gibt es keine Unterscheidung zwischen Control und Data. Wenn PE1 ein C-Multicast-Paket (Control oder Data) über das Standard-MDT an seine Nachbarn senden muss, fügt PE1 die folgenden Header hinzu:
-
GRE-Header mit Protokolltyp = 0x0800 (IPv4)
-
IPv4-Header mit (Quelle, Ziel) = (172.16.0.11, 232.0.0.100)
Die getunnelten Pakete kommen bei allen anderen PEs an, die die beiden Kopfzeilen entfernen. Das Ergebnis ist das ursprüngliche (Kontroll- oder Daten-) C-Multicast-Paket, das PE1 ursprünglich in das Standard-MDT eingegeben hatte.
PE1 ist die Wurzel seines Standard-MDTs und kann optional die Wurzel eines oder mehrerer Daten-MDTs sein. Was ist ein Daten-MDT? Angenommen, PE1 ist der Sender-PE eines C-Multicast-Streams (C-S, C-G) mit hoher Bandbreite, und von 1.000 entfernten PEs haben nur 10 einen Downstream-Empfänger für (C-S, C-G). Aus Gründen der Bandbreiteneffizienz ist es sinnvoll, ein neues MDT einzurichten, das nur für den Transport dieses bestimmten (C-S, C-G) zuständig ist. Dieses Daten-MDT hätte nur 10 Blätter: die 10 Empfänger-PEs, die den Datenstrom empfangen möchten.
Hinweis
Standard- und Daten-MDTs werden oft als Inklusiv- bzw. Selektivbäume bezeichnet. Inclusive Trees schließen alle möglichen Blätter ein, während Selective Trees eine bestimmte Teilmenge der Blätter auswählen.
Beachte, dass die bisher beschriebenen Protokolle (C-PIM, P-PIM SSM und GRE) in der Regel nicht ausreichen, um die Blätter der einzelnen MDTs automatisch zu erkennen. Es werden zusätzliche Protokolle benötigt und eingesetzt, um diese Autodiscovery-Funktion (AD) zu erreichen. Welche Protokolle? Die Antwort hängt von der Art der Implementierung ab. In der Terminologie von Cisco (zum Zeitpunkt dieses Artikels):
- Rosen GRE
- Für Default MDT mit P-PIM Any Source Multicast (ASM) sind keine zusätzlichen Protokolle erforderlich, da die P-Source AD-Funktion von P-PIM übernommen wird (die Quellensuche in PIM ASM wird in Kapitel 15 behandelt). Die Daten-MDTs werden mit User Datagram Protocol (UDP)-Paketen signalisiert, die im Default-MDT ausgetauscht werden.
- Rosen GRE mit BGP AD
- Standard-MDT mit P-PIM SSM erfordert eine neue Multiprotokoll-BGP-Adressfamilie für (P-S, P-G) AD. Daten-MDTs können entweder über BGP oder UDP signalisiert werden.
Hinweis
Die Cisco-Dokumentation ordnet jedem Carrier Multicast Flavor eine Profilnummer zu. Zum Beispiel ist Rosen GRE das MVPN-Profil 0 und Rosen GRE mit BGP AD das MVPN-Profil 3.
Weitere Details zur GRE-Implementierung und Interoperabilität von Rosen liegen außerhalb des Rahmens dieses Buches, da wir uns auf MPLS und nicht auf GRE konzentrieren. Seien wir fair: Der Rosen-Entwurf ist seit zwei Jahrzehnten die de facto L3 Multicast VPN-Technologie und hat die Geschäftsanforderungen vieler Kunden erfüllt. Aber im Laufe der Zeit wird sie durch Modelle der nächsten Generation ersetzt.
Werfen wir abschließend noch einen Blick auf die Vor- und Nachteile dieses Modells:
-
Pro: Ein MDT ist eigentlich ein (Provider-)Multicast-Baum, der die effiziente Replikation von Multicast-Daten ermöglicht. Wenn PE1 zwei Core-Uplink-Schnittstellen hat und ein Multicast-Datenpaket an 1.000 entfernte PEs senden muss, repliziert PE1 das Paket höchstens einmal und sendet höchstens eine Kopie des Pakets aus jedem Core-Uplink. Außerdem implementiert dieses Modell Daten-MDT für eine noch effizientere Verteilung.
-
Nachteil: C-PIM in einem LAN ist komplex und laut. Wenn PE3 einen C-PIM Join an PE1 sendet, erhalten alle anderen PEs im VPN diese Nachricht und überprüfen sie. Wie du bereits gesehen hast, werden PIM Join/Prune-Nachrichten an 224.0.0.13 gesendet und regelmäßig aufgefrischt. Das macht die Lösung in der Kontrollebene weniger skalierbar und robust.
-
Schließlich bietet dieses Modell nicht die volle Flexibilität der Forwarding-Plane. Es sind zwei P-Tunnel-Typen verfügbar: PIM/GRE und MP2MP mLDP (siehe nächste Seite). Keiner von ihnen kann von MPLS-Funktionen wie Traffic Engineering profitieren.
Warnung
Bevor wir weitermachen, entfernen wir zunächst PIM von allen Core-Links, denn P-PIM wird nicht mehr benötigt. Von nun an ist das Kernnetz MPLS-Gebiet!
Direkte Inter-PE Modell-PE-PE PIM Adjacencies über MPLS Label-Switched Paths
In den Begriffen der Tabelle 4-1 ist dieses Modell A1, C2, E3, T2, Y4. Es wird nur von IOS XR und nur für S2 implementiert.
PIM ist für bidirektionale Verbindungen ausgelegt. Wenn R1 einen PIM-Join über Link L an R2 sendet, muss der Multicast-Verkehr von R2 zu R1 über denselben Link L fließen. MPLS Label-Switched Paths (LSPs) sind jedoch unidirektional - oder doch nicht? Tatsächlich gibt es einen Typ von LSP, der bidirektional ist. Er heißt Multipoint-to-Multipoint LSP (MP2MP LSP) und ist einer der beiden LSP-Typen, die in RFC 6388 - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths beschrieben sind. Mit einer dieser Erweiterungen (P2MP oder MP2MP) wird LDP oft als Multipoint LDP (mLDP) bezeichnet. Um den RFC zu paraphrasieren:
Ein MP2MP-LSP [...] besteht aus einem einzigen Root-Knoten, null oder mehr Transitknoten und einem oder mehreren Leaf-LSRs, die gleichermaßen als Ingress- oder Egress-LSR fungieren.
Kurz gesagt haben MP2MP-LSPs einen zentralen (sogenannten Root-)LSR, an dem alle Zweige zusammenlaufen. Die PEs sitzen an den Blättern und tauschen mit ihren LDP-Nachbarn zwei Arten von Multipoint (MP) FEC Label Mappings aus: up, für den Nutzerverkehr, der von einem Blatt zum Root fließt, und down, für den Nutzerverkehr, der vom Root zu einem Blatt fließt. Aus der Sicht des Dienstes emuliert das MP2MP LSP ein bidirektionales LAN, das die PEs miteinander verbindet, und zwar ohne Lernmechanismus, um Flooding zu reduzieren. Jedes Paket, das in ein MP2MP LSP geschickt wird, erreicht alle Blätter. In diesem Sinne ist der MP2MP LSP ein Default MDT oder Inclusive Tree.
Zurzeit nennt Cisco dieses Modell Rosen mLDP, da es viele Ähnlichkeiten mit Rosen GRE aufweist. In der Cisco-Dokumentation wird der Name Rosen verwendet, um eine Vielzahl von MVPN-Profilen zu kennzeichnen. Einige von ihnen ähneln dem Draft Rosen(draft-rosen-vpn-mcast), andere hingegen nicht. Dieses Tag gibt also keinen wirklichen Hinweis auf die zugrunde liegende Technologie.
Sowohl bei Rosen GRE als auch bei Rosen mLDP bauen die PEs C-PIM Adjazenzen über das Default MDT auf. Daher sind sie beide auf die Implementierung von C-PIM in einem LAN angewiesen. Und nicht zuletzt benötigen beide zusätzliche Mechanismen, um die Blätter der Default und/oder Data MDTs automatisch zu erkennen.
Hinweis
Daten-MDTs sind P2MP, im Gegensatz zu den Standard-MDTs, die MP2MP sind.
Der Hauptunterschied zwischen Rosen GRE und Rosen mLDP liegt in der Art und Weise, wie die C-PIM-Nachrichten und C-Multicast-Pakete über das Default MDT ausgetauscht werden: über IP- bzw. MPLS-Tunnel. Bei Rosen mLDP werden die C-PIM-Joins in MPLS gekapselt und fließen in die entgegengesetzte Richtung wie der C-Multicast-Verkehr. Du kannst Rosen GRE mit Rosen mLDP vergleichen, indem du P-PIM durch LDP und GRE durch MPLS ersetzst.
Weder Rosen GRE noch Rosen mLDP werden in diesem Buch weiter behandelt. Das erste Modell basiert nicht auf MPLS, und das zweite ist derzeit nicht interoperabel. Beide Modelle basieren auf der Einrichtung von PE-PE C-PIM Adjazenzen über den Kern.
Jenseits des direkten Inter-PE-Modells - keine Einrichtung von PE-PE PIM-Adjacencies
Die Bewertung früherer Modelle zeigt, dass das Tunneln von C-PIM zwischen PEs nicht besonders skalierbar ist. Anfang der 2000er Jahre begannen Juniper und Cisco damit, neue Rahmenwerke für die Signalisierung und den Transport von Multicast-Verkehr über ein MPLS-Backbone zu definieren. Damals wurden diese neuen Paradigmen als Next-Generation oder NG bezeichnet, aber heute ist es einfach die neueste Technologie. Auch wenn viele es weiterhin NG nennen, dieses Buch tut das nicht.
Diese modernen Frameworks lassen PIM nur noch auf PE-CE- und PE-Host-Verbindungen laufen. Allerdings bauen die PEs keine C-PIM-Adjazenzen mehr untereinander auf. Stattdessen signalisiert ein skalierbares Carrier-Class-Protokoll C-Multicast-Informationen zwischen den PEs. Grundsätzlich gibt es zwei solcher Protokolle: BGP und LDP. Beide sind in der Lage, den C-Multicast-Status zu kodieren.
Out-of-Band-Modell
Wenn BGP verwendet wird, um den C-Multicast Join-Status zu signalisieren, sind die Service- und die Transportebene lose gekoppelt. Dank bestimmter Techniken, die in Kapitel 5 beschrieben werden, unterstützt BGP praktisch alle in Tabelle 4-1 aufgeführten dynamischen P-Tunnel-Technologien.
Betrachten wir den besonderen Fall, in dem LDP das P-Tunnel-Signalisierungsprotokoll ist. In den Begriffen der Tabelle 4-1 lautet dieses Modell A3, C3, E3, T2, [Y2, Y3, Y4]. Die Aufgabe von LDP besteht in diesem Fall darin, die LSPs aufzubauen, die die Multicast-Daten transportieren. BGP kümmert sich vollständig um die C-Multicast-Signalisierung von PE zu PE. In diesem Sinne ist die Dienstebene (BGP) nicht eng an die Transportebene (hier LDP) gekoppelt. BGP führt die Out-of-Band C-Multicast-Signalisierung durch. Dieses Modell bietet eine große Flexibilität bei der Wahl des P-Tunnels und stützt sich auf einen umfangreichen Signalisierungsmechanismus, der später in Kapitel 5 behandelt wird.
Hop-by-Hop Inter-PE Modell
Wenn LDP (anstelle von BGP) verwendet wird, um den C-Multicast Join-Status zu signalisieren, sind die Service- und die Transportebene eng miteinander gekoppelt: LDP signalisiert beide gleichzeitig, dank spezieller FEC-Typen. Dies ist eine In-Band C-Multicast-Signalisierung, d.h. die Dienst- und die Transportebene werden miteinander vermischt.
Dieses Modell ist weniger flexibel und skalierbar als die Out-of-Band-Architektur, aber auch einfacher zu verstehen. Deshalb verwenden wir es für das erste Multicast over MPLS-Beispiel in diesem Buch. Endlich!
Internet-Multicast über MPLS mit In-Band-Multipoint-LDP-Signalisierung
In diesem Abschnitt wird der P2MP-Teil von RFC 6826 - Multipoint LDP In-Band Signaling for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths erläutert.
In den Begriffen der Tabelle 4-1 ist dieses Modell S1, A2, C2, E3, T2, Y3. In der Dokumentation von Cisco wird es Global Inband genannt. Es ist die einfachste Art, dynamisches Multicast über MPLS einzusetzen. Obwohl es einfach zu bedienen und einzurichten ist, hat diese Carrier-Multicast-Variante auch einige Einschränkungen:
-
Es erzeugt einen C-Multicast-Label-Status auf den Core-LSRs, wodurch einer der Hauptvorteile von MPLS zunichte gemacht wird: die Reduzierung des Status, indem keine Kundenrouten an die P-Router weitergegeben werden.
-
Es hat keine P-Tunnel-Flexibilität (es ist nur auf LDP beschränkt).
-
Es unterstützt noch keine Inclusive Tunnels (Standard-MDTs).
Mehrpunkt-LDP
Multipoint LDP (mLDP) ist kein neues Protokoll, sondern eine Reihe von LDP-Erweiterungen und -Verfahren. PE1 und PE2 bauen eine einzige LDP-Sitzung auf und nutzen sie, um Label-Mappings für alle FEC-Elemente auszutauschen. Dazu gehören die guten alten IPv4-Präfixe (wie in einfachem LDP) und zusätzlich die Multipoint-FEC-Elemente, die alle in derselben LDP-Sitzung bekannt gegeben werden.
Tipp
Verwende das Policy Framework in Junos und IOS XR, um auszuwählen, welche FECs du über die LDP-Sitzung ankündigen möchtest. Du möchtest LDP zum Beispiel nur für P2MP-FECs verwenden, nicht aber für IPv4-Unicast-FECs.
LDP wird mLDP genannt, wenn die Nachbarn spezielle MP-Fähigkeiten aushandeln. Genauer gesagt kann ein Nachbar, der die P2MP-Fähigkeit (0x0508) unterstützt, P2MP-FEC-Elemente über eine (m)LDP-Sitzung signalisieren.
Beginnen wir mit einem Szenario, in dem LDP auf allen Schnittstellen konfiguriert ist (siehe Kapitel 2). Beispiel 4-16 zeigt die inkrementelle mLDP-Konfiguration in Junos.
Beispiel 4-16. mLDP-Konfiguration (Junos)
protocols {
ldp p2mp;
}
Beispiel 4-17 zeigt die Konfiguration in IOS XR.
Beispiel 4-17. mLDP-Konfiguration (IOS XR)
mpls ldp mldp
Hinweis
Sowohl in Junos als auch in IOS XR ist es eine gute Praxis, mLDP make-before-break zu konfigurieren, um den Verkehrsverlust bei der Wiederherstellung der Verbindung zu minimieren. Die Details liegen außerhalb des Rahmens dieses Buches.
Als Ergebnis dieser Konfiguration handeln die LDP-Peers die P2MP-Fähigkeit aus. Schauen wir uns die Verhandlung zwischen PE1 (Junos) und PE2 (IOS XR) an: Beide haben die P2MP-Fähigkeit gemeinsam:
Beispiel 4-18. LDP-Fähigkeitsaushandlung (Junos und IOS XR)
juniper@PE1> show ldp session 172.16.0.22 detail
[...]
Capabilities advertised: p2mp, make-before-break
Capabilities received: p2mp
RP/0/0/CPU0:PE2#show mpls ldp neighbor 172.16.0.11:0 detail
[...]
Capabilities:
Sent:
0x508 (MP: Point-to-Multipoint (P2MP))
0x509 (MP: Multipoint-to-Multipoint (MP2MP))
0x50b (Typed Wildcard FEC)
Received:
0x508 (MP: Point-to-Multipoint (P2MP))
Im Moment signalisiert die LDP-Sitzung nur die klassischen IPv4-Präfix-FEC-Elemente. Momentan werden in den LDP-Sitzungen keine P2MP-FEC-Elemente angekündigt, weil es noch keinen Dienst gibt, der ein Multipoint-LSP erfordert. Das wird sich bald ändern.
Hinweis
Du musst mLDP auf allen LSRs und LERs konfigurieren.
In-Band-Signalisierung
Zu diesem Zeitpunkt haben PE2, PE3 und PE4 einen Upstream-PIM-Join-Status, der auf PE1 zeigt, aber RPF schlägt fehl, weil PIM von den Core-Links entfernt wurde. In der C- und P-Terminologie läuft P-PIM nicht mehr und C-PIM muss sich auf mLDP verlassen, um den Multicast-Baum durch den Core zu erweitern. C-PIM weiß jedoch nicht, dass es sich auf mLDP verlassen kann. Noch nicht.
Später in diesem Kapitel wirst du die Konfiguration sehen (siehe Beispiel 4-19 und Beispiel 4-26), die die automatische Umwandlung des C-PIM Join-Status in LDP P2MP FECs ermöglicht. Dadurch wird ein P2MP LSP mit PE1 als Wurzel und drei Blättern (PE2, PE3 und PE4) erstellt. Der P2MP LSP wird von mLDP aufgebaut, und die Signalisierung erfolgt tatsächlich in Upstream-Richtung: von den Blättern zur Root (PE1). Im Gegensatz dazu werden die C-Multicast-Daten stromabwärts getunnelt, von der Root zu den Blättern.
Du kannst Abbildung 4-3 als Leitfaden für den folgenden mLDP-Walkthrough verwenden.
Hinweis
Für den Rest dieses Kapitels werden die IS-IS-Metriken für die Verbindungen PE1-PE2 und PE3-PE4 auf 100 erhöht. Wenn es also keine Verbindungsausfälle gibt, laufen alle kürzesten Pfade zwischen den PEs über P-Router.
Abbildung 4-3. mLDP P2MP LSPs-In-Band Signalisierung und Weiterleitung
Nehmen wir an, dass alle Hosts in Abbildung 4-1, mit Ausnahme der Quelle H1, den (10.1.1.10, 232.1.1.1) Multicast-Fluss abonniert haben. Mit anderen Worten: H2, H3, H4, H22, H33, H34 und H44 sind alle C-Multicast-Empfänger.
Signalisierung des Join-Status von einer Egress-PE, auf der Junos läuft
Die folgende Junos-Konfiguration verbindet C-PIM mit mLDP an den Junos PEs:
Beispiel 4-19. mLDP-In-Band-Konfiguration an den PEs (Junos)
protocols {
pim mldp-inband-signalling;
}
Hinweis
Diese Konfiguration wird nur auf den PEs (Ingress und Egress) benötigt. Reine P-Router wie P1 und P2 brauchen sie nicht, da sie nicht einmal PIM ausführen.
Nachdem der C-PIM Join-Status bei PE3 mit dem Befehl clear pim joingelöscht wurde ,beginnt derMulticast-Ping von H1 an 232.1.1.1, Antworten von H3, H4 und H33 zu erhalten.
Warnung
Verwende den Befehl clear pim join mit Vorsicht. Dieser Befehl ist in der Regel störend für die etablierten Multicast-Ströme. Versuche, die einzelnen (S, G), die du löschen willst, genau anzugeben.
Schauen wir uns an, wie dieser PE1→PE3-Zweig des Multicast-Baums durch den Core signalisiert wird. Der Egress-PE (PE3) weiß, dass die C-Multicast-Quelle 10.1.1.10 hinter PE1 liegt.
Beispiel 4-20. RPF-Auflösung am Egress PE-PE3 (Junos)
juniper@PE3> show route 10.1.1.10 detail active-path
[...]
Protocol next hop: 172.16.0.11
juniper@PE3> show pim source inet
Instance: PIM.master Family: INET
Source 10.1.1.10
Prefix 10.1.1.0/24
Upstream protocol MLDP
Upstream interface Pseudo MLDP
Upstream neighbor MLDP LSP root <172.16.0.11>
Dank der soeben vorgenommenen Konfiguration kann der Upstream-C-PIM-Join-Status von PE3 über das Multicast Label Distribution Protocol (mLDP) aufgelöst werden, wie in Beispiel 4-21 gezeigt.
Beispiel 4-21. Upstream C-PIM Join-Status am Egress PE-PE3 (Junos)
juniper@PE3> show pim join inet detail
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 232.1.1.1
Source: 10.1.1.10
Flags: sparse,spt
Upstream protocol: MLDP
Upstream interface: Pseudo MLDP
Downstream neighbors:
Interface: ge-2/0/3.1034
Interface: ge-2/0/4.1033
Aus Sicht der Weiterleitungsebene ist der (Downstream-)Pfad PE1→PE3, aber die Signalisierung muss in umgekehrter Richtung erfolgen: von PE3 zu PE1. Mit anderen Worten: Die Signalisierung erfolgt stromaufwärts vom Blatt zur Wurzel. PE3 ist nicht direkt mit PE1 verbunden, also muss PE3 (der Egress-PE) den RPF-Nachbarn zu PE1 (der Root) finden.
Beispiel 4-22. RPF-Lookup am Egress PE-PE3 (Junos)
juniper@PE3> show route 172.16.0.11 table inet.0
inet.0: 43 destinations, 51 routes (43 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.11/32 *[IS-IS/18] 04:37:38, metric 20
> to 10.0.0.8 via ge-2/0/1.0
PE3 baut nun ein P2MP-FEC-Element auf, ordnet ihm ein Label zu und kündigt das Label-Mapping nur P1 an. Warum P1? Weil er der RPF-Nachbar - und LDP-Nachbar - gegenüber der Root (PE1) ist. Diese gezielte Bekanntmachung unterscheidet sich grundlegend von der Promiscuous Label Mapping-Verteilung von IPv4-Präfix-FEC-Elementen, die in Abbildung 2-3 und Abbildung 2-4 dargestellt ist. Im P2MP-Fall führt der nachgelagerte LSR eine Routensuche durch, bevor er das Label Mapping ankündigt, so dass nur der RPF-Nachbar es erhält.
Beispiel 4-23. P2MP FEC-Signalisierung vom Egress PE-PE3 (Junos)
juniper@PE3> show ldp p2mp fec LDP P2MP FECs: P2MP root-addr 172.16.0.11, grp: 232.1.1.1, src: 10.1.1.10 Fec type: Egress (Active) Label: 301200 juniper@PE3> show ldp database p2mp Input label database, 172.16.0.33:0--172.16.0.1:0 Labels received: 8 Output label database, 172.16.0.33:0--172.16.0.1:0 Labels advertised: 19 Label Prefix 301200 P2MP root-addr 172.16.0.11, grp: 232.1.1.1, src: 10.1.1.10 Input label database, 172.16.0.33:0--172.16.0.44:0 Labels received: 19 Output label database, 172.16.0.33:0--172.16.0.44:0 Labels advertised: 18
Lass uns das neue FEC-Element interpretieren. Das Format der MP (P2MP und MP2MP) FEC-Elemente ist in RFC 6388 - LDP Extensions for Point-to-Multipoint and Multipoint Label Switched Paths beschrieben, das wir hier paraphrasieren:
Das P2MP FEC Element besteht aus der Adresse der Wurzel des P2MP LSP und einem opaken Wert. [...] Der opaque Wert ist im Kontext des Root-Knotens eindeutig. Die Kombination aus (Root Node Address Typ, Root Node Address, Opaque Value) identifiziert eine P2MP LSP innerhalb des MPLS-Netzwerks eindeutig.
Zurück zum Beispiel: Die P2MP Root-Adresse ist 172.16.0.11 (die Loopback-Adresse von PE1) und der Opaque-Wert lautet: group 232.1.1.1, source 10.1.1.10. Wie du siehst, enthält das FEC-Element, das zum Aufbau dieses P2MP-LSP verwendet wird, auch C-Multicast-Informationen, nämlich die C-Group und die C-Source. Das ist genau das, was In-Band bedeutet. Diese Informationen sind jedoch in einem undurchsichtigen Wert kodiert, was bedeutet, dass die Transit-LSRs sie nicht verstehen müssen: Nur die Root muss sie verstehen.
Wenn P1 dieses P2MP FEC-Element empfängt, schaut er nur auf seine Root-Adresse (172.16.0.11) und natürlich auf das Label. P1 führt eine RPF-Prüfung durch, weist ein neues Label zu und sendet ein P2MP Label Mapping an seinen RPF-Nachbarn in Richtung Root, PE1.
Beispiel 4-24. mLDP P2MP FEC Signalisierung vom Transit P-P1 (Junos)
juniper@P1> show ldp p2mp fec LDP P2MP FECs: P2MP root-addr 172.16.0.11, grp: 232.1.1.1, src: 10.1.1.10 Fec type: Transit (Active) Label: 300400 juniper@P1> show ldp database session 172.16.0.11 p2mp Input label database, 172.16.0.1:0--172.16.0.11:0 Labels received: 9 Output label database, 172.16.0.1:0--172.16.0.11:0 Labels advertised: 7 Label Prefix 300400 P2MP root-addr 172.16.0.11, grp: 232.1.1.1, src: 10.1.1.10
Im Gegensatz zu P1 ist der Ingress-PE (PE1) der Root, also schaut er in den MP-Opaque-Wert, der den C-Multicast-Status enthält. Tatsächlich wandelt PE1 den Downstream-MLDP-FEC in den Upstream-C-PIM-Join-Status um. Letzterer existiert bereits aufgrund des lokalen Empfängers H11, so dass der mLDP FEC lediglich eine Aktualisierung der ausgehenden Schnittstellenliste auslöst.
Beispiel 4-25. Upstream C-PIM Join Status am Ingress PE-PE1 (Junos)
juniper@PE1> show pim join inet detail
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 232.1.1.1
Source: 10.1.1.10
Flags: sparse,spt
Upstream interface: ge-2/0/1.1010
Downstream neighbors:
Interface: ge-2/0/2.1011
Interface: Pseudo-MLDP
Signalisierung des Join-Status von einer Egress-PE, die IOS XR ausführt
Die IOS XR-Konfiguration, die C-PIM mit mLDP bei PE2 verbindet, wird in Beispiel 4-26 gezeigt.
Beispiel 4-26. mLDP-In-Band-Konfiguration bei PE2 (IOS XR)
prefix-set PR-REMOTE-SOURCES
10.1.1.0/24 eq 32,
10.2.0.0/16 eq 32
end-set
!
route-policy PL-MLDP-INBAND
if source in PR-REMOTE-SOURCES then
set core-tree mldp-inband
else
pass
endif
end-policy
!
router pim
address-family ipv4
rpf topology route-policy PL-MLDP-INBAND
!
multicast-routing
address-family ipv4
mdt mldp in-band-signaling ipv4
!
PE4 wird auf ähnliche Weise konfiguriert, nur mit einigen Anpassungen in prefix-set. Wie bei Junos ist diese Konfiguration nur bei den PEs erforderlich, nicht bei den Ps. Nachdem der C-PIM-Join-Status bei PE2 und PE4 mit dem Befehl clear pim ipv4 topologygelöscht wurde, beginnt der Multicast-Ping von H1 an 232.1.1.1, Antworten von H2, H22 und H44 zu erhalten.
Warnung
Verwende den Befehl clear pim ipv4 topology mit Vorsicht. Dieser Befehl ist in der Regel störend für die etablierten Multicast-Ströme. Versuche, die einzelnen (S, G), die du löschen willst, genau anzugeben.
Schauen wir uns an, wie diese Zweige des Multicast-Baums durch den Kern signalisiert werden. Einer der Egress-PEs (PE2) fungiert als Verzweigungspunkt, so dass die Pfade H1→H2 und H1→H22 im Kern denselben Unterpfad (PE1→PE2) nutzen.
Nachfolgend siehst du den C-PIM-Upstream-Join-Status bei PE2. Erinnere dich daran, dass die Verbindung PE1-PE2 einen hohen IS-IS-Metrikwert hat, so dass der kürzeste PE2→PE1-Pfad über P2 und P1 verläuft.
Beispiel 4-27. Upstream C-PIM Join am egress PE-PE2 (IOS XR)
RP/0/0/CPU0:PE2#show mrib route 232.1.1.1
IP Multicast Routing Information Base
[...]
(10.1.1.10,232.1.1.1) RPF nbr: 10.0.0.5 Flags: RPF
Up: 01:00:38
Incoming Interface List
Imdtdefault Flags: A LMI, Up: 01:00:38
Outgoing Interface List
GigabitEthernet0/0/0/0.1020 Flags: F NS, Up: 01:00:38
GigabitEthernet0/0/0/1.1022 Flags: F NS LI, Up: 01:00:38
Die Schnittstelle imdtdefault ist der interne "Klebstoff" zwischen der C-PIM- und der mLDP-Domäne bei PE2. Lass dich von dem Namen nicht verwirren: Dieser mLDP LSP ist ein Daten-MDT (selektiver Baum). Der C-PIM-Upstream-Join-Status löst nun die Erstellung und Signalisierung eines P2MP-FEC-Label-Mappings aus, das PE2 an P2 sendet.
Beispiel 4-28. P2MP FEC-Signalisierung von egress PE-PE2 (IOS XR)
RP/0/0/CPU0:PE2#show mpls mldp database
mLDP database
LSM-ID: 0x00001 Type: P2MP Uptime: 01:08:29
FEC Root : 172.16.0.11
Opaque decoded : [ipv4 10.1.1.10 232.1.1.1]
Upstream neighbor(s) :
172.16.0.2:0 [Active] Uptime: 00:12:26
Local Label (D) : 24021
Downstream client(s):
PIM MDT Uptime: 01:08:29
Egress intf : Imdtdefault
Table ID : IPv4: 0xe0000000
RPF ID : 3
P2 erhält P2MP-FEC-Label-Mappings von PE2 und PE4, die dann zu einem einzigen Label-Mapping aggregiert werden, das P2 an P1 weiterleitet.
Beispiel 4-29. P2MP FEC-Signalisierung bei Transit P-P2 (IOS XR)
RP/0/0/CPU0:P2#show mpls mldp database
mLDP database
LSM-ID: 0x00003 Type: P2MP Uptime: 00:39:07
FEC Root : 172.16.0.11
Opaque decoded : [ipv4 10.1.1.10 232.1.1.1]
Upstream neighbor(s) :
172.16.0.1:0 [Active] Uptime: 00:39:07
Local Label (D) : 24020
Downstream client(s):
LDP 172.16.0.22:0 Uptime: 00:39:07
Next Hop : 10.0.0.4
Interface : GigabitEthernet0/0/0/0
Remote label (D) : 24021
LDP 172.16.0.44:0 Uptime: 00:37:55
Next Hop : 10.0.0.11
Interface : GigabitEthernet0/0/0/5
Remote label (D) : 24021
Hinweis
In Beispiel 4-29 ist der Wert des Remote-Labels 24021 in beiden Downstream-Zweigen zufällig derselbe. Das ist nur ein typischer MPLS-Zufall; die Labels hätten auch andere Werte haben können.
Dies ist die Ansicht eines Verzweigungspunkts auf der Steuerungsebene: Zwei Downstream-Zweige (P2→PE2 und P2→PE4) werden zu einem einzigen Upstream-Zweig (P1→P2) zusammengeführt. In der Weiterleitungsebene ist der Prozess umgekehrt: Ein Paket, das von P1 auf P2 ankommt, wird zu PE2 und PE4 weitergeleitet. Schauen wir uns den Lebensweg eines C-Multicast-Pakets an.
Lebensdauer eines C-Multicast-Pakets in einem mLDP P2MP LSP
Nach der Analyse der Kontrollebene wollen wir uns nun der Weiterleitungsebene widmen.
Ingress PE
PE1 repliziert jedes eingehende (10.1.1.10, 232.1.1.1) C-Multicast-Paket und sendet eine Kopie an den direkt angeschlossenen Empfänger H11 und eine weitere Kopie - eingekapselt in MPLS - über den PE1-P1-Core-Link, wie in Beispiel 4-30 gezeigt.
Beispiel 4-30. mLDP P2MP LSP-Weiterleitung am Ingress PE-PE1 (Junos)
1 juniper@PE1> show multicast route detail 2 Instance: master Family: INET 3 4 Group: 232.1.1.1 5 Source: 10.1.1.10/32 6 Upstream interface: ge-2/0/1.1010 7 Downstream interface list: 8 ge-2/0/4.0 ge-2/0/2.1011 9 Session description: Source specific multicast 10 Statistics: 0 kBps, 1 pps, 8567 packets 11 Next-hop ID: 1048581 12 Upstream protocol: PIM 13 14 juniper@PE1> show route table inet.1 match-prefix "232.1.1.1*" 15 16 inet.1: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 17 + = Active Route, - = Last Active, * = Both 18 19 232.1.1.1,10.1.1.10/64*[PIM/105] 07:08:35 20 to 10.0.0.3 via ge-2/0/4.0, Push 300400 21 via ge-2/0/2.1011 22 23 juniper@PE1> show route forwarding-table destination 232.1.1.1 24 table default extensive 25 Destination: 232.1.1.1.10.1.1.10/64 26 Route type: user 27 Route reference: 0 Route interface-index: 332 28 Multicast RPF nh index: 0 29 Flags: cached, check incoming interface, [...] 30 Next-hop type: indirect Index: 1048581 Reference: 2 31 Nexthop: 32 Next-hop type: composite Index: 595 Reference: 1 33 # Now comes the list of core (MPLS) next hops 34 Next-hop type: indirect Index: 1048577 Reference: 2 35 Nexthop: 36 Next-hop type: composite Index: 592 Reference: 1 37 Nexthop: 10.0.0.3 38 Next-hop type: Push 300400 Index: 637 Reference: 2 39 Load Balance Label: None 40 Next-hop interface: ge-2/0/4.0 41 # Now comes the list of access (IPv4) next hops 42 Next-hop type: indirect Index: 1048591 Reference: 2 43 Nexthop: 44 Next-hop type: composite Index: 633 Reference: 1 45 Next-hop type: unicast Index: 1048574 Reference: 3 46 Next-hop interface: ge-2/0/2.1011
Alle vorherigen Befehle zeigen lediglich die verschiedenen Stadien eines Multicast-Weiterleitungs-Cache-Eintrags. Die inet.1 Auxiliary Routing Information Base (RIB) ist eigentlich ein Multicast-Cache, dessen Einträge die Forwarding-Tabelle (die Forwarding Information Base [FIB]) füllen. Die Next-Hop-Strukturen von Junos weisen eine hohe Indirektionsebene auf. In der Praxis kannst du dir den composite next hop als eine Aktion vorstellen. Im Fall von Multicast-Routen ist diese Aktion "replicate". Eine ausführliche Diskussion über Composite Next Hops für Unicast findest du in Kapitel 20.
Sieh dir Zeile 37 in Beispiel 4-30 an. Eine Kopie des C-Multicast-Pakets wird in MPLS und dann in Ethernet eingekapselt. Die Ziel-MAC-Adresse des Ethernet-Frames ist die Unicast-MAC-Adresse von 10.0.0.3 (P1), die normalerweise über ARP aufgelöst wird.
Hinweis
Multicast über MPLS over Ethernet wird in Unicast-Frames transportiert.
Dies ist ein wichtiger Vorteil für Szenarien, in denen die Kernverbindung zwar logisch Punkt-zu-Punkt ist, aber über eine darunter liegende Mehrpunkt-Infrastruktur verläuft. So kann AS 65000 beispielsweise Multipoint-L2VPN-Dienste bei einem externen SP kaufen und dieses L2-Overlay für die Implementierung seiner eigenen Core Links nutzen. Aus Sicht von AS 65000 handelt es sich dabei um Punkt-zu-Punkt-Kernverbindungen, aber hinter den Kulissen werden Multicast-Ethernet-Frames durch das Multipoint-L2VPN im Netz des Transportanbieters geflutet. Diese Überlegung verdeutlicht den Vorteil der Einkapselung von C-Multicast-Paketen in Unicast-MPLS-over-Ethernet-Frames. L2VPN-Dienste werden in Kapitel 6, Kapitel 7 und Kapitel 8 näher erläutert.
Schließlich kannst du den Begriff unicast in Beispiel 4-30, Zeile 45 ignorieren. Seine Bedeutung wird in Kapitel 20 ausführlich erklärt und er hat nichts mit dem klassischen Begriff des Unicast zu tun.
Aufgrund des aktuell konfigurierten IGP-Metrikschemas - Inter-PE-Links haben eine höhere Metrik (100) - sendet PE1 nur eine Kopie des C-Multicast-Pakets in den Kern. Wenn die IGP-Metriken auf die Standardwerte zurückgesetzt würden, würde PE1 eine Kopie an P1 und eine weitere Kopie an PE2 senden. Mit anderen Worten: Nichts hindert einen Ingress PE daran, ein Replikationspunkt eines P2MP LSP zu sein, wenn die Topologie dies erfordert.
Hinweis
In diesem Beispiel läuft auf dem Ingress PE (PE1) Junos. Wenn der Multicast-Ping von H2 kommt, läuft auf dem Ingress PE (PE2) IOS XR und die Ergebnisse sind erfolgreich und symmetrisch zu den hier gezeigten.
Transit P-Router mit Junos
Wenn es bei P1 ankommt, wird das MPLS-Paket in zwei Kopien weiter repliziert: eine geht an PE3 und eine an P2, wie in Beispiel 4-31 gezeigt.
Beispiel 4-31. mLDP P2MP LSP-Weiterleitung an einem Transit PE-P1 (Junos)
juniper@P1> show ldp p2mp path
P2MP path type: Transit/Egress
Output Session (label): 172.16.0.11:0 (300400) (Primary)
Input Session (label): 172.16.0.33:0 (301200)
172.16.0.2:0 (24020)
Attached FECs: P2MP root-addr 172.16.0.11,
grp: 232.1.1.1, src: 10.1.1.10 (Active)
juniper@P1> show route forwarding-table label 300400 extensive
Routing table: default.mpls [Index 0]
MPLS:
Destination: 300400
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
Flags: sent to PFE
Next-hop type: indirect Index: 1048582 Reference: 2
Nexthop:
Next-hop type: composite Index: 602 Reference: 1
# Now comes the replication towards PE3
Nexthop: 10.0.0.9
Next-hop type: Swap 301200 Index: 594 Reference: 2
Load Balance Label: None
Next-hop interface: ge-2/0/6.0
# Now comes the replication towards P2
Next-hop type: unilist Index: 1048581 Reference: 2
# Now comes the first P1-P2 link for load balancing
Nexthop: 10.0.0.7
Next-hop type: Swap 24020 Index: 596 Reference: 1
Load Balance Label: None
Next-hop interface: ge-2/0/3.0 Weight: 0x1
# Now comes the second P1-P2 link for load balancing
Nexthop: 10.0.0.25
Next-hop type: Swap 24020 Index: 597 Reference: 1
Load Balance Label: None
Next-hop interface: ge-2/0/4.0 Weight: 0x1
Wenn du dir Beispiel 4-31 genau ansiehst, gibt es einen neuen Typ von Next Hop namens unilist. Das bedeutet, dass die einzelne Kopie des Pakets, die nach P2 gesendet wird, über die beiden P1-P2-Verbindungen verteilt werden muss - nicht repliziert. Diese einzelne Kopie wird über den ersten oder den zweiten Link gesendet, je nachdem, wie die Hash-Berechnung des Pakets ausfällt (siehe "LDP und Equal-Cost Multipath", falls dir diese Sprache nicht vertraut vorkommt). Die Tatsache, dass das Gewicht in beiden Links 0x1 ist, bedeutet, dass beide für den Lastausgleich verfügbar sind. Daher unterstützt mLDP in Junos von Haus aus Equal-Cost Multipath (ECMP) über parallele Links.
Transit P-Router mit IOS XR
P2 repliziert das Paket weiter an PE2 und PE4, wie im folgenden Beispiel dargestellt:
Beispiel 4-32. mLDP P2MP LSP Weiterleitung an einem Transit PE-P2 (IOS XR)
RP/0/0/CPU0:P2#show mpls forwarding labels 24020
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ------- -------------- ---------- ---------- --------
24020 24021 MLDP: 0x00003 Gi0/0/0/0 10.0.0.4 2170
24021 MLDP: 0x00003 Gi0/0/0/5 10.0.0.11 2170
Egress PE mit Junos
PE3 löst das MPLS-Label auf und repliziert die resultierenden IPv4-Multicast-Pakete an die beiden Empfänger-ACs, wie du in Beispiel 4-33 sehen kannst.
Hinweis
Für P2MP-LSPs gibt es kein Penultimate Hop Popping (PHP). Im Fall von Global Internet Multicast in diesem Kapitel ist dies wichtig, weil die Core Links keine nativen Multicast-Pakete transportieren sollten. Im Fall des Multicast-VPNs ist dies ebenfalls wichtig, aber aus einem anderen Grund, der in Kapitel 5 behandelt wird.
Beispiel 4-33. mLDP P2MP LSP-Weiterleitung an einer Egress PE-PE3 (Junos)
juniper@PE3> show route forwarding-table label 301200 extensive Routing table: default.mpls [Index 0] MPLS: Destination: 301200 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 Flags: sent to PFE Next-hop type: indirect Index: 1048577 Reference: 2 Nexthop: Next-hop type: composite Index: 601 Reference: 1 # Now comes the replication towards VLAN 1034 [...] Next-hop type: Pop Index: 597 Reference: 2 Load Balance Label: None Next-hop interface: ge-2/0/3.1034 # Now comes the replication towards H33 [...] Next-hop type: Pop Index: 600 Reference: 2 Load Balance Label: None Next-hop interface: ge-2/0/4.1033
Unicast Next Hops wurden aus Beispiel 4-33 entfernt, weil sie irreführend sind: Multicast-MAC-Adressen werden mit einer mathematischen Regel berechnet; sie werden nicht über ARP aufgelöst.
Egress PE mit IOS XR
Schauen wir uns an, wie PE4 das MPLS-Label aufhebt und das IPv4-Multicast-Paket nur an H44 sendet.
Beispiel 4-34. mLDP P2MP LSP Forwarding an einer egress PE-PE4 (IOS XR)
RP/0/0/CPU0:PE4#show mrib route 10.1.1.10 232.1.1.1
IP Multicast Routing Information Base
[...]
(10.1.1.10,232.1.1.1) RPF nbr: 10.0.0.10 Flags: RPF
Up: 09:45:39
Incoming Interface List
Imdtdefault Flags: A LMI, Up: 03:17:05
Outgoing Interface List
GigabitEthernet0/0/0/2.1034 Flags: LI, Up: 12:40:38
GigabitEthernet0/0/0/3.1044 Flags: F NS LI, Up: 09:01:24
Bei den Tests in diesem Buch empfängt H44 den C-Multicast-Datenstrom nur, wenn der Unicast-CEF-Eintrag von PE4 für 172.16.0.11 in ein LDP-Label aufgelöst wird. Wenn PE4s RPF zu PE1 in einen (P2P) RSVP-Tunnel aufgelöst wird, leitet PE4 den Verkehr nicht an H44 weiter. Mit anderen Worten: Zum jetzigen Zeitpunkt kann die IOS XR-Implementierung von mLDP nicht mit Unicast-RSVP-TE koexistieren. Diese Randbedingung wurde bei Junos PE3 nicht beobachtet.
Der wichtigste Punkt in der vorherigen Ausgabe ist das Flag F - Forward. Bei der Schnittstelle zu H44 ist das Flag gesetzt, bei der anderen Schnittstelle (VLAN 1034) jedoch nicht. Wenn du jedoch die Quelle anhältst und ein paar Minuten wartest, wird das F-Flag bei beiden Einträgen wieder gesetzt. Schauen wir mal, warum.
CE Multihoming
Es ist wichtig, dass jeder Host eine, und nur eine, Kopie jedes Multicast-Pakets erhält. H2, H11, H22, H33 und H44 haben keine Zugriffsredundanz, also erhalten sie nicht mehrere Kopien jedes von H1 gesendeten Pakets. Umgekehrt sind H3, H4 und H34 (direkt oder indirekt) mit PE3 und PE4 multihomed. Lass uns diesen Fall genauer besprechen.
Egress PE Redundanz
Die folgende Diskussion ist ziemlich allgemein für IP Multicast und nicht spezifisch für das mLDP In-Band Modell. Die VLAN 1034-Topologie(Abbildung 4-1) ist ein klassisches Beispiel für PE-Redundanz. Drei Geräte (BR3, BR4 und H34) sind mit dem SP (AS 65000) über ein VLAN verbunden, das sowohl mit PE3 als auch mit PE4 multihomed ist. Es sind zwei EBGP-Sitzungen eingerichtet: PE3-BR3 und PE4-BR4. Außerdem sind alle Router im VLAN 1034 PIM-Nachbarn. Hier ist die spezifische PIM-Konfiguration der Geräte:
-
PE3:
protocols pim interface ge-2/0/3.1034 priority 200 -
PE4: Standardkonfiguration ( PIM-Priorität 1)
-
BR3, BR4:
protocols pim interface ge-0/0/1.1034 priority 0 -
H34:
router pim [vrf H34] address-family ipv4 interface GigabitEthernet0/0/0/0.1034 dr-priority 0
Bei dieser Konfiguration ist PE3 der Designated Router (DR), was du mit dem Befehl show pim interfaces auf PE3 bzw. show pim neighbor auf PE4 überprüfen kannst. Der DR ist für die Verarbeitung der IGMP-Berichte von den direkt angeschlossenen Hosts (in diesem Fall H34) verantwortlich.
Abbildung 4-4 veranschaulicht den C-Multicast-Konvergenzprozess auf VLAN 1034 in zwei Schritten.
Abbildung 4-4. C-Multicast-Egress-PE-Redundanz und C-PIM-Assert
Zu Beginn sind sowohl PE3 als auch PE4 bereit, den (10.1.1.10, 232.1.1.1) Datenverkehr an VLAN 1034 weiterzuleiten. Hier ist der Grund dafür:
-
PE3 ist der DR und verarbeitet die IGMP-Berichte von H34.
-
PE3 ist der Upstream-Nachbar eines PIM (10.1.1.10, 232.1.1.1)-Joins, der von BR3 gesendet wurde, weil BR3 nur eine eBGP-Sitzung mit PE3 hat.
-
PE4 ist der Upstream-Nachbar eines PIM (10.1.1.10, 232.1.1.1)-Joins, der von BR4 gesendet wurde, weil BR4 nur eine eBGP-Sitzung mit PE4 hat.
Wenn H1 das erste C-Multicast-Paket an 232.1.1.1 sendet, leiten sowohl PE3 als auch PE4 es an VLAN 1034 weiter. Dies führt zu einer Duplizierung von C-Multicast-Paketen in VLAN 1034, was du in der ersten Gruppe von Ping-Antworten überprüfen kannst.
Beispiel 4-35. mLDP P2MP LSP Weiterleitung an einem Transit PE-P2 (IOS XR)
1 RP/0/0/CPU0:H# ping vrf H1 232.1.1.1 source 10.1.1.10 count 1 2 Reply to request 0 from 10.1.11.11, 1 ms 3 Reply to request 0 from 10.1.22.22, 9 ms 4 Reply to request 0 from 10.2.33.33, 9 ms 5 Reply to request 0 from 10.2.44.44, 9 ms 6 Reply to request 0 from 10.2.3.30, 9 ms 7 Reply to request 0 from 10.2.0.34, 9 ms 8 Reply to request 0 from 10.2.4.40, 9 ms 9 Reply to request 0 from 10.2.3.30, 19 ms 10 Reply to request 0 from 10.2.0.34, 19 ms 11 Reply to request 0 from 10.2.4.40, 19 ms
ICMP Echo Request #0 erhält doppelte Antworten von H3, H34 und H4. Aus Sicht der Dienste ist dies höchst unerwünscht. Für die meisten Multicast-Anwendungen ist es genauso schlimm, eine doppelte oder vervielfältigte Kopie des ursprünglichen Datenstroms zu erhalten, wie gar keinen Datenstrom zu bekommen. Aus diesem Grund starten PE3 und PE4, wenn sie diese Paketverdopplung entdecken, einen Wettbewerb namens PIM Assert, der auf ihrer Route zur Multicast-Quelle 10.1.1.10 basiert.
Beispiel 4-36. Egress PE Redundanz-Unicast Route zur C-Quelle
1 juniper@PE3> show route active-path 10.1.1.10 2 3 inet.0: 44 destinations, 53 routes (44 active, 0 holddown, 0 hidden) 4 5 10.1.1.0/24 *[BGP/170] 1d 12:04:09, MED 100, localpref 100, 6 from 172.16.0.201, AS path: 65001 I [...] 7 > to 10.0.0.8 via ge-2/0/1.0, Push 300368 8 9 RP/0/0/CPU0:PE4#show route 10.1.1.10 10 11 Routing entry for 10.1.1.0/24 12 Known via "bgp 65000", distance 200, metric 100 13 Tag 65001, type internal 14 Installed Jan 6 06:11:52.147 for 15:19:12 15 Routing Descriptor Blocks 16 172.16.0.11, from 172.16.0.201 17 Route metric is 100 18 No advertising protos.
Obwohl das MED-Attribut der Route in beiden Fällen 100 ist, beträgt die standardmäßige administrative Distanz des BGP-Protokolls bei PE3 (Zeile 5, Junos) 170, bei PE4 (Zeile 12, IOS XR) dagegen 200. Die niedrigste administrative Distanz gewinnt, also wird PE3 zum C-PIM (10.1.1.10, 232.1.1.1) Assert-Gewinner. Zu diesem Zeitpunkt hört PE4 auf, den Datenfluss in VLAN 1034 zu injizieren. Da PIM-Assert-Pakete an die Adresse 224.0.0.13 gesendet werden, sieht BR4 den Assert-Wettbewerb und leitet seinen PIM (C-S, C-G) Join Upstream Neighbor an PE3 weiter. Insgesamt wird die Paketverdopplung in VLAN 1034 behoben und PE3 wird zum einzigen Forwarder.
Hinweis
In VLAN 1044 gibt es kein Assert. Die Tatsache, dass PE3 der Assert-Gewinner in VLAN 1034 ist, hindert PE4 also nicht daran, die Pakete an H44 weiterzuleiten.
Wie bei PIM nicht anders zu erwarten, werden Assert-Pakete regelmäßig aufgefrischt. Mit anderen Worten: Assert hat, wie Join/Prune, einen weichen Zustand. Einige Minuten, nachdem die C-Source keinen Datenverkehr mehr sendet, geht Assert in den Ruhezustand über und der ursprüngliche Zustand wird wiederhergestellt (das F-Flag erscheint für VLAN 1034 in Beispiel 4-34). Selbst in einem Modell mit PIM SSM gibt es also Szenarien, in denen die Signalisierung des Multicast-Baums datengesteuert ist.
Ingress PE-Redundanz
Nehmen wir nun an, dass eine aktive C-Multicast-Quelle zu PE1 und PE2 multihomed ist und dass diese Quelle Verkehr an (C-S, C-G) sendet. Nun senden sowohl H33 als auch H44 einen IGMP-Report, der diesen Datenfluss abonniert. Wie wird der P2MP LSP signalisiert? Es gibt zwei Fälle:
-
Sowohl PE3 als auch PE4 wählen denselben Upstream PE (entweder PE1 oder PE2) als Root für den P2MP FEC. In diesem Fall wird ein einzelner P2MP LSP mit einer Root und zwei Leaves erstellt: PE3 und PE4.
-
PE3 und PE4 wählen unterschiedliche Upstream-PEs aus. PE3 wählt zum Beispiel PE1 und PE4 wählt PE2. In diesem Fall gibt es zwei P2MP-LSPs, von denen eine bei PE1 und die andere bei PE2 verankert ist. Jede dieser P2MP-LSPs hat ein einziges (und unterschiedliches) Blatt.
In keinem dieser Fälle besteht die Gefahr einer Datendopplung: Jeder Egress-PE signalisiert den P2MP-FEC an einen einzigen Ingress-PE. Dies ist ein allgemeiner Vorteil von Selective Trees.
mLDP In-Band und PIM ASM
Zum jetzigen Zeitpunkt unterstützen die Implementierungen der Anbieter nur PIM SSM in Kombination mit mLDP In-Band. Die Bemühungen um die Unterstützung von PIM ASM sind in zwei RFCs zusammengefasst:
-
RFC 7438 - mLDP-In-Band-Signalisierung mit Wildcards
-
RFC 7442 - Übertragung von PIM-SM in ASM Mode Trees über mLDP
Andere Internet-Multicast über MPLS-Varianten
Es gibt einige zusätzliche Global Internet Multicast (S1) Varianten. Hier ist eine nicht erschöpfende Liste.
Statische RSVP-TE P2MP LSPs
Es gibt noch ein weiteres interoperables Modell für die Signalisierung und den Transport von Internet Multicast zwischen Junos und IOS XR PEs. In der Cisco-Dokumentation wird es Global P2MP-TE genannt. In den Begriffen der Tabelle 4-1 ist es S1, A0, C0, E3, T3, Y3.
Es basiert auf der Verwendung statischer Routen, um IP-Multicast-Verkehr in RSVP-TE P2MP LSPs zu platzieren. Der Netzwerkadministrator konfiguriert die Blätter jeder LSP manuell. Obwohl dieses Modell in relativ statischen Umgebungen wie dem traditionellen IPTV erfolgreich angewendet werden kann, ist es für die Zwecke dieses Buches nicht besonders interessant.
BGP Internet Multicast
Junos unterstützt eine Art von Routing-Instanz namens mpls-internet-multicast, die BGP-Multicast-VPN-Techniken für die Signalisierung und den Transport von Internet-Multicast-Verkehr einsetzt. In den Begriffen der Tabelle 4-1 sind das S1, A3, C3, [E1, E2, E3], [T0, T1, T2, T3, T4], [Y1, Y2, Y3, Y4]. Es werden jedoch nicht alle Kombinationen unterstützt.
Obwohl IOS XR diesen Ansatz nicht implementiert, kannst du die IOS XR PEs mit Internet VRFs konfigurieren, die BGP Multicast VPN ausführen. Aus Sicht der Interoperabilität ist es jedoch interessanter, sich auf das echte BGP Multicast VPN zu konzentrieren, mit VRFs auf beiden PE-Typen (Junos und IOS XR). Los geht's in Kapitel 5!
Get MPLS in der SDN-Ära now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
