Sommario

Introduzione

Premesse

Segnalazione In-Band

Valore opaco utilizzato nel profilo

Albero principale MLDP

ALBERO P2MP

ALBERO MP2MP

Valore opaco

Segnalazione overlay

Tipi di LSP MLDP

Label Switched Multicast

Topologia

Configurazione

Verifica

Verifica dettagliata

Come costruire un Control Plane?

Passaggio 1. Questo scambio di messaggi viene eseguito dopo la configurazione del protocollo MLDP nel core.

Passaggio 2. Abilitare la SEGNALAZIONE IN BANDA nel core a MLDP.

Il ricevitore è online

L'origine avvia lo streaming

Packet Capture (PCAP)

Verifica LSPVIF

Conclusioni

Informazioni correlate

Introduzione

Questo documento descrive la funzionalità MLDP globale di segnalazione in-band che è il profilo 7 per il multicast di nuova generazione su VPN (mVPN). Per illustrarne il comportamento, vengono usati un esempio e l'implementazione in Cisco IOS.

Premesse

- albero in banda P2MP mLDP nel nucleo; nessun routing multicast C.

- Il traffico del cliente può essere SM S, G o SSM.

- Supporto per la tabella globale (S, G) su PE.

- PIM nel core non è necessario per mLDP

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.

Valore opaco utilizzato nel profilo

Il transito IPv4 PIM-SSM consente di trasportare i flussi PIM-SSM globali attraverso il core Multiprotocol Label Switch (MPLS). Il valore opaco contiene il valore effettivo (S, G) che risiede nella tabella di route globale dei router PE in ingresso e in uscita.

