Cómo solucionar problemas de IGMP y PIM en modo denso

Descripción

Este artículo explica cómo FortiGate responde a varios mensajes PIM en modo denso e IGMP en una red multicast.

Este artículo asume que la configuración de PIM e IGMP ya está en marcha:

– IGMP está configurado en LHR (Last Hop Router) en este diagrama R2.

– Modo denso PIM configurado entre R1 y R2.

– Fuente de multidifusión conectada a R1.

Diagrama

Prueba realizada en FortiOS 6.4.

Solución

En el diagrama anterior.

1) El servidor multicast que tiene la dirección IP 10.100.3.75 comienza a enviar un flujo multicast hacia el grupo 239.16.10.1 a través del puerto2 de R1 (FHR).

R1 # diag sniffer packet any ‘host 239.16.10.1’ 4
1.370198 port2 en 10.100.3.75.42734 -> 239.16.10.1.12345: udp 46
2.370499 port2 en 10.100.3.75.42734 -> 239.16.10.1.12345: udp 46
3.370885 port2 en 10.100.3.75.42734 -> 239.16.10.1.12345: udp 46

2) R1 crea una entrada (S,G) en su tabla de multidifusión e inunda los paquetes de multidifusión hacia todos sus vecinos PIM DM en el Puerto4 y el Puerto3.

R1 # diag sniffer packet any ‘host 239.16.10.1’ 4
62.417822 puerto2 en 10.100.3.75.34901 -> 239.16.10.1.12345: udp 46
62.418309 puerto4 fuera 10.100.3.75.34901 -> 239.16.10.1.12345: udp 46
62.418335 puerto3 fuera 10.100.3.75.34901 -> 239.16.10.1.12345: udp 46

R1 # get router info multicast pim dense-mode table 239.16.10.1
Tabla de enrutamiento multicast PIM-DM
(10.100.3.75, 239.16.10.1)
Tiempo de vida de la MRT: 210
Fuente conectada directamente en el puerto2
Estado-Refresco Estado del originador: Originador
Intervalo de actualización del estado (recibido): 0
Upstream IF: puerto2
Estado de subida: Reenviando
Estado de afirmación: NoInfo
Temporizador de la alerta: 180 segundos
Lista de IFs descendentes:
puerto3, en ‘olist’:
Bandera: IN-OLIST
Estado de bajada: NoInfo
Estado de la afirmación: NoInfo
port4, en ‘olist’:
Bandera: IN-OLIST
Estado de bajada: NoInfo
Estado de la afirmación: NoInfo

3) Después de que R2 reciba el flujo de multidifusión que fue inundado por R1, R2 creará una entrada (S,G) en su tabla de multidifusión:

– Observe que la lista de interfaces de salida está vacía, esto se debe a que el receptor de multidifusión, aunque está en línea, no ha enviado el Join IGMP al grupo 239.16.10.1

– Fíjese en el estado de subida del puerto 2 en el R2, es Pruned porque el R2 ha enviado un PIM Prune hacia el R1.

4) Después de que R1 reciba el mensaje PIM Prune de R2, esperará un breve periodo de tiempo para ver si algún otro router en el mismo segmento requiere el mismo flujo.

Si no es así, R1 podará la interfaz port3 de la OLIST (Outgoing Interface List) para el flujo de multidifusión (10.100.3.75, 239.16.10.1) después de lo cual los paquetes de multidifusión ya no se envían hacia R2.

R1 # get router info multicast pim dense-mode table 239.16.10.1
Tabla de enrutamiento multicast PIM-DM
(10.100.3.75, 239.16.10.1)
Tiempo de vida de la MRT: 210
Fuente conectada directamente en el puerto2
Estado-Refresco Estado del originador: Originador
Intervalo de actualización del estado (recibido): 0
Flujo ascendente IF: puerto2
Estado del flujo ascendente: Reenviando
Estado de alerta: NoInfo
Temporizador de la afirmación: 180 segundos
Lista de IFs descendentes:
puerto3:
Bandera:
Estado de bajada: Podado
Estado de la afirmación: NoInfo
puerto4, en ‘olist’:
Bandera: IN-OLIST
Estado de bajada: NoInfo
Estado de alerta: NoInfo

5) Después de un tiempo, el receptor multicast decide unirse al grupo 239.16.10.1 para poder recibir el flujo. Por lo tanto, enviará un mensaje IGMP Join hacia el R2.

7) El R2, que ha recibido el mensaje IGMP Join, actualizará su tabla de grupos IGMP y enviará un mensaje PIM Graft al R1 para esta entrada (S,G) en particular. R1 responderá con un Graft ACK.

R2 # get router info multicast igmp groups 239.16.10.1
Membresía del grupo conectado IGMP
Dirección del grupo Interfaz Tiempo de actividad Caduca Último informe
239.16.10.1 puerto3 00:05:45 00:00:42 10.102.0.49

8) Después de que R1 envíe el Graft-ACK, R1 actualizará su OLIST y comenzará a reenviar el flujo multicast para (10.100.3.75, 239.16.10.1) a través del puerto3.

R1 # diag sniffer packet any ‘host 239.16.10.1’ 4
0.723376 puerto2 en 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46
0.723438 port3 out 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46
0.723476 port4 out 10.100.3.75.54361 -> 239.16.10.1.12345: udp 46