Desentrañando Multicast en MPLS con Cisco: Un Enfoque Detallado

La transmisión de datos eficientes a múltiples destinos simultáneamente es una necesidad crítica en las redes modernas. El multicast, en su esencia, permite que una red replique un único paquete a múltiples destinos. Las aplicaciones típicas de multicast incluyen la televisión por IP (IPTV), donde numerosos usuarios pueden ver el mismo canal en vivo al mismo tiempo. La ruta de reenvío utilizada para transportar tráfico multicast se modela típicamente como un árbol, con la fuente como la raíz y los receptores en las hojas. En un árbol multicast, los enrutadores replican el tráfico en los puntos de ramificación. El tráfico fluye de la raíz a las hojas, similar a la savia en un árbol. En este sentido, los términos "aguas arriba" y "aguas abajo" desafían la gravedad: si imaginamos la imagen de un árbol invertida, con la raíz arriba y las hojas abajo, el tráfico fluiría hacia abajo. Con esta imagen en mente, es más fácil entender por qué, en el mundo del multicast, "aguas arriba" significa hacia la raíz (fuente) y "aguas abajo" significa hacia las hojas (receptores). Volvamos a la realidad después de este breve giro imaginativo. En resumen, las tecnologías multicast hacen posible que una red replique un solo paquete a múltiples destinos.

En el contexto de las redes MPLS (Multiprotocol Label Switching), la implementación de multicast presenta desafíos únicos, especialmente cuando se trata de integrar el tráfico del cliente (C-multicast) en la red del proveedor (P-multicast). Este artículo profundiza en la tecnología de Cisco MPLS Multicast VPN (M-VPN), explorando las teorías subyacentes, las configuraciones esenciales y las consideraciones prácticas. Abordaremos la configuración del multicast global, utilizando Source-Specific Multicast (SSM), y luego pasaremos a la configuración de Default-MDT (Multicast Distribution Tree) y Data-MDT.

Fundamentos de Multicast en Redes y la Necesidad de MPLS

El multicast es fundamental para la eficiencia de la red cuando se trata de entregar el mismo contenido a un gran número de destinatarios. A diferencia del unicast, donde cada destino recibe una copia separada del paquete, el multicast envía una sola copia del paquete desde la fuente, y los nodos intermedios de la red se encargan de replicarlo y enviarlo a los receptores interesados. Esta replicación inteligente evita la saturación de la red y optimiza el uso del ancho de banda.

En redes IP tradicionales, el Protocolo Independiente de Multicast (PIM) es el principal protocolo utilizado para construir y mantener árboles multicast. PIM opera en dos modos principales: Dense Mode (DM) y Sparse Mode (SM).

• Dense Mode (DM): Asume que hay receptores en todas las subredes y envía inundaciones de tráfico multicast a todas partes, confiando en que los enrutadores en los bordes de la red supriman el tráfico hacia las subredes sin receptores. Este enfoque es simple pero ineficiente en redes grandes.
• Sparse Mode (SM): Asume que los receptores son escasos y requiere un mecanismo explícito para construir árboles de reenvío. Utiliza un Rendezvous Point (RP) o un mecanismo de descubrimiento de fuentes para establecer el camino del tráfico. El tráfico solo se envía a las subredes que han expresado interés en recibirlo.

Cuando se introducen las redes MPLS, la forma en que se maneja el tráfico multicast cambia significativamente. MPLS está diseñado para túneles de conmutación de etiquetas eficientes, y la integración del tráfico multicast del cliente dentro de estos túneles requiere enfoques específicos. Aquí es donde entran en juego las M-VPNs.

M-VPNs: Uniendo Multicast y MPLS

Las M-VPNs permiten a los proveedores de servicios (SPs) ofrecer servicios de red privada virtual que soportan tráfico multicast a sus clientes, todo ello dentro de una infraestructura MPLS compartida. Esto significa que el tráfico multicast de diferentes clientes puede coexistir en la misma red MPLS sin interferir entre sí.

La terminología utilizada en este artículo sigue la convención común de usar el prefijo "P-" para objetos específicos del proveedor (por ejemplo, rutas o túneles multicast) y el prefijo "C-" para objetos del cliente (por ejemplo, direcciones IP privadas).

M-LDP y la Construcción de Túneles Multipunto

El protocolo Multiprotocol Label Switching (MPLS) Label Distribution Protocol (M-LDP) juega un papel crucial en la señalización y construcción de túneles. M-LDP permite la construcción de LSPs (Label Switched Paths) punto a multipunto (P2MP) y multipunto a multipunto (MP2MP).

