La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
Questo documento descrive il GRE (BGP AD - PIM C) dell'albero di distribuzione multicast predefinito (MDT) per il multicast su VPN (mVPN). Per illustrarne il comportamento, vengono usati un esempio e l'implementazione in Cisco IOS.
Viene utilizzato per collegare multicast a tutto il PE in un unico VRF. Per impostazione predefinita, viene eseguito il collegamento di tutti i router PE. Per impostazione predefinita, trasferisce tutto il traffico. Tutto il traffico di controllo PIM e il traffico del piano dati. Esempio: (*,G) Traffico e traffico (S,G). Il valore predefinito è must. Questo MDT predefinito consente di connettere tutti i router PE. Rappresenta da multipunto a multipoint. Chiunque può inviare e tutti possono ricevere dall'albero.
È opzionale e viene creato su richiesta. Trasporta traffico specifico (S,G). Nell'ultima versione di IOS, la soglia è configurata come 0 e infinita. Ogni volta che un primo pacchetto raggiunge il VRF, il MDT dati viene inizializzato e se il valore è infinito il MDT dati non viene mai creato e il traffico si sposta in avanti nel MDT predefinito. Data MDT è sempre l'albero di ricezione e non invia mai traffico. MDT dati è solo per il traffico (S,G).
La soglia alla quale viene creato l'MDT dei dati può essere configurata per router o per VRF. Quando la trasmissione multicast supera la soglia definita, il router PE di invio crea l'MDT dati e invia un messaggio UDP (User Datagram Protocol), contenente informazioni sull'MDT dati a tutti i router dell'MDT predefinito. Le statistiche per determinare se un flusso multicast ha superato la soglia MDT dei dati vengono esaminate una volta al secondo.
Nota: Dopo aver inviato il messaggio UDP, un router PE attende altri 3 secondi prima di passare al sistema; 13 secondi è il tempo di cambio nel caso peggiore e 3 secondi è il caso migliore.
Gli MDT dati vengono creati solo per le voci di route multicast (S, G) nella tabella di routing multicast VRF. Non vengono creati per le voci (*, G) indipendentemente dal valore della singola velocità dati di origine
Se ci sono 5 PE ciascuno contenente mVRF RED, ci sono 5 voci (S, G).
Se SSM non viene utilizzato per la configurazione di Data MDT:
G è noto come configurato, ma PE non conosce direttamente il valore di S (S, G) di Default MDT propagato da MP-BGP.
Il vantaggio di SSM è che non dipende dall'uso di un RP per derivare il router PE di origine per un particolare gruppo MDT.
L'indirizzo IP del PE di origine e del gruppo MDT predefinito viene inviato tramite Border Gateway Protocol (BGP)
BGP può inviare queste informazioni in due modi:
Nota: Le MVPN GRE sono state supportate prima dell'utilizzo di MDT SAFI; in realtà, anche prima di MDT SAFI utilizzando RD tipo 2. Tecnicamente, per il profilo 3, MDT SAFI non dovrebbe essere configurato, ma entrambi i SAFI sono contemporaneamente supportati per la migrazione.
L'attributo PMSI contiene l'indirizzo di origine e l'indirizzo del gruppo. Per formare il tunnel MT.
232.0.0.0 - 232.255.255.255 è stato riservato per le applicazioni multicast specifiche dell'origine globale.
239.0.0.0 - 239.255.255.255 è l'intervallo di spazi di indirizzi multicast IPv4 con ambito amministrativo
Ambito locale organizzazione IPv4 - 239.192.0.0/14
L'ambito locale è l'ambito di inclusione minimo e pertanto non è ulteriormente divisibile.
Gli intervalli 239.0.0.0/10, 239.64.0.0/10 e 239.128.0.0/10 non sono assegnati e sono disponibili per l'espansione di questo spazio.
Questi intervalli devono essere lasciati non assegnati finché lo spazio 239.192.0.0/14 non è più sufficiente.
Ad esempio, tutti i VRF che utilizzano Default-MDT 239.192.10.1 devono utilizzare lo stesso intervallo di dati MDT 239.232.1.0/24
Segnalazione sovrapposta di Rosen GRE è mostrato nell'immagine.
La topologia di Rosen GRE è mostrata nell'immagine.
MVPN introduce le informazioni di routing multicast nella tabella di routing e inoltro VPN. Quando un router Provider Edge (PE) riceve dati multicast o pacchetti di controllo da un router Customer Edge (CE), l'inoltro viene eseguito in base alle informazioni contenute nell'istanza MVRF (Multicast VPN Routing and Forwarding instance). MVPN non utilizza la commutazione di etichetta.
Un insieme di MVRF in grado di inviare reciprocamente traffico multicast costituisce un dominio multicast. Ad esempio, il dominio multicast per un cliente che desidera inviare determinati tipi di traffico multicast a tutti i dipendenti globali è costituito da tutti i router CE associati all'azienda.
VRF SSM-BGP mBGP: Address family VPNv4 VRF Routing Protocol
Verificare che tutte le interfacce collegate siano attive.
Dopo aver configurato mdt default 239.232.0.0
È arrivato il tunnel 0 e ha assegnato il suo indirizzo di loopback 0 come origine.
%LINEPROTO-5-UPDOWN: Protocollo di linea su tunnel di interfaccia0, stato modificato in attivo
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
Nell'immagine viene mostrata la creazione del tunnel MDT.
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
Non appena viene visualizzata la VPN BGP MVPN, tutti i dispositivi PE si rilevano a vicenda tramite la route di tipo 1. Formato tunnel multicast. BGP trasporta tutti gli indirizzi PE di origine e gruppo nell'attributo PMSI.
Nell'immagine è illustrato Exchange di tipo 1 route.
L'immagine mostra 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
Non appena si configurano le informazioni RP:
%LINEPROTO-5-UPDOWN: Protocollo di linea sull'interfaccia Tunnel1, stato modificato in attivo
Scambio di messaggi bootstrap tramite tunnel MDT
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
Nell'immagine viene mostrato lo scambio di messaggi bootstrap tramite il tunnel MDT.
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
Tunnel PIM di registro formato da due tunnel e tunnel MDT.
Comando da controllare:
**MDT BGP:
PE1#sh ip pim vrf m-SSM mdt bgp
** inviare dati FHR:
PE1#sh ip pim vrf m-SSM mdt