El protocolo PIM es un conjunto de protocolos para la transmisión de multicast en la red entre enrutadores. Las relaciones de vecindad se construyen de manera similar a la de los protocolos de enrutamiento dinámico. PIMv2 envía cada 30 segundos mensajes Hello a la dirección multicast reservada 224.0.0.13 (All-PIM-Routers). El mensaje contiene los Hold Timers, que generalmente es igual a 3.5 veces el Hello Timer, es decir, 105 segundos por defecto.
PIM utiliza dos modos de operación principales: Dense y Sparse. Comencemos con el modo Dense.
Árboles de distribución basados en la fuente.
El modo Dense es apropiado cuando hay un gran número de clientes de varios grupos multicast. Cuando el enrutador recibe tráfico multicast, primero verifica la regla RPF. RPF es una regla que se utiliza para verificar la fuente del multicast con la tabla de enrutamiento unicast. Es necesario que el tráfico llegue a la interfaz que oculta a este host según la tabla de enrutamiento unicast. Este mecanismo resuelve el problema de la aparición de bucles durante la transmisión de multicast.
R3, a partir del mensaje multicast, reconoce la fuente del multicast (Source IP) y revisa dos flujos de R1 y R2 en su tabla de enrutamiento unicast. El flujo desde la interfaz que indica la tabla (R1 a R3) será transmitido, mientras que el flujo de R2 será descartado, ya que para llegar a la fuente del multicast, los paquetes deben ser enviados a través de S0/1.
La pregunta es: ¿qué sucederá si tienes dos rutas equivalentes con la misma métrica? En este caso, el enrutador elegirá según el next-hop de estas rutas. Aquella con la dirección IP más alta ganará. Si es necesario modificar este comportamiento, se puede utilizar ECMP. Más detalles .
Después de verificar la regla RPF, el enrutador envía el paquete multicast a todos sus vecinos PIM, excepto al que recibió el paquete. Los demás enrutadores PIM repiten este proceso. El camino que siguió el paquete multicast desde la fuente hasta los destinatarios finales forma un árbol llamado árbol de distribución basado en la fuente, árbol de camino más corto (SPT), árbol de fuente. Tres nombres diferentes, elige cualquiera.
¿Cómo resolver el problema de que algunos enrutadores no puedan recibir un flujo multicast y no haya nadie a quien enviárselo, mientras que su enrutador ascendente lo envía? Para ello se ideó el mecanismo Prune.
Mensaje Prune.
Por ejemplo, R2 seguirá enviando multicast a R3, aunque R3 lo descarte por la regla RPF. ¿Por qué sobrecargar el canal? R3 envía un mensaje PIM Prune y R2, al recibir este mensaje, eliminará la interfaz S0/1 de la lista de interfaces de salida para este flujo, lista de interfaces desde las cuales se debe enviar este tráfico.
La siguiente es una definición más formal de un mensaje PIM Prune:
El mensaje PIM Prune es enviado por un router a un segundo router para hacer que el segundo router elimine el enlace sobre el cual se recibe el Prune de un SPT (S,G) particular.
Después de recibir el mensaje Prune, R2 establece un temporizador Prune en 3 minutos. Después de tres minutos, comenzará a enviar tráfico nuevamente, hasta que reciba otro mensaje Prune. Esto es en PIMv1.
En PIMv2 se ha añadido el temporizador State Refresh (por defecto 60 segundos). Tan pronto como se envía un mensaje Prune desde R3, se activa este temporizador en R3. Al expirar este temporizador, R3 enviará un mensaje State Refresh, que restablecerá el temporizador Prune de 3 minutos en R2 para este grupo.
Razones para enviar un mensaje Prune:
- Cuando un paquete multicast no pasa la verificación RPF.
- Cuando no hay clientes localmente conectados que hayan solicitado unirse a un grupo multicast (IGMP Join) y no hay vecinos PIM a los cuales se pueda enviar tráfico multicast (interfaz no podada).
Mensaje Graft.
Imaginemos que R3 no quería tráfico de R2, envió un Prune y estaba recibiendo multicast de R1. Pero de repente, se cayó el canal entre R1 y R3 y R3 quedó sin multicast. Se pueden esperar 3 minutos hasta que el temporizador Prune en R2 expire. Tres minutos es mucho tiempo para esperar, por lo que es necesario enviar un mensaje que elimine inmediatamente el estado podado de la interfaz S0/1 en R2. Este mensaje será el mensaje Graft. Tras recibir el mensaje Graft, R2 enviará en respuesta un Graft-ACK.
Sobrecarga de Prune.
Veamos este esquema. R1 transmite multicast en el segmento con dos enrutadores. R3 recibe y transmite tráfico, R2 recibe, pero no tiene a quién transmitir el tráfico. Envía un mensaje de Prune a R1 en este segmento. R1 debe eliminar Fa0/0 de la lista y dejar de transmitir en este segmento, pero, ¿qué pasará con R3? R3 está en el mismo segmento y también ha recibido este mensaje de Prune y comprende toda la gravedad de la situación. Antes de que R1 deje de transmitir, establece un temporizador de 3 segundos y dejará de transmitir en 3 segundos. Son 3 segundos — exactamente el tiempo que tiene R3 para no perder su multicast. Por lo tanto, R3, lo antes posible, envía un mensaje Pim Join para este grupo y R1 ya no piensa en dejar de transmitir. A continuación, se explican los mensajes de Join.
Mensaje Assert.
Imaginemos la siguiente situación: en una red transmiten simultáneamente dos enrutadores. Reciben el mismo flujo de la fuente y ambos lo transmiten en una red a través de la interfaz e0. Por lo tanto, necesitan determinar quién será el único transmisor para esta red. Para esto se utilizan mensajes Assert. Cuando R2 y R3 detectan la duplicación del tráfico multicast, es decir, en R2 y R3 llega un multicast que ellos mismos transmiten, los enrutadores entienden que aquí algo no está bien. En ese caso, los enrutadores envían mensajes Assert que incluyen la Distancia Administrativa y la métrica de la ruta que se utiliza para alcanzar la fuente del multicast — 10.1.1.10. El ganador se determina así:
- El que tenga la AD más baja.
- Si la AD es igual, entonces el que tenga la métrica más baja.
- Si sigue habiendo igualdad, entonces el que tenga la dirección IP más alta en la red en la que están transmitiendo este multicast.
El ganador de esta votación se convierte en el Enrutador Designado. Para elegir al DR también se utilizan mensajes Pim Hello. Al inicio del artículo se mostró el mensaje PIM Hello, donde se puede notar el campo DR. Gana el que tenga la dirección IP más alta en este enlace.
Tabla útil:
Tabla MROUTE.
Después de la revisión inicial del funcionamiento del protocolo PIM, necesitamos entender cómo trabajar con la tabla de enrutamiento multicast. En la tabla mroute se almacena información sobre qué flujos han sido solicitados por los clientes y qué flujos se están transmitiendo desde los servidores multicast.
Por ejemplo, al recibir un Informe de Membresía IGMP o un PIM Join en alguna interfaz, se añade una entrada en la tabla de enrutamiento tipo (*, G):
Este registro significa que se ha recibido una solicitud de tráfico desde la dirección 238.38.38.38. La bandera DC indica que el multicast funcionará en modo denso y C significa que el receptor está conectado directamente al enrutador, es decir, el enrutador recibió un informe de membresía IGMP y unirse a PIM.
Si hay un registro del tipo (S,G), significa que tenemos un flujo multicast:
En el campo S — 192.168.1.11, tenemos la dirección IP de la fuente del multicast, que será verificada por la regla RPF. En caso de problemas, primero se debe verificar la tabla unicast para la ruta hacia la fuente. En el campo de interfaz entrante se indica la interfaz por la que llega el multicast. En la tabla de enrutamiento unicast, la ruta hacia la fuente debe hacer referencia a la interfaz indicada aquí. En la interfaz saliente se indica hacia dónde se redirigirá el multicast. Si está vacío, significa que no han llegado solicitudes para ese tráfico al enrutador. Más información detallada sobre todas las banderas se puede encontrar. .
PIM Sparse-mode.
La estrategia Sparse-mode es opuesta al Dense-mode. Cuando Sparse-mode recibe tráfico multicast, enviará tráfico solo a través de aquellas interfaces donde haya habido solicitudes para ese flujo, como mensajes Pim Join o informes IGMP con solicitudes para ese tráfico.
Elementos similares entre SM y DM:
- Las relaciones de vecindad se establecen de la misma manera que en PIM DM.
- La regla RPF está activa.
- La selección de DR es similar.
- El mecanismo Prune Overrides y los mensajes Assert son análogos.
Para controlar a quién, dónde y qué tráfico multicast se necesita en la red, se requiere un centro de información común. Este centro será nuestro Punto de Rendezvous (RP). Todos los que deseen algún tráfico multicast o que comiencen a recibir tráfico multicast de la fuente, deben enviarlo al RP.
Cuando el RP reciba tráfico multicast, lo enviará a aquellos enrutadores que lo han solicitado previamente.
Imaginemos una topología donde RP es R3. Tan pronto como R1 reciba tráfico de S1, encapsulará este paquete multicast en un mensaje unicast PIM Register y lo enviará al RP. ¿Cómo sabe quién es el RP? En este caso, está configurado estáticamente, y hablaremos sobre la configuración dinámica del RP más adelante.
ip pim rp-address 3.3.3.3
RP verificará si hubo información de alguien que deseara recibir este tráfico. Supongamos que no hubo. Entonces, RP enviará a R1 un mensaje PIM Register-Stop, lo que significa que a nadie le interesa este multicast, la inscripción ha sido rechazada. R1 no enviará el multicast. Sin embargo, la fuente del host del multicast lo seguirá enviando, así que R1, tras recibir el Register-Stop, iniciará un temporizador de su suppressión de registro, igual a 60 segundos. 5 segundos antes de que expire este temporizador, R1 enviará un mensaje Register vacío con el bit Null-Register (es decir, sin el paquete multicast encapsulado) hacia RP. RP, a su vez, actuará de la siguiente manera:
- Si no hay receptores, responderá con un mensaje Register-Stop.
- Si aparecen receptores, no responderá de ninguna manera. R1, al no recibir una negativa a su registro en 5 segundos, se alegrará y enviará un mensaje Register con el multicast encapsulado a RP.
Ya parece claro cómo llega el multicast a RP, ahora intentaremos responder la pregunta de cómo RP lleva el tráfico a los receptores. Aquí es necesario introducir un nuevo concepto: el árbol de ruta raíz (RPT). El RPT es un árbol con su raíz en RP, creciendo hacia los receptores, ramificándose en cada enrutador PIM-SM. RP lo crea al recibir mensajes PIM Join y agrega una nueva rama al árbol. Así, cada enrutador descendente hace lo mismo. La regla general es la siguiente:
- Cuando un enrutador PIM-SM recibe un mensaje PIM Join en alguna interfaz, excepto en la interfaz donde se oculta RP, agrega una nueva rama al árbol.
- También se agrega una rama cuando un enrutador PIM-SM recibe un informe de membresía IGMP desde un host directamente conectado.
Imaginemos que tenemos un cliente multicast en el enrutador R5 en el grupo 228.8.8.8. Tan pronto como R5 reciba un informe de membresía IGMP del host, R5 envía PIM Join en dirección a RP y agrega la interfaz que mira hacia el host al árbol. Luego, R4 recibe PIM Join de R5, agrega a la interfaz Gi0/1 en el árbol y envía PIM Join en dirección a RP. Finalmente, RP (R3) recibe PIM Join y agrega Gi0/0 al árbol. Así, se registra al receptor del multicast. Se forma un árbol con raíz R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
Después de esto, se enviará un PIM Join a R1 y R1 comenzará a enviar tráfico multicast. Es importante notar que si el host solicitó el tráfico antes de que comenzara la transmisión del multicast, el RP no enviará el PIM Join y, en general, no enviará nada hacia R1.
Si de repente, mientras se envía el multicast, el host deja de querer recibirlo, tan pronto como el RP reciba el PIM Prune en la interfaz Gi0/0, enviará inmediatamente un PIM Register-Stop directamente a R1, y luego el mensaje PIM Prune a través de la interfaz Gi0/1. El PIM Register-stop se envía por unicasting a la dirección desde la cual se recibió el PIM Register.
Como mencionamos antes, tan pronto como el enrutador envía un PIM Join a otro, por ejemplo, R5 a R4, se agrega una entrada en R4:
Y se inicia un temporizador, que deberá ser reiniciado constantemente por R5 con mensajes PIM Join, de lo contrario, R4 lo excluirá de la lista de salida. R5 enviará mensajes PIM Join cada 60 segundos.
Cambio de Árbol de Ruta Más Corta.
Agregaremos una interfaz entre R1 y R5, y veremos cómo fluye el tráfico con esta topología.
Supongamos que el tráfico se envió y recibió según el antiguo esquema R1-R2-R3-R4-R5, y luego conectamos y configuramos la interfaz entre R1 y R5.
Primero, se reconstruirá la tabla de enrutamiento de unicasting en R5 y ahora la red 192.168.1.0/24 se alcanza a través de la interfaz R5 Gi0/2. Ahora, al recibir multicast en la interfaz Gi0/1, R5 entiende que la regla RPF no se satisface y sería más lógico recibir el multicast a través de Gi0/2. Debe desconectarse del RPT y construir un árbol más corto, que se llama Árbol de Ruta Más Corta (SPT). Para ello, envía un PIM Join a R1 a través de Gi0/2 y R1 comienza a enviar multicast también a través de Gi0/2. Ahora R5 debe darse de baja del RPT para no recibir dos copias. Para ello, envía un mensaje Prune indicando la dirección IP de origen e insertando un bit especial — RPT-bit. Esto significa que no necesito que me envíen tráfico, tengo aquí un árbol mejor. RP también envía mensajes PIM Prune hacia R1, pero no envía el mensaje Register-Stop. Otra característica es que R5 ahora enviará constantemente PIM Prune al RP, ya que R1 continúa enviando PIM Register al RP cada minuto. El RP, mientras no haya nuevos interesados en este tráfico, le responderá con un rechazo. R5 notifica al RP que sigue recibiendo multicast a través del SPT.
Búsqueda dinámica de RP.
Auto-RP.
Esta tecnología es propietaria de Cisco y no es muy popular, pero todavía está presente. El funcionamiento de Auto-RP se basa en dos etapas principales:
1) El RP envía mensajes RP-Announce a la dirección reservada — 224.0.1.39, proclamándose RP ya sea para todos o para grupos específicos. Este mensaje se envía cada minuto.
2) Se necesita un agente de mapeo de RP, que enviará mensajes RP-Discovery indicando qué RP debe escuchar cada grupo. A partir de este mensaje, los enrutadores PIM normales determinarán su RP. El agente de mapeo puede ser el mismo enrutador RP o un enrutador PIM separado. RP-Discovery se envía a la dirección 224.0.1.40 con un temporizador de un minuto.
Analicemos el proceso más a fondo:
Configurar R3 como RP:
ip pim send-rp-announce loopback 0 scope 10
R2 como agente de mapeo:
ip pim send-rp-discovery loopback 0 scope 10
Y en todos los demás esperaremos al RP a través de Auto-RP:
ip pim autorp listener
Una vez que configuremos R3, comenzará a enviar RP-Announce:
Y R2, después de configurarse como agente de mapeo, comenzará a esperar mensajes RP-Announce. Solo cuando encuentre al menos un RP, comenzará a enviar RP-Discovery:
De esta manera, tan pronto como los enrutadores normales (PIM RP Listener) reciban este mensaje, sabrán dónde buscar el RP.
Uno de los principales problemas de Auto-RP es que para recibir los mensajes RP-Announce y RP-Discovery se debe enviar PIM Join a las direcciones 224.0.1.39-40, y para enviarlo, es necesario conocer la ubicación del RP. El clásico dilema del huevo y la gallina. Para resolver este problema se ideó el modo PIM Sparse-Dense-Mode. Si un enrutador no conoce el RP, funciona en modo Dense-mode; si lo conoce, en modo Sparse-mode. Cuando en las interfaces de los enrutadores normales se configura PIM Sparse-mode y el comando ip pim autorp listener, el enrutador funcionará en modo Dense-mode solo para el multicast del protocolo Auto-RP (224.0.1.39-40).
BootStrap Router (BSR).
Esta función funciona de manera similar a Auto-RP. Cada RP envía un mensaje al agente de mapeo, que recopila información de mapeo y luego la comunica a todos los demás enrutadores. Describamos el proceso de manera análoga a Auto-RP:
1) Una vez que configuremos R3 como candidato a ser RP, con el comando:
ip pim rp-candidate loopback 0
Entonces R3 no hará nada, para empezar a enviar mensajes especiales, primero necesita encontrar al agente de mapeo. Así que pasamos al segundo paso.
2) Configuramos R2 como agente de mapeo:
ip pim bsr-candidate loopback 0
R2 comienza a enviar mensajes de PIM Bootstrap, donde se establece a sí mismo como el agente de mapeo:
Este mensaje se envía a la dirección 224.0.0.13, que el protocolo PIM utiliza para otros mensajes. Se envían en todas direcciones, así que no hay problema del huevo y la gallina, como ocurría en Auto-RP.
3) En cuanto el RP recibe un mensaje del enrutador BSR, envía inmediatamente un mensaje unicast a la dirección del enrutador BSR:
Después de lo cual, el BSR, al recibir información sobre el RP, los enviará en multicast a la dirección 224.0.0.13, que escuchan todos los enrutadores PIM. Por lo tanto, no existe un comando equivalente ip pim autorp listener para enrutadores normales en BSR.
Anycast RP con el Protocolo de Descubrimiento de Fuentes Multicast (MSDP).
Auto-RP y BSR nos permiten distribuir la carga en el RP de la siguiente manera: Cada grupo multicast tiene solo un RP activo. No se puede realizar la distribución de carga para un grupo multicast con varios RPs. MSDP lo hace al proporcionar a los enrutadores RP la misma dirección IP con una máscara de 255.255.255.255. MSDP obtiene información mediante uno de los métodos: estática, Auto-RP o BSR.
En la imagen tenemos una configuración de Auto-RP con MSDP. Ambos RPs están configurados con la dirección IP 172.16.1.1/32 en la interfaz Loopback 1 y se utiliza para todos los grupos. Durante el RP-Announce, ambos enrutadores se presentan, haciendo referencia a esta dirección. El agente de mapeo Auto-RP, al recibir información, difunde RP-Discovery sobre el RP con la dirección 172.16.1.1/32. Sobre la red 172.16.1.1/32, informamos a los enrutadores mediante IGP y, respectivamente. De este modo, los enrutadores PIM solicitan o registran flujos desde el RP que está indicado como siguiente salto en la ruta hacia la red 172.16.1.1/32. El propio protocolo MSDP está destinado para los RPs para intercambiar mensajes sobre información de multicast.
Consideremos una topología así:
Switch6 envía tráfico a la dirección 238.38.38.38 y hasta ahora solo lo sabe RP-R1. Aquí, Switch7 y Switch8 han solicitado este grupo. Los enrutadores R5 y R4 enviarán PIM Join a R1 y R3, respectivamente. ¿Por qué? La ruta hacia 13.13.13.13 en R5 apuntará a R1 con la métrica IGP, al igual que en R4.
RP-R1 sabe sobre el flujo y comenzará a transmitirlo en dirección a R5, mientras que R4 no sabe nada al respecto, ya que R1 no lo enviará así sin más. Por lo tanto, MSDP es necesario. Lo configuramos en R1 y R5:
ip msdp peer 3.3.3.3 connect-source Loopback1 en R1
ip msdp peer 1.1.1.1 connect-source Loopback3 en R3
Establecerán una sesión entre ellos y, al recibir cualquier flujo, informarán sobre él a su RP vecino.
Cuando el RP-R1 reciba un flujo del Switch6, enviará de inmediato un mensaje MSDP Source-Active a través de unicasting, que contendrá información del tipo (S, G) — información sobre la fuente y el destino del multicast. Ahora que el RP-R3 sabe que existe una fuente como el Switch6, al recibir una solicitud del R4 para dicho flujo, enviará un PIM Join hacia el Switch6, guiándose por la tabla de enrutamiento. Por lo tanto, el R1, al recibir dicho PIM Join, comenzará a enviar tráfico hacia el RP-R3.
El MSDP funciona sobre TCP, los RPs se envían mensajes keepalive entre sí para verificar la viabilidad. El temporizador es de 60 segundos.
Sigue siendo desconocida la función de separación de pares MSDP en diferentes dominios, ya que en los mensajes Keepalive y SA no se especifica pertenencia a ningún dominio. Además, en esta topología se probó una configuración con la especificación de diferentes dominios — no hubo diferencia en el funcionamiento.
Si alguien puede aclarar esto, con gusto leeré en los comentarios.
Fuente: habr.com
