Contenido

Introducción

Antecedentes

Señalización MLDP

Señalización en banda

Señalización superpuesta o fuera de banda

Clase de equivalencia de reenvío de comodín (FEC) con tipo de protocolo de distribución de etiquetas (LDP) # RFC5918

Topología

Señalización superpuesta

Configuración

Verificación

¿Cómo se crea un plano de control?

MLDP P2MP

Conclusión

Información Relacionada

Introducción

Este documento describe el VRF MLDP de señalización en banda que es el Perfil 6 para Multicast de Última Generación sobre VPN (mVPN). Utiliza un ejemplo y la implementación en Cisco IOS para ilustrar el comportamiento.

Antecedentes

Señalización en banda del protocolo de distribución de etiquetas de multidifusión (MLDP) para permitir que el núcleo MLDP cree un estado (S,G) o (*,G) sin utilizar la señalización fuera de banda, como el protocolo de gateway fronterizo (BGP) o la multidifusión independiente de protocolo (PIM).

La VPN de multidifusión admitida por MLDP (MVPN) permite agregar secuencias de multidifusión VPN a través de un árbol específico de VPN.

No se crea ningún estado de cliente en el núcleo de MLDP. Hay el único estado para los árboles de distribución de multidifusión de datos (MDT) y predeterminados.

En algunos escenarios, el estado creado para los flujos de VPN es limitado y no parece ser un factor de riesgo o limitante. En estos escenarios, MLDP puede generar MDT dentro de banda que sean Trayectorias conmutadas por etiquetas de tránsito (LSP).

Los árboles utilizados en un espacio VPN son MDT. Los árboles utilizados en la tabla global son LSP de tránsito punto a multipunto (P2MP) o multipunto a multipunto (MP2MP).

En ambos casos, un único flujo de multidifusión (VPN o no) se asocia a un único LSP en el núcleo MPLS. La información de flujo se codifica en la clase de equivalencia de reenvío (FEC) del LSP. Esto es señalización en banda.

LSM proporciona ventajas en comparación con los túneles de núcleo GRE que se utilizan actualmente para transportar el tráfico del cliente en el núcleo y aprovecha la infraestructura MPLS para transportar paquetes de multidifusión IP, proporcionando un plano de datos común para unidifusión y multidifusión.

Señalización MLDP

La señalización MLDP proporciona dos funciones:

- Para descubrir la FEC (y su valor opaco asociado) para un LSP MP

- Para asignar un flujo de multidifusión a un LSP MP

Señalización en banda

- El valor opaco se utiliza para asignar un LSP MP a un flujo de multidifusión IP.

- El contenido del valor opaco se deriva del flujo multicast.

Señalización superpuesta o fuera de banda

- Utiliza un protocolo de superposición para asignar un LSP MP a un flujo de multidifusión IP.

- El PE raíz de ingreso puede asignar un valor opaco o configurarlo estáticamente.

- MP LSP se crea a demanda o se puede configurar previamente.

- Permite agregar secuencias de multidifusión en un único MP LSP.

Protocolo de distribución de etiquetas (LDP) Clase de equivalencia de reenvío (FEC) con tipo comodín # RFC5918

El elemento FEC comodín con tipo hace referencia a todos los FEC del tipo especificado que cumplen la restricción.  Especifica un 'tipo de elemento FEC' y una restricción opcional, que está diseñada para proporcionar información adicional.

El formato del elemento FEC comodín con tipo es:

Comodín con tipo: Tipo de elemento FEC de un octeto (0x05).

LDP [RFC5036] distribuye etiquetas para las clases de equivalencia de reenvío (FEC).  LDP utiliza TLV FEC en los mensajes LDP para especificar FEC.

Un TLV LDP FEC incluye uno o más elementos FEC.  Un elemento FEC incluye un tipo FEC y un valor opcional dependiente del tipo.

RFC 5036 especifica dos tipos FEC (Prefijo y Comodín) y otros documentos especifican tipos FEC adicionales; Por ejemplo, consulte [RFC447] y [MLDP].

Según lo especificado por RFC 5036, el elemento FEC comodín se refiere a todos los FEC relativos a una restricción opcional.

La única restricción RFC 5036 especifica es una que limita el alcance del elemento FEC comodín a "todos los FEC enlazados a una etiqueta dada".

La especificación RFC 5036 del elemento FEC comodín presenta estas deficiencias que limitan su utilidad:

- El elemento FEC comodín no tiene tipo.  Hay situaciones en las que sería útil poder hacer referencia a todos los FEC de un tipo determinado (como otra restricción).

