PIM-SM através de uma VPN: verificar BSR, mapeamento de RP e caminhos RPF

O túnel está ativo, os pings unicast atravessam-no e o recetor continua a mostrar um ecrã preto. Numa implementação de PIM-SM esse sintoma quase sempre significa que um dos quatro caminhos de controle está quebrado e que o caminho de dados nunca foi o problema. Percorra a lista abaixo por ordem e pare no primeiro passo que falhar, porque cada passo seguinte depende do anterior. Guardo estas cinco verificações num ficheiro de rascunho e colo-as num terminal quando chega uma queixa de multicast, o que evita que o diagnóstico se transforme em suposições.

Comece pelo recetor, não pelo túnel

Um recetor que nunca pediu o grupo não cria estado em nenhum router, por isso confirme que a adesão existe no segmento virado para o recetor antes de inspecionar qualquer outra coisa. Em plataformas do estilo Cisco, show ip igmp groups no router do último salto imprime os grupos aderidos ao lado da interface que os ouviu. Quando o grupo falta nessa saída, o túnel é uma distração: o pedido morreu no switch de acesso, no socket do host ou numa VLAN sem querier.

Duas causas banais explicam a maioria das adesões em falta que vi: uma discrepância de versão do IGMP entre host e router, e uma eleição de querier que caiu num switch que não encaminha. A terceira é mais subtil: o grupo está aderido mas na VLAN errada, porque o host tem duas placas de rede e a aplicação ligou-se à errada. Os recetores IPv6 têm o problema equivalente com MLD, onde show ipv6 mld groups responde à mesma pergunta. Nenhuma destas se resolve mexendo no túnel, e é exatamente por isso que a ordem importa.

Assim que a adesão estiver visível, confirme que o PIM está ativado tanto na interface virada para o recetor como na interface que leva ao ponto de encontro. Um router com associação IGMP mas sem PIM na sua interface de montante manterá o grupo numa tabela local e não enviará nada para lado nenhum.

O conjunto BSR chega ao outro lado?

As mensagens Bootstrap Router avançam salto a salto dentro de um único domínio PIM, e é essa a direção que se quebra através de um túnel. Os RP candidatos enviam os seus anúncios ao BSR eleito por unicast, pelo que o troço RP-para-BSR sobrevive normalmente intacto num túnel a funcionar. A inundação de mensagens Bootstrap na outra direção depende de cada interface intermédia ter o PIM ativado e de nada parar as mensagens numa fronteira. RFC 5059 define essa distribuição e as fronteiras de âmbito administrativo que a podem encurtar.

Uma instrução ip pim bsr-border, uma ACL que filtre o protocolo 103 ou um túnel IPsec baseado em políticas que não consiga transportar multicast cortarão cada um a inundação, deixando o unicast intacto. É precisamente essa combinação que faz a falha parecer um problema de RP quando na realidade é um problema de alcançabilidade, e é por isso que leio o estado do BSR antes da configuração do RP.

No router do lado remoto, show ip pim bsr-router indica o BSR eleito e o conjunto de RP aprendido; se a saída estiver vazia, o lado remoto está no seu próprio domínio e nenhuma configuração de RP reconciliará os dois. Compare os intervalos de grupo e os endereços de RP em show ip pim rp mapping dos dois lados do túnel. Um mapeamento que só existe localmente produz uma árvore partilhada que termina no lugar errado, e o recetor espera para sempre.

Alinhe o mapeamento de RP dos dois lados do túnel

RP estático, BSR e anycast-RP são três formas de responder à mesma pergunta, e misturá-las através de um túnel é uma forma fiável de construir um domínio que nunca converge. Se a extremidade principal usar BSR e a filial usar um ip pim rp-address estático apontado a outro endereço, a filial constrói a sua árvore partilhada para um RP que não sabe que o recetor existe. O mapeamento tem de concordar tanto no intervalo de grupo como no endereço, uma vez que um intervalo mais específico vence um mais amplo.

O anycast-RP existe precisamente para que dois locais possam partilhar um único endereço RP, e vale a pena nomeá-lo aqui porque muda o que significa «o mesmo RP». Dois RP que anunciam um endereço são consistentes por conceção; dois RP que anunciam endereços diferentes para o mesmo intervalo não o são, por mais saudável que cada local pareça isoladamente.

Para multicast específico da origem dentro de 232.0.0.0/8, o RP nunca é consultado, pelo que um mapeamento de RP vazio não é automaticamente uma falha. Decida que modelo de serviço a aplicação usa antes de perseguir um RP que nunca foi necessário.

Leia a pesquisa RPF em direção à origem

O PIM constrói uma árvore invertendo o caminho unicast, por isso a verificação que importa é a rota de volta para a origem, ou de volta para o RP no caso de uma árvore partilhada. Uma adesão que chega por uma interface que o router não considera de montante é descartada, e o motivo é registado como falha de RPF e não como falha do túnel. Num router de filial com uma rota predefinida sobre o túnel e uma rota mais específica sobre a WAN, a interface RPF pode ser facilmente a WAN, ainda que a origem só seja alcançável através do túnel. É a razão isolada mais comum para uma adesão ser descartada em silêncio.

show ip rpf 192.0.2.10 imprime a interface escolhida, o próximo salto e a rota que produziu a decisão, o que normalmente basta para ver a discrepância. Uma rota multicast estática como ip mroute 192.0.2.0 255.255.255.0 tunnel0 sobrepõe-se à pesquisa unicast para esse prefixo, e é uma correção legítima quando a topologia multicast difere realmente da topologia unicast. Trate-a como configuração a documentar, não como um remendo aplicado durante um incidente e depois esquecido.

Confirme a adesão com comandos, não com um ping

O ping prova que o unicast funciona, o que já sabia. A confirmação ponta a ponta é uma sequência que mostra a adesão, o mapeamento, o vizinho e a árvore nessa ordem, e cada comando responde a uma pergunta diferente.

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

Uma entrada (S,G) preenchida com uma interface de entrada real e uma lista de saída não vazia significa que o plano de controle terminou o seu trabalho. Uma entrada cuja interface de entrada é lida como Null, ou um contador etiquetado RPF failed que continua a subir, aponta para a secção anterior e não para o túnel.

Se os cinco comandos parecerem corretos e o recetor continuar sem ver nada, o suspeito restante é a política do próprio túnel: uma ACL de cifra ou uma regra de firewall que permite o protocolo de encaminhamento unicast mas não PIM, IGMP ou o próprio tráfego do grupo. Num túnel IPsec baseado em políticas o multicast não é transportado de todo, pelo que a resposta é um desenho GRE ou VTI e não outra exceção de filtro. Anote qual das cinco verificações falhou antes de mudar alguma coisa, e depois mude apenas essa camada.