El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
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.
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.
La señalización MLDP proporciona dos funciones:
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:
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
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.
Tarea 2: Verifique la unidifusión VPNv4 de la Familia de Direcciones BGP.
Tarea 3: Verifique el tráfico de multidifusión de extremo a extremo.
En la entrada PE VRF mRIB en PE1, PE2 y PE3
Tarea 4: Verifique el NÚCLEO MPLS.
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.
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.
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.