PIM-SM a través de una VPN: compruebe BSR, el mapeo de RP y las rutas RPF

El túnel está activo, los pings unicast lo atraviesan y el receptor sigue mostrando una pantalla negra. En una implantación de PIM-SM ese síntoma casi siempre significa que uno de los cuatro caminos de control está roto y que el camino de datos nunca fue el problema. Recorra la lista de abajo en orden y deténgase en el primer paso que falle, porque cada paso posterior depende del anterior. Tengo estas cinco comprobaciones en un archivo de borrador y las pego en un terminal cuando llega una queja de multicast, lo que evita que el diagnóstico se convierta en conjeturas.

Empiece por el receptor, no por el túnel

Un receptor que nunca pidió el grupo no genera ningún estado en ningún router, así que confirme que la unión existe en el segmento orientado al receptor antes de inspeccionar cualquier otra cosa. En plataformas tipo Cisco, show ip igmp groups en el router del último salto muestra los grupos unidos junto a la interfaz que los escuchó. Cuando el grupo falta en esa salida, el túnel es una distracción: la petición murió en el switch de acceso, en el socket del host o en una VLAN sin querier.

Dos causas mundanas explican la mayoría de las uniones que faltan que he visto: una discrepancia de versión de IGMP entre host y router, y una elección de querier que cayó en un switch que no enruta. Una tercera es más sutil: el grupo está unido pero en la VLAN equivocada, porque el host tiene dos tarjetas de red y la aplicación se enlazó a la incorrecta. Los receptores IPv6 tienen el problema equivalente con MLD, donde show ipv6 mld groups responde a la misma pregunta. Ninguna de estas se arregla tocando el túnel, y es exactamente por eso por lo que importa el orden.

Una vez que la unión es visible, confirme que PIM está habilitado tanto en la interfaz orientada al receptor como en la interfaz que lleva hacia el punto de encuentro. Un router con membresía IGMP pero sin PIM en su interfaz ascendente mantendrá el grupo en una tabla local y no enviará nada a ninguna parte.

¿Llega el conjunto BSR al otro lado?

Los mensajes de Bootstrap Router avanzan salto a salto dentro de un único dominio PIM, y esa es la dirección que se rompe a través de un túnel. Los RP candidatos envían sus anuncios al BSR elegido por unicast, así que el tramo RP-a-BSR suele sobrevivir intacto en un túnel que funciona. La inundación de mensajes Bootstrap en la otra dirección depende de que cada interfaz intermedia tenga PIM habilitado y de que nada detenga los mensajes en una frontera. RFC 5059 define esa distribución y las fronteras de ámbito administrativo que pueden acortarla.

Una sentencia ip pim bsr-border, una ACL que filtre el protocolo 103 o un túnel IPsec basado en políticas que no pueda transportar multicast cortarán cada uno la inundación mientras dejan el unicast intacto. Esa combinación es la que hace que el fallo parezca un problema de RP cuando en realidad es un problema de alcanzabilidad, y por eso leo el estado del BSR antes de leer la configuración del RP.

En el router del lado lejano, show ip pim bsr-router indica el BSR elegido y el conjunto de RP aprendido; si la salida está vacía, el lado lejano está en su propio dominio y ninguna configuración de RP reconciliará a los dos. Compare los rangos de grupo y las direcciones RP en show ip pim rp mapping a ambos lados del túnel. Un mapeo que solo existe localmente produce un árbol compartido que termina en el lugar equivocado, y el receptor espera para siempre.

Haga coincidir el mapeo de RP en ambos lados del túnel

RP estático, BSR y anycast-RP son tres formas de responder a la misma pregunta, y mezclarlas a través de un túnel es una forma fiable de construir un dominio que nunca converge. Si el extremo principal usa BSR y la sucursal usa un ip pim rp-address estático que apunta a otra dirección, la sucursal construye su árbol compartido hacia un RP que no sabe que el receptor existe. El mapeo debe coincidir tanto en el rango de grupo como en la dirección, ya que un rango más específico gana sobre uno más amplio.

Anycast-RP existe precisamente para que dos sedes puedan compartir una dirección RP, y merece nombrarse aquí porque cambia lo que significa «el mismo RP». Dos RP que anuncian una dirección son coherentes por diseño; dos RP que anuncian direcciones distintas para el mismo rango no lo son, por muy sano que parezca cada sitio por separado.

Para el multicast específico de fuente dentro de 232.0.0.0/8, nunca se consulta al RP, así que un mapeo de RP vacío no es automáticamente un fallo. Decida qué modelo de servicio usa la aplicación antes de perseguir un RP que nunca hizo falta.

Lea la búsqueda RPF hacia la fuente

PIM construye un árbol invirtiendo el camino unicast, así que la comprobación que importa es la ruta de vuelta a la fuente, o de vuelta al RP para un árbol compartido. Una unión que llega por una interfaz que el router no considera ascendente se descarta, y el motivo se registra como un fallo de RPF y no como un fallo del túnel. En un router de sucursal con una ruta por defecto sobre el túnel y una ruta más específica sobre la WAN, la interfaz RPF puede ser fácilmente la WAN aunque la fuente solo sea alcanzable a través del túnel. Esa es la razón más común de que una unión se descarte silenciosamente.

show ip rpf 192.0.2.10 muestra la interfaz elegida, el siguiente salto y la ruta que produjo la decisión, lo que normalmente basta para ver la discrepancia. Una ruta multicast estática como ip mroute 192.0.2.0 255.255.255.0 tunnel0 anula la búsqueda unicast para ese prefijo, y es una corrección legítima cuando la topología multicast difiere realmente de la topología unicast. Trátela como configuración que debe documentarse, no como un parche aplicado durante un incidente y luego olvidado.

Confirme la unión con comandos, no con un ping

El ping demuestra que el unicast funciona, algo que ya sabía. La confirmación de extremo a extremo es una secuencia que muestra la unión, el mapeo, el vecino y el árbol en ese orden, y cada comando responde a una pregunta distinta.

show ip igmp groups 239.1.1.1
show ip pim rp mapping
show ip pim neighbor
show ip rpf 192.0.2.10
show ip mroute 239.1.1.1

Una entrada (S,G) poblada con una interfaz de entrada real y una lista de salida no vacía significa que el plano de control terminó su trabajo. Una entrada cuya interfaz de entrada dice Null, o un contador etiquetado RPF failed que sigue subiendo, apunta a la sección anterior y no al túnel.

Si los cinco comandos parecen correctos y el receptor sigue sin ver nada, el sospechoso restante es la política del propio túnel: una ACL de cifrado o una regla de cortafuegos que permite el protocolo de enrutamiento unicast pero no PIM, IGMP ni el propio tráfico del grupo. En un túnel IPsec basado en políticas, el multicast no se transporta en absoluto, así que la respuesta es un diseño GRE o VTI y no otra excepción de filtro. Anote cuál de las cinco comprobaciones falló antes de cambiar nada, y luego cambie solo esa capa.