Segnalazione in-band MULTICAST di nuova generazione (VRF MLDP: Profilo 6)
Sommario
Introduzione
Questo documento descrive il VRF MLDP del segnale in-band che è il profilo 6 per il multicast di nuova generazione su VPN (mVPN). Per illustrarne il comportamento, vengono usati un esempio e l'implementazione in Cisco IOS.
Premesse
Segnalazione in banda MLDP (Multicast Label Distribution Protocol) per consentire al core MLDP di creare lo stato (S,G) o (*,G) senza utilizzare la segnalazione fuori banda, ad esempio BGP (Border Gateway Protocol) o PIM (Protocol Independent Multicast).
MVPN (Multicast VPN) supportata da MLDP consente l'aggregazione di flussi multicast VPN su un albero specifico della VPN.
Nel core MLDP non viene creato alcuno stato del cliente, ma esiste l'unico stato per gli alberi di distribuzione multicast predefiniti e di dati (MDT).
In alcuni scenari, lo stato creato per i flussi VPN è limitato e non sembra rappresentare un rischio o un fattore limitante. In questi scenari, MLDP è in grado di creare MDT in-band costituiti da percorsi Label Switched (LSP) in transito.
Gli alberi utilizzati in uno spazio VPN sono MDT. Gli alberi utilizzati nella tabella globale sono LSP in transito point-to-multipoint (P2MP) o multipoint-to-multipoint (MP2MP).
In entrambi i casi, un singolo flusso multicast (VPN o meno) è associato a un singolo LSP nel core MPLS. Le informazioni sul flusso sono codificate nella classe FEC (Forwarding Equivalence Class) dell'LSP. Questa è una segnalazione in-band.
LSM offre vantaggi se paragonati ai tunnel GRE core attualmente utilizzati per trasportare il traffico della clientela nel core e sfrutta l'infrastruttura MPLS per trasportare i pacchetti IP multicast, fornendo un data plane comune per unicast e multicast.
Segnalazione MLDP
La segnalazione MLDP fornisce due funzioni:
- Per rilevare la FEC (e il valore opaco associato) per un provider di servizi di traduzione MP
- Per assegnare un flusso multicast a un LSP MP
Segnalazione In-Band
- Il valore opaco viene utilizzato per mappare un LSP MP a un flusso multicast IP.
- Il contenuto del valore opaco deriva dal flusso multicast.
Segnalazione overlay o out-of-band
- Utilizza un protocollo overlay per mappare un LSP MP a un flusso multicast IP.
- Il valore opaco può essere assegnato dal PE radice in entrata o configurato staticamente.
- MP LSP viene creato su richiesta o può essere preconfigurato.
- Consente l'aggregazione di flussi multicast su un singolo LSP MP.
Tipo di carattere jolly LDP (Label Distribution Protocol) - FEC (Forward Equivalence Class) n. RFC5918
L'elemento FEC con caratteri jolly tipizzati si riferisce a tutte le FEC del tipo specificato che soddisfano il vincolo. Specifica un 'Tipo di elemento FEC' e un vincolo facoltativo, allo scopo di fornire informazioni aggiuntive.
Il formato dell'elemento FEC con caratteri jolly digitati è il seguente:
Carattere jolly digitato: Tipo di elemento FEC a un ottetto (0x05).
LDP [RFC5036] distribuisce etichette per le classi di equivalenza di inoltro (FEC). I protocolli LDP utilizzano TLV FEC nei messaggi LDP per specificare le FEC.
Un TLV FEC LDP include uno o più elementi FEC. Un elemento FEC include un tipo FEC e un valore opzionale dipendente dal tipo.
RFC 5036 specifica due tipi FEC (Prefisso e Wildcard), mentre altri documenti specificano tipi FEC aggiuntivi; ad esempio, vedere [RFC447] e [MLDP].
Come specificato nella RFC 5036, l'elemento FEC con caratteri jolly si riferisce a tutte le FEC relative a un vincolo facoltativo.
L'unico vincolo specificato nella RFC 5036 è quello che limita l'ambito dell'elemento FEC con caratteri jolly a "tutti i FEC associati a una determinata etichetta".
La specifica RFC 5036 dell'elemento FEC con caratteri jolly presenta le seguenti carenze che ne limitano l'utilità:
- L'elemento FEC con caratteri jolly non è tipizzato. In alcune situazioni potrebbe essere utile fare riferimento a tutti i valori FEC di un determinato tipo (come un altro vincolo).
- L'utilizzo dell'elemento FEC con caratteri jolly è limitato ai messaggi Ritiro ed Etichetta rilascio. In alcune situazioni potrebbe essere utile disporre di un elemento FEC con caratteri jolly, con un vincolo di tipo, nei messaggi di richiesta etichetta.
Topologia
Segnalazione overlay
Configurazione
Passaggio 1. Abilitare MPLS MLDP nei nodi principali.
Registrazione mpls mldp
Passaggio 2. Abilitare la segnalazione IN BANDA MLDP in CORE.
In PE1, PE2 e PE3
# ip multicast vrf INBAND-MLDP mpls mldp
# ip pim vrf INBAND-MLDP mpls source loopback 0
Passaggio 3. Abilitare PIM SM in tutte le interfacce CE e nell'interfaccia PE VRF.
Su CE1, CE2, CE3 e tutte le interfacce VRF PE1, PE2 e PE3
# interfaccia x/x
# ip pim modalità sparse
# interfaccia loopback x/x
# ip pim modalità sparse
Passaggio 4. Abilitare il multicast nel VRF.
In PE1, PE2 e PE3
# ip multicast-routing vrf INBAND-MLDP
Passaggio 5. Abilitare VRF sull'interfaccia PE-CE x/x del router PE.
# interfaccia x/x
# ip vrf forwarding INBAND-MLDP
Passaggio 6. Configurare la modalità SSM nei nodi CE e PE (solo VRF).
Sui nodi CE
# ip pim ssm predefinito
Su PE1, PE2, PE3 in VRF
# ip pim vrf INBAND-MLDP ssm predefinito
Passaggio 7. Configurare il gruppo IGMP SSM 232.1.1.1 (ricevitore).
Sul ricevitore 2 e 3
CE #interface x/x
# ip pim join-group 232.1.1.1 origine 10.1.0.2
Verifica
IGP, MPLS LDP, BGP funziona correttamente su tutta la rete.
In questa sezione, la verifica viene effettuata per controllare l'adiacenza VPN AF nella rete core/di aggregazione. Viene controllata l'adiacenza tra CE-PE e il control-plane insieme al Data plane per il traffico VPN su rete MPLS.
Per verificare che i dispositivi CE (Local and Remote Customer Edge) possano comunicare attraverso il nucleo MPLS (Multiprotocol Label Switching), eseguire le seguenti attività:
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 il traffico multicast da un'estremità all'altra.
- Controllare il vicinato PIM con il vicino PIM connesso.
- Verificare che lo stato multicast sia stato creato nel VRF.
In PE VRF mRIB entry in PE1, PE2 e PE3
- Verificare che l'ingresso mFIB VRF (S, G), il pacchetto sia incrementato nell'inoltro software.
- Verificare che i pacchetti ICMP vengano raggiunti da CE a CE.
Attività 4: Verificare MPLS CORE.
- Verificare il core MPLS LSP.
- Verificare l'inoltro MPLS all'interno del core secondo le specifiche di progettazione.
- Verificare il funzionamento del ping LSP MPLS P2MP.
Come costruire un Control Plane?
Verificare il control plane che l'imposizione dell'etichetta venga eseguita quando il router PE viene inoltrato in base all'intestazione IP e aggiunge un'etichetta MPLS al pacchetto al momento dell'ingresso in una rete MPLS.
In direzione dell'imposizione delle etichette, il router cambia i pacchetti in base a una ricerca nella tabella CEF per trovare l'hop successivo e aggiunge le informazioni sull'etichetta appropriate archiviate nella FIB per la destinazione. Quando un router esegue lo swapping di etichette nel core di un pacchetto MPLS, esegue una ricerca nella tabella MPLS. Il router deriva questa tabella MPLS (LFIB) dalle informazioni nella tabella CEF e nella base di informazioni sulle etichette (LIB).
L'eliminazione dell'etichetta si verifica quando il router PE riceve un pacchetto MPLS, prende una decisione di inoltro basata sull'etichetta MPLS, rimuove l'etichetta e invia un pacchetto IP. Il router PE utilizza l'LFIB per determinare il percorso di un pacchetto in questa direzione. Come accennato in precedenza, una sessione speciale iBGP semplifica l'annuncio dei prefissi VPNv4 e delle relative etichette tra i router PE. Nel file PE di annuncio, BGP alloca le etichette per i prefissi VPN appresi localmente e le installa nel file LFIB, ovvero la tabella di inoltro MPLS.
Passaggio 1. Dopo aver configurato il piano MLDP nel nucleo, questi messaggi vengono scambiati.
MLDP: P2MP Wildcard label request sent to 11.11.11.11:0 success MLDP: MP2MP Wildcard label request sent to 11.11.11.11:0 success MLDP-MFI: Enabled MLDP MFI client on Lspvif0; status = ok LDP Peer 11.11.11.11:0 re-announced MLDP-NBR: 11.11.11.11:0 UP sess_hndl: 1, (old ID: 0.0.0.0:0) mLDP-RW: Sending RW notification message to process: mLDP Process mLDP-RW: RW Tracking started for: 11.11.11.11 MLDP-LDP: [id 0] Wildcard label request from: 11.11.11.11:0 label: 0 root: 6.2.0.0 Opaque_len: 0 sess_hndl: 0x1 MLDP-LDP: [id 0] Wildcard label request from: 11.11.11.11:0 label: 0 root: 8.2.0.0 Opaque_len: 0 sess_hndl: 0x1 Neighbor 11.11.11.11 request for the label request to PE1.
Utilizzare questo comando di debug per verificare la configurazione precedente:
# debug mpls mldp all
Passaggio 2. Abilitare la segnalazione IN BANDA in VRF.
PE1 # Config t # ip pim vrf MLDP-INBAND mpls source loopback 0 # ip multicast vrf MLDP-INBAND mpls mldp MLDP: Enabled IPv4 on Lspvif0 unnumbered with Loopback0 MLDP-MFI: Enable lsd on int failed; not registered; MLDP: Enable pim on lsp vif: Lspvif0 MLDP: Add success lsp vif: Lspvif0 address: 0.0.0.0 application: MLDP vrf_id: 1 MLDP-DB: Replaying database events for opaque type value: 250 %LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up PIM(1): Check DR after interface: Lspvif0 came up! PIM(1): Changing DR for Lspvif0, from 0.0.0.0 to 1.1.1.1 (this system) %PIM-5-DRCHG: VRF MLDP-INBAND: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0 Use this Debug to check the preceding establishment # debug ip pim vrf LDP-INBAND6 PE1#sh interfaces lspvif 0 Lspvif0 is up, line protocol is up Hardware is Interface is unnumbered. Using address of Loopback0 (1.1.1.1) MTU 17940 bytes, BW 8000000 Kbit/sec, DLY 5000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation LOOPBACK, loopback not set
Quando il ricevitore è in linea:
Il ricevitore 3 si connette e invia i messaggi PIM JOIN (S, G) a PE3.
PIM(1): Received v2 Join/Prune on Ethernet0/2 from 10.2.0.2, to us PIM(1): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set MRT(1): Create (*,232.1.1.1), RPF (unknown, 0.0.0.0, 2147483647/0) MLDP: Interface Lspvif1 moved from VRF (default) to VRF MLDP-INBAND MLDP: Enabled IPv4 on Lspvif1 unnumbered with Loopback0 MLDP-MFI: Enabled MLDP MFI client on Lspvif1; status = ok MRT(1): Add interface Lspvif1 MLDP: Enable pim on lsp vif: Lspvif1 MLDP: Add success lsp vif: Lspvif1 address: 1.1.1.1 application: MLDP vrf_id: 1 MLDP: LDP root 1.1.1.1 added mLDP-RW: Sending RW notification message to process: mLDP Process mLDP-RW: RW Tracking started for: 1.1.1.1 MLDP: Route watch started for 1.1.1.1 topology: base ipv4 MLDP-DB: Added [vpnv4 10.1.0.2 232.1.1.1 1:1] DB Entry MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Added P2MP branch for MRIBv4(1) label %MLDP-5-ADD_BRANCH: [vpnv4 10.1.0.2 232.1.1.1 1:1] Root: 1.1.1.1, Add P2MP branch MRIBv4(1) remote label MLDP: nhop 10.0.2.2 added MLDP-NBR: 11.11.11.11:0 mapped to next_hop: 10.0.2.2 MLDP: Root 1.1.1.1 old paths: 0 new paths: 1 MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Changing peer from none to 11.11.11.11:0 MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] Add accepting element nbr: 11.11.11.11:0 MLDP: [vpnv4 10.1.0.2 232.1.1.1 1:1] label mappping msg sent to 11.11.11.11:0 success MLDP-DB: [vpnv4 10.1.0.2 232.1.1.1 1:1] path to peer: 11.11.11.11:0 changed None:0.0.0.0 to Ethernet0/3:10.0.2.2
Qualsiasi comunicazione da Receiver (S,G) Join, verrà convertita in MLDP e tutti i messaggi vengono attraversati verso Lspvif 1
Se PIM JOIN (S,G) è il protocollo guidato dal destinatario, MLDP inizia a creare il database MLDP da ricevitore a origine. Allocazione etichetta downstream per MLDP P2MP.
MLDP P2MP
Il trasporto di pacchetti P2MP viene implementato utilizzando il protocollo RSVP (Resource Reservation Protocol), P2MP - Progettazione del traffico (P2MP-TE) e il trasporto di pacchetti M2M viene implementato tramite VPN multicast IPv4 (MVPN) utilizzando il protocollo MLDP (Multicast Label Distribution Protocol).
Il pacchetto viene trasportato su tre tipi di router:
· Router headend: Incapsula il pacchetto IP con una o più etichette.
· Router per punto intermedio: Sostituisce l'etichetta in-label con una out-label.
· Router di coda: Rimuove l'etichetta dal pacchetto.
Flusso di pacchetti in una rete MVPN basata su MLDP Per ogni pacchetto in entrata, MPLS crea più etichette di uscita. I pacchetti provenienti dalla rete di origine vengono replicati lungo il percorso verso la rete di ricezione. Il router CE1 invia il traffico multicast IP nativo. Il router PE1 impone un'etichetta sul pacchetto multicast in ingresso e replica il pacchetto etichettato nella rete principale MPLS. Quando il pacchetto raggiunge il router principale (P), viene replicato con le etichette appropriate per il MDT predefinito MP2MP o il MDT dati P2MP e trasportato a tutti i PE in uscita. Una volta che il pacchetto raggiunge l'uscita PE, l'etichetta viene rimossa e il pacchetto multicast IP viene replicato sull'interfaccia VRF
PE1#sh mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 1 Type: P2MP Uptime : 00:23:11 FEC Root : 1.1.1.1 (we are the root) Opaque decoded : [vpnv4 10.1.0.2 232.1.1.1 1:1] Opaque length : 16 bytes Opaque value : FA 0010 0A010002E80101010000000100000001 Upstream client(s) : None Expires : N/A Path Set ID : 1 Replication client(s): 11.11.11.11:0 Uptime : 00:23:11 Path Set ID : None Out label (D) : 21 Interface : Ethernet0/1* Local label (U): None Next Hop : 10.0.1.2 RR-P#sh mpls mldp database * For interface indicates MLDP recursive forwarding is enabled * For RPF-ID indicates wildcard value > Indicates it is a Primary MLDP MDT Branch LSM ID : 2 Type: P2MP Uptime : 00:28:12 FEC Root : 1.1.1.1 Opaque decoded : [vpnv4 10.1.0.2 232.1.1.1 1:1] Opaque length : 16 bytes Opaque value : FA 0010 0A010002E80101010000000100000001 Upstream client(s) : 1.1.1.1:0 [Active] Expires : Never Path Set ID : 2 Out Label (U) : None Interface : Ethernet0/1* Local Label (D): 21 Next Hop : 10.0.1.1 Replication client(s): 3.3.3.3:0 Uptime : 00:28:12 Path Set ID : None Out label (D) : 26 Interface : Ethernet0/2* Local label (U): None Next Hop : 10.0.3.1 2.2.2.2:0 Uptime : 00:24:41 Path Set ID : None Out label (D) : 25 Interface : Ethernet0/3* Local label (U): None Next Hop : 10.0.2.1 RR-P#sh mpls forwarding-table labels 21 Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface 21 26 [vpnv4 10.1.0.2 232.1.1.1 1:1] \ 0 Et0/2 10.0.3.1 25 [vpnv4 10.1.0.2 232.1.1.1 1:1] \ 0 Et0/3 10.0.2.1
MRIB creato su dispositivi PE:
PE1#sh ip mroute vrf MLDP-INBAND 232.1.1.1 verbose IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, U - URD, I - Received Source Specific Host Report, (10.1.0.2, 232.1.1.1), 00:00:17/00:02:42, flags: sTI Incoming interface: Ethernet0/2, RPF nbr 10.1.0.2 Outgoing interface list: Lspvif0, LSM ID: 1, Forward/Sparse, 00:00:17/00:02:42
All'avvio del flusso di origine:
Quando la sorgente multicast inizia a inviare traffico, si verifica [10.1.0.2, 232.1.1.1], come mostrato nell'immagine.
Il traffico proveniente dalla sorgente 10.1.0.2 viene trasmesso in streaming da 232.1.1.1. Entra attraverso ethernet0/2.
Il pacchetto è stato inoltrato tramite Lspvif 0.
PIM(0): Insert (10.1.0.2,232.1.1.1) join in nbr 10.1.0.2's queue PIM(0): Building Join/Prune packet for nbr 10.1.0.2 PIM(0): Adding v2 (10.1.0.2/32, 232.1.1.1), S-bit Join PIM(0): Send v2 join/prune to 10.1.0.2 (Ethernet0/2) MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Ethernet0/2 (FS) accepted for forwarding MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Ethernet0/2 (FS) sent on Lspvif0, LSM NBMA/4
Il pacchetto viene tunneling in Lspvif 0.
Sul lato ricevitore:
Sul lato ricevente, il pacchetto raggiunge l'Lspvif 1.
MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Lspvif1 (FS) accepted for forwarding MFIBv4(0x0): Pkt (10.1.0.2,232.1.1.1) from Lspvif1 (FS) sent on Ethernet0/0 PIM(0): Received v2 Join/Prune on Ethernet0/0 from 10.3.0.2, to us PIM(0): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set PIM(0): Update Ethernet0/0/10.3.0.2 to (10.1.0.2, 232.1.1.1), Forward state, by PIM SG Join
Quando il pacchetto raggiunge il pacchetto PE1, controlla l'ID LSM per inoltrare il traffico, che ha l'etichetta da imporre nel pacchetto multicast.
L'immagine mostra come viene verificata l'interfaccia LSPVIF.
Per ogni pacchetto in entrata, MPLS crea più etichette di uscita. I pacchetti provenienti dalla rete di origine vengono replicati lungo il percorso verso la rete di ricezione. Il router CE1 invia il traffico multicast IP nativo. Il router PE1 impone un'etichetta sul pacchetto multicast in ingresso e replica il pacchetto etichettato nella rete principale MPLS.
Quando il pacchetto raggiunge il router principale (P), viene replicato con le etichette appropriate per il MDT predefinito MP2MP o il MDT dati P2MP e trasportato a tutti i PE in uscita. Una volta che il pacchetto raggiunge l'uscita PE, l'etichetta viene rimossa e il pacchetto multicast IP viene replicato sull'interfaccia VRF.
Conclusione
La configurazione MLDP di MVPN consente il recapito di pacchetti IPv4 multicast tramite MPLS. In questa configurazione vengono utilizzate le etichette MPLS per costruire strutture di distribuzione multicast (MDT) predefinite e di dati.
La replica MPLS viene utilizzata come meccanismo di inoltro nella rete principale. Per il corretto funzionamento della configurazione MLDP MVPN, verificare che la configurazione MPLS MLDP globale sia abilitata.
Informazioni correlate
Feedback