Il valore opaco non solo identifica in modo univoco l'LSP MP, ma può anche trasportare le informazioni di flusso (S, G) dalla rete multicast IP perimetrale. I router IP nel percorso LSP (Label Switched Path) MP non devono analizzare il valore opaco, ma lo utilizzano come indice nel database LSP MP locale per determinare gli hop successivi in cui replicare il pacchetto multicast. Tuttavia, l'LSP PE in ingresso (più vicino all'origine) decodifica il valore in modo da poter selezionare l'LSP MP corretto per il flusso in ingresso (S, G). Il PE in uscita può utilizzare il valore per installare lo stato (S, G) nel VRF locale o nella tabella di route globale.

1. LSM consente di utilizzare un singolo piano di inoltro MPLS sia per il traffico unicast che multicast.

2. LSM consente di utilizzare la protezione MPLS esistente (ad esempio, MPLS (TE/RSVP) e i meccanismi MPLS (OAM) per il traffico multicast.

3. LSM Riduce la complessità operativa grazie all'eliminazione della necessità di PIM nella rete principale MPLS.

Albero principale MLDP

ALBERO P2MP

Il driver del ricevitore e la radice sono stati segnalati tramite FEC P2MP MLDP.

Identificazione univoca:

- Indirizzo nodo radice

- P2MP LSP -ID [32 bit]

ALBERO MP2MP

Configuration Driven e root sono configurati manualmente.

Identificazione univoca:

- Indirizzo nodo radice

- MP2MP LSP -ID [32 bit]

Valore opaco

Utilizzato per trasportare Informazioni flusso multicast, che ha significato per Radice e foglie.

- Segnalazione in banda (S,G)

- LSPID (Predefinito/Dati)

Tipo 1: Definito da MDLP, contiene LSP-ID per gestire lo spazio ID per P2MP / MP2MP LSP.

Tipo 2: Definita per il provisioning di tunnel MP-LDP e utilizzata per BGP-MVPN senza sovrapposizioni.

Segnalazione overlay

Tipi di LSP MLDP

Label Switched Multicast

Estensioni della tecnologia MPLS per il supporto del multicast tramite etichette:

- LSP point-to-multipoint

- LSP multipoint-to-multipoint

P2MP

MP2MP

Etichetta

Allocazione a monte

Upstream e Downstream

Traffico

Flusso in downstream

Upstream e Downstream

Radice

Router in ingresso

Fornisci/Fornisci Edge

Tipo di traffico

Router di controllo

Controlla solo traffico

Tipo LSP

Radice a molte foglie

Molte radici a molte foglie

Topologia

Configurazione

Passaggio 1. Abilitare MPLS MLDP nei nodi principali.

In PE1, PE2 e PE3:

Registrazione mpls mldp

Passaggio 2. Abilitare la segnalazione IN BANDA MLDP in CORE.

In PE1, PE2 e PE3:

# ip multicast mpls mldp

# ip pim mpls origine loopback 0

Passaggio 3. Abilitare il routing multicast.

Su tutti i nodi:

# ip multicast-routing

Passaggio 4. Abilitare PIM (Protocol Independent Multicast) SSM in Customer Edge (CE).

Sui nodi CE:

# ip pim ssm predefinito

Passaggio 5. Abilitare PIM SM in tutte le interfacce CE e nell'interfaccia PE (Provider Edge).

Su CE1, CE2, CE3 e tutte le interfacce PE rivolte verso CE:

# interfaccia x/x

# ip pim modalità sparse

# interfaccia loopback x/x

# ip pim modalità sparse

Nota: x rappresenta il numero di interfaccia che PE ha collegato a CE e viceversa.

Verifica

Attività 1: Verificare La Connettività Fisica.

- Verificare che tutte le interfacce collegate siano attive.

Attività 2: Verifica unicast IPv4 famiglia di indirizzi BGP

- Verificare che il protocollo Border Gateway Protocol (BGP) sia abilitato in tutti i router per i router AF IPv4 unicast e i router BGP adiacenti siano attivi.

- Verificare che la tabella BGP IPv4 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.

- Su voce mRIB PE 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.

Attività 4: Verificare MPLS CORE.

- Verificare il core MPLS LSP.

- Verificare l'inoltro MPLS all'interno del core secondo le specifiche di progettazione.

- Ping MPLS P2MP LSP per IPv4.

Verifica dettagliata

IGP (Interior Gateway Protocol), MPLS LDP, Border Gateway Protocol (BGP) funziona correttamente su tutta la rete.

In questa sezione, verificare di archiviare la rete di base/aggregazione. Controllare l'adiacenza, il control plane e il Data plane per il traffico sulla rete MPLS.

Per verificare che i dispositivi CE locali e remoti possano comunicare attraverso il nucleo MPLS (Multiprotocol Label Switching), eseguire la procedura illustrata nell'immagine:

Come costruire un Control Plane?

Verificare il control plane, in cui l'imposizione Label viene eseguita quando il router PE viene inoltrato, in base all'intestazione IP e aggiunge un'etichetta MPLS al pacchetto quando questo entra in una rete MPLS.

Nella direzione dell'imposizione delle etichette, il router cambia i pacchetti in base a una ricerca nella tabella Cisco Express Forwarding (CEF) per trovare l'hop successivo e aggiunge le informazioni sull'etichetta appropriate archiviate nella FIB di 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 facilita la pubblicità dei prefissi VPNv4 e delle relative etichette tra router PE. Nel file PE di annuncio, BGP alloca le etichette per i prefissi VPN appresi localmente e le installa nel database LFIB (Label Forwarding Information Base), ovvero la tabella di inoltro MPLS.

Passaggio 1. Questo scambio di messaggi viene eseguito dopo la configurazione del protocollo MLDP nel core.

MLDP-MFI: Enabled MLDP MFI client on Ethernet0/0; status =  ok

MLDP-MFI: Enabled MLDP MFI client on Ethernet0/1; status =  ok

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-NBR: 11.11.11.11:0 ask LDP for adjacencies

Nota: Utilizzare # debug mpls mldp all per verificare la condizione precedente.

PE1#sh mpls mldp neighbors

MLDP peer ID    : 11.11.11.11:0, uptime 00:02:05 Up,

Target Adj     : No

Session hndl   : 1

Upstream count : 0

Branch count   : 0

Path count     : 1

Path(s)        : 10.0.1.2          LDP Ethernet0/1

Nhop count     : 0

Passaggio 2. Abilitare la SEGNALAZIONE IN BANDA nel core a MLDP.

loopback origine mpls ip 0

ip multicast mpls mldp

MLDP: Enabled IPv4 on Lspvif0 unnumbered with Loopback0

MLDP-MFI: Enabled MLDP MFI client on Lspvif0; status =  ok

PIM(*): PIM subblock added to Lspvif0

MLDP: Enable pim on lsp vif: Lspvif0

MLDP: Add success lsp vif: Lspvif0 address: 0.0.0.0 application: MLDP vrf_id: 0

MLDP-DB: Replaying database events for opaque type value: 3

%LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif0, changed state to up

PIM(0): Check DR after interface: Lspvif0 came up!

%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 1.1.1.1 on interface Lspvif0

Nota: Utilizzare # debug mpls mldp all per verificare la condizione precedente.

PE1#sh int 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

Nota: MPLS MLDP non è ancora stato creato perché il ricevitore non è ancora online.

Il ricevitore 3 si connette e invia i messaggi PIM JOIN (S, G) a PE3.

Il ricevitore è online

PIM(0): Received v2 Join/Prune on Ethernet0/2 from 10.2.0.2, to us

PIM(0): Join-list: (10.1.0.2/32, 232.1.1.1), S-bit set

MRT(0): Create (*,232.1.1.1), RPF (unknown, 0.0.0.0, 2147483647/0)

MRT(0): RPF Track start on 10.1.0.2 for (10.1.0.2, 232.1.1.1)

MRT(0): Reset the z-flag for (10.1.0.2, 232.1.1.1)

MLDP: Enabled IPv4 on Lspvif1 unnumbered with Loopback0

MLDP-MFI: Enable lsd on int failed; not registered;

PIM(*): PIM subblock added to Lspvif1

MLDP: Enable pim on lsp vif: Lspvif1

MLDP: Add success lsp vif: Lspvif1 address: 1.1.1.1 application: MLDP vrf_id: 0

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) update (t=0) RPF: 0.0.0.0

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) set rpf nbr: 0.0.0.0

