In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
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.
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.
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
Wenn 5 PEs jeweils mVRF ROT enthalten, gibt es 5 x (S, G) Einträge.
Wenn SSM nicht zum Einrichten von Daten-MDTs verwendet wird:
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:
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.
Das PMSI-Attribut trägt die Quelladresse und die Gruppenadresse. Um den MT-Tunnel zu bilden.
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.
Beispielsweise sollten alle VRFs, die den Standard-MDT 239.192.10.1 verwenden, denselben Daten-MDT-Bereich 239.232.1.0/24 verwenden.
Die Overlay-Signalisierung von Rosen GRE wird im Bild angezeigt.
Die Topologie der Rosen GRE wird im Bild angezeigt.
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.
VRF SSM-BGP mBGP: Address family VPNv4 VRF Routing Protocol
Überprüfen Sie, ob alle angeschlossenen Schnittstellen UP sind.
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.
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.
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