Inhalt

Einführung

Was ist Standard-MDT?

Was ist Daten-MDT?

BGP

Multicast-Adressierung für SSM-Gruppe

Empfehlungen

Overlay-Signalisierung

Topologie

Multicast-VPN-Routing und -Weiterleitung sowie Multicast-Domänen

Konfigurationsaufgaben

Überprüfen

Aufgabe 1: Überprüfen der physischen Verbindung

Aufgabe 2: VPNv4-Unicast der BGP-Adressfamilie überprüfen.

Aufgabe 3: MVPN-Unicast der BGP-Adressfamilie überprüfen.

Aufgabe 4: Überprüfung des gesamten Multicast-Datenverkehrs.

Wie werden Tunnelschnittstellen erstellt?

Erstellung von MDT-Tunneln

PIM-Nachbarschaft

Zugehörige Informationen

Einführung

In diesem Dokument wird der Standard Multicast Distribution Tree (MDT) GRE (BGP AD - PIM C) für Multicast over VPN (mVPN) beschrieben. Es wird ein Beispiel und die Implementierung in Cisco IOS verwendet, um das Verhalten zu veranschaulichen.

Was ist Standard-MDT?

Er wird verwendet, um Multicast mit allen PEs in einer VRF-Instanz zu verbinden. Standard bedeutet, dass alle PE-Router miteinander verbunden werden. Standardmäßig wird der gesamte Datenverkehr übertragen. Der gesamte PIM-Kontrollverkehr und der Datenverkehr auf Datenebene. Beispiel: (*,G) Datenverkehr und (S,G)-Datenverkehr. Der Standardwert ist "absolviert". Dieser Standard-MDT verbindet alle PE-Router mit der Verbindung. Dies stellt Multipoint-zu-Multipoint dar. Jeder kann senden und jeder kann von dem Baum empfangen.

Was ist Daten-MDT?

Sie ist optional und wird bei Bedarf erstellt. Er überträgt spezifischen (S,G)-Datenverkehr. In der neuesten IOS-Version ist der Grenzwert als 0 und unendlich konfiguriert. Wenn ein erstes Paket auf die VRF-Instanz trifft, wird der Daten-MDT initialisiert. Bei Unendlichkeit wird der Daten-MDT niemals erstellt, und der Datenverkehr wird im Standard-MDT weitergeleitet. Der Daten-MDT ist immer der empfangende Tree, der niemals Datenverkehr sendet. Daten-MDT ist nur für den (S,G)-Datenverkehr bestimmt.

Der Schwellenwert, bei dem der Daten-MDT erstellt wird, kann auf Router- oder VRF-Basis konfiguriert werden. Wenn die Multicast-Übertragung den festgelegten Grenzwert überschreitet, erstellt der sendende PE-Router den Daten-MDT und sendet eine User Datagram Protocol (UDP)-Nachricht, die Informationen über den Daten-MDT an alle Router im Standard-MDT enthält. Die Statistiken, anhand derer ermittelt wird, ob ein Multicast-Stream den Daten-MDT-Grenzwert überschritten hat, werden einmal pro Sekunde überprüft.

Hinweis: Nachdem ein PE-Router die UDP-Nachricht gesendet hat, wartet er noch 3 Sekunden, bevor er umschaltet. 13 Sekunden sind die Worst-Case-Switchover-Zeit und 3 Sekunden sind der beste Fall.

Daten-MDTs werden nur für Multicast-Routeneinträge (S, G) in der VRF-Multicast-Routing-Tabelle erstellt. Sie werden nicht für (*,G)-Einträge erstellt, unabhängig vom Wert der einzelnen Quelldatenrate

- Lässt zu, dass PE direkt einem Source Tree für einen MDT beitreten kann.

- Im Netzwerk sind keine Rendezvous Points erforderlich.

- RPs stellen einen potenziellen Fehlerpunkt und zusätzliche Gemeinkosten dar.

- Sie ermöglichen jedoch Shared Trees und BiDir-Trees (weniger Status).

- Reduzierung der Weiterleitungsverzögerung

- Vermeiden Sie Verwaltungsaufwand für die Verwaltung von Gruppen-/RP-Zuordnungen und redundanten RPs für die Zuverlässigkeit.

- Ein Kompromiss ist mehr erforderlich.

- (S, G) für jedes mVPN in einem PE.

Wenn 5 PEs jeweils mVRF ROT enthalten, gibt es 5 x (S, G) Einträge.

