Next Generation MULTICAST - Standard-MDT-GRE (BGP AD - PIM C: Profil 3)

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