- El uso del elemento FEC comodín se limita sólo a los mensajes de retirada de etiquetas y liberación de etiquetas.  Hay situaciones en las que sería útil tener un elemento FEC comodín, con restricción de tipo, en los mensajes de Solicitud de etiqueta.

Topología

Señalización superpuesta

Configuración

Paso 1. Habilite MPLS MLDP en nodos de núcleo.

# mpls mldp logging

Paso 2. Habilite la SEÑALIZACIÓN DE ENTRADA MLDP en el NÚCLEO.

En PE1, PE2 y PE3

# ip multicast vrf INBAND-MLDP mpls mldp

# ip pim vrf INBAND-MLDP mpls source loopback 0

Paso 3. Habilite PIM SM en todas las interfaces CE y la interfaz PE VRF.

En CE1, CE2, CE3 y todas las interfaces VRF PE1, PE2 y PE3

# interface x/x

# ip pim sparse-mode

# interface loopback x/x

# ip pim sparse-mode

Nota: Habilite PIM-Mode sólo en interfaces de cara CE en routers de borde del proveedor; no se requiere en el núcleo.

Paso 4. Habilite multicast en el VRF.

En PE1, PE2 y PE3

# ip multicast-routing vrf INBAND-MLDP

Paso 5. Habilite el VRF en la interfaz PE-CE x/x del router PE.

# interface x/x

# ip vrf forwarding INBAND-MLDP

Paso 6. Configure el modo SSM en nodos CE y PE (sólo VRF).

En nodos CE

# ip pim ssm default

En PE1, PE2, PE3 bajo VRF

# ip pim vrf INBAND-MLDP ssm default

Paso 7. Configure el grupo IGMP SSM 232.1.1.1 (receptor).

En el receptor 2 y 3

CE #interface x/x

# ip pim Join-group 232.1.1.1 source 10.1.0.2

Verificación

IGP, MPLS LDP, BGP funciona bien en nuestra red de extremo a extremo.

En esta sección, la verificación se realiza para verificar la adyacencia de VPN AF en la red de núcleo/agregación. La adyacencia se verifica entre CE-PE y el plano de control también se verifica junto con el plano de datos para el tráfico VPN sobre la red MPLS.

Para comprobar que los dispositivos periféricos de cliente (CE) locales y remotos pueden comunicarse a través del núcleo de switching de etiquetas multiprotocolo (MPLS), lleve a cabo estas tareas:

Tarea 1: Verifique la conectividad física.

- Verifique que toda la interfaz conectada esté ACTIVADA.

Tarea 2: Verifique la unidifusión VPNv4 de la Familia de Direcciones BGP.

- Verifique que BGP esté habilitado en todos los routers para que la unidifusión AF VPNv4 y los vecinos BGP estén ACTIVOS.

- Verifique que la tabla de unidifusión VPNv4 de BGP tenga todos los prefijos del cliente.

Tarea 3: Verifique el tráfico de multidifusión de extremo a extremo.

- Verifique la vecindad PIM con el vecino PIM conectado.

- Verifique que el estado multicast se cree en el VRF.

En la entrada PE VRF mRIB en PE1, PE2 y PE3

- Verifique que la entrada mFIB de VRF (S, G), el paquete se incrementa en el reenvío de software.

- Verifique que los paquetes ICMP lleguen de CE a CE.

Tarea 4: Verifique el NÚCLEO MPLS.

- Verifique el núcleo MPLS LSP.

- Verifique el reenvío MPLS dentro del núcleo según el diseño.

- Verifique el funcionamiento del ping MPLS P2MP LSP.

¿Cómo se crea un plano de control?

Verifique el plano de control que la imposición de Label ocurre cuando el router PE se reenvía en función del encabezado IP y agrega una etiqueta MPLS al paquete al ingresar a una red MPLS.

En la dirección de la imposición de etiquetas, el router conmuta los paquetes según una búsqueda de tabla CEF para encontrar el salto siguiente y agrega la información de etiqueta apropiada almacenada en la FIB para el destino. Cuando un router realiza un intercambio de etiquetas en el núcleo en un paquete MPLS, el router realiza una búsqueda de tabla MPLS. El router deriva esta tabla MPLS (LFIB) de la información de la tabla CEF y de la Base de información de etiquetas (LIB).

La disposición de la etiqueta ocurre cuando el router PE recibe un paquete MPLS, toma una decisión de reenvío basada en la etiqueta MPLS, quita la etiqueta y envía un paquete IP. El router PE utiliza el LFIB para la determinación de la trayectoria de un paquete en esta dirección.Como se indicó anteriormente, una sesión iBGP especial facilita el anuncio de prefijos VPNv4 y sus etiquetas entre routers PE. En el PE de anuncio, BGP asigna etiquetas para los prefijos VPN aprendidos localmente e los instala en el LFIB, que es la tabla de reenvío MPLS.