1. Konfigurieren Sie den Befehl ip pim ssm range (ip pim ssm range) auf P- und PE-Routern (vermeidet die Erstellung unnötiger (*,G)-Einträge).

2. SSM wird für Daten-MDTs empfohlen.

3. Verwenden Sie BiDir, wenn möglich, für den Standard-MDT (die BiDir-Unterstützung ist plattformspezifisch).

Wenn SSM nicht zum Einrichten von Daten-MDTs verwendet wird:

- Für jede VRF-Instanz muss ein eindeutiger Satz von Multicast-P-Adressen konfiguriert werden. Zwei VRFs im gleichen MD können nicht mit demselben Adresssatz konfiguriert werden.

- Es werden viele weitere Multicast-P-Adressen benötigt.

- Komplizierte Betriebsabläufe und Verwaltung

- SSM erfordert, dass der PE einem (S, G) nicht (*, G) beitritt.

G wird als konfiguriert bezeichnet, aber der PE kennt nicht direkt den vom MP-BGP propagierten S (S, G) des Standard-MDT.

Der Vorteil von SSM besteht darin, dass es nicht von der Verwendung eines RP abhängig ist, um den Quell-PE-Router für eine bestimmte MDT-Gruppe abzuleiten.

Die IP-Adresse des Quell-PE und der Standard-MDT-Gruppe wird über Border Gateway Protocol (BGP) gesendet.

BGP kann diese Informationen auf zwei Arten senden:

- Erweiterte Community

- Proprietäre Lösung von Cisco

- Nicht transitive Attribut (nicht geeignet für AS-interne Attribute)

- BGP-Adressfamilie MDT SAFI (66)

- Draft-nalawade-idr-mdt-safi

Hinweis: GRE MVPNs wurden vor der Verwendung von MDT SAFI unterstützt. sogar noch vor MDT SAFI mithilfe von RD Typ 2. Technisch gesehen sollte für Profile 3 kein MDT-SAFI konfiguriert werden, aber beide SAFIs werden gleichzeitig für die Migration unterstützt.

BGP

- Quell-PE- und MDT-Standardgruppe, die in NLRI von MP_REACH_NLRI kodiert ist.

- Der RD entspricht dem der MVRF-Instanz, für die die MDT-Standardgruppe konfiguriert ist.

- RD-Typ ist 0 oder 1

Das PMSI-Attribut trägt die Quelladresse und die Gruppenadresse. Um den MT-Tunnel zu bilden.

Multicast-Adressierung für SSM-Gruppe

232.0.0.0 - 232.255.255.255 wurde für globale Source-spezifische Multicast-Anwendungen reserviert.

239.0.0.0 - 239.255.255.255 ist der administrativ abgestufte IPv4-Multicast-Adressbereich.

Der lokale IPv4-Bereich der Organisation - 239.192.0.0/14

Der lokale Bereich ist der minimale einschließende Bereich und kann daher nicht weiter aufgeteilt werden.

Die Bereiche 239.0.0.0/10, 239.64.0.0/10 und 239.128.0.0/10 sind nicht zugewiesen und können erweitert werden.

Diese Bereiche sollten nicht zugewiesen werden, bis der Platz 239.192.0.0/14 nicht mehr ausreicht.

Empfehlungen

- Der Standard-MDT sollte Adressen aus dem 239/8-Bereich ziehen, beginnend mit dem Bereich, der mit dem lokalen Organisationsbereich von 239.192.0.0/14 definiert wurde.

- Der Daten-MDT sollte Adressen aus dem lokalen Organisationsbereich beziehen.

- Es ist auch möglich, den globalen SSM-Bereich 232.0.0.0 - 232.255.255.255 zu verwenden.

- Da SSM immer einen eindeutigen (S, G)-Status verwendet, besteht keine Möglichkeit einer Überschneidung, da der SSM-Multicast-Stream von verschiedenen Quellen (mit unterschiedlichen Adressen) initiiert wird, unabhängig davon, ob sich diese im Anbieternetzwerk oder im größeren Internet befinden.

- Verwenden Sie für jede mVRF-Instanz in einer bestimmten Multicast-Domäne (in der der Standard-MDT üblich ist) denselben Daten-MDT-Pool.

Beispielsweise sollten alle VRFs, die den Standard-MDT 239.192.10.1 verwenden, denselben Daten-MDT-Bereich 239.232.1.0/24 verwenden.

Overlay-Signalisierung