• LSP P2MP: Un LSP que comienza en un nodo raíz y se extiende a múltiples nodos hoja.
• LSP MP2MP: Un LSP identificado por una dirección IP raíz compartida y un valor opaco, compartido por todas las hojas. Consiste en secciones descendentes y ascendentes. La parte descendente es un LSP P2MP con raíz en el nodo compartido, y la parte ascendente es un LSP multipunto a punto (MP2P) construido desde el nodo raíz hacia las hojas para permitir que estas últimas envíen tráfico aguas arriba hacia la raíz. Es importante tener en cuenta que los componentes de un LSP MP2P son LSPs de unicast clásicos que conectan cada hoja a la raíz del LSP MP2MP.

Una de las aplicaciones más destacadas de los M-LSPs es el encapsulamiento efectivo del tráfico multicast en redes MPLS. Dado que los M-LSPs se señalan utilizando M-LDP y los árboles multicast utilizan PIM, el problema radica en mapear los árboles multicast a los M-LSPs. Es intuitivamente obvio que los árboles de camino más corto podrían mapearse a LSPs P2MP y los árboles compartidos corresponderían a LSPs MP2MP.

Enfoques de Mapeo: Señalización In-band vs. Out-of-band

Existen dos enfoques principales para implementar el mapeo de árboles multicast a M-LSPs:

1. Señalización In-band: En este enfoque, los mensajes PIM se traducen directamente en enlaces de M-LDP (FEC bindings). Esto permite que el tráfico multicast transite a través de núcleos MPLS habilitados de manera óptima sin necesidad de habilitar PIM y el enrutamiento multicast en el núcleo MPLS. Los dispositivos de borde IP-a-MPLS traducirán los mensajes PIM Join en enlaces M-LDP FEC y codificarán la información de grupo/fuente en valores opacos para que el otro dispositivo de borde convierta el enlace M-LDP FEC en PIM Joins. El trabajo está en curso para estandarizar la señalización in-band en los siguientes borradores de IETF: "draft-wijnands-mpls-mldp-in-band-signaling" y "draft-rekhter-pim-sm-over-mldp".

   • Ventaja: Puede ser útil para implementaciones de M-VPN al traducir directamente todas las uniones PIM del cliente en grupos P2MP del núcleo. Este enfoque también se conoce como "Direct MDT" y su beneficio es el hecho de que no se necesitan adyacencias PIM del cliente en la interfaz del túnel SP.
   • Desventaja: El inconveniente masivo es el crecimiento incontrolado del estado de reenvío en el núcleo del SP, lo que limita seriamente la escalabilidad de este enfoque.

2. Señalización Out-of-band: Este enfoque es bien conocido por la implementación de MVPN de Rosen, donde los puntos finales de M-VPN se descubren mediante extensiones MP-BGP y los MDTs se mapean a grupos multicast del núcleo SP (túneles P) mediante configuración manual. Con algunas modificaciones, este enfoque podría adaptarse para usar M-LSPs como transporte (túneles P o P-Tunnels) en lugar de mGRE.

   • Default MDT: Podría instanciarse como un LSP MP2MP que conecta todos los PEs (Provider Edge) que participan en una M-VPN particular.
   • Data MDTs: Podrían crearse dinámicamente bajo demanda mapeando flujos multicast seleccionados a túneles P más óptimos instanciados como LSPs P2MP.
   • Ventaja: Mucho más escalable que la señalización in-band para M-VPNs.
   • Limitación: Aún requiere PIM para señalar grupos multicast del cliente, lo que resulta en una malla completa de adyacencias C-PIM superpuestas entre los routers PE, una malla por cada M-VPN implementada. Además, PIM, al ser un protocolo de estado blando, re-señaliza periódicamente todos los árboles, lo que supone una carga adicional para los routers PE. El trabajo está en curso para reducir la cantidad de mensajes de actualización de PIM, conocido como "reducción de actualización".

Implementación Práctica de M-VPNs con M-LDP en Cisco

La implementación de M-VPNs utilizando M-LDP para la señalización de túneles P (out-of-band) ofrece varias ventajas, especialmente en comparación con el uso de mGRE (multipoint Generic Routing Encapsulation).

Ventajas de M-LDP sobre mGRE

• Reducción de la sobrecarga de señalización PIM: Al utilizar M-LDP para construir los túneles P, se reduce la necesidad de que PIM opere en el núcleo de la red del proveedor.
• Protección de tráfico con MPLS TE FRR: Los M-LSPs señalizados con M-LDP pueden beneficiarse de la protección de tráfico mediante Fast Reroute (FRR) de Traffic Engineering (TE) de MPLS. Esto permite una rápida recuperación ante fallos de enlaces o nodos.
• Ingeniería de Tráfico: Si bien los LSPs P2MP señalizados con RSVP-TE basados en fuente tienen la capacidad de utilizar la base de datos de ingeniería de tráfico para una utilización óptima de los recursos, los LSPs M-LDP señalizados dinámicamente en orden descendente no permiten el pre-cálculo y la reserva de recursos. Sin embargo, el uso de M-LSPs en lugar de mGRE permite una protección de tráfico efectiva mediante un enrutamiento recursivo: si un nodo aguas arriba detecta que la mejor ruta a un nodo aguas abajo cruza un túnel MPLS, la rama M-LSP correspondiente se redirige a través del túnel utilizando una etiqueta de túnel adicional.

