Señalización en banda de MULTICAST de última generación (VRF MLDP: Perfil 6)
Contenido
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
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
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
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.
Comentarios