Die Overlay-Signalisierung von Rosen GRE wird im Bild angezeigt.

Topologie

Die Topologie der Rosen GRE wird im Bild angezeigt.

Multicast-VPN-Routing und -Weiterleitung sowie Multicast-Domänen

MVPN führt Multicast-Routing-Informationen zur VPN-Routing- und Weiterleitungstabelle ein. Wenn ein Provider Edge (PE)-Router Multicast-Daten- oder Steuerungspakete von einem Customer Edge (CE)-Router empfängt, wird die Weiterleitung gemäß den Informationen in der Multicast VPN Routing and Forwarding (MVRF)-Instanz (Routing and Forwarding) durchgeführt. MVPN verwendet kein Label-Switching.

Eine Multicast-Domäne besteht aus einer Reihe von MVRFs, die Multicast-Datenverkehr miteinander senden können. Beispielsweise besteht die Multicast-Domäne eines Kunden, der bestimmte Arten von Multicast-Datenverkehr an alle globalen Mitarbeiter senden möchte, aus allen CE-Routern, die diesem Unternehmen zugeordnet sind.

Konfigurationsaufgaben

1. Aktivieren Sie Multicast-Routing auf allen Knoten.

2. Aktivieren Sie Protocol Independent Multicast (PIM) Sparse Mode auf der gesamten Schnittstelle.

3. Mit vorhandenem VRF konfigurieren Sie einen Standard-MDT.

4. Konfigurieren Sie die VRF-Instanz an der Schnittstelle Ethernet0/x.

5. Aktivieren Sie Multicast-Routing auf VRF.

6. Konfigurieren Sie den PIM SSM-Standard in allen Knoten im Core.

7. Konfigurieren Sie das MVPN der BGP-Adressfamilie.

8. Konfigurieren Sie BSR RP im CE-Knoten.

9. Vorkonfiguriert:

VRF SSM-BGP

mBGP: Address family VPNv4

VRF Routing Protocol

Überprüfen

Aufgabe 1: Überprüfen der physischen Verbindung

Überprüfen Sie, ob alle angeschlossenen Schnittstellen UP sind.

Aufgabe 2: VPNv4-Unicast der BGP-Adressfamilie überprüfen.

- Überprüfen Sie, ob BGP auf allen Routern für AF-VPNv4-Unicast und BGP-Nachbarn UP aktiviert ist.

- Überprüfen Sie, ob die BGP VPNv4-Unicast-Tabelle über alle Kundenpräfixe verfügt.

Aufgabe 3: MVPN-Unicast der BGP-Adressfamilie überprüfen.

- Stellen Sie sicher, dass BGP auf allen Routern für AF-IPV4-MVPN aktiviert ist, und dass BGP-Nachbarn UP sind.

- Stellen Sie sicher, dass sich alle PE-Discovery-Elemente mit der Route Typ 1 gegenseitig erkennen.

Aufgabe 4: Überprüfung des gesamten Multicast-Datenverkehrs.

- Überprüfen Sie die PIM-Nachbarschaft.

- Überprüfen Sie, ob der Multicast-Status in der VRF-Instanz erstellt wird.

- Überprüfen Sie den mRIB-Eintrag auf PE1, PE2 und PE3.

- Stellen Sie sicher, dass der mFIB-Eintrag (S, G) und der Paketabruf in der Software-Weiterleitung erhöht werden.

- Überprüfen der Reichweite von ICMP-Paketen zwischen CE und CE

Wie werden Tunnelschnittstellen erstellt?

Erstellung von MDT-Tunneln

Sobald Sie den mittleren Standardwert 239.232.0.0 konfiguriert haben

Tunnel 0 wurde aufgerufen und seine Loopback 0-Adresse als Quelle zugewiesen.

%LINEPROTO-5-UPDOWN: Leitungsprotokoll auf Interface Tunnel0 (Schnittstellentunnel0), Status auf up

PIM(1): Check DR after interface: Tunnel0 came up!

PIM(1): Changing DR for Tunnel0, from 0.0.0.0 to 1.1.1.1 (this system)

%PIM-5-DRCHG: VRF SSM-BGP: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Tunnel0

Dieses Bild zeigt die Erstellung des MDT-Tunnels.

PE1#sh int tunnel 0

Tunnel0 is up, line protocol is up

Hardware is Tunnel

Interface is unnumbered. Using address of Loopback0 (1.1.1.1)

MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 1.1.1.1 (Loopback0)

