PIM-SM a través dunha VPN: comprobe BSR, a asignación de RP e as rutas RPF

O túnel está activo, os pings unicast córreno e o receptor segue mostrando unha pantalla negra. Nunha implantación de PIM-SM ese síntoma case sempre significa que un dos catro camiños de control está roto e que o camiño de datos nunca foi o problema. Percorra a lista de abaixo en orde e detéñase no primeiro paso que falle, porque cada paso posterior depende do anterior. Teño estas cinco comprobacións nun ficheiro de borrador e pégoas nun terminal cando chega unha queixa de multicast, o que evita que o diagnóstico se converta en conxecturas.

Empece polo receptor, non polo túnel

Un receptor que nunca pediu o grupo non xera ningún estado en ningún router, así que confirme que a unión existe no segmento orientado ao receptor antes de inspeccionar calquera outra cousa. En plataformas tipo Cisco, show ip igmp groups no router do último salto mostra os grupos unidos xunto á interface que os escoitou. Cando o grupo falta nesa saída, o túnel é unha distracción: a petición morreu no switch de acceso, no socket do host ou nunha VLAN sen querier.

Dúas causas mundanas explican a maioría das unións que faltan que vin: unha discrepancia de versión de IGMP entre host e router, e unha elección de querier que caeu nun switch que non encamiña. Unha terceira é máis sutil: o grupo está unido pero na VLAN equivocada, porque o host ten dúas tarxetas de rede e a aplicación enlazouse á incorrecta. Os receptores IPv6 teñen o problema equivalente con MLD, onde show ipv6 mld groups responde á mesma pregunta. Ningunha destas se arranxa tocando o túnel, e é exactamente por iso polo que importa a orde.

Unha vez que a unión é visible, confirme que PIM está activado tanto na interface orientada ao receptor como na interface que leva cara ao punto de encontro. Un router con pertenza IGMP pero sen PIM na súa interface ascendente manterá o grupo nunha táboa local e non enviará nada a ningures.

Chega o conxunto BSR ao outro lado?

As mensaxes de Bootstrap Router avanzan salto a salto dentro dun único dominio PIM, e esa é a dirección que se rompe a través dun túnel. Os RP candidatos envían os seus anuncios ao BSR elixido por unicast, así que o tramo RP-a-BSR adoita sobrevivir intacto nun túnel que funciona. A inundación de mensaxes Bootstrap na outra dirección depende de que cada interface intermedia teña PIM activado e de que nada deteña as mensaxes nunha fronteira. RFC 5059 define esa distribución e as fronteiras de ámbito administrativo que poden acurtala.

Unha sentenza ip pim bsr-border, unha ACL que filtre o protocolo 103 ou un túnel IPsec baseado en políticas que non poida transportar multicast cortarán cada un a inundación mentres deixan o unicast intacto. Esa combinación é a que fai que o fallo pareza un problema de RP cando en realidade é un problema de alcanzabilidade, e por iso leo o estado do BSR antes de ler a configuración do RP.

No router do lado afastado, show ip pim bsr-router indica o BSR elixido e o conxunto de RP aprendido; se a saída está baleira, o lado afastado está no seu propio dominio e ningunha configuración de RP reconciliará os dous. Compare os rangos de grupo e os enderezos RP en show ip pim rp mapping a ambos lados do túnel. Unha asignación que só existe localmente produce unha árbore compartida que remata no lugar equivocado, e o receptor espera para sempre.

Faga coincidir a asignación de RP a ambos lados do túnel

RP estático, BSR e anycast-RP son tres formas de responder á mesma pregunta, e mesturalas a través dun túnel é unha forma fiable de construír un dominio que nunca converxe. Se o extremo principal usa BSR e a sucursal usa un ip pim rp-address estático que apunta a outro enderezo, a sucursal constrúe a súa árbore compartida cara a un RP que non sabe que o receptor existe. A asignación debe coincidir tanto no rango de grupo como no enderezo, xa que un rango máis específico gaña sobre un máis amplo.

Anycast-RP existe precisamente para que dous sitios poidan compartir un enderezo RP, e merece nomearse aquí porque cambia o que significa «o mesmo RP». Dous RP que anuncian un enderezo son coherentes por deseño; dous RP que anuncian enderezos distintos para o mesmo rango non o son, por moi san que pareza cada sitio por separado.

Para o multicast específico de fonte dentro de 232.0.0.0/8, nunca se consulta o RP, así que unha asignación de RP baleira non é automaticamente un fallo. Decida que modelo de servizo usa a aplicación antes de perseguir un RP que nunca fixo falta.

Lea a busca RPF cara á fonte

PIM constrúe unha árbore invertendo o camiño unicast, así que a comprobación que importa é a ruta de volta á fonte, ou de volta ao RP para unha árbore compartida. Unha unión que chega por unha interface que o router non considera ascendente descártase, e o motivo rexístrase como un fallo de RPF e non como un fallo do túnel. Nun router de sucursal cunha ruta por defecto sobre o túnel e unha ruta máis específica sobre a WAN, a interface RPF pode ser facilmente a WAN aínda que a fonte só sexa alcanzable a través do túnel. Esa é a razón máis común de que unha unión se descarte silenciosamente.

show ip rpf 192.0.2.10 mostra a interface elixida, o seguinte salto e a ruta que produciu a decisión, o que normalmente abonda para ver a discrepancia. Unha ruta multicast estática como ip mroute 192.0.2.0 255.255.255.0 tunnel0 anula a busca unicast para ese prefixo, e é unha corrección lexítima cando a topoloxía multicast difire realmente da topoloxía unicast. Trátea como configuración que se debe documentar, non como un parche aplicado durante un incidente e despois esquecido.

Confirme a unión con ordes, non cun ping

O ping demostra que o unicast funciona, algo que xa sabía. A confirmación de extremo a extremo é unha secuencia que mostra a unión, a asignación, o veciño e a árbore nesa orde, e cada orde responde a unha 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

Unha entrada (S,G) poboada cunha interface de entrada real e unha lista de saída non baleira significa que o plano de control rematou o seu traballo. Unha entrada cuxa interface de entrada di Null, ou un contador etiquetado RPF failed que segue subindo, apunta á sección anterior e non ao túnel.

Se as cinco ordes parecen correctas e o receptor segue sen ver nada, o sospeitoso restante é a política do propio túnel: unha ACL de cifrado ou unha regra de cortalumes que permite o protocolo de encamiñamento unicast pero non PIM, IGMP nin o propio tráfico do grupo. Nun túnel IPsec baseado en políticas, o multicast non se transporta en absoluto, así que a resposta é un deseño GRE ou VTI e non outra excepción de filtro. Anote cal das cinco comprobacións fallou antes de cambiar nada, e logo cambie só esa capa.