Capítulo 4. Multidifusión de Internet por MPLS
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Este capítulo describe la Multidifusión Global por Internet, a diferencia del Capítulo 5, que se centra en la Multidifusión VPN. Empecemos con una introducción básica a la multidifusión que también debería ayudar a comprender mejor el Capítulo 5.
Los paquetes multidifusión fluyen desde una fuente determinada (S) a un grupo (G) de receptores, a diferencia de los paquetes unidifusión, que se destinan a un único receptor. La ruta de reenvío utilizada para transportar la multidifusión suele modelarse como un árbol, en el que la fuente es la raíz y los receptores se sitúan en las hojas. En un árbol multidifusión, los routers replican el tráfico en los puntos de ramificación. El tráfico fluye de la raíz a las hojas, como la savia en un árbol. En ese sentido, los términos ascendente y descendente desafían a la gravedad: toma una imagen de un árbol y ponla boca abajo, con la raíz en la parte superior y las hojas en la parte inferior, y deja que el tráfico fluya hacia abajo. Con esta imagen en mente es más fácil entender por qué, en el terreno de la multidifusión, ascendente significa hacia la raíz (fuente) y descendente es hacia las hojas (receptores). Los paquetes multidifusión fluyen aguas abajo de forma punto a multipunto.
Volvamos a la realidad después de este breve retorcimiento de la imaginación. En pocas palabras, las tecnologías de multidifusión hacen posible que una red replique un único paquete a múltiples destinos. Una aplicación de multidifusión popular y típica es la televisión IP (IPTV), por la que muchos usuarios residenciales y móviles pueden estar viendo el mismo canal en directo al mismo tiempo. Si la fuente tuviera que replicar y producir miles o millones de copias para cada paquete, los requisitos en términos de potencia de procesamiento y ancho de banda de red en el sitio de origen serían enormes, por no mencionar el impacto en la latencia. Afortunadamente, la fuente de IPTV suele ser un servidor (o un clúster) que sólo envía una copia del flujo multidifusión desde su interfaz de red. Pero, ¿cómo puede llegar este flujo a todos los receptores? La multidifusión resuelve el reto: la red del proveedor de servicios (SP) construye un árbol que replica el paquete original, garantizando que cada receptor reciba una y sólo una copia del mismo. Este árbol realiza una replicación eficiente en los puntos de ramificación; así, sólo una copia de cada paquete atraviesa un determinado enlace de red.
Hay muchas otras aplicaciones de multidifusión, cada una con requisitos diferentes. Algunas de ellas tienen tasas de bits bajas y una latencia estrictamente baja (por ejemplo, la distribución de datos bursátiles en tiempo real a empresas de trading, o la transmisión de señales de radar a operadores de control aéreo). Otras aplicaciones multidifusión mueven grandes volúmenes de tráfico y tienen requisitos de latencia variados, como las videoconferencias, o la distribución de software y medios a repositorios y cachés.
Este capítulo trata de la distribución de multidifusión IPv4 a través de un núcleo MPLS para dos tipos de servicio: Multidifusión por Internet (en la Tabla de Enrutamiento Global) y Multidifusión IP VPN. Aunque IPv6 no se trata en profundidad, la configuración y la mecánica son muy similares.
Pero, antes de sumergirnos en los servicios, repasemos primero los fundamentos de la multidifusión IP.
Multidifusión IP
Un flujo IP multidifusión suele representarse como (S, G), donde S y G son las direcciones IP de origen y destino de los paquetes de datos, respectivamente:
- S
- Se trata de una dirección IP unidifusión (v4 o v6), que representa a un único host. Este host (S) es la fuente del flujo multidifusión.
- G
- Se trata de una dirección IP multidifusión, que representa a un grupo de hosts (receptores) interesados en recibir el tráfico.
¿Cuál es la diferencia entre una dirección IP unidifusión y una multidifusión? Ambas tienen un aspecto similar, pero hay rangos de direcciones bien conocidos que están reservados para la multidifusión:
-
El rango de direcciones de multidifusión IPv4 es 224/4, es decir, de 224.0.0.0 a 239.255.255.255
-
El rango de direcciones de multidifusión IPv6 es ff00::/8
No todas las direcciones IP de multidifusión son enrutables entre dominios. Todas las direcciones de los rangos 224/24 y ff02::/16 son link-local y, por tanto, no son enrutables. Por poner un ejemplo, los paquetes hola LDP no dirigidos tienen como dirección IP de destino 224.0.0.2. Para obtener una lista completa de los rangos de direcciones de multi difusión reservados para diferentes fines, consulta el Registro del Espacio de Direcciones de Multidifusión IPv4 e IPv6 en el sitio web de la IANA.
En los dominios Ethernet de Capa 2 (L2), los paquetes IP Multicast se encapsulan dentro de una cabecera Ethernet. La tarjeta de interfaz de red que introduce la trama en el dominio L2 simplemente copia su propia dirección MAC en el campo Dirección MAC de origen de la cabecera Ethernet de la trama; así funciona Ethernet. Pero la dirección MAC de destino es especial:
- Multidifusión IPv4
- El Protocolo de Resolución de Direcciones (ARP) no juega ningún papel aquí. Los últimos 23 bits de la dirección IPv4 Multicast se añaden al prefijo MAC 01:00:5e para formar una dirección MAC de destino. Por ejemplo, los paquetes IPv4 destinados a 232.1.2.3 se encapsulan en una cabecera Ethernet con la dirección MAC de destino 01:00:5e:01:02:03.
- Multidifusión IPv6
- El Descubrimiento de Vecinos (ND) no juega ningún papel aquí. Los últimos 32 bits de la dirección IPv6 Multicast se añaden al prefijo 33:33 MAC. Por ejemplo, los paquetes IPv6 destinados a ff3e::0001:0203 tienen la dirección MAC de destino 33:33:00:01:02:03.
En realidad, hay algo en común entre los prefijos 01:00:5e y 33:33. El último bit del primer octeto se pone a 1 en ambos casos. En Ethernet, cualquier trama con ese bit puesto a 1 se considera una trama de multidifusión(no necesariamente IP). Muchos protocolos no IP utilizan este tipo de direcciones MAC de destino. Por ejemplo, los hellos punto a punto y LAN de Sistema Intermedio a Sistema Intermedio (IS-IS) se envían a las direcciones MAC 09:00:2b:00:00:05 y 01:80:c2:00:00:15, respectivamente.
Del mismo modo, en las tramas unidifusión, la dirección MAC de destino tiene el último bit del primer octeto puesto a 0. Normalmente, una dirección MAC unidifusión se resuelve dinámicamente mediante ARP (en IPv4) o ND (en IPv6); a diferencia de las direcciones MAC multidifusión, que se calculan estáticamente con la regla matemática explicada en los párrafos anteriores.
Protocolos IP Multicast
Las fuentes de multidifusión son sin estado. Se limitan a enviar los paquetes desde una interfaz de red a un segmento de red local. Este segmento puede contener receptores locales y, lo que es más importante, también uno o varios enrutadores con capacidad multidifusión, denominados enrutadores de primer salto (FHR).
En cambio, los receptores finales son de estado y señalan sus suscripciones multidifusión mediante un protocolo de enlace local: Internet Group Management Protocol (IGMP) para grupos IPv4, y Multicast Listener Discovery (MLD) para grupos IPv6. Es de esperar que exista un router con capacidad de multidifusión conectado localmente al mismo segmento que los receptores. Dicho dispositivo se denomina Enrutador de Último Salto (LHR), y procesa los mensajes IGMP y MLD locales.
¿Qué ocurre si un FHR y un LHR están a varios saltos de distancia el uno del otro? Pues bien, un árbol multidifusión debe conectar el FHR con el LHR, de forma que todos los segmentos con receptores locales puedan recibir los paquetes multidifusión. ¿Y cómo se señaliza dicho árbol? Ésta es la función principal del protocolo de multidifusión independiente del protocolo (PIM).
PIM tiene funciones adicionales, como el descubrimiento de fuentes de multidifusión, y también proporciona un mecanismo de redundancia en topologías con varios FHR (o varios LHR) en el mismo segmento.
Modos de multidifusión IP
El PIM puede funcionar en dos modos principales:
- Modo disperso
- En el modo disperso (RFC 4601, standards track), los receptores activan la señalización del árbol multidifusión. En otras palabras, un flujo multidifusión se reenvía de forma nativa si, y sólo si, hay receptores aguas abajo para ese flujo. Esto da lugar a una utilización eficiente de los recursos de ancho de banda.
- Modo Denso
- En el Modo Denso (RFC 3973, vía experimental), el tráfico se inunda primero por todos los caminos posibles, en caso de que haya receptores. Después, si no hay receptores por un camino determinado, esa rama se poda del árbol de multidifusión. Este modo se utiliza raramente, porque no es escalable en términos de ancho de banda y señalización. Por lo tanto, no se trata en este libro.
Dentro del modo PIM disperso, hay tres submodos: Multidifusión de Cualquier Fuente (ASM), Multidifusión de Fuente Específica (SSM) y Bidireccional (BIDIR).
Nota
La documentación de Cisco suele utilizar el término Modo Sparse para referirse sólo a ASM. En sentido estricto, el Modo Sparse es en realidad un superconjunto que incluye ASM, SSM y BIDIR. Este libro utiliza la terminología estándar.
Algunos receptores simplemente se suscriben a un grupo G si están interesados en recibir todo el tráfico destinado a la dirección del grupo G, independientemente de qué fuentes estén activas para ese grupo. Estos receptores generan una suscripción (*, G), o ASM mediante IGMP o MLD.
Otros receptores también especifican la fuente S de la que quieren recibir tráfico multidifusión. Estos receptores generan una suscripción (S, G), o SSM mediante IGMP o MLD. El RFC 4607 enumera todas las direcciones IP multidifusión reservadas para el uso de SSM. En el caso de IPv4, el rango de direcciones SSM por defecto es 232/8, o 232.0.0.0 a 232.255.255.255. También puedes configurar la red para que utilice direcciones fuera de este rango para SSM.
No existe una línea fronteriza sólida entre ASM y SSM. Aunque un receptor envíe un mensaje ASM (*, G), en algún momento la red puede acabar señalizando el estado SSM (S, G) directamente hacia la fuente (upstream). Hay varios escenarios en los que esto ocurre, y los verás más adelante en este capítulo.
Tanto ASM como SSM tienen pros y contras. Aunque ASM es más sencillo para el receptor, SSM lo es para la red. A los routers les resulta mucho más fácil construir un árbol multidifusión si las fuentes se conocen de antemano que si deben descubrir las fuentes desde cero. Por esta razón, el ASM se deja para el final del Capítulo 5.
En ASM y SSM, los árboles multidifusión son unidireccionales: transportan el tráfico de las fuentes a los receptores. En cambio, BIDIR (RFC 5015) cubre un caso de uso especial para el que las fuentes también pueden ser receptores, y viceversa. Para estas aplicaciones, tiene sentido construir un árbol bidireccional.
Nota
Este libro se centra en ASM y SSM, los modos más comunes.
La multidifusión en general y el PIM en particular tienen mucha terminología. En lugar de repasarla toda desde cero, vamos a introducirla gradualmente a medida que avancen los ejemplos.
Multidifusión clásica por Internet
La multidifusión por Internet es el transporte de tráfico global de multidifusión IP a través de un núcleo SP. Los perímetros proveedores (PEs) reenvían los paquetes en el contexto de la Tabla de Enrutamiento Global (GRT). En otras palabras, no hay VPN implicada en este servicio. Por otra parte, Clásico implica sin MPLS: el punto de partida es, por tanto, muy similar al del Capítulo 1, y la necesidad de MPLS (o túnel IP) aparecerá de forma natural.
Iniciar fuentes y receptores de multidifusión
La Figura 4-1 muestra la topología de este capítulo. Las métricas IS-IS están configuradas inicialmente como sigue: valor 15 para los enlaces PE1-PE2 y PE3-PE4, y el valor por defecto (10) en los enlaces restantes (PE-P y P-P). Esta topología también tiene Reflectores de Ruta (RR), aunque no se muestren en la Figura 4-1.
H1 y H2 generan activamente tráfico hacia los grupos SSM 232.1.1.1 y 232.2.2.2, respectivamente. Los receptores de multidifusión de ambos grupos están repartidos por toda la red, y se suscribirán uno a uno, por lo que puedes ver cómo se crea el árbol de multidifusión.
Figura 4-1. Topología de multidifusión en Internet
Nota
Todos los hosts se simulan dentro de un único dispositivo IOS XR o máquina virtual (VM) llamado H. Más concretamente, cada host es un VRF-lite dentro de H.
Un simple ping es suficiente para generar tráfico multidifusión. Hagamos que el host H1 envíe un paquete por segundo hacia 232.1.1.1, como se muestra en el siguiente ejemplo:
Ejemplo 4-1. Generar tráfico IP Multicast mediante ping (IOS XR)
RP/0/0/CPU0:H#ping vrf H1 232.1.1.1 source 10.1.1.10
count 100000 timeout 1
Type escape sequence to abort.
Sending 100000, 100-byte ICMP Echos to 232.1.1.1, timeout is 0s:
.............[...]
Consejo
Si generas paquetes multidifusión desde un dispositivo Junos, asegúrate de que utilizas las opciones de ping bypass-routing, interface y ttl.
El ping anterior falla. Es de esperar, dado que aún no hay receptores: deja que el ping se ejecute continuamente en segundo plano.
A continuación, vamos a convertir algunos anfitriones en receptores de multidifusión dinámica. Aquí tienes un ejemplo de configuración para recibir el anfitrión H11 en el dispositivo H:
Ejemplo 4-2. Receptor multidifusión en H11 (IOS XR)
router igmp vrf H11 interface GigabitEthernet0/0/0/0.1011 join-group 232.1.1.1 10.1.1.10 !
Esto hace que H11 comience a enviar mensajes dinámicos de Informe IGMP, suscribiéndose efectivamente al flujo (S, G) = (10.1.1.10, 232.1.1.1). Supongamos que H3, H4, H22, H33, H34 y H44 (es decir, todas las máquinas excepto H2) también están suscritas al mismo flujo (S, G).
En sentido estricto, el ejemplo anterior está incompleto. Para que IOS XR simule un receptor final de multidifusión, primero hay que activar la interfaz en el nivel multicast-routing, y esto tiene algunas implicaciones.
Nota
En Junos, esta función de emulación dinámica del receptor sólo está disponible en el modo ASM (protocols sap listen <group>). Además, tanto Junos como IOS XR admiten suscripciones estáticas -ASM y SSM- en la interfaz orientada al receptor de un LHR.
Señalización del árbol multidifusión
Después de que las fuentes y los receptores de multidifusión estén activos, es hora de señalizar el árbol de multidifusión. Y para ello, los CEs y PEs necesitan ejecutar los protocolos multidifusión que se muestran aquí:
Ejemplo 4-3. Configuración de enrutamiento multidifusión en PE1 (Junos)
protocols {
igmp {
interface ge-2/0/2.1011 version 3;
pim {
interface ge-2/0/2.1011;
interface ge-2/0/1.1010;
}}
Se aplica una configuración similar a PE3, CE1, CE2, BR3 y BR4. De momento, sólo están configuradas las interfaces de acceso (PE-H, PE-CE y CE-H).
Por defecto en Junos, una interfaz configurada para PIM también ejecuta automáticamente IGMP en ella. La versión IGMP por defecto es la 2, y se requiere la versión IGMP 3 para procesar Informes (S, G).
PIM es un protocolo de router a router, por lo que, estrictamente hablando, la interfaz de último salto ge-2/0/2.1011 no necesita realmente PIM. IGMP es suficiente en la interfaz de último salto. Sin embargo, H11 podría convertirse en remitente de multidifusión en algún momento. Además, como verás próximamente en este capítulo, habilitar PIM en todas las interfaces de acceso multidifusión IP del router se considera una buena práctica para una posible redundancia y detección de bucles.
El tráfico multidifusión fluye ahora de extremo a extremo, gracias al intercambio de protocolos ilustrado en la Figura 4-2.
Figura 4-2. IGMP y PIM en acción (modelo SSM)
Veamos la configuración del enrutamiento multidifusión en IOS XR:
Ejemplo 4-4. Configuración de enrutamiento multidifusión en PE2 (IOS XR)
multicast-routing address-family ipv4 interface GigabitEthernet0/0/0/0.1020 enable interface GigabitEthernet0/0/0/1.1022 enable
La configuración anterior habilita realmente PIM e IGMP en las interfaces PE-CE y PE-H especificadas.
Señalización IGMP
El árbol multidifusión se señaliza en sentido ascendente, desde los receptores hacia la fuente. Empecemos por la rama del árbol cuya hoja es H11. La siguiente captura, tomada en PE1, muestra el intercambio de paquetes IGMP entre PE1 y H11.
Ejemplo 4-5. Consulta IGMP (desde PE1) e informe (desde H11)
juniper@PE1> monitor traffic interface ge-2/0/2.1011 no-resolve
size 2000 extensive matching igmp
<timestamp> Out
-----original packet-----
00:50:56:8b:32:4a > 01:00:5e:00:00:01, ethertype 802.1Q (0x8100),
length 54: vlan 1011, p 6, ethertype IPv4, (tos 0xc0, ttl 1,
id 20138, offset 0, flags [none], proto: IGMP (2), length: 36,
optlength: 4 ( RA )) 10.1.11.1 > 224.0.0.1: igmp query v3
<timestamp> In
-----original packet-----
IP (tos 0xc0, ttl 1, id 2772, offset 0, flags [none], proto: IGMP (2), length: 76,
optlength: 4 ( RA )) 10.1.11.11 > 224.0.0.22: igmp v3 report [...]
[gaddr 232.1.1.1 is_in { 10.1.1.10 }]
PE1 envía la Consulta IGMP a 224.0.0.1, la dirección multicast link-local de todos los hosts. H11 responde con un Informe IGMP destinado a 224.0.0.22, la dirección de todos los enrutadores IGMPv3. La información sobre las suscripciones (S, G) está en la carga útil del Informe IGMP.
Reenvío de ruta inversa
PE1 procesa además el Informe IGMP mirando la dirección S (10.1.1.10) y realizando una búsqueda de ruta IP unidifusión. Este proceso de búsqueda de la fuente se denomina Reverse Path Forwarding (RPF) y es un concepto central en el mundo de la multidifusión.
Ejemplo 4-6. RPF en PE1 (Junos)
juniper@PE1> show route active-path 10.1.1.10
inet.0: 44 destinations, 53 routes (44 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.1.1.0/24 *[BGP/170] 02:32:51, MED 100, localpref 100
AS path: 65001 I, validation-state: unverified
> to 10.1.0.0 via ge-2/0/1.1010
juniper@PE1> show multicast rpf 10.1.1.10
Multicast RPF table: inet.0 , 44 entries
10.1.1.0/24
Protocol: BGP
Interface: ge-2/0/1.1010
Neighbor: 10.1.0.0
En pocas palabras, los paquetes multidifusión que llegan a la interfaz no RPF se descartan.
Por defecto, la búsqueda de rutas IP unidifusión y la búsqueda RPF proporcionan exactamente el mismo resultado. Se dice entonces que las topologías unidifusión y multidifusión son congruentes. Si quieres que el tráfico unidifusión y multidifusión sigan rutas diferentes, también es posible hacer que las topologías no sean congruentes. Esto se explica con más detalle al final del Capítulo 5.
Señalización PIM
CE1 y PE1 intercambian paquetes hola PIM destinados a 224.0.0.13, la dirección multidifusión link-local de todos los routers PIM. Mediante ese intercambio, se convierten en vecinos PIM.
Ejemplo 4-7. Vecinos PIM en PE1 (Junos)
juniper@PE1> show pim neighbors B = Bidirectional Capable, G = Generation Identifier H = Hello Option Holdtime, L = Hello Option LAN Prune Delay, P = Hello Option DR Priority, T = Tracking Bit Instance: PIM.master Interface IP V Mode Option Uptime Neighbor addr ge-2/0/1.1010 4 2 HPLGT 02:40:25 10.1.0.0
Desde la perspectiva de PE1, el vecino PIM CE1 es también el vecino ascendente RPF en ruta hacia la fuente. Por tanto, PE1 envía un mensaje PIM (S, G) Join ascendente a CE1:
Ejemplo 4-8. Estado de unión PIM (S, G) de PE1 a CE1 (Junos)
juniper@PE1> show pim join inet detail
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 232.1.1.1
Source: 10.1.1.10
Flags: sparse,spt
Upstream interface: ge-2/0/1.1010
Downstream neighbors:
Interface: ge-2/0/2.1011
El Join PIM (S, G) es en realidad un paquete Join/Prune PIM. Estos mensajes contienen una lista Join(añadir unarama) y una lista Prune(cortar una rama). En este ejemplo, el receptor está activado, por lo que PE1 envía el paquete Join/Prune con una lista Prune vacía. Un paquete PIM Join/Prune de este tipo suele denominarse PIM Join. El Ejemplo 4-9 muestra el paquete en detalle.
Ejemplo 4-9. Paquete de unión PIM (S, G) de PE1 a CE1 (Junos)
juniper@PE1> monitor traffic interface ge-2/0/1.1010 no-resolve
size 2000 detail matching pim
<timestamp> Out IP (tos 0xc0, ttl 1, id 36704, offset 0, no flags,
proto: PIM (103), length: 54) 10.1.0.1 > 224.0.0.13
Join / Prune, cksum 0xd6dc (correct), upstream-neighbor: 10.1.0.0
1 group(s), holdtime: 3m30s
group #1: 232.1.1.1, joined sources: 1, pruned sources: 0
joined source #1: 10.1.1.10(S)
Nota
IGMP y PIM son, por tanto, protocolos de estado suave. En el mundo de la multidifusión IP, todos los mensajes del protocolo (consulta e informe IGMP, hola y unión/desafío PIM, etc.) se actualizan periódicamente. Por defecto, PIM Hello y Join/Prune se actualizan cada 10 y 60 segundos, respectivamente.
Como puedes ver, los mensajes PIM se encapsulan como paquetes IP con el protocolo nº 103 y la dirección IP de destino 224.0.0.13. Como se trata de una dirección IPv4 de multidifusión local de enlace, todos los routers PIM de la misma VLAN también procesarían el paquete. PE1 sólo tiene un vecino en la VLAN 1010, pero ¿y si hubiera más vecinos en el dominio de difusión? ¿Cómo puede PE1 indicar que el mensaje va dirigido realmente a CE1? Lo hace a través del campo vecino ascendente de la carga útil PIM.
Pero, ¿por qué se envía el mensaje PIM Join a 224.0.0.13 si sólo está dirigido a CE1? PIM en una LAN es un tema complejo y, en algunos casos, es importante que todos los routers PIM vecinos de la LAN tengan visibilidad completa de todos los intercambios de mensajes. Así se evitan los cortes de tráfico no deseados y la duplicación.
Reenvío multidifusión
Por último, CE1 es el FHR y, tras recibir el paquete PIM Join/Prune, sólo tiene que reenviar el tráfico multidifusión hacia PE1, como se muestra en el siguiente ejemplo:
Ejemplo 4-10. Estado de reenvío multidifusión en CE1 (Junos)
juniper@CE1> show multicast route inet detail
Instance: master Family: INET
Group: 232.1.1.1
Source: 10.1.1.10/32
Upstream interface: ge-0/0/1.1001
Downstream interface list:
ge-0/0/2.1010
Session description: Source specific multicast
Statistics: 0 kBps, 1 pps, 6064 packets
[...]
Nota
Esta ruta multidifusión no es realmente una ruta. Es más preciso considerarla como una entrada de la caché de reenvío.
Ahora que la fuente (H1) y el receptor (H11) están conectados a través del árbol multidifusión, el ping multidifusión tiene éxito: cada solicitud de eco enviada desde H1 a 232.1.1.1 tiene una respuesta de vuelta, procedente de H11 (10.1.11.11). Si no ves las respuestas, puede que te encuentres ante un caso límite en la implementación del receptor dinámico: intenta reiniciarlo borrando y aplicando de nuevo la configuración de router igmp vrf H11 en H (en dos commits).
Multidifusión clásica en Internet: conexión de islas multidifusión a través del núcleo
El árbol tiene ahora una raíz (H1), una hoja (H11) y una única rama que las conecta.
Tránsito de un salto por el núcleo (PE1-PE2)
Vamos a añadir dos hojas más al árbol:
-
H22 envía un Informe IGMP (S, G) a PE2.
-
H2 envía un Informe IGMP (S, G) a CE2, que envía un Join PIM (S, G) a PE2.
Como resultado, PE2 tiene el estado multidifusión (S, G) representado en el siguiente ejemplo:
Ejemplo 4-11. RIB multidifusión (IOS XR)
RP/0/0/CPU0:PE2#show mrib route 232.1.1.1
[...]
IP Multicast Routing Information Base
(10.1.1.10,232.1.1.1) RPF nbr: 0.0.0.0 Flags: RPF
Up: 01:26:05
Outgoing Interface List
GigabitEthernet0/0/0/0.1020 Flags: F NS, Up: 01:26:00
GigabitEthernet0/0/0/1.1022 Flags: F NS LI, Up: 01:26:05
La entrada (S, G) está instalada en la RIB multidifusión (MRIB) de PE2, pero lamentablemente el vecino RPF es 0.0.0.0. En otras palabras, RPF ha fallado. como se muestra en el Ejemplo 4-12.
Ejemplo 4-12. RPF fallido en PE2 (IOS XR)
RP/0/0/CPU0:PE2#show pim rpf
Table: IPv4-Unicast-default
* 10.1.1.10/32 [200/100]
via Null with rpf neighbor 0.0.0.0
En realidad, PE2 tiene una ruta BGP válida hacia 10.1.1.10, y su siguiente salto BGP (172.16.0.11) es alcanzable a través de la interfaz Gi 0/0/0/2. ¿Por qué falla RPF? Porque PIM no está activado en el núcleo, por lo que PE1 y PE2 no son vecinos PIM entre sí.
En este ejemplo clásico sin MPLS, el siguiente paso es activar PIM en las interfaces del núcleo. Una vez hecho esto, los nuevos receptores se conectan correctamente a la fuente.
Ejemplo 4-13. RPF correcto en PE2 (IOS XR)
RP/0/0/CPU0:PE2#show pim neighbor GigabitEthernet 0/0/0/2
[...]
Neighbor Address Interface Uptime Expires DR pri
10.0.0.0 GigabitEthernet0/0/0/2 00:00:20 00:01:25 1
10.0.0.1* GigabitEthernet0/0/0/2 00:00:20 00:01:26 1 (DR)
RP/0/0/CPU0:PE2#show pim rpf
Table: IPv4-Unicast-default
* 10.1.1.10/32 [200/100]
via GigabitEthernet0/0/0/2 with rpf neighbor 10.0.0.0
RP/0/0/CPU0:PE2#show mrib route 232.1.1.1
[...]
(10.1.1.10,232.1.1.1) RPF nbr: 10.0.0.0 Flags: RPF
Up: 01:50:26
Incoming Interface List
GigabitEthernet0/0/0/2 Flags: A, Up: 00:01:13
Outgoing Interface List
GigabitEthernet0/0/0/0.1020 Flags: F NS, Up: 01:50:21
GigabitEthernet0/0/0/1.1022 Flags: F NS LI, Up: 01:50:26
En este punto, el árbol multidifusión tiene tres hojas (H11, H22 y H2) conectadas a la raíz (H1), por lo que el ping multidifusión recibe tres respuestas por petición, como se muestra en el Ejemplo 4-14.
Ejemplo 4-14. Ping multidifusión exitoso con tres receptores
RP/0/0/CPU0:H#ping vrf H1 232.1.1.1 source 10.1.1.10 count 100000 Type escape sequence to abort. Sending 100000, 100-byte ICMP Echos to 232.1.1.1, timeout is 2s: Reply to request 0 from 10.1.11.11, 1 ms Reply to request 0 from 10.1.2.20, 1 ms Reply to request 0 from 10.1.22.22, 1 ms Reply to request 1 from 10.1.11.11, 9 ms Reply to request 1 from 10.1.2.20, 9 ms Reply to request 1 from 10.1.22.22, 1 ms [...]
Una sola copia de cada paquete atraviesa cada enlace, incluida la conexión PE1→PE2. Hay dos etapas de replicación: una en PE1 y otra en PE2.
Con respecto al flujo (10.1.1.10, 232.1.1.1), PE1 y PE2 se denominan popularmente PE emisor y PE receptor, respectivamente. Se trata de un papel por flujo: un PE determinado puede ser PE emisor para algunos flujos, y PE receptor para otros. El PE1 no se considera PE receptor aunque tenga un receptor local (H11), porque el flujo no llega desde el núcleo.
Nota
En este capítulo y en el Capítulo 5, los siguientes términos son equivalentes: PE raíz, PE de entrada y PE emisor. Del mismo modo, estos términos también son sinónimos: PE hoja, PE salida y PE receptor.
Tránsito de dos saltos por el núcleo (PE1-P1-PE3)
Añadamos una hoja más: H33. El LHR es ahora PE3, que como PE tiene visibilidad completa de las rutas BGP del cliente. Gracias a ello, PE3 realiza con éxito una búsqueda RPF hacia el origen (10.1.1.10) y envía un Join PIM (S, G) a su vecino PIM ascendente: P1. Hasta aquí todo correcto. Sin embargo, P1, como enrutador P puro, no tiene visibilidad de las rutas BGP, por lo que no puede realizar RPF hacia la fuente multidifusión:
Ejemplo 4-15. RPF fallido en P1 (Junos)
juniper@P1> show route 10.1.1.10
inet.0: 33 destinations, 33 routes (33 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[Static/5] 2w2d 05:08:19
Discard
juniper@P1> show pim join inet
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 232.1.1.1
Source: 10.1.1.10
Flags: sparse,spt
Upstream interface: unknown (no neighbor)
Pero, ¿cómo han conseguido los receptores H2 y H22 unirse al árbol multidifusión enraizado en H1? Porque las ramas de multidifusión que conectan la raíz con H2 y H22 no atraviesan ningún enrutador P. Por el contrario, la conexión entre H1 y H33 sólo puede realizarse a través de un enrutador P; de ahí el fallo en la señalización de la rama multidifusión de extremo a extremo para H33.
¿Cómo puedes resolver este problema? En realidad, hay muchas maneras, ¡probablemente demasiadas! Veamos los distintos enfoques cualitativos de este reto.
Señalización del estado de unión entre PE remotos
El fallo de RPF en un router de tránsito es un problema muy similar al clásico que motivó MPLS en el Capítulo 1. Ahora, no afecta al reenvío de paquetes de datos unidifusión, sino a la propagación de estados de Unión PIM (S, G). La fuente S es un prefijo unidifusión externo que pertenece a un AS diferente y no es alcanzable a través del IGP. En el capítulo 1 se propusieron varias formas de resolver el problema del reenvío unidifusión (sin redistribuir las rutas externas en el IGP), y todas ellas consistían en tunelizar los paquetes de datos de usuario. Pero aquí, en el caso de la multidifusión, es el Join PIM (S, G) (un paquete de control ), y no el tráfico de datos de usuario, lo que hay que tunelizar. Esto abre la puerta a un conjunto más diverso de opciones de diseño. A continuación se exponen algunas estrategias posibles para señalar el estado Join entre PE remotos.
Nota
Esta sección se centra en las formas de resolver los fallos de RPF en los routers de tránsito. El debate es independiente del servicio, que puede ser multidifusión global de Internet o VPN multidifusión (MVPN). En la práctica, algunos de los planteamientos que siguen sólo se aplican para MVPN.
Variantes de multidifusión IP de operador
Así que pasemos de la multidifusión IP clásica a la multidifusión IP portadora, que tiene capacidad de tunelización para resolver el reto del núcleo multisalto.
La Tabla 4-1 enumera seis de las muchas dimensiones que tiene el universo multidifusión.
| Servicio | Multidifusión global por Internet (S1), VPN multidifusión (S2) |
| Arquitectura C-Multicast | Ninguno (A0), Inter-PE directo (A1), Inter-PE salto a salto (A2), Fuera de banda (A3) |
| Protocolo de Señalización Inter-PE C-Multicast | Ninguno (C0), PIM (C1), LDP (C2), BGP (C3) |
| Encapsulación del túnel P | Ninguno (E0), GRE sobre IP Unicast (E1), GRE sobre IP Multicast (E2), MPLS (E3) |
| Protocolo de señalización del túnel P | Ninguno (T0), PIM (T1), LDP (T2), RSVP-TE (T3), Protocolo de enrutamiento con extensiones MPLS (T4) |
| Trazado del túnel P | Ninguno (Y0), P2P (Y1), MP2P (Y2), P2MP (Y3), MP2MP (Y4) |
Nota
Los prefijos C y P significan cliente y proveedor, respectivamente. El modelo clásico de multidifusión IP es puramente multidifusión C. En cambio, los modelos de multidifusión IP de operador también tienen dimensiones P-.
Cada sabor de multidifusión de operador tiene al menos un elemento de cada dimensión. Como puedes imaginar, no todas las combinaciones tienen sentido y cada proveedor sólo admite un subconjunto de ellas. Aunque este libro se centra en las combinaciones admitidas tanto por Junos como por IOS XR, para completarlo, también se tratan brevemente las combinaciones no interoperables.
Consejo
Imprime una copia de la Tabla 4-1 y guárdala como referencia mientras lees los capítulos de multidifusión de este libro.
Existen dos tipos de servicio, dependiendo de si el enrutamiento multidifusión se realiza en la tabla de enrutamiento global o en una VRF. Este capítulo se centra en los servicios globales, pero toma prestados tácticamente algunos ejemplos que sólo se implementan para la VPN multidifusión.
Este libro considera tres arquitecturas C-Multicast:
-
En el modelo Inter-PE directo (A1), PE1 y PE3 establecen una adyacencia C-PIM a través de un túnel bidireccional. Este túnel transporta paquetes C-Multicast de control y datos.
-
En el modelo Hop-by-Hop (A2), PE3 convierte el estado C-PIM Join ascendente en un mensaje diferente que P1 puede procesar y enviar a PE1, que a su vez lo convierte en estado C-PIM Join. Esta arquitectura también se conoce como In-Band, o Proxy.
-
En el modelo Fuera de Banda (A3), PE3 señala el estado C-Join a PE1 con un protocolo IP no tunelizado. Al igual que en el modelo A1, P1 no desempeña ningún papel en el plano de control C-Multicast.
No te preocupes si estas definiciones aún no tienen mucho sentido. Guárdalas como referencia y te resultarán mucho más claras a medida que sigas leyendo.
Nota
En los términos de la Tabla 4-1, el modelo clásico de multidifusión IP es: S1, A2, C1, E0, T0, Y0.
Modelo Inter-PE Directo-Adyacencias PIM de PE a PE sobre Túneles IP Unicast
En los términos de la Tabla 4-1, este modelo es A1, C1, E1, T0, Y1. Está implementado tanto por Junos como por IOS XR para S1 y S2.
Este enfoque requiere un túnel IP de unidifusión (por ejemplo, basado en GRE) entre cada par de PE. Hay una instancia PIM y sólo se ejecuta en los PE. Este contexto PIM suele denominarse C-PIM.
Centrémonos en los siguientes túneles: PE1→PE3 y PE3→PE1. PE1 y PE3 ven este par de túneles GRE como una interfaz punto a punto que interconecta las dos islas multidifusión IP de forma transparente. PE1 y PE3 intercambian dos tipos de tráfico multidifusión a través de los túneles GRE:
-
Los paquetes decontrol como PIM Hello o (S, G) Join se destinan a 224.0.0.13, una dirección multidifusión (aunque sea link-local, donde el enlace es el túnel GRE)
-
Paquetes dedatos del flujo de usuario multidifusión activo (10.1.1.10→232.1.1.1)
Desde el punto de vista de los túneles GRE, no hay distinción entre Control y Datos. Si PE1 necesita enviar un paquete multidifusión (Control o Datos) a PE3 a través del túnel GRE PE1→PE3, añade las siguientes cabeceras:
-
Cabecera GRE con Tipo de Protocolo = 0x0800 (IPv4).
-
Cabecera IPv4 con (Origen, Destino) = (172.16.0.11, 172.16.0.33). En otras palabras, los puntos finales del túnel GRE son las direcciones loopback primarias de PE1 y PE3.
Tras recibir los paquetes tunelizados, PE3 elimina estas dos cabeceras. El resultado es el paquete multidifusión original (Control o Datos) que PE1 había introducido inicialmente en el túnel. Y la misma lógica se aplica a los paquetes que viajan en sentido inverso: de PE3 a PE1.
¿Hasta qué punto es bueno este modelo? Aunque puedes utilizarlo de forma táctica para implementaciones limitadas o temporales, no puedes considerarlo como un enfoque moderno y escalable, por las mismas razones por las que Internet no funciona a través de túneles IP. El modelo también se ve afectado por las siguientes limitaciones específicas de la multidifusión:
-
Si el PE1 tiene dos interfaces de enlace ascendente al núcleo, pero necesita enviar un paquete de datos multidifusión a 1.000 PE remotos, el PE1 debe replicar el paquete 999 veces y enviar cada una de las 1.000 copias a un túnel GRE unidifusión diferente. Esta técnica se denomina Replicación de Entrada, y provoca un consumo ineficiente de ancho de banda. Cuando los paquetes de datos multidifusión se envían al núcleo, la principal ventaja de la multidifusión (árbol de replicación eficiente) simplemente se pierde.
-
Los PE establecen adyacencias PIM a través de los túneles GRE. La naturaleza de estado suave del PIM provoca una actualización periódica de todos los paquetes PIM (Hello, Join/Prune, etc.) al menos una vez por minuto. Este ruido de fondo carga innecesariamente el plano de control. Piensa por un momento en cómo los PE intercambian rutas unidifusión: una actualización de BGP a través de una conexión TCP fiable, y ya está (no se requiere un refresco periódico de la ruta). En ese sentido, el protocolo multidifusión de PE a PE (PIM) es menos escalable que el protocolo unidifusión (BGP).
Siempre que los túneles GRE de unidifusión entren en el juego de la multidifusión, es importante asegurarse de que sólo los atraviesa el tráfico de multidifusión del cliente. El tráfico unidifusión del cliente debe viajar en MPLS. Este requisito de no congruencia se analiza con más detalle al final del Capítulo 5.
Modelo Inter-PE directo-Adyacencias PIM de PE a PE a través de túneles IP de multidifusión
En los términos de la Tabla 4-1, este modelo es A1, C1, E2, T1, [Y3, Y4]. Está implementado tanto por Junos como por IOS XR sólo para S2.
Se describe en el histórico RFC 6037 - Solución de Cisco Systems para multidifusión en VPN IP BGP/MPLS. La mayoría de la gente lo llama draft Rosen porque draft-rosen-vpn-mcast fue el precursor del RFC 6037.
En el borrador Rosen -implementado sólo para VPN IP- cada PE (por ejemplo, PE1) es la raíz de al menos un túnel GRE de multidifusión por VPN, llamado Árbol de Distribución de Multidifusión (MDT). ¿Por qué al menos uno y no sólo uno? Vamos a saltarnos esta pregunta por un momento, y pensar que cada PE es la raíz de un MDT llamado MDT por defecto.
Este modelo requiere dos instancias distintas de PIM: C-PIM (donde C significa Cliente) y P-PIM (donde P significa Proveedor). Ten en cuenta que C y P sólo representan contextos diferentes. En realidad, PIM se implementa de la misma manera: al fin y al cabo, es el mismo protocolo:
-
C-PIM es la instancia de servicio de PIM y se ejecuta en el perímetro: PE-a-CE, y PE-a-PE (este último, a través de los túneles GRE). Se utiliza para señalar los árboles multidifusión del usuario final, en este ejemplo (10.1.1.10→232.1.1.1). Hasta ahora, el contexto PIM utilizado a lo largo de este capítulo ha sido siempre C-PIM. Desde el punto de vista de C-PIM, el núcleo es sólo una interfaz LAN que interconecta todos los PE. Los PE simplemente establecen adyacencias PIM sobre el núcleo, como harían sobre cualquier otra interfaz.
-
P-PIM es la instancia de transporte de PIM y sólo se ejecuta en los enlaces centrales. Se utiliza para construir los Túneles de Proveedor GRE Multicast o Túneles P. El modo P-PIM más popular es el SSM. Una de las ventajas de SSM es que simplifica mucho la asignación de Grupos de Proveedores (P-G). Supongamos que PE1 y PE3 son las raíces de los Túneles P (172.16.0.11→P-G1) y (172.16.0.33→P-G3), respectivamente. P-G1 y P-G3 pueden ser diferentes, pero también podrían ser iguales. Con SSM, mientras las fuentes sean diferentes, los árboles multidifusión siguen siendo distintos aunque G1 sea igual a G3. Esto es especialmente importante para los MDT de datos, que se tratan más adelante en esta sección.
Nota
P-PIM se ejecuta en la instancia de enrutamiento global (VRF por defecto), mientras que C-PIM se ejecuta en una VRF (no por defecto). Por tanto, el servicio se presta en el contexto de una VPN. Y puede ser el servicio de multidifusión por Internet siempre que se preste dentro de una VPN por Internet.
Volviendo a la Tabla 4-1, P-PIM SSM corresponde a Y3 y P-PIM ASM a Y4.
Supongamos que cada uno de los PE del núcleo es la raíz de un Túnel-P cuyo Grupo-P SSM es 232.0.0.100 -el mismo para simplificar, aunque también podría ser un Grupo-P distinto por raíz-. PE1 recibe las siguientes uniones P-PIM (S1, G) de sus vecinos P-PIM, donde S1 = 172.16.0.11 y G = 232.0.0.1:
-
PE2 envía un Join (S1, G) directamente a PE1.
-
PE3 envía un Join (S1, G) a P1 y luego P1 envía un paquete Join (S1, G) a PE1.
-
PE4 envía un Join (S1, G) a P2, luego P2 envía un Join (S1, G) a P1, que ya está enviando paquetes Join (S1, G) a PE1.
De este modo, PE1 es la raíz de un MDT predeterminado cuyas hojas son PE2, PE3 y PE4.
Asimismo, PE1 también es una hoja de los MDT por defecto de los PE remotos. De hecho, PE1 envía los siguientes Joins P-PIM: (172.16.0.22, 232.0.0.100) a PE2, (172.16.0.33, 232.0.0.100) a P1 en ruta a PE3, y (172.16.0.44, 232.0.0.100) a P1 en ruta a PE4.
Este proceso acaba estableciendo una superposición tipo LAN que interconecta a todos los PE entre sí. Los PE intercambian dos tipos de tráfico C-Multicast a través del MDT por defecto:
-
Los paquetes decontrol como C-PIM Hello o C-PIM (S, G) Join están destinados a 224.0.0.13, una dirección multidifusión (aunque sea link-local)
-
Paquetesde datos del flujo de usuario C-Multicast activo (10.1.1.10→232.1.1.1)
Desde el punto de vista del MDT por defecto, no hay distinción entre Control y Datos. Si PE1 necesita enviar un paquete C-Multicast (Control o Datos) a sus vecinos a través del MDT por defecto, PE1 añade las siguientes cabeceras:
-
Cabecera GRE con Tipo de Protocolo = 0x0800 (IPv4)
-
Cabecera IPv4 con (Origen, Destino) = (172.16.0.11, 232.0.0.100)
Los paquetes tunelizados llegan a todos los demás PE, que eliminan las dos cabeceras. El resultado es el paquete original (Control o Datos) C-Multicast que PE1 había puesto inicialmente en el MDT por defecto.
PE1 es la raíz de su MDT por defecto, y opcionalmente puede ser la raíz de uno o más MDT de datos. ¿Qué es una MDT de datos? Supongamos que PE1 es el PE emisor de un flujo C-Multicast (C-S, C-G) de gran ancho de banda, y que de 1.000 PE remotos, sólo 10 de ellos tienen receptores de bajada para (C-S, C-G). Por eficiencia del ancho de banda, tiene sentido señalar una nueva MDT que se dedique a transportar sólo ese (C-S, C-G) concreto. Esta MDT de datos sólo tendría 10 hojas: los 10 PE receptores interesados en recibir el flujo.
Nota
Los MDT Predeterminados y de Datos suelen denominarse Árboles Inclusivos y Selectivos, respectivamente. Los Árboles Inclusivos incluyen todas las hojas posibles, y los Árboles Selectivos seleccionan un subconjunto específico de hojas.
Ten en cuenta que los protocolos descritos hasta ahora (C-PIM, P-PIM SSM y GRE) no suelen bastar para autodescubrir las hojas de cada MDT. Se necesitan e implementan protocolos adicionales para lograr esta función de autodescubrimiento (AD). ¿Qué protocolos? La respuesta varía según el tipo de implementación. Utilizando la terminología de Cisco (en el momento de escribir esto):
- Rosen GRE
- La MDT por defecto con P-PIM Any Source Multicast (ASM) no requiere ningún protocolo adicional, porque la función P-Source AD la realiza P-PIM (el descubrimiento de fuentes en PIM ASM se trata en el Capítulo 15). En cuanto a los MDT de Datos, se señalizan con paquetes del Protocolo de Datagramas de Usuario (UDP) que se intercambian en el MDT Predeterminado.
- Rosen GRE con BGP AD
- Los MDT por defecto con SSM P-PIM requieren una nueva familia de direcciones BGP multiprotocolo para AD (P-S, P-G). En cuanto a los MDT de Datos, pueden señalizarse utilizando BGP o UDP.
Nota
La documentación de Cisco asocia cada sabor de multidifusión de portadora con un número de perfil. Por ejemplo, Rosen GRE es MVPN Perfil 0, y Rosen GRE con BGP AD es MVPN Perfil 3.
Más detalles sobre la implementación e interoperabilidad de Rosen GRE están fuera del alcance de este libro, ya que nos centramos en MPLS y no en GRE. Seamos justos: el borrador Rosen ha sido la tecnología VPN Multicast L3 de facto durante dos décadas, y ha resuelto los requisitos empresariales de muchos clientes. Pero, a medida que pasa el tiempo, está siendo sustituida por modelos de nueva generación.
Para terminar, veamos los pros y los contras de este modelo:
-
Pro: un MDT es en realidad un árbol de multidifusión (proveedor) que facilita la replicación eficiente de datos de multidifusión. Si el PE1 tiene dos interfaces de enlace ascendente de núcleo y necesita enviar un paquete de datos multidifusión a 1.000 PE remotos, el PE1 replica el paquete como máximo una vez y envía como máximo una copia del paquete por cada enlace ascendente de núcleo. Además, este modelo implementa MDT de datos para una distribución aún más eficiente.
-
Contra: C-PIM en una LAN es complejo y ruidoso. Si PE3 envía un Join C-PIM a PE1, todos los demás PE de la VPN lo reciben y lo investigan. Como has visto anteriormente, los mensajes PIM Join/Prune se envían a 224.0.0.13 y se actualizan periódicamente. Esto hace que la solución sea menos escalable y robusta en el plano de control.
-
Por último, este modelo no proporciona una flexibilidad total en el plano de reenvío. Hay dos tipos de P-Tunnel disponibles: PIM/GRE y MP2MP mLDP (próximamente). Ninguno de ellos puede beneficiarse de funciones MPLS como la Ingeniería de Tráfico.
Advertencia
Antes de seguir adelante, eliminemos primero PIM de todos los enlaces del núcleo, porque P-PIM ya no es necesario. A partir de ahora, ¡el núcleo es territorio MPLS!
Modelo Inter-PE Directo-PE Adyacencias PIM a través de rutas de conmutación de etiquetas MPLS
En los términos de la Tabla 4-1, este modelo es A1, C2, E3, T2, Y4. Sólo está implementado por IOS XR y sólo para S2.
PIM está diseñado para enlaces bidireccionales. Cuando R1 envía un Join PIM a R2 por el enlace L, el tráfico multidifusión debe fluir de R2 a R1 por el mismo enlace L. Sin embargo, las rutas de conmutación de etiquetas (LSP) MPLS son unidireccionales... ¿o no? En realidad, hay un tipo de LSP que es bidireccional. Se denomina LSP multipunto a multipunto (LSP MP2MP) y es uno de los dos tipos de LSP descritos en el RFC 6388 - Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths. Con cualquiera de estas extensiones (P2MP o MP2MP), el LDP suele denominarse LDP Multipunto (mLDP). Parafraseando el RFC:
Un LSP MP2MP [...] consta de un único nodo raíz, cero o más nodos de tránsito, y uno o más LSR de hoja que actúan igualmente como LSR de entrada o de salida.
En pocas palabras, los LSP MP2MP tienen un LSR central (llamado raíz), donde se unen todas las ramas. Los PE se sitúan en las hojas e intercambian con sus vecinos LDP dos tipos de mapeos de etiquetas FEC multipunto (MP): ascendente, para el tráfico de usuario que fluye de una hoja a la raíz, y descendente, para el tráfico de usuario que fluye de la raíz a una hoja. Desde una perspectiva de servicio, el LSP MP2MP emula una LAN bidireccional que interconecta los PE, y sin mecanismo de aprendizaje para reducir las inundaciones. Cualquier paquete introducido en un LSP MP2MP llega a todas las hojas. En ese sentido, el MP2MP LSP es un MDT por defecto o Árbol Inclusivo.
En el momento de escribir esto, Cisco llama a este modelo Rosen mLDP, ya que tiene muchas similitudes con Rosen GRE. La documentación de Cisco utiliza el nombre Rosen para etiquetar una amplia variedad de perfiles MVPN. Algunos de ellos son similares al borrador Rosen(borrador-rosen-vpn-mcast), mientras que otros no lo son. Por tanto, esta etiqueta no proporciona realmente una pista con respecto a la tecnología subyacente.
Tanto en Rosen GRE como en Rosen mLDP, los PE construyen adyacencias C-PIM sobre el MDT por defecto. Por tanto, ambos dependen de la implementación de C-PIM en una LAN. Por último, pero no por ello menos importante, ambos requieren mecanismos adicionales para autodescubrir las hojas de MDT Predeterminadas y/o de Datos.
Nota
Los MDT de Datos son P2MP, a diferencia del MDT Predeterminado, que es MP2MP.
La principal diferencia entre Rosen GRE y Rosen mLDP radica en la forma en que se intercambian los mensajes C-PIM y los paquetes C-Multicast a través del MDT por defecto: mediante túneles IP o MPLS, respectivamente. En Rosen mLDP, los Joins C-PIM se encapsulan en MPLS, y fluyen en dirección opuesta al tráfico C-Multicast. Puedes comparar Rosen GRE con Rosen mLDP sustituyendo P-PIM por LDP, y GRE por MPLS.
Ni Rosen GRE ni Rosen mLDP se tratan con más detalle en este libro. El primero no se basa en MPLS y el segundo no es interoperable a día de hoy. Ambos modelos se basan en el establecimiento de adyacencias PE-PE C-PIM a través del núcleo.
Más allá del Modelo Inter-PE Directo-No Establecer Adyacencias PIM PE-PE
La evaluación de los modelos anteriores muestra que tunelizar C-PIM entre PEs no es especialmente escalable. A principios de la década de 2000, Juniper y Cisco empezaron a definir nuevos marcos para señalizar y transportar el tráfico multidifusión a través de una red troncal MPLS. En su momento, este nuevo conjunto de paradigmas se denominó Next-Generation o NG, pero ahora es simplemente tecnología punta. Aunque mucha gente sigue llamándola NG, este libro no lo hace.
Estos marcos modernos dejan el PIM funcionando sólo en los enlaces PE-CE y PE-Host. Sin embargo, los PE ya no establecen adyacencias C-PIM entre sí. En su lugar, un protocolo escalable de clase portadora señala la información C-Multicast inter-PE. Existen básicamente dos protocolos de este tipo: BGP y LDP. Ambos son capaces de codificar el estado C-Multicast.
Modelo fuera de banda
Cuando se utiliza BGP para señalar el estado de Unión C-Multicast, los planos de servicio y transporte están débilmente acoplados. Gracias a ciertas técnicas que se describen en el Capítulo 5, BGP admite virtualmente todas las tecnologías de Túneles P dinámicos enumeradas en la Tabla 4-1.
Consideremos el caso particular en el que LDP es el protocolo de señalización del Túnel P. En los términos de la Tabla 4-1, este modelo es A3, C3, E3, T2, [Y2, Y3, Y4]. El papel de LDP en este caso es construir los LSP que transportan los datos multidifusión. BGP se encarga por completo de la señalización C-Multicast del servicio PE a PE. En ese sentido, el plano de servicio (BGP) no está estrechamente acoplado al plano de transporte (LDP en este caso). BGP realiza la señalización C-Multicast fuera de banda. Este modelo proporciona una gran flexibilidad en la elección del Túnel P, y se basa en un rico mecanismo de señalización, que se trata más adelante, en el Capítulo 5.
Modelo Hop-by-Hop Inter-PE
Cuando se utiliza LDP (en lugar de BGP) para señalar el estado de Unión C-Multicast, los planos de servicio y transporte están estrechamente acoplados: LDP señala ambos al mismo tiempo, gracias a tipos especiales de FEC. Esto es señalización C-Multicast en banda, lo que significa que los planos de servicio y de transporte están mezclados.
Este modelo es menos flexible y escalable que la arquitectura fuera de banda, pero también más sencillo de entender, así que vamos a utilizarlo para el primer ejemplo ilustrado de Multidifusión sobre MPLS de este libro. ¡Por fin!
Multidifusión de Internet por MPLS con señalización LDP multipunto en banda
Esta sección ilustra la parte P2MP del RFC 6826 - Señalización en banda LDP multipunto para rutas conmutadas por etiquetas punto a multipunto y multipunto a multipunto.
En los términos de la Tabla 4-1, este modelo es S1, A2, C2, E3, T2, Y3. En la documentación de Cisco, se denomina Banda Interna Global. Es la forma más sencilla de implementar la multidifusión dinámica sobre MPLS. Aunque facilita el funcionamiento y la implementación, este modelo de multidifusión de operador también tiene algunas limitaciones:
-
Crea el estado de etiqueta C-Multicast en los LSR del núcleo, rompiendo una de las principales ventajas de MPLS: reducir el estado al no propagar las rutas de los clientes a los routers P.
-
No tiene flexibilidad P-Tunnel (sólo está restringida a LDP).
-
Todavía no es compatible con los Túneles Inclusivos (MDTs por defecto).
LDP multipunto
El LDP multipunto (mLDP) no es un protocolo nuevo, sino un conjunto de extensiones y procedimientos del LDP. PE1 y PE2 establecen una única sesión LDP, y la utilizan para intercambiar mapeos de etiquetas para todos los elementos FEC. Éstos incluyen los prefijos IPv4 de toda la vida (como en el LDP simple ) y, además, los elementos FEC Multipunto; todos anunciados en la misma sesión LDP.
Consejo
Utiliza el marco de políticas de Junos e IOS XR para seleccionar qué FEC quieres anunciar en la sesión LDP. Por ejemplo, puede que quieras utilizar LDP sólo para FEC P2MP, no para FEC Unicast IPv4.
El LDP se denomina mLDP si los vecinos negocian capacidades MP especiales. Más concretamente, un vecino que soporte la capacidad P2MP (0x0508) puede señalar elementos P2MP FEC a través de una sesión (m)LDP.
Empecemos con un escenario en el que LDP está configurado en todas las interfaces (ver Capítulo 2). El Ejemplo 4-16 muestra la configuración incremental de mLDP en Junos.
Ejemplo 4-16. Configuración de mLDP (Junos)
protocols {
ldp p2mp;
}
El Ejemplo 4-17 presenta la configuración en IOS XR.
Ejemplo 4-17. Configuración de mLDP (IOS XR)
mpls ldp mldp
Nota
Es una buena práctica, tanto en Junos como en IOS XR, configurar mLDP make-before-break para minimizar la pérdida de tráfico al recuperar el enlace. Los detalles quedan fuera del alcance de este libro.
Como resultado de esta configuración, los pares LDP negocian la capacidad P2MP. Veamos la negociación entre PE1 (Junos) y PE2 (IOS XR): ambos tienen en común la capacidad P2MP:
Ejemplo 4-18. Negociación de capacidades LDP (Junos e IOS XR)
juniper@PE1> show ldp session 172.16.0.22 detail
[...]
Capabilities advertised: p2mp, make-before-break
Capabilities received: p2mp
RP/0/0/CPU0:PE2#show mpls ldp neighbor 172.16.0.11:0 detail
[...]
Capabilities:
Sent:
0x508 (MP: Point-to-Multipoint (P2MP))
0x509 (MP: Multipoint-to-Multipoint (MP2MP))
0x50b (Typed Wildcard FEC)
Received:
0x508 (MP: Point-to-Multipoint (P2MP))
Por ahora, la sesión LDP sólo señala los elementos FEC de prefijo IPv4 clásicos. De momento, no se anuncian elementos FEC P2MP en las sesiones LDP porque aún no hay ningún servicio que requiera un LSP multipunto. Esto está a punto de cambiar.
Nota
Debes configurar mLDP en todos los LSR y LER.
Señalización en banda
En este momento, PE2, PE3 y PE4 tienen el estado de unión PIM ascendente apuntando a PE1, pero RPF está fallando porque PIM se ha eliminado de los enlaces del núcleo. En la terminología de C y P, P-PIM ya no se ejecuta y C-PIM necesita confiar en mLDP para extender el árbol multidifusión a través del núcleo. Sin embargo, C-PIM no sabe que puede confiar en mLDP. Sin embargo.
Más adelante en este capítulo, verás la configuración (ver Ejemplo 4-19 y Ejemplo 4-26) que permite la conversión automática del estado de Unión C-PIM en FECs P2MP LDP. Esto desencadena la creación de un LSP P2MP enraizado en PE1 y con tres hojas (PE2, PE3 y PE4). El LSP P2MP se construye mediante mLDP, y la señalización en realidad va en dirección ascendente: desde las hojas hacia la raíz (PE1). En cambio, los datos C-Multicast se tunelizan en sentido descendente, desde la raíz hacia las hojas.
Puedes utilizar la Figura 4-3 como guía para el siguiente recorrido mLDP.
Nota
Para el resto de este capítulo, los enlaces PE1-PE2 y PE3-PE4 tienen sus métricas IS-IS elevadas a 100. Así, en ausencia de fallos de enlace, todos los caminos más cortos inter-PE pasan por enrutadores P.
Figura 4-3. Señalización y reenvío mLDP P2MP LSPs-In-Band
Supongamos que todos los hosts de la Figura 4-1, a excepción del origen H1, están suscritos al flujo multidifusión (10.1.1.10, 232.1.1.1). Es decir H2, H3, H4, H22, H33, H34 y H44 son todos receptores de multidifusión C.
Estado de unión de señalización de un PE de salida que ejecuta Junos
La siguiente configuración de Junos enlaza C-PIM con mLDP en los PE de Junos:
Ejemplo 4-19. Configuración en banda del mLDP en los PE (Junos)
protocols {
pim mldp-inband-signalling;
}
Nota
Esta configuración sólo es necesaria en los PE (de entrada y salida). Los routers P puros como P1 y P2 no la necesitan, porque ni siquiera ejecutan PIM.
Después de borrar el estado de unión C-PIM en PE3 -utilizando el comando clear pim join-, elping multidifusión de H1 a 232.1.1.1 empieza a recibir respuestas de H3, H4 y H33.
Advertencia
Utiliza el comando clear pim join con precaución. Este comando suele perturbar los flujos multidifusión establecidos. Intenta ser específico con respecto al (S, G) concreto que quieres borrar.
Veamos cómo se señaliza esta rama PE1→PE3 del árbol multidifusión a través del núcleo. El PE de salida (PE3) sabe que la fuente C-Multicast 10.1.1.10 está más allá de PE1.
Ejemplo 4-20. Resolución RPF en la salida PE-PE3 (Junos)
juniper@PE3> show route 10.1.1.10 detail active-path
[...]
Protocol next hop: 172.16.0.11
juniper@PE3> show pim source inet
Instance: PIM.master Family: INET
Source 10.1.1.10
Prefix 10.1.1.0/24
Upstream protocol MLDP
Upstream interface Pseudo MLDP
Upstream neighbor MLDP LSP root <172.16.0.11>
Gracias a la configuración que acabamos de aplicar, el estado de Unión C-PIM ascendente de PE3 puede resolverse mediante el Protocolo de Distribución de Etiquetas Multicast (mLDP), como se muestra en el Ejemplo 4-21.
Ejemplo 4-21. Estado de unión C-PIM ascendente en PE-PE3 de salida (Junos)
juniper@PE3> show pim join inet detail
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 232.1.1.1
Source: 10.1.1.10
Flags: sparse,spt
Upstream protocol: MLDP
Upstream interface: Pseudo MLDP
Downstream neighbors:
Interface: ge-2/0/3.1034
Interface: ge-2/0/4.1033
Desde la perspectiva del plano de reenvío, la ruta (descendente) es PE1→PE3, pero debe señalizarse al revés: de PE3 a PE1. En otras palabras, la señalización tiene lugar aguas arriba, de la hoja a la raíz. PE3 no está conectado directamente a PE1, por lo que PE3 (el PE de salida) necesita encontrar el vecino RPF hacia PE1 (la raíz).
Ejemplo 4-22. Búsqueda RPF en la salida PE-PE3 (Junos)
juniper@PE3> show route 172.16.0.11 table inet.0
inet.0: 43 destinations, 51 routes (43 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.16.0.11/32 *[IS-IS/18] 04:37:38, metric 20
> to 10.0.0.8 via ge-2/0/1.0
Ahora, PE3 construye un elemento FEC P2MP, le asigna una etiqueta y anuncia la asignación de etiquetas sólo a P1. ¿Por qué P1? Porque es el vecino RPF -y vecino LDP- de la raíz (PE1). Este anuncio dirigido es totalmente distinto de la distribución promiscua de Label Mapping de elementos FEC de prefijo IPv4, representada en la Figura 2-3 y la Figura 2-4. En el caso P2MP, el LSR descendente realiza una búsqueda de ruta antes de anunciar la asignación de etiquetas, por lo que sólo la recibe el vecino RPF.
Ejemplo 4-23. Señalización P2MP FEC de salida PE-PE3 (Junos)
juniper@PE3> show ldp p2mp fec LDP P2MP FECs: P2MP root-addr 172.16.0.11, grp: 232.1.1.1, src: 10.1.1.10 Fec type: Egress (Active) Label: 301200 juniper@PE3> show ldp database p2mp Input label database, 172.16.0.33:0--172.16.0.1:0 Labels received: 8 Output label database, 172.16.0.33:0--172.16.0.1:0 Labels advertised: 19 Label Prefix 301200 P2MP root-addr 172.16.0.11, grp: 232.1.1.1, src: 10.1.1.10 Input label database, 172.16.0.33:0--172.16.0.44:0 Labels received: 19 Output label database, 172.16.0.33:0--172.16.0.44:0 Labels advertised: 18
Interpretemos el nuevo elemento FEC. El formato de los elementos FEC MP (P2MP y MP2MP) se describe en el RFC 6388 - Extensiones LDP para rutas conmutadas por etiquetas punto a multipunto y multipunto a multipunto, que parafraseamos aquí:
El Elemento FEC P2MP está formado por la dirección de la raíz del LSP P2MP y un valor opaco. [...] El valor opaco es único dentro del contexto del nodo raíz. La combinación de (tipo de dirección del nodo raíz, dirección del nodo raíz, valor opaco) identifica de forma única un LSP P2MP dentro de la red MPLS.
Volviendo al ejemplo, la Dirección Raíz P2MP es 172.16.0.11 (la dirección loopback de PE1) y el Valor Opaco es: group 232.1.1.1, source 10.1.1.10. Como puedes ver, el elemento FEC utilizado para construir este LSP P2MP también contiene información C-Multicast, concretamente el C-Grupo y el C-Fuente. Esto es precisamente lo que significa In-Band. Pero esta información está codificada en un valor opaco, lo que significa que los LSR de tránsito no necesitan entenderla: sólo lo hace la raíz.
Cuando P1 recibe este elemento P2MP FEC, sólo mira su dirección raíz (172.16.0.11) y, por supuesto, la etiqueta. P1 realiza una comprobación RPF, asigna una nueva etiqueta y envía un P2MP Label Mapping a su vecino RPF hacia la raíz, PE1.
Ejemplo 4-24. Señalización mLDP P2MP FEC desde tránsito P-P1 (Junos)
juniper@P1> show ldp p2mp fec LDP P2MP FECs: P2MP root-addr 172.16.0.11, grp: 232.1.1.1, src: 10.1.1.10 Fec type: Transit (Active) Label: 300400 juniper@P1> show ldp database session 172.16.0.11 p2mp Input label database, 172.16.0.1:0--172.16.0.11:0 Labels received: 9 Output label database, 172.16.0.1:0--172.16.0.11:0 Labels advertised: 7 Label Prefix 300400 P2MP root-addr 172.16.0.11, grp: 232.1.1.1, src: 10.1.1.10
A diferencia de P1, el PE de entrada (PE1) es la raíz, por lo que examina el valor opaco MP, que contiene el estado C-Multicast. De hecho, PE1 convierte el FEC mLDP descendente en estado C-PIM Join ascendente. Este último ya existe debido al receptor local H11, por lo que el FEC mLDP simplemente desencadena una actualización de la lista de interfaces salientes.
Ejemplo 4-25. Estado de unión C-PIM ascendente en el PE-PE1 de entrada (Junos)
juniper@PE1> show pim join inet detail
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard
Group: 232.1.1.1
Source: 10.1.1.10
Flags: sparse,spt
Upstream interface: ge-2/0/1.1010
Downstream neighbors:
Interface: ge-2/0/2.1011
Interface: Pseudo-MLDP
Señalización del estado de Unión desde un PE de salida que ejecuta IOS XR
La configuración IOS XR que enlaza C-PIM con mLDP en PE2 se muestra en el Ejemplo 4-26.
Ejemplo 4-26. Configuración en banda de mLDP en PE2 (IOS XR)
prefix-set PR-REMOTE-SOURCES
10.1.1.0/24 eq 32,
10.2.0.0/16 eq 32
end-set
!
route-policy PL-MLDP-INBAND
if source in PR-REMOTE-SOURCES then
set core-tree mldp-inband
else
pass
endif
end-policy
!
router pim
address-family ipv4
rpf topology route-policy PL-MLDP-INBAND
!
multicast-routing
address-family ipv4
mdt mldp in-band-signaling ipv4
!
PE4 está configurado de forma similar, con sólo algunos ajustes en el prefix-set. Al igual que en Junos, esta configuración sólo es necesaria en los PE, no en los Ps. Tras borrar el estado de Unión C-PIM en PE2 y PE4 -utilizando el comando clear pim ipv4 topology-, el ping multidifusión de H1 a 232.1.1.1 empieza a recibir respuestas de H2, H22 y H44.
Advertencia
Utiliza el comando clear pim ipv4 topology con precaución. Este comando suele perturbar los flujos multidifusión establecidos. Intenta ser específico con respecto al (S, G) concreto que quieres borrar.
Veamos cómo se señalizan estas ramas del árbol multidifusión a través del núcleo. En realidad, uno de los PE de salida (PE2) actúa como punto de ramificación, por lo que las rutas H1→H2 y H1→H22 comparten en realidad la misma sub-ruta (PE1→PE2) en el núcleo.
A continuación se muestra el estado de Unión ascendente C-PIM en PE2. Recuerda que el enlace PE1-PE2 tiene un valor métrico IS-IS alto, por lo que la ruta PE2→PE1 más corta pasa por P2 y P1.
Ejemplo 4-27. Unión C-PIM ascendente en el PE-PE2 de salida (IOS XR)
RP/0/0/CPU0:PE2#show mrib route 232.1.1.1
IP Multicast Routing Information Base
[...]
(10.1.1.10,232.1.1.1) RPF nbr: 10.0.0.5 Flags: RPF
Up: 01:00:38
Incoming Interface List
Imdtdefault Flags: A LMI, Up: 01:00:38
Outgoing Interface List
GigabitEthernet0/0/0/0.1020 Flags: F NS, Up: 01:00:38
GigabitEthernet0/0/0/1.1022 Flags: F NS LI, Up: 01:00:38
La interfaz imdtdefault es el "pegamento" interno entre los dominios C-PIM y mLDP en PE2. Que no te confunda el nombre: este LSP mLDP es un MDT (árbol selectivo) de datos. Ahora, el estado de Unión ascendente C-PIM desencadena la creación y señalización de un mapeo de etiquetas P2MP FEC que PE2 envía a P2.
Ejemplo 4-28. Señalización P2MP FEC desde el PE-PE2 de salida (IOS XR)
RP/0/0/CPU0:PE2#show mpls mldp database
mLDP database
LSM-ID: 0x00001 Type: P2MP Uptime: 01:08:29
FEC Root : 172.16.0.11
Opaque decoded : [ipv4 10.1.1.10 232.1.1.1]
Upstream neighbor(s) :
172.16.0.2:0 [Active] Uptime: 00:12:26
Local Label (D) : 24021
Downstream client(s):
PIM MDT Uptime: 01:08:29
Egress intf : Imdtdefault
Table ID : IPv4: 0xe0000000
RPF ID : 3
P2 recibe mapeos de etiquetas FEC P2MP de PE2 y PE4, que luego se agregan en un único mapeo de etiquetas que P2 señala aguas arriba a P1.
Ejemplo 4-29. Señalización P2MP FEC en Tránsito P-P2 (IOS XR)
RP/0/0/CPU0:P2#show mpls mldp database
mLDP database
LSM-ID: 0x00003 Type: P2MP Uptime: 00:39:07
FEC Root : 172.16.0.11
Opaque decoded : [ipv4 10.1.1.10 232.1.1.1]
Upstream neighbor(s) :
172.16.0.1:0 [Active] Uptime: 00:39:07
Local Label (D) : 24020
Downstream client(s):
LDP 172.16.0.22:0 Uptime: 00:39:07
Next Hop : 10.0.0.4
Interface : GigabitEthernet0/0/0/0
Remote label (D) : 24021
LDP 172.16.0.44:0 Uptime: 00:37:55
Next Hop : 10.0.0.11
Interface : GigabitEthernet0/0/0/5
Remote label (D) : 24021
Nota
En el Ejemplo 4-29, el valor de la etiqueta remota 24021 resulta ser el mismo en las dos ramas descendentes. Se trata de una coincidencia típica de MPLS; las etiquetas también podrían haber tenido valores distintos.
Ésta es la vista del plano de control de un punto de ramificación: dos ramas descendentes (P2→PE2 y P2→PE4) se fusionan en una única rama ascendente (P1→P2). En el plano de reenvío, el proceso es el contrario: un paquete que llega a P2 desde P1 se replica hacia PE2 y PE4. Examinemos la vida de un paquete C-Multicast.
Vida de un paquete C-Multicast en un LSP mLDP P2MP
Tras analizar el plano de control, centrémonos en el plano de reenvío.
Entrada PE
PE1 replica cada paquete C-Multicast entrante (10.1.1.10, 232.1.1.1) y envía una copia hacia el receptor H11 conectado directamente, y otra copia -encapsulada en MPLS- hacia el enlace central PE1-P1, como se muestra en el Ejemplo 4-30.
Ejemplo 4-30. Reenvío de LSP mLDP P2MP en el PE-PE1 de entrada (Junos)
1 juniper@PE1> show multicast route detail 2 Instance: master Family: INET 3 4 Group: 232.1.1.1 5 Source: 10.1.1.10/32 6 Upstream interface: ge-2/0/1.1010 7 Downstream interface list: 8 ge-2/0/4.0 ge-2/0/2.1011 9 Session description: Source specific multicast 10 Statistics: 0 kBps, 1 pps, 8567 packets 11 Next-hop ID: 1048581 12 Upstream protocol: PIM 13 14 juniper@PE1> show route table inet.1 match-prefix "232.1.1.1*" 15 16 inet.1: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden) 17 + = Active Route, - = Last Active, * = Both 18 19 232.1.1.1,10.1.1.10/64*[PIM/105] 07:08:35 20 to 10.0.0.3 via ge-2/0/4.0, Push 300400 21 via ge-2/0/2.1011 22 23 juniper@PE1> show route forwarding-table destination 232.1.1.1 24 table default extensive 25 Destination: 232.1.1.1.10.1.1.10/64 26 Route type: user 27 Route reference: 0 Route interface-index: 332 28 Multicast RPF nh index: 0 29 Flags: cached, check incoming interface, [...] 30 Next-hop type: indirect Index: 1048581 Reference: 2 31 Nexthop: 32 Next-hop type: composite Index: 595 Reference: 1 33 # Now comes the list of core (MPLS) next hops 34 Next-hop type: indirect Index: 1048577 Reference: 2 35 Nexthop: 36 Next-hop type: composite Index: 592 Reference: 1 37 Nexthop: 10.0.0.3 38 Next-hop type: Push 300400 Index: 637 Reference: 2 39 Load Balance Label: None 40 Next-hop interface: ge-2/0/4.0 41 # Now comes the list of access (IPv4) next hops 42 Next-hop type: indirect Index: 1048591 Reference: 2 43 Nexthop: 44 Next-hop type: composite Index: 633 Reference: 1 45 Next-hop type: unicast Index: 1048574 Reference: 3 46 Next-hop interface: ge-2/0/2.1011
Todos los comandos anteriores simplemente muestran diferentes etapas de una entrada de la caché de reenvío multidifusión. La Base de Información de Enrutamiento (RIB) auxiliar de inet.1 es en realidad una caché multidifusión cuyas entradas rellenan la tabla de reenvío (la Base de Información de Reenvío [FIB]). Existe un profundo nivel de indirección en las estructuras de siguiente salto de Junos. En la práctica, puedes pensar en el siguiente salto de composite como una acción. En el caso de las rutas multidifusión, esta acción es replicar. Puedes encontrar una discusión completa sobre los próximos saltos compuestos aplicados a la unidifusión en el Capítulo 20.
Mira la línea 37 del Ejemplo 4-30. Una copia del paquete C-Multicast se encapsula en MPLS y luego en Ethernet. La dirección MAC de destino de la trama Ethernet es la dirección MAC de unidifusión asociada a 10.0.0.3 (P1), normalmente resuelta mediante ARP.
Nota
La multidifusión en MPLS sobre Ethernet se transporta en tramas unidifusión.
Ésta es una ventaja importante para escenarios en los que el enlace central, a pesar de ser lógicamente punto a punto, transita por una infraestructura multipunto subyacente. Por ejemplo, la AS 65000 puede comprar servicios L2VPN multipunto a un SP externo y utilizar esta superposición L2 para implementar sus propios enlaces centrales. Desde la perspectiva de la AS 65000, se trata de enlaces centrales punto a punto, pero entre bastidores las tramas Ethernet multidifusión se inundan a través de la L2VPN multipunto en la red del proveedor de transporte. Este razonamiento pone de manifiesto la ventaja de encapsular los paquetes C-Multicast en tramas unidifusión MPLS sobre Ethernet. Los servicios L2VPN se tratan con más detalle en los Capítulos 6, 7 y 8.
Por último, puedes ignorar el término unicast en el Ejemplo 4-30, línea 45. Su significado se explica detalladamente en el capítulo 20 y no tiene nada que ver con la noción clásica de unidifusión.
Debido al esquema de métricas IGP actualmente configurado -los enlaces inter-PE tienen una métrica más alta (100)-, PE1 sólo envía una copia del paquete C-Multicast al núcleo. Si las métricas IGP volvieran a los valores por defecto, PE1 enviaría una copia a P1 y otra copia a PE2. En otras palabras, nada impide que un PE de entrada sea un punto de replicación de un LSP P2MP si la topología lo requiere.
Nota
En este ejemplo, el PE de entrada (PE1) ejecuta Junos. Si el ping multidifusión procede de H2, el PE de entrada (PE2) ejecuta IOS XR, y los resultados son satisfactorios y simétricos a los mostrados aquí.
Enrutador P de tránsito con Junos
Cuando llega a P1, el paquete MPLS se replica en dos copias: una va a PE3 y otra a P2, como se muestra en el Ejemplo 4-31.
Ejemplo 4-31. Reenvío mLDP P2MP LSP en un PE-P1 de tránsito (Junos)
juniper@P1> show ldp p2mp path
P2MP path type: Transit/Egress
Output Session (label): 172.16.0.11:0 (300400) (Primary)
Input Session (label): 172.16.0.33:0 (301200)
172.16.0.2:0 (24020)
Attached FECs: P2MP root-addr 172.16.0.11,
grp: 232.1.1.1, src: 10.1.1.10 (Active)
juniper@P1> show route forwarding-table label 300400 extensive
Routing table: default.mpls [Index 0]
MPLS:
Destination: 300400
Route type: user
Route reference: 0 Route interface-index: 0
Multicast RPF nh index: 0
Flags: sent to PFE
Next-hop type: indirect Index: 1048582 Reference: 2
Nexthop:
Next-hop type: composite Index: 602 Reference: 1
# Now comes the replication towards PE3
Nexthop: 10.0.0.9
Next-hop type: Swap 301200 Index: 594 Reference: 2
Load Balance Label: None
Next-hop interface: ge-2/0/6.0
# Now comes the replication towards P2
Next-hop type: unilist Index: 1048581 Reference: 2
# Now comes the first P1-P2 link for load balancing
Nexthop: 10.0.0.7
Next-hop type: Swap 24020 Index: 596 Reference: 1
Load Balance Label: None
Next-hop interface: ge-2/0/3.0 Weight: 0x1
# Now comes the second P1-P2 link for load balancing
Nexthop: 10.0.0.25
Next-hop type: Swap 24020 Index: 597 Reference: 1
Load Balance Label: None
Next-hop interface: ge-2/0/4.0 Weight: 0x1
Si te fijas bien en el Ejemplo 4-31, hay un nuevo tipo de siguiente salto llamado unilist. Significa que la copia única del paquete que se envía a P2 debe equilibrarse en carga -no replicarse- a través de los dos enlaces P1-P2. Esta copia única se envía por el primer o por el segundo enlace, dependiendo de los resultados del cálculo del hash del paquete (consulta "LDP y Equal-Cost Multipath" si este lenguaje no te resulta familiar). El hecho de que el Peso sea 0x1 en ambos enlaces significa que ambos están disponibles para el equilibrio de carga. Por tanto, en Junos, mLDP admite de forma nativa Equal-Cost Multipath (ECMP) a través de enlaces paralelos.
Enrutador P de tránsito con IOS XR
P2 sigue replicando el paquete hasta PE2 y PE4, como se ilustra en el siguiente ejemplo:
Ejemplo 4-32. Reenvío mLDP P2MP LSP en un PE-P2 de tránsito (IOS XR)
RP/0/0/CPU0:P2#show mpls forwarding labels 24020
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ------- -------------- ---------- ---------- --------
24020 24021 MLDP: 0x00003 Gi0/0/0/0 10.0.0.4 2170
24021 MLDP: 0x00003 Gi0/0/0/5 10.0.0.11 2170
PE de salida con Junos
PE3 extrae la etiqueta MPLS y replica los paquetes multidifusión IPv4 resultantes hacia los dos AC receptores, como puedes ver en el Ejemplo 4-33.
Nota
En los LSP P2MP no hay salto penúltimo (PHP). En el caso de la multidifusión global de Internet de este capítulo, esto es importante porque los enlaces centrales no deben transportar paquetes de multidifusión de usuario nativo. En el caso de la VPN multidifusión, también es importante, pero por un motivo distinto, que se trata en el Capítulo 5.
Ejemplo 4-33. Reenvío de LSP mLDP P2MP en un PE-PE3 de salida (Junos)
juniper@PE3> show route forwarding-table label 301200 extensive Routing table: default.mpls [Index 0] MPLS: Destination: 301200 Route type: user Route reference: 0 Route interface-index: 0 Multicast RPF nh index: 0 Flags: sent to PFE Next-hop type: indirect Index: 1048577 Reference: 2 Nexthop: Next-hop type: composite Index: 601 Reference: 1 # Now comes the replication towards VLAN 1034 [...] Next-hop type: Pop Index: 597 Reference: 2 Load Balance Label: None Next-hop interface: ge-2/0/3.1034 # Now comes the replication towards H33 [...] Next-hop type: Pop Index: 600 Reference: 2 Load Balance Label: None Next-hop interface: ge-2/0/4.1033
Los siguientes saltos de multidifusión se han eliminado del Ejemplo 4-33 porque son engañosos: las direcciones MAC de multidifusión se calculan con una regla matemática; no se resuelven mediante ARP.
PE de salida con IOS XR
Veamos cómo PE4 salta la etiqueta MPLS y envía el paquete multidifusión IPv4 sólo a H44.
Ejemplo 4-34. Reenvío mLDP P2MP LSP en un PE-PE4 de salida (IOS XR)
RP/0/0/CPU0:PE4#show mrib route 10.1.1.10 232.1.1.1
IP Multicast Routing Information Base
[...]
(10.1.1.10,232.1.1.1) RPF nbr: 10.0.0.10 Flags: RPF
Up: 09:45:39
Incoming Interface List
Imdtdefault Flags: A LMI, Up: 03:17:05
Outgoing Interface List
GigabitEthernet0/0/0/2.1034 Flags: LI, Up: 12:40:38
GigabitEthernet0/0/0/3.1044 Flags: F NS LI, Up: 09:01:24
En las pruebas de este libro, H44 sólo recibe el flujo C-Multicast si la entrada CEF unidifusión de PE4 para 172.16.0.11 resuelve a una etiqueta LDP. Si el RPF de PE4 a PE1 se resuelve con un túnel RSVP (P2P), PE4 no reenvía el tráfico a H44. En otras palabras, en el momento de escribir esto, la implementación IOS XR de mLDP no coexiste con RSVP-TE unidifusión. Esta condición límite no se observó en Junos PE3.
El punto clave de la salida anterior es el indicador F - Reenviar. La interfaz hacia H44 tiene la bandera activada, pero la otra interfaz (VLAN 1034) no. Sin embargo, si detienes la fuente y esperas unos minutos, la bandera F vuelve a estar activada en ambas entradas. Veamos por qué.
CE Multihoming
Es esencial que cada host reciba una, y sólo una, copia de cada paquete multidifusión. H2, H11, H22, H33 y H44 no tienen redundancia de acceso, por lo que no reciben varias copias de cada paquete enviado por H1. Por el contrario, H3, H4 y H34 son multihomed (directa o indirectamente) a PE3 y PE4. Analicemos este caso con más detalle.
Redundancia PE de salida
La siguiente discusión es bastante genérica en Multicast IP y no específica del modelo mLDP In-Band. La topología de la VLAN 1034(Figura 4-1) es un ejemplo clásico de Redundancia PE. Tres dispositivos (BR3, BR4 y H34) están conectados al SP (AS 65000) en una VLAN que es multihomed tanto para PE3 como para PE4. Hay dos sesiones EBGP establecidas: PE3-BR3 y PE4-BR4. Además, todos los routers de la VLAN 1034 son vecinos PIM. Ésta es la configuración PIM específica de los dispositivos:
-
PE3:
protocols pim interface ge-2/0/3.1034 priority 200 -
PE4: Configuración por defecto ( prioridad PIM 1)
-
BR3, BR4:
protocols pim interface ge-0/0/1.1034 priority 0 -
H34:
router pim [vrf H34] address-family ipv4 interface GigabitEthernet0/0/0/0.1034 dr-priority 0
Con esta configuración, PE3 es el router designado (DR), lo que puedes verificar utilizando el comando show pim interfaces en PE3, o show pim neighbor en PE4. El DR es responsable de procesar los Informes IGMP de los hosts conectados directamente (en este caso, H34).
La Figura 4-4 ilustra el proceso de convergencia C-Multicast en la VLAN 1034, en dos pasos.
Figura 4-4. Redundancia C-Multicast-egress PE y C-PIM Assert
Inicialmente, tanto PE3 como PE4 están preparados para reenviar el tráfico (10.1.1.10, 232.1.1.1) a la VLAN 1034. He aquí por qué:
-
PE3 es el DR y está procesando los Informes IGMP de H34.
-
PE3 es el vecino ascendente de un Join PIM (10.1.1.10, 232.1.1.1) enviado por BR3, porque BR3 sólo tiene una sesión eBGP con PE3.
-
PE4 es el vecino ascendente de un Join PIM (10.1.1.10, 232.1.1.1) enviado por BR4, porque BR4 sólo tiene una sesión eBGP con PE4.
Cuando H1 envía el primer paquete C-Multicast a 232.1.1.1, tanto PE3 como PE4 lo reenvían a la VLAN 1034. Esto provoca una duplicación de paquetes C-Multicast en la VLAN 1034, que puedes comprobar en el primer conjunto de respuestas ping.
Ejemplo 4-35. Reenvío mLDP P2MP LSP en un PE-P2 de tránsito (IOS XR)
1 RP/0/0/CPU0:H# ping vrf H1 232.1.1.1 source 10.1.1.10 count 1 2 Reply to request 0 from 10.1.11.11, 1 ms 3 Reply to request 0 from 10.1.22.22, 9 ms 4 Reply to request 0 from 10.2.33.33, 9 ms 5 Reply to request 0 from 10.2.44.44, 9 ms 6 Reply to request 0 from 10.2.3.30, 9 ms 7 Reply to request 0 from 10.2.0.34, 9 ms 8 Reply to request 0 from 10.2.4.40, 9 ms 9 Reply to request 0 from 10.2.3.30, 19 ms 10 Reply to request 0 from 10.2.0.34, 19 ms 11 Reply to request 0 from 10.2.4.40, 19 ms
La petición eco ICMP nº 0 recibe respuestas duplicadas de H3, H34 y H4. Desde el punto de vista del servicio, esto es totalmente indeseable. Para la mayoría de las aplicaciones de multidifusión, recibir una copia duplicada o multiplicada del flujo de datos original puede ser tan malo como no recibirlo en absoluto. Por esa razón, cuando PE3 y PE4 detectan esta duplicación de paquetes, inician una competición llamada PIM Assert, basada en su ruta a la fuente de multidifusión 10.1.1.10.
Ejemplo 4-36. Redundancia PE de salida - Ruta unidifusión al origen C
1 juniper@PE3> show route active-path 10.1.1.10 2 3 inet.0: 44 destinations, 53 routes (44 active, 0 holddown, 0 hidden) 4 5 10.1.1.0/24 *[BGP/170] 1d 12:04:09, MED 100, localpref 100, 6 from 172.16.0.201, AS path: 65001 I [...] 7 > to 10.0.0.8 via ge-2/0/1.0, Push 300368 8 9 RP/0/0/CPU0:PE4#show route 10.1.1.10 10 11 Routing entry for 10.1.1.0/24 12 Known via "bgp 65000", distance 200, metric 100 13 Tag 65001, type internal 14 Installed Jan 6 06:11:52.147 for 15:19:12 15 Routing Descriptor Blocks 16 172.16.0.11, from 172.16.0.201 17 Route metric is 100 18 No advertising protos.
Aunque el atributo MED de la ruta es 100 en ambos casos, la distancia administrativa por defecto del protocolo BGP es 170 en PE3 (línea 5, Junos), frente a 200 en PE4 (línea 12, IOS XR). Gana la distancia administrativa más baja, por lo que PE3 se convierte en el ganador de C-PIM (10.1.1.10, 232.1.1.1) Assert. En este punto, PE4 deja de inyectar el flujo en la VLAN 1034. Además, como los paquetes PIM Assert se envían a la dirección 224.0.0.13, BR4 ve la competición Assert y redirige su PIM (C-S, C-G) Join Upstream Neighbor a PE3. En general, se soluciona la duplicación de paquetes en la VLAN 1034 y PE3 se convierte en el reenviador único.
Nota
No hay ninguna afirmación en la VLAN 1044. Por tanto, el hecho de que PE3 sea el ganador de la afirmación en la VLAN 1034 no impide que PE4 reenvíe los paquetes a H44.
Como es de esperar en PIM, los paquetes Assert se actualizan periódicamente. En otras palabras, Assert, al igual que Join/Prune, tiene un estado suave. Unos minutos después de que la C-Fuente deje de enviar tráfico, se agota el tiempo de espera de Assert y se reanuda el estado inicial (aparece la bandera F para la VLAN 1034 en el Ejemplo 4-34). Por lo tanto, incluso en un modelo con PIM SSM, hay escenarios en los que la señalización del árbol multidifusión está dirigida por datos.
Redundancia PE de entrada
Ahora, supongamos que una fuente C-Multicast activa está multihomedada a PE1 y PE2, y que esta fuente está enviando tráfico a (C-S, C-G). Ahora, tanto H33 como H44 envían un Informe IGMP suscribiéndose a ese flujo. ¿Cómo se señaliza el LSP P2MP? Hay dos casos:
-
Tanto PE3 como PE4 eligen el mismo PE ascendente (ya sea PE1 o PE2) como raíz para el FEC P2MP. En este caso, se crea un único LSP P2MP, con una raíz y dos hojas: PE3 y PE4.
-
PE3 y PE4 eligen PEs ascendentes diferentes. Por ejemplo, PE3 selecciona PE1 y PE4 selecciona PE2. En este caso, hay dos LSP P2MP, uno enraizado en PE1 y otro enraizado en PE2. Cada uno de estos LSP P2MP tiene una única (y diferente) hoja.
No hay riesgo de duplicación de datos en ninguno de estos casos: cada PE de salida señala la FEC P2MP hacia un único PE de entrada. Ésta es una ventaja general de los Árboles Selectivos.
mLDP En Banda y PIM ASM
En el momento de escribir esto, las implementaciones de los proveedores sólo admiten PIM SSM en combinación con mLDP In-Band. Los esfuerzos para dar soporte a PIM ASM están polarizados en dos RFC:
-
RFC 7438 - Señalización en banda mLDP con comodines
-
RFC 7442 - Transporte de árboles PIM-SM en modo ASM sobre mLDP
Otras variantes de multidifusión por Internet sobre MPLS
Existen algunas variantes adicionales de la multidifusión global por Internet (S1). Aquí tienes una lista no exhaustiva.
LSP estáticos RSVP-TE P2MP
Existe otro modelo interoperable para señalizar y transportar la multidifusión de Internet entre PE de Junos y PE de IOS XR. En la documentación de Cisco, se denomina P2MP-TE Global. En los términos de la Tabla 4-1, es S1, A0, C0, E3, T3, Y3.
Se basa en el uso de rutas estáticas para colocar el tráfico IP Multicast en LSPs RSVP-TE P2MP. El administrador de red configura manualmente las hojas de cada LSP. Aunque puedes aplicar con éxito este modelo a entornos relativamente estáticos, como la IPTV tradicional, no resulta especialmente atractivo para los fines de este libro.
Multidifusión por Internet BGP
Junos admite un tipo de instancia de enrutamiento denominada mpls-internet-multicast, que aplica técnicas de VPN multidifusión BGP a la señalización y el transporte del tráfico multidifusión de Internet. En los términos de la Tabla 4-1, es S1, A3, C3, [E1, E2, E3], [T0, T1, T2, T3, T4], [Y1, Y2, Y3, Y4]. Sin embargo, no todas las combinaciones son compatibles.
Aunque IOS XR no implementa este enfoque, puedes configurar los PE de IOS XR con VRFs de Internet que ejecuten VPN Multicast BGP. Dicho esto, desde el punto de vista de la interoperabilidad es más interesante centrarse en la auténtica VPN multidifusión BGP, con VRF en ambos tipos de PE (Junos e IOS XR). ¡Vamos a por ello en el Capítulo 5!
Get MPLS en la era SDN now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