Tunnel Subblocks:

src-track:

Tunnel0 source tracking subblock associated with Loopback0

Set of tunnels with source Loopback0, 1 member (includes iterators), on interface <OK>

Tunnel protocol/transport multi-GRE/IP

Key disabled, sequencing disabled

Checksumming of packets disabled

Sobald das BGP MVPN aktiviert ist, erkennen sich alle PEs über die Route Typ 1. Multicast-Tunnel gebildet. BGP überträgt alle Gruppen- und Quell-PE-Adressen im PMSI-Attribut.

Dieses Bild zeigt die Exchange der Route vom Typ 1.

Dieses Bild zeigt PCAP-1.

PE1#sh ip mroute

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

L - Local, P - Pruned, R - RP-bit set, F - Register flag,

T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report,

Z - Multicast Tunnel, z - MDT-data group sender,

(3.3.3.3, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ

Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2

Outgoing interface list:

MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18

(2.2.2.2, 239.232.0.0), 00:01:41/00:01:18, flags: sTIZ

Incoming interface: Ethernet0/1, RPF nbr 10.0.1.2

Outgoing interface list:

MVRF SSM-BGP, Forward/Sparse, 00:01:41/00:01:18

“Z” Multicast Tunnel formed after BGP mVPN comes up, as it advertises the Source PE and Group Address in PMSI attribute.

PIM-Nachbarschaft

PE1#sh ip pim vrf SSM-BGP neighbor

PIM Neighbor Table

Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,

P - Proxy Capable, S - State Refresh Capable, G - GenID Capable

Neighbor          Interface                Uptime/Expires    Ver   DR

Address                                                            Prio/Mode

10.1.0.2          Ethernet0/2           00:58:18/00:01:31 v2  1 / DR S P G

3.3.3.3           Tunnel0                00:27:44/00:01:32 v2    1 / S P G

2.2.2.2           Tunnel0                 00:27:44/00:01:34 v2    1 / S P G

Sobald Sie die RP-Informationen konfigurieren:

%LINEPROTO-5-UPDOWN: Leitungsprotokoll auf Interface Tunnel1, gewechselter Status auf up

Der Austausch der Bootstrap-Nachricht über einen MDT-Tunnel

PIM(1): Received v2 Bootstrap on Tunnel0 from 2.2.2.2

PIM(1): pim_add_prm:: 224.0.0.0/240.0.0.0, rp=22.22.22.22, repl = 0, ver =2, is_neg =0, bidir = 0, crp = 0

PIM(1): Update

prm_rp->bidir_mode = 0 vs bidir = 0 (224.0.0.0/4, RP:22.22.22.22), PIMv2

*May 18 10:28:42.764: PIM(1): Received RP-Reachable on Tunnel0 from 22.22.22.22

Dieses Bild zeigt den Bootstrap-Nachrichtenaustausch über einen MDT-Tunnel.

PE2#sh int tunnel 1

Tunnel1 is up, line protocol is up

Hardware is Tunnel

Description: Pim Register Tunnel (Encap) for RP 22.22.22.22 on VRF SSM-BGP

Interface is unnumbered. Using address of Ethernet0/2 (10.2.0.1)

MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 10.2.0.1 (Ethernet0/2), destination 22.22.22.22

Tunnel Subblocks:

src-track:

Tunnel1 source tracking subblock associated with Ethernet0/2

Set of tunnels with source Ethernet0/2, 1 member (includes iterators), on interface <OK>

Tunnel protocol/transport PIM/IPv4

Tunnel TOS/Traffic Class 0xC0,  Tunnel TTL 255

Tunnel transport MTU 1472 bytes

Tunnel is transmit only

Zwei Tunnel bildeten PIM Registertunnel und MDT Tunnel.

- Tunnel 0 wird zum Senden der PIM-Join-Nachricht und des Multicast-Datenverkehrs mit geringer Bandbreite verwendet.

- Tunnel 1 wird verwendet, um die PIM-gekapselte Registrierungsnachricht zu senden.

Befehl zur Überprüfung:

**MDT-BGP:

PE1#sh ip pim vrf m-SSM mdt bgp

** Daten-FHR senden:

PE1#sh ip pim vrf m-SSM mdt

Zugehörige Informationen

- https://tools.ietf.org/html/rfc4760

- https://tools.ietf.org/html/rfc5110

- https://tools.ietf.org/html/rfc6513

- Technischer Support und Dokumentation - Cisco Systems