Paso 1. Una vez que configure el MLDP en el núcleo. Estos mensajes se intercambian.

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.

Utilice esta depuración para comprobar el establecimiento anterior:

# debug mpls mldp all

Nota: Responda a las solicitudes de etiquetas comodín con tipo recibidas del par reproduciendo su base de datos de etiquetas para los prefijos. Utilice las solicitudes de etiquetas comodín con tipo hacia los pares para solicitar una repetición de la base de datos de etiquetas de peer para los prefijos.

Paso 2. Habilite INBAND SIGNALING en 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

Nota: MPLS MLDP todavía no se ha creado porque el receptor todavía no está en línea.

Cuando el receptor se conecta:

El receptor 3 se conecta y envía los mensajes 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

Cualquier comunicación de la Unión del Receptor (S,G) se convertirá en MLDP y todos los mensajes se transmitirán hacia el Lspvif 1

Con PIM JOIN (S,G) como MLDP es un protocolo dirigido por el receptor, comienza a construir la base de datos MLDP de Receptor a Origen. Esta es la asignación de etiquetas descendentes para MLDP P2MP.

MLDP P2MP

El transporte de paquetes P2MP se implementa mediante el protocolo de reserva de recursos (RSVP) P2MP: la ingeniería de tráfico (P2MP-TE) y el transporte de paquetes M2M se implementan a través de la VPN multidifusión IPv4 (MVPN) mediante el protocolo de distribución de etiquetas de multidifusión (MLDP).

El paquete se transporta a través de tres tipos de routers:

Router de cabecera ·: Encapsula el paquete IP con una o más etiquetas.

Router · de punto medio: Reemplaza la etiqueta con una etiqueta externa.

Router de extremo ·: Quita la etiqueta del paquete.

Flujo de Paquetes en la Red MVPN Basada en MLDP Para cada paquete entrante, MPLS crea varias etiquetas out. Los paquetes de la red de origen se replican a lo largo de la trayectoria a la red del receptor. El router CE1 envía el tráfico de multidifusión IP nativo. El router PE1 impone una etiqueta al paquete multicast entrante y replica el paquete etiquetado hacia la red de núcleo MPLS. Cuando el paquete alcanza el router de núcleo (P), el paquete se replica con las etiquetas apropiadas para el MDT predeterminado MP2MP o el MDT de datos P2MP y se transporta a todos los PE de salida. Una vez que el paquete alcanza el PE de salida, se elimina la etiqueta y el paquete de multidifusión IP se replica en la interfaz 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 creado en dispositivos 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

Cuando Source comienza a transmitir:

Cuando el origen multicast comienza a enviar tráfico, [10.1.0.2, 232.1.1.1] ocurre como se muestra en esta imagen.

Tráfico desde el origen 10.1.0.2 en streaming desde 232.1.1.1. Ingresa a través de ethernet0/2.

El paquete fue reenviado a través de 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

Este paquete se tuneliza en el Lspvif 0.

En el lado receptor:

En el lado del receptor, el paquete llega al 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

Cuando el paquete llega al PE1, verifica el ID de LSM para reenviar el tráfico, que etiqueta para imponer en el paquete de multidifusión.

Esta imagen muestra la verificación de la interfaz LSPVIF.

Para cada paquete entrante, MPLS crea varias etiquetas salientes. Los paquetes de la red de origen se replican a lo largo de la trayectoria a la red del receptor. El router CE1 envía el tráfico de multidifusión IP nativo. El router PE1 impone una etiqueta al paquete multicast entrante y replica el paquete etiquetado hacia la red de núcleo MPLS.

Cuando el paquete alcanza el router de núcleo (P), el paquete se replica con las etiquetas apropiadas para el MDT predeterminado MP2MP o el MDT de datos P2MP y se transporta a todos los PE de salida. Una vez que el paquete alcanza el PE de salida, se elimina la etiqueta y el paquete de multidifusión IP se replica en la interfaz VRF.

Conclusión

La configuración de MLDP MVPN habilita la entrega de paquetes multidifusión IPv4 mediante MPLS. Esta configuración utiliza etiquetas MPLS para construir árboles de distribución multidifusión (MDT) predeterminados y de datos.

La replicación MPLS se utiliza como mecanismo de reenvío en la red principal. Para que la configuración MLDP MVPN funcione, asegúrese de que la configuración MPLS MLDP global esté habilitada.

Información Relacionada

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

- 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.pdf

- Soporte Técnico y Documentación - Cisco Systems