MLDP-MRIB-IP: wavl insert success (10.1.0.2, 232.1.1.1)

MLDP-MRIB-IP: no RPF neighbor, done!

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) update (t=1) RPF: 1.1.1.1

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) set rpf nbr: 1.1.1.1

MLDP-MRIB-IP: Change RPF neighbor from 0.0.0.0 to 1.1.1.1

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) update idb = Lspvif1, (f=2,c=2)

MLDP-MRIB-IP: add accepting interface: Lspvif1 root: 1.1.1.1

MLDP-MRIB-IP: change interface from NULL to Lspvif1

%LINEPROTO-5-UPDOWN: Line protocol on Interface Lspvif1, changed state to up

PIM(0): Check DR after interface: Lspvif1 came up!

PIM(0): Changing DR for Lspvif1, from 0.0.0.0 to 2.2.2.2 (this system)

%PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 2.2.2.2 on interface Lspvif1

Nota: Utilizzare # debug mpls mldp all e # debug ip bgp ipv4 mvpn updates Debug per controllare l'impostazione precedente.

Qualsiasi comunicazione da Receiver (S,G) Join, viene convertita in MLDP e tutti i messaggi vengono attraversati verso Lspvif 1

Utilizzando PIM JOIN (S,G) come protocollo guidato dal destinatario, MLDP crea il database MLDP da ricevitore a origine. Allocazione etichetta downstream per MLDP P2MP.

Nota: Nella segnalazione in banda, le interfacce virtuali (LSPVIF) Label Switched Path vengono create per ingresso-PE per implementare un RPF rigido, ad esempio. accettare un pacchetto (S,G) solo se proviene dal PE remoto previsto; questo è LSPVIF1 nel tuo caso. In un file PE di origine, il valore LSPVIF predefinito viene utilizzato per l'inoltro al core. Si noti che non vi è alcun segno di numeri di interfaccia LSPVIF, ad esempio lspvif0 non è sempre l'interfaccia predefinita e lspvif1 non è sempre l'interfaccia per PE. Questi numeri vengono allocati su richiesta come richiesto.