Configuración Clave y Consideraciones

Para implementar M-VPNs con M-LDP, se deben seguir varios pasos de configuración:

1. Habilitar LDP y MPLS en interfaces: Asegurarse de que MPLS y LDP estén habilitados en las interfaces del núcleo del proveedor (P-interfaces) y en las interfaces de borde del cliente (PE-interfaces).
2. Configurar VRFs con un Identificador de VPN: El VPN ID está estandarizado en RFC 2685 y sirve para identificar la misma VPN en múltiples PEs, posiblemente abarcando múltiples ASs. A diferencia de los RDs (Route Distinguishers) y RTs (Route Targets), este valor es el mismo entre todos los sitios y puede ser utilizado por protocolos como RADIUS o DHCP para asignar la información de configuración adecuada. M-LDP utiliza el VPN-ID para la construcción del valor opaco compartido por todos los PEs para una M-VPN dada. El VPN-ID reemplaza el uso del grupo multicast del núcleo SP compartido que era necesario para los túneles P basados en mGRE. El formato para el VPN-ID es "OUI:Unique-ID", donde ambos valores están en hexadecimal.
3. Especificar la Dirección IP Raíz del MDT Predeterminado: Esto es necesario para crear el LSP MP2MP compartido conocido por todos los PEs para una M-VPN particular. Este LSP se utiliza para establecer adyacencias C-PIM y reenviar todo el tráfico multicast por defecto. Cabe destacar que una única raíz puede ser utilizada por múltiples M-VPNs siempre que utilicen diferentes VPN-IDs. En implementaciones del mundo real, la ubicación del nodo raíz es importante, ya que por defecto solo se utiliza un túnel P para todo el tráfico de M-VPN, lo que resulta en una carga adicional en la raíz MP2MP, ya que se supone que todo el tráfico de M-VPN transita por este enrutador.
4. Configurar el número de MDTs de datos disponibles para una VRF dada: Este valor es específico por VRF y por enrutador. Al igual que los MDTs de datos clásicos (multicast mGRE), se configura el umbral de tráfico (por defecto no hay cambio) que debe cruzarse para que el PE señale un LSP P2MP separado para los flujos multicast que exceden ese umbral. No es necesario especificar el valor opaco similar al rango de grupos multicast necesarios para VPNs mGRE. Se reutilizará el mismo valor opaco, sin embargo, los LSPs de MDT de datos tendrán como raíz la dirección IP de BGP Next-Hop correspondiente a la dirección IP de la C-fuente multicast. Tenga en cuenta que múltiples MDTs de datos construidos por diferentes PEs hacia la misma raíz se fusionarán efectivamente en el núcleo debido a que comparten el mismo VPN-ID.

Ejemplo de Configuración y Verificación

Consideremos una topología de ejemplo que consta de tres enrutadores (R1, R2, R3) formando un núcleo SP libre de multicast que utiliza M-LDP en el núcleo y túneles de respaldo automáticos de un salto para la protección de tráfico. Los enrutadores CE1 y CE2 del dominio del cliente utilizan PIM SSM para la señalización multicast, y CE2 se une al grupo 232.1.1.1 originado en CE1 utilizando IGMPv3.

La configuración habilitaría LDP y RSVP-TE en el núcleo, configurando automáticamente túneles primarios y de respaldo de un salto. Un proceso OSPF se configuraría para la autoconfiguración de LDP. Se crearía una VRF en el enrutador, y R1 se configuraría para emparejarse con R2 utilizando el intercambio de la familia de direcciones VPN-IPv4. No hay enrutamiento multicast habilitado en las P-interfaces; solo la VRF se configura para enrutamiento multicast utilizando PIM-SSM.

La configuración de M-LDP crearía un único MDT predeterminado basado en MPLS utilizando el Loopback0 de R3 como nodo raíz. El valor opaco para este LSP MP2MP se construiría basándose en el valor del VPN ID de 100:1. Además, los MDTs de datos se activarían cuando el flujo de tráfico supere 1 Kbps. El límite de Data MDT es 10 por VRF. Y, por último, R3 se configuraría como un enrutador P puro.

Los tres enrutadores se configurarían para túneles primarios y de respaldo de un salto, lo que permite una protección completa de los enlaces: cada fallo de enlace en esta topología estaría protegido por Fast-Reroute.

Verificación:

Tras la configuración, se realizarían varias verificaciones:

