Une relation de voisinage PIM qui ne se forme jamais, ou qui se forme mais élit le mauvais DR, casse le multicast avant même qu'IGMP ou la table de transfert n'aient une chance de compter. Voici l'ordre de vérification pour le plan de contrôle sous-jacent — les commandes display exactes pour l'état d'interface PIM, le statut du voisin et l'élection du DR, et les causes qui reviennent sans cesse dans les déploiements réels.
Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026
Soit la relation de voisinage ne se forme jamais, soit elle se forme et élit le mauvais appareil comme DR — et en aval, les deux ressemblent simplement à un multicast qui ne fonctionne pas.
Tout ce qu'IGMP et la table de transfert multicast font en aval dépend du fait que PIM ait déjà correctement accompli deux choses en amont : former une relation de voisinage avec le routeur adjacent, et élire le bon routeur désigné pour réellement répliquer le trafic sur le segment. Quand l'un des deux est faux, IGMP peut être parfaitement configuré et la table de transfert peut être exactement correcte, et le multicast n'atteindra quand même pas l'utilisateur — parce que l'appareil censé transférer le trafic sur ce segment n'est pas celui qui le fait, ou n'est même pas présent.
Si la plainte réelle est un gel IPTV ou une mosaïque vidéo CCTV plutôt qu'une panne du plan de contrôle, notre note complémentaire sur le dépannage vidéo multicast couvre le côté IGMP/table/bande passante de cela ; celle-ci porte sur ce qui doit être vrai côté PIM avant que tout cela ne s'applique.
Les pannes du plan de contrôle PIM se répartissent en exactement deux formes sur cet arbre : la relation de voisinage ne se forme jamais, ou elle se forme et le mauvais appareil finit par être en charge du segment.
Placer d'abord le symptôme ici indique laquelle des sections ci-dessous s'applique réellement — un voisin réellement absent nécessite un correctif complètement différent de celui d'un voisin présent mais silencieusement à sens unique.
Les légendes du schéma restent en anglais pour la clarté technique.
Un voisin réellement en panne et un voisin actif mais silencieusement à sens unique se ressemblent sur display pim neighbor d'un seul appareil — les deux vous laissent sans pair fonctionnel — mais les corrections sont très éloignées l'une de l'autre. L'arbre ci-dessus sert à les distinguer avant de toucher à la moindre configuration.
Trois vérifications, dans l'ordre — chacune sert de contexte à la suivante, et les commandes qui indiquent à laquelle vous êtes réellement bloqué.
display pim neighbor n'affichant absolument rien produit la même sortie que PIM n'ait jamais été configuré ou qu'une véritable panne de voisinage se produise — vérifiez d'abord l'explication la plus simple.
<Device> display current-configuration interface GigabitEthernet0/0/1
// no pim sm / pim dm line at all
[Device] multicast routing-enable
// required first if the device reports:
// Error: Please create Multicast Enable first, because current configuration depends on the object.
[Device-GigabitEthernet0/0/1] pim sm
<Device> display pim interface GigabitEthernet0/0/1
// check State column: Down here means check physical/protocol state firstPIM activé et l'interface Up ne suffisent toujours pas — le Hello lui-même doit être accepté des deux côtés.
<Device> display pim neighbor
VPN-Instance: public net
Total Number of Neighbors = 0
// confirm subnet match, neighbor filter-policy, and Generation ID requirement next
<Device> display current-configuration interface Vlanif100
// check for a pim neighbor-policy acl-number entry that could be filtering the peerL'existence d'une relation de voisinage n'est pas la même chose que le bon appareil étant en charge du segment — c'est ici que le DR double et les pannes post-mise à niveau apparaissent.
<Device1> display pim interface Eth-Trunk3.50
Interface State NbrCnt HelloInt DR-Pri DR-Address
Eth-Trunk3.50 up 0 30 1 10.194.163.17 (local)
// NbrCnt 0 with DR-Address local on both upstream devices -> one-way Hello, not a real absence
[Device3-Eth-Trunk3] undo storm suppression multicast packets 0
// storm suppression on the member port was dropping PIM Hello
<DeviceA> display pim neighbor
Total Number of Neighbors = 3
// a neighbor and a DR role that didn't exist before the last upgrade -- compare against the pre-upgrade baselineUne fois les trois vérifications ci-dessus effectuées, ces cinq causes expliquent la plupart des vraies pannes dans les déploiements réels.
SYMPTÔMEdisplay pim neighbor n'affiche absolument rien sur une interface qui devrait clairement avoir un voisin de l'autre côté du lien.
CAUSEL'interface n'a tout simplement jamais eu pim sm (ou pim dm) configuré. Sans PIM configuré, il n'y a pas de Hello à envoyer ou recevoir, donc aucune relation de voisinage ne peut jamais exister, indépendamment du reste étant correct.
CORRECTIFConfigurez pim sm sur l'interface ; si l'appareil signale qu'il a besoin du multicast activé d'abord, exécutez multicast routing-enable dans la vue système d'abord, puis configurez PIM sur l'interface.
<Device> display current-configuration interface GigabitEthernet0/0/1
// no pim sm/pim dm line at all
[Device] multicast routing-enable
[Device-GigabitEthernet0/0/1] pim smSYMPTÔMELe voisin PIM ne se forme pas spécifiquement vers le routeur d'un fournisseur tiers, même si l'interface est Up, PIM est activé, et les deux interfaces sont sur le même sous-réseau.
CAUSEUn appareil est configuré pour rejeter les messages Hello qui ne portent pas de paramètre Generation ID. Cette option n'est pas envoyée de manière identique par tous les fournisseurs, et quand le Hello du pair ne l'inclut pas, la relation de voisinage ne se forme jamais silencieusement — cela apparaît spécifiquement en interopérabilité entre fournisseurs, pas dans les déploiements du même fournisseur.
CORRECTIFVérifiez si l'appareil est configuré pour exiger l'option Generation ID dans les messages Hello reçus, et assouplissez cette exigence lors de l'interopérabilité avec un fournisseur qui ne l'envoie pas.
<Device> display current-configuration interface Vlanif100
// check for a Generation-ID requirement in the PIM configuration
// relax it when the peer's Hello doesn't carry the optionSYMPTÔMEDeux appareils amont sur le même segment agrégé affichent tous deux DR-Address comme local — les deux pensent avoir remporté l'élection DR, et les deux transfèrent du trafic multicast sur le même lien aval.
CAUSEUne commande de suppression de tempête sur un port membre de l'Eth-Trunk aval supprimait silencieusement les paquets Hello PIM. Chaque appareil amont n'entendait que son propre Hello réfléchi, jamais celui de l'autre, donc chacun se considérait comme le seul appareil du segment et s'élisait DR.
CORRECTIFRetirez la commande de suppression de tempête multicast du port membre qui supprime le trafic de contrôle PIM, ou excluez explicitement l'adresse multicast de PIM (224.0.0.13) de toute politique de contrôle de tempête en place.
<Device1> display pim interface Eth-Trunk3.50
Interface State NbrCnt HelloInt DR-Pri DR-Address
Eth-Trunk3.50 up 0 30 1 10.194.163.17 (local)
[Device3-Eth-Trunk3] undo storm suppression multicast packets 0SYMPTÔMEJuste après une mise à niveau du firmware, les utilisateurs en aval ne peuvent plus recevoir de multicast, même si rien n'a été touché dans la topologie ou la configuration.
CAUSELe comportement d'élection DR PIM de l'appareil a changé entre les versions — une interface qui perdait auparavant l'élection DR face au bon appareil amont l'a remportée à la place après la mise à niveau, et le nouveau DR incorrect n'a aucun chemin pour répliquer le trafic vers les utilisateurs aval, donc le flux multicast s'arrête simplement là.
CORRECTIFComparez display pim neighbor et display pim interface avant et après la mise à niveau pour toute interface où le DR a changé ; là où le nouveau DR ne devrait pas transférer vers ce segment, retirez l'interface de la relation de voisinage dont elle ne devrait pas faire partie, ou ajustez dr-priority pour forcer le bon appareil à gagner.
<DeviceA> display pim interface
Vlanif4091 up 1 30 1 192.168.17.1
// a PIM neighbor relationship and a DR role that didn't exist before the upgradeSYMPTÔMEAprès le redémarrage ou la réinitialisation d'un appareil, le service IPTV en aval reste cassé même si tous les liens reviennent et semblent sains.
CAUSEUn port d'agrégation portait un VLAN qu'il ne devrait pas avoir, laissant les paquets Hello PIM de plusieurs voisins amont non liés fuir vers l'interface de l'appareil aval. Avec plusieurs voisins PIM supplémentaires soudainement visibles sur ce VLAN, l'élection DR ne favorisait plus l'appareil aval lui-même, et il a cessé d'être celui qui répliquait le trafic multicast vers les utilisateurs en dessous de lui.
CORRECTIFRetirez le VLAN qui ne devrait pas être porté sur ce port trunk, afin que l'appareil aval ne voie que les voisins PIM qu'il est réellement censé voir.
<Device4> display pim neighbor
Total Number of Neighbors = 11
// several extra neighbors received via a leaked VLAN on Eth-Trunk20
[Device2-Eth-Trunk20] undo port trunk allow-pass vlan 43Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
Sur un segment multicast partagé, le routeur désigné est le seul appareil responsable de l'envoi des requêtes IGMP sur ce segment et du transfert du trafic multicast dessus — tous les autres routeurs PIM du même segment restent silencieux pour ce rôle. Si l'appareil qui remporte l'élection n'a pas de chemin utilisable vers les vrais récepteurs en aval, le multicast n'est tout simplement pas répliqué vers eux, même si tous les autres routeurs PIM du segment fonctionnent bien.
Confirmez d'abord que pim sm est réellement configuré sur cette interface, avec display current-configuration interface — une configuration manquante produit exactement la même sortie vide qu'une véritable panne de voisinage. Confirmez ensuite que l'état PIM de l'interface est Up avec display pim interface ; si c'est Down, vérifiez l'état physique et de protocole avant de regarder PIM lui-même.
Cela signifie que chaque appareil pense être le seul routeur PIM sur ce segment, ce qui signifie presque toujours que les paquets Hello ne s'atteignent pas mutuellement dans au moins une direction — pas que la logique d'élection elle-même soit cassée. Vérifiez tout ce qui, sur le chemin, pourrait silencieusement supprimer le trafic de contrôle multicast, en particulier une politique de suppression de tempête ou de QoS appliquée à 224.0.0.13, avant de supposer qu'il s'agit d'un problème de configuration PIM.
Le comportement d'élection DR de PIM est l'une des choses qui peuvent changer entre versions, même sans aucun changement de configuration de votre part. Comparez display pim interface et display pim neighbor avant et après la mise à niveau pour le VLAN ou l'interface affecté — si un nouveau DR apparaît là où l'ancien se trouvait, et que le nouveau DR ne peut pas réellement atteindre les utilisateurs en aval, c'est le mécanisme.
Vérifiez si l'un ou l'autre des appareils est configuré pour rejeter les messages Hello sans option Generation ID — c'est un point de friction fréquent entre fournisseurs, puisque le Hello par défaut de tous les fournisseurs ne l'inclut pas. Assouplir cette exigence du côté qui la vérifie suffit généralement à laisser la relation se former.
Cette note s'appuie sur le modèle de dépannage PIM du routeur Huawei série AR et ses commandes display pim interface / pim neighbor, ainsi que sur les cas de terrain qui les sous-tendent. Si votre passerelle est d'un autre fournisseur, les commandes exactes changent, mais l'ordre de vérification sous-jacent — activé, up, voisin, DR — s'applique directement. Elle ne couvre pas en profondeur les cas particuliers spécifiques à PIM-SSM ni les interactions MSDP anycast-RP.
Dites-nous si le voisin est complètement absent ou actif avec le mauvais DR, plus la sortie de display pim interface / pim neighbor, et nous vous aiderons à l'interpréter.