PE3#sh ip mroute 232.1.1.1 verbose

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,

T - SPT-bit set, p - PIM Joins on route,

(10.1.0.2, 232.1.1.1), 00:19:28/00:02:42, flags: sTp

Incoming interface: Lspvif1, RPF nbr 1.1.1.1

Outgoing interface list:

Ethernet0/0, Forward/Sparse, 00:19:28/00:02:42, p

PE3#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:28:02

FEC Root           : 1.1.1.1

Opaque decoded     : [ipv4 10.1.0.2 232.1.1.1]

Opaque length      : 8 bytes

Opaque value       : 03 0008 0A010002E8010101

Upstream client(s) :

11.11.11.11:0    [Active]

Expires        : Never         Path Set ID  : 1

Out Label (U)  : None          Interface    : Ethernet0/3*

Local Label (D): 24            Next Hop     : 10.0.3.2

Replication client(s):

MRIBv4(0)

Uptime         : 00:28:02      Path Set ID  : None

Interface      : Lspvif1

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 : A   Type: P2MP   Uptime : 00:40:52

FEC Root           : 1.1.1.1

Opaque decoded     : [ipv4 10.1.0.2 232.1.1.1]

Opaque length      : 8 bytes

Opaque value       : 03 0008 0A010002E8010101

Upstream client(s) :

1.1.1.1:0    [Active]

Expires        : Never         Path Set ID  : A

Out Label (U)  : None          Interface    : Ethernet0/1*

Local Label (D): 24            Next Hop     : 10.0.1.1

Replication client(s):

2.2.2.2:0

Uptime         : 00:40:52      Path Set ID  : None

Out label (D)  : 23            Interface    : Ethernet0/3*

Local label (U): None          Next Hop     : 10.0.2.1

3.3.3.3:0

Uptime         : 00:40:52      Path Set ID  : None

Out label (D)  : 24            Interface    : Ethernet0/2*

Local label (U): None          Next Hop     : 10.0.3.1

Informazioni ricevute nel file PE di origine in base alla ricerca RPF per l'hop successivo.

MLDP-LDP: [ipv4 10.1.0.2 232.1.1.1] label mapping from: 11.11.11.11:0 label: 23 root: 1.1.1.1 Opaque_len: 11 sess_hndl: 0x1

MLDP: LDP root 1.1.1.1 added

MLDP-DB: Added [ipv4 10.1.0.2 232.1.1.1] DB Entry

MLDP-DB: [ipv4 10.1.0.2 232.1.1.1] Changing branch 11.11.11.11:0 from Null/0.0.0.0 to Ethernet0/1/10.0.1.2

MLDP-MFI: Could not add Path type: PKT, Label: 23, Next hop: 11.11.11.11, Interface: NULL to set: 3, error 1

MLDP-DB: [ipv4 10.1.0.2 232.1.1.1] Added P2MP branch for 11.11.11.11:0 label 23

MLDP-MRIB-IP: [ipv4 10.1.0.2 232.1.1.1] client update: We are root

MLDP-MRIB-IP: wavl insert success (10.1.0.2, 232.1.1.1)

MLDP-MRIB-IP: [ipv4 10.1.0.2 232.1.1.1] Created: Lspvif0 for: 0.0.0.0

MLDP-MRIB: Created adjacency for LSM ID 3

MLDP-MRIB-IP: [ipv4 10.1.0.2 232.1.1.1] Created adjacency on Lspvif0

MLDP: nhop 1.1.1.1 added

MRT(0): Set the T-flag for (10.1.0.2, 232.1.1.1)

MRT(0): (10.1.0.2,232.1.1.1), RPF install from  /0.0.0.0 to Ethernet0/2/10.1.0.2