• Estado de M-LDP: Observar la salida de M-LDP para confirmar la presencia de rutas adicionales a cada par a través de túneles MPLS TE que no tengan LDP habilitado. Esto se debe a la activación del comando mpls mldp path traffic-eng.
• Túneles de Ingeniería de Tráfico Locales: Comprobar los túneles de ingeniería de tráfico locales en R1 para ver si los túneles mencionados anteriormente son túneles primarios de un salto hacia R2 y R3 respectivamente.
• Existencia del LSP MP2MP: Validar la existencia del LSP MP2MP para la VPN configurada en R1 y R2. Este LSP debería tener como raíz R3, y tanto R1 como R2 deberían tener componentes ascendentes y descendentes de este LSP. El componente ascendente (U) del LSP MP2MP utiliza la etiqueta 17 y el túnel 65337 para llegar al siguiente salto ascendente hacia el nodo raíz.
• Clientes de replicación: Los nodos aguas abajo del LSP P2MP que deben recibir el tráfico replicado multipunto se conocen como clientes de replicación. En este caso, el cliente de replicación es la VRF MVRF habilitada para multicast, que utiliza la interfaz virtual LSPVIF0 como interfaz multicast de "entrada". Esta interfaz es la abstracción utilizada por Cisco IOS para representar el LSP P2MP de terminación.
• Tabla de reenvío MPLS: Al verificar la tabla de reenvío MPLS en R1, se observaría que la etiqueta del componente descendente P2MP se mapea a "MDT 100:1" utilizando una operación de búsqueda agregada.
• Etiquetas en la Raíz del LSP MP2MP: Se examinaría la raíz del LSP MP2MP para obtener información sobre las etiquetas ascendentes y descendentes. La salida ilustraría que R3 ve dos clientes P2MP LSP descendentes para el valor opaco "mdt 100:1" y utiliza la etiqueta 21 para ambos. Ambos clientes descendentes son alcanzables a través de los túneles TE. Además, se anuncian dos etiquetas "upstream MP2P" por R3 a R1 y R2 respectivamente para ser utilizadas para el encapsulamiento del tráfico ascendente.
• Adyacencias C-PIM: Tras asegurar la existencia del LSP MP2MP, se verificarían las adyacencias C-PIM que deberían haberse establecido utilizando el LSP MP2MP. Las adyacencias se establecerían sobre la interfaz LSPVIF0, que parece ser la fuente real del paquete multicast para cada instancia C-PIM.
• Conectividad del Plano de Datos: Se probaría la conectividad del plano de datos enviando paquetes ping de origen a 232.1.1.1 desde CE1. La salida indicaría que los paquetes ICMP recibidos llegan en encapsulación MPLS utilizando la etiqueta descendente de 21. Se observaría claramente el paquete MPLS recibido en el LSP ascendente con la etiqueta de 17 y transmitido aguas abajo en la interfaz del túnel que conecta R3 con R2 utilizando la etiqueta descendente de 21. Esto completaría la prueba de conectividad básica y LSP MP2MP.
• Prueba de FRR: Se probaría el FRR tal como se aplica al LSP MP2MP. Observando el estado de los túneles MPLS TE, y devolviendo las cosas a la normalidad en R3 (por simplicidad), se intentaría un flood ping desde CE1 al grupo 232.1.1.1 (con un valor de tiempo de espera de cero).

Estado Actual y Futuro de M-LDP en M-VPNs

M-LDP ha alcanzado la fase de despliegue inicial y puede utilizarse para implementaciones de M-VPNs intra-AS. Las dos ventajas principales de usar M-LDP sobre el transporte mGRE son la reducción de la sobrecarga de señalización PIM y la opción de proteger el tráfico multicast utilizando MPLS TE FRR. Sin embargo, a diferencia de los LSPs P2MP basados en RSVP-TE señalizados por fuente, los LSPs señalizados con M-LDP no admiten ingeniería de tráfico, solo enrutamiento recursivo sobre túneles TE.

La versión de IOS utilizada para las pruebas admite M-VPNs basadas en túneles P señalizados por M-LDP (fuera de banda), pero no parece admitir la señalización in-band de LSPs M-LDP. Sin embargo, algunos comandos M-LDP dan una idea de que M-LDP ya admite los tipos opacos necesarios para implementar la señalización in-band. Muchas de las características de M-LDP se están desarrollando y experimentando actualmente. Los comandos utilizados en este artículo aún no están documentados públicamente y anunciados oficialmente, pero todavía están disponibles en IOS 12.2SR soportado para emuladores 7200 en Dynamips.

La implementación de M-VPNs con M-LDP representa un avance significativo en la entrega eficiente y escalable de tráfico multicast en entornos MPLS, ofreciendo un equilibrio entre el rendimiento, la flexibilidad y la protección del tráfico.

tags: #multicast #in #mpls #cisco