PIM-SM à travers un VPN : vérifier le BSR, le mappage RP et les chemins RPF

Le tunnel est monté, les pings unicast le traversent, et le récepteur affiche toujours un écran noir. Dans un déploiement PIM-SM, ce symptôme signifie presque toujours que l’un des quatre chemins de contrôle est cassé et que le chemin de données n’a jamais été le problème. Parcourez la liste ci-dessous dans l’ordre et arrêtez-vous à la première étape qui échoue, car chaque étape suivante dépend de la précédente. Je garde ces cinq sondes dans un fichier de brouillon et je les colle dans un terminal quand une plainte multicast arrive, ce qui évite que le diagnostic ne tourne à la conjecture.

Commencez par le récepteur, pas par le tunnel

Un récepteur qui n’a jamais demandé le groupe ne crée aucun état sur aucun routeur, alors confirmez que l’adhésion existe sur le segment côté récepteur avant d’inspecter quoi que ce soit d’autre. Sur les plateformes de type Cisco, show ip igmp groups sur le routeur de dernier saut affiche les groupes rejoints à côté de l’interface qui les a entendus. Quand le groupe manque dans cette sortie, le tunnel est une distraction : la requête est morte au commutateur d’accès, à la socket de l’hôte ou dans un VLAN sans querier.

Deux causes banales expliquent la plupart des adhésions manquantes que j’ai vues : une incompatibilité de version IGMP entre l’hôte et le routeur, et une élection de querier qui a abouti sur un commutateur qui ne route pas. Une troisième est plus subtile : le groupe est rejoint mais sur le mauvais VLAN, parce que l’hôte a deux cartes réseau et que l’application s’est liée à la mauvaise. Les récepteurs IPv6 ont le problème équivalent avec MLD, où show ipv6 mld groups répond à la même question. Aucune de ces causes ne se corrige en touchant au tunnel, et c’est exactement pourquoi l’ordre compte.

Une fois l’adhésion visible, confirmez que PIM est activé à la fois sur l’interface côté récepteur et sur l’interface qui mène vers le point de rendez-vous. Un routeur doté de l’appartenance IGMP mais sans PIM sur son interface amont gardera le groupe dans une table locale et n’enverra rien nulle part.

L’ensemble BSR atteint-il l’autre côté ?

Les messages Bootstrap Router avancent de saut en saut dans un seul domaine PIM, et c’est la direction qui casse à travers un tunnel. Les RP candidats envoient leurs annonces au BSR élu en unicast, si bien que le tronçon RP-vers-BSR survit généralement intact à un tunnel qui fonctionne. L’inondation de messages Bootstrap dans l’autre sens dépend de l’activation de PIM sur chaque interface intermédiaire et de l’absence de tout arrêt des messages à une frontière. RFC 5059 définit cette distribution et les frontières de portée administrative qui sont autorisées à l’écourter.

Une instruction ip pim bsr-border, une ACL qui filtre le protocole 103 ou un tunnel IPsec basé sur des politiques qui ne peut pas transporter le multicast couperont chacun l’inondation tout en laissant l’unicast intact. C’est précisément cette combinaison qui fait ressembler la panne à un problème de RP alors qu’il s’agit en réalité d’un problème d’accessibilité, et c’est pourquoi je lis l’état du BSR avant de lire la configuration du RP.

Sur le routeur du côté distant, show ip pim bsr-router nomme le BSR élu et l’ensemble de RP appris ; si la sortie est vide, le côté distant est dans son propre domaine et aucune quantité de configuration RP ne réconciliera les deux. Comparez les plages de groupes et les adresses de RP dans show ip pim rp mapping des deux côtés du tunnel. Un mappage qui n’existe que localement produit un arbre partagé qui se termine au mauvais endroit, et le récepteur attend indéfiniment.

Alignez le mappage RP des deux côtés du tunnel

RP statique, BSR et anycast-RP sont trois façons de répondre à la même question, et les mélanger à travers un tunnel est un moyen fiable de construire un domaine qui ne converge jamais. Si l’extrémité principale utilise BSR et que la succursale utilise un ip pim rp-address statique pointant vers une autre adresse, la succursale construit son arbre partagé vers un RP qui ignore que le récepteur existe. Le mappage doit concorder à la fois sur la plage de groupes et sur l’adresse, puisqu’une plage plus précise l’emporte sur une plage plus large.

Anycast-RP existe précisément pour que deux sites puissent partager une adresse RP, et il vaut la peine de le nommer ici car cela change ce que signifie « le même RP ». Deux RP annonçant une seule adresse sont cohérents par conception ; deux RP annonçant des adresses différentes pour la même plage ne le sont pas, quelle que soit la santé apparente de chaque site pris isolément.

Pour le multicast spécifique à la source dans 232.0.0.0/8, le RP n’est jamais consulté, donc un mappage RP vide n’est pas automatiquement une panne. Décidez quel modèle de service l’application utilise avant de courir après un RP qui n’a jamais été nécessaire.

Lisez la recherche RPF vers la source

PIM construit un arbre en inversant le chemin unicast, donc la vérification qui compte est la route de retour vers la source, ou vers le RP pour un arbre partagé. Une adhésion qui arrive sur une interface que le routeur ne considère pas comme amont est rejetée, et la raison est journalisée comme un échec RPF plutôt que comme un échec de tunnel. Sur un routeur de succursale avec une route par défaut via le tunnel et une route plus spécifique via le WAN, l’interface RPF peut facilement être le WAN alors même que la source n’est joignable que par le tunnel. C’est la raison la plus courante pour laquelle une adhésion est silencieusement écartée.

show ip rpf 192.0.2.10 affiche l’interface choisie, le prochain saut et la route qui a produit la décision, ce qui suffit généralement à voir la discordance. Une route multicast statique comme ip mroute 192.0.2.0 255.255.255.0 tunnel0 outrepasse la recherche unicast pour ce préfixe, et c’est un correctif légitime lorsque la topologie multicast diffère réellement de la topologie unicast. Traitez-la comme une configuration à documenter, non comme un correctif appliqué pendant un incident puis oublié.

Confirmez l’adhésion avec des commandes, pas avec un ping

Le ping prouve que l’unicast fonctionne, ce que vous saviez déjà. La confirmation de bout en bout est une séquence qui montre l’adhésion, le mappage, le voisin et l’arbre dans cet ordre, et chaque commande répond à une question différente.

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

Une entrée (S,G) remplie avec une véritable interface d’entrée et une liste de sortie non vide signifie que le plan de contrôle a terminé son travail. Une entrée dont l’interface d’entrée affiche Null, ou un compteur étiqueté RPF failed qui continue de grimper, renvoie à la section précédente plutôt qu’au tunnel.

Si les cinq commandes semblent correctes et que le récepteur ne voit toujours rien, le suspect restant est la politique propre au tunnel : une ACL de chiffrement ou une règle de pare-feu qui autorise le protocole de routage unicast mais pas PIM, IGMP ni le trafic de groupe lui-même. Sur un tunnel IPsec basé sur des politiques, le multicast n’est pas transporté du tout, donc la réponse est une conception GRE ou VTI plutôt qu’une nouvelle exception de filtre. Notez laquelle des cinq sondes a échoué avant de changer quoi que ce soit, puis ne changez que cette couche.