PIM(0): Insert (10.1.0.2,232.1.1.1) join in nbr 10.1.0.2's queue

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) update (t=1) RPF: 10.1.0.2

MLDP-MRIB-IP: (10.1.0.2,232.1.1.1/32) set rpf nbr: 10.1.0.2

MLDP-MRIB-IP: ignoring interface Ethernet0/2, no LS

Nota: Utilizzare # debug mpls mldp all e # debug ip bgp ipv4 mvpn updates per verificare la condizione precedente.

PE1#sh ip mroute 232.1.1.1 verbose

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, I - Received Source Specific Host Report,

(10.1.0.2, 232.1.1.1), 00:25:14/stopped, flags: sTI

Incoming interface: Ethernet0/2, RPF nbr 10.1.0.2

Outgoing interface list:

Lspvif0, LSM ID: 4, Forward/Sparse, 00:25:14/00:01:45

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 : 4   Type: P2MP   Uptime : 00:25:25

FEC Root           : 1.1.1.1 (we are the root)

Opaque decoded     : [ipv4 10.1.0.2 232.1.1.1]

Opaque length      : 8 bytes

Opaque value       : 03 0008 0A010002E8010101

Upstream client(s) :

None

Expires        : N/A           Path Set ID  : 4

Replication client(s):

11.11.11.11:0

Uptime         : 00:25:25      Path Set ID  : None

Out label (D)  : 24            Interface    : Ethernet0/1*

Local label (U): None          Next Hop     : 10.0.1.2

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: [ipv4 10.1.0.2 232.1.1.1] label mapping from: 11.11.11.11:0 label: 23 root: 1.1.1.1 Opaque_len: 11 sess_hndl: 0x1

Neighbor 11.11.11.11 request for the label request to PE1.

Nota: Rispondere alle richieste di etichette con caratteri jolly digitati ricevute dal peer rieseguendo il database di etichette per i prefissi. Utilizzare le richieste di etichette con caratteri jolly tipizzate nei confronti dei peer per richiedere la riproduzione del database di etichette peer per i prefissi.

MLDP-LDP: [ipv4 10.1.0.2 232.1.1.1] label mapping from: 11.11.11.11:0 label: 24 root: 1.1.1.1 Opaque_len: 11 sess_hndl: 0x1

MLDP: LDP root 1.1.1.1 added

MLDP-DB: Added [ipv4 10.1.0.2 232.1.1.1] DB Entry

MLDP-DB: [ipv4 10.1.0.2 232.1.1.1] Changing branch 11.11.11.11:0 from Null/0.0.0.0 to Ethernet0/1/10.0.1.2

%MLDP-5-ADD_BRANCH: [ipv4 10.1.0.2 232.1.1.1] Root: 1.1.1.1, Add P2MP branch 11.11.11.11:0 remote label 24

debug ip mfib pak

debug ip mfib mrib

L'origine avvia lo streaming

Traffic from Source 10.1.0.2 streaming from 232.1.1.1. Enters through ethernet0/2.

The packet got forwarded via 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

Packet Capture (PCAP)

Il pacchetto viene tunneling in Lspvif 0.

At the receiver Side:

At the receiver side the packet reach at the 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

Verifica LSPVIF

Quando il pacchetto raggiunge il pacchetto PE1, controlla l'ID LSM per inoltrare il traffico, che ha l'etichetta da imporre nel pacchetto multicast.

Conclusioni

La segnalazione in banda LDP (M-LDP) multipunto consente di trasportare il traffico multicast su una backbone IP/MPLS esistente, evitando al contempo l'uso di PIM nel core del provider.

Sul router Label-Edge (LER), abilitare PIM per utilizzare la segnalazione in banda M-LDP per i vicini a monte quando il LER non rileva un vicino a monte PIM.

Informazioni correlate

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

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

- https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_lsm/configuration/15-sy/imc-lsm-15-sy-book...

- Documentazione e supporto tecnico – Cisco Systems