Sommario

Introduzione

Che cos'è Default MDT?

Cos'è Data MDT?

BGP

Indirizzamento multicast per gruppo SSM

Raccomandazioni

Segnalazione overlay

Topologia

Domini multicast VPN di routing e inoltro

Task di configurazione

Verifica

Attività 1: Verificare La Connettività Fisica.

Attività 2: Verificare la versione unicast VPNv4 della famiglia di indirizzi BGP.

Attività 3: Verificare la VPN unicast per la famiglia di indirizzi BGP.

Attività 4: Verificare il traffico multicast da un'estremità all'altra.

Come vengono create le interfacce tunnel?

Creazione tunnel MDT

Villaggio PIM

Informazioni correlate

Introduzione

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.

Che cos'è Default MDT?

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.

Cos'è Data MDT?

È 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

- Consente a PE di unirsi direttamente a un albero di origine per un MDT.

- Nessun punto di rendering necessario nella rete.

- Le RP sono un potenziale punto di errore e costi generali aggiuntivi.

- Ma permettono alberi condivisi e della BiDir (meno stato).

- Ridurre il ritardo di inoltro.

- Evitare il sovraccarico di gestione per amministrare il mapping di gruppi/RP e RP ridondanti per garantire affidabilità.

- Un compromesso è più richiesto dallo stato.

- (S, G) per ogni mVPN in un PE.

Se ci sono 5 PE ciascuno contenente mVRF RED, ci sono 5 voci (S, G).

1. Configurare il comando ip pim ssm range sui router P e PE (evitando la creazione di voci non necessarie (*, G)).

2. SSM consigliato per i Data-MDT.

3. Se possibile, utilizzare BiDir per Default-MDT (il supporto BiDir è specifico della piattaforma).

Se SSM non viene utilizzato per la configurazione di Data MDT:

- Ogni VRF deve essere configurato con un set univoco di indirizzi IP multicast; non è possibile configurare due VRF nello stesso MD con lo stesso insieme di indirizzi.

- Sono necessari molti più indirizzi IP multicast.

- Operazioni e gestione complesse.

- SSM richiede che il PE si unisca a (S, G) e non a (*, G).

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:

- Community estesa

- Soluzione proprietaria Cisco

- Attributo non transitivo (non adatto per inter-AS)

- Famiglia di indirizzi BGP MDT SAFI (66)

- draft-nalawade-idr-mdt-safi

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.

BGP

- Gruppo predefinito PE e MDT di origine codificato in NLRI di MP_REACH_NLRI.

- RD è uguale a quello del MVRF per cui è configurato il gruppo predefinito MDT.

- Tipo RD è 0 o 1

L'attributo PMSI contiene l'indirizzo di origine e l'indirizzo del gruppo. Per formare il tunnel MT.

Indirizzamento multicast per gruppo SSM

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.

Raccomandazioni

- Default-MDT deve disegnare gli indirizzi dallo spazio 239/8 a partire dall'intervallo definito con l'ambito locale dell'organizzazione di 239.192.0.0/14

- Data-MDT deve disegnare indirizzi dall'ambito locale dell'organizzazione.

- È inoltre possibile utilizzare l'intervallo globale SSM da 232.0.0.0 a 232.255.255.255

- Poiché SSM utilizza sempre uno stato univoco (S, G), non vi è alcuna possibilità di sovrapposizione in quanto il flusso multicast SSM verrà avviato da origini diverse (con indirizzi diversi), che si trovino nella rete del provider o in Internet.

- Utilizzare lo stesso pool Data-MDT per ogni mVRF all'interno di un particolare dominio multicast (dove è comune Default-MDT).

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 overlay

Segnalazione sovrapposta di Rosen GRE è mostrato nell'immagine.

Topologia

La topologia di Rosen GRE è mostrata nell'immagine.

Domini multicast VPN di routing e inoltro

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.

Task di configurazione

1. Abilitare il routing multicast su tutti i nodi.

2. Abilitare la modalità di sparsità PIM (Protocol Independent Multicast) in tutta l'interfaccia.

3. Con il VRF esistente, configurare MDT predefinito.

4. Configurare il VRF sull'interfaccia Ethernet0/x.

5. Abilitare il routing multicast su VRF.

6. Configurare PIM SSM Default in tutti i nodi all'interno del core.

7. Configurare la VPN della famiglia di indirizzi BGP.

8. Configurare BSR RP nel nodo CE.

9. Preconfigurato:

VRF SSM-BGP

mBGP: Address family VPNv4

VRF Routing Protocol

Verifica

Attività 1: Verificare La Connettività Fisica.

Verificare che tutte le interfacce collegate siano attive.

Attività 2: Verificare la versione unicast VPNv4 della famiglia di indirizzi BGP.

- Verificare che BGP sia abilitato in tutti i router per i router AF VPNv4 unicast e i router BGP adiacenti siano attivi.

- Verificare che la tabella unicast BGP VPNv4 contenga tutti i prefissi del cliente.

Attività 3: Verificare la VPN unicast per la famiglia di indirizzi BGP.

- Verificare che BGP sia abilitato in tutti i router per la VPN IPV4 AF e i router adiacenti BGP siano attivi.

- Verificare che tutte le rilevazioni PE si verifichino reciprocamente, con route di tipo 1.

Attività 4: Verificare il traffico multicast da un'estremità all'altra.

- Controlla il vicinato di PIM.

- Verificare che lo stato multicast sia stato creato nel VRF.

- Verificare la voce mRIB in PE1, PE2 e PE3.

- Verificare che la voce (S, G) mFIB, packet venga incrementata nell'inoltro software.

- Verificare che i pacchetti ICMP vengano raggiunti da CE a CE.

Come vengono create le interfacce tunnel?

Creazione tunnel MDT

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.

Villaggio PIM

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.

- Il tunnel 0 viene usato per inviare il join PIM e il traffico multicast con larghezza di banda ridotta.

- Il tunnel 1 viene usato per inviare il messaggio PIM encapsulated Register.

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

Informazioni correlate

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

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

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

- Documentazione e supporto tecnico – Cisco Systems