Un IPTV qui saccade et un flux CCTV qui se transforme en mosaïque sont souvent la même panne sous deux visages différents — une jonction multicast qui n'aboutit jamais, une table de transfert à qui il manque une entrée, ou des rafales de trafic qui dépassent ce que le port de sortie peut mettre en tampon. Voici l'ordre de vérification qui trouve le plus vite lequel des deux c'est — les commandes display exactes pour IGMP, les tables multicast de niveau 2 et 3, et les causes qui expliquent la plupart de ces tickets sur le terrain.
By Yuwen Zhang (Atlas), founder of AtlasCommTech — 13 years of carrier & enterprise network deployments · Updated July 2026
Qu'il s'agisse d'un décodeur qui saccade ou d'un flux CCTV qui se dissout en blocs, la question de fond est la même : le flux multicast atteint-il réellement ce port, et l'atteint-il assez vite.
Le gel IPTV et la mosaïque vidéo CCTV sont signalés comme s'il s'agissait de problèmes différents — l'un est une plainte de décodeur, l'autre une plainte de vidéosurveillance — mais au fond, la vidéo multicast ne peut échouer que de deux façons : le flux n'est jamais transféré au port, ou il l'est mais arrive en retard, incomplet, ou perdu. La première est un problème de jonction/table — IGMP, IGMP Snooping ou PIM n'a jamais construit le chemin. La seconde est un problème de capacité — le chemin existe, mais quelque chose entre la source et l'écran ne suit pas pendant un instant.
Voici l'ordre de vérification qui distingue les deux : la jonction a-t-elle réellement atteint l'appareil, les tables multicast de niveau 2 et 3 ont-elles réellement les bonnes entrées, et c'est seulement ensuite qu'on regarde si le trafic lui-même dépasse ce qu'un port peut mettre en tampon — plus les causes qui reviennent sans cesse dans les déploiements CCTV et IPTV réels, et les réponses aux questions que cela suscite le plus.
Le gel et la mosaïque se répartissent en exactement deux formes sur cet arbre : aucun flux du tout, ou un flux présent mais dégradé.
Placer d'abord le symptôme ici indique laquelle des sections ci-dessous s'applique réellement — traquer un problème de bande passante alors que la vraie panne est une entrée IGMP Snooping manquante (ou l'inverse) fait perdre beaucoup de temps.
Les légendes du schéma restent en anglais pour la clarté technique.
Une entrée de table de transfert manquante et un problème de bande passante/rafale se ressemblent à l'écran — les deux se traduisent par un gel ou une mosaïque — mais ils se situent à des endroits complètement différents et nécessitent des corrections complètement différentes. 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é.
Si le routage multicast n'a jamais été activé, le trafic multicast inconnu est diffusé comme du broadcast — et cela suffit à lui seul à provoquer une mosaïque.
<Device> display interface 10GE0/0/1
Output: 490255596853 packets, 722496062037058 bytes
Discard: 416538726, Pause: 0
// Discard counter climbing on the output side -> congestion, not a join fault
<Device> display igmp snooping configuration
Info: There is no igmp snooping configuration.
// no multicast table at all -> unknown multicast is flooded exactly like broadcast
#
igmp snooping enable
vlan 10
igmp snooping enable
igmp snooping querier enableLe multicast peut être activé partout et la jonction peut quand même ne pas construire l'entrée qui achemine le trafic vers ce port précis.
<Device> display l2-multicast forwarding-table
VLAN Total (Source,Group) Interface
100 1 (*, 226.0.1.205)
// no outgoing interface toward the PC listed -> entry never reached this port
<Device> display igmp snooping vlan 10
IGMP Version is Set to default 2
// third-party device sends IGMPv3 Query; this device is v2 and can't process it
// -> router-port ages out once the v3 Query goes out, stream cutsC'est ici qu'un flux dont on a prouvé qu'il atteint le bon port et la bonne entrée de table peut quand même geler ou se transformer en mosaïque.
<Device> display interface 10GE0/0/2
Output: ... Discard: 33021, still increasing
// mirror the source-facing port and check with Wireshark:
// server sleeps ~1s, then bursts near 1Gbit/s for a few ms -- average rate only ~10Mbit/s
[Device] interface 10GE0/0/2
[Device-10GE0/0/2] qos burst-mode enhanced
// enhanced burst mode gives the egress port more buffer for this traffic shapeUne fois les trois vérifications ci-dessus effectuées, ces cinq causes expliquent la plupart des vraies pannes dans les déploiements CCTV et IPTV réels.
SYMPTÔMELe flux de la caméra affiche une mosaïque dès la connexion — display interface sur le port montre un compteur Discard important et croissant côté sortie.
CAUSELe réseau du client transportait de la vidéo multicast, mais l'appareil d'accès n'avait aucune configuration IGMP Snooping. Sans table multicast à consulter, le trafic multicast inconnu est transféré exactement comme du broadcast — diffusé à tous les ports du VLAN — et la congestion qui en résulte perd des paquets, ce qui se traduit à l'écran par une mosaïque.
CORRECTIFActivez IGMP Snooping globalement et sous le VLAN spécifique, et activez la fonction de requêteur de niveau 2 sur le commutateur le plus proche de la source multicast si le VLAN n'a pas d'autre requêteur.
igmp snooping enable
vlan 10
igmp snooping enable
igmp snooping querier enableSYMPTÔMELa vidéo se lit normalement pendant un moment puis coupe — débrancher et rebrancher le câble de l'utilisateur ne fait que retarder la même panne, cela ne la corrige pas.
CAUSEUne version IGMP/IGMP Snooping supérieure peut traiter les paquets de protocole d'une version inférieure, mais pas l'inverse. Le premier rapport de l'utilisateur construit correctement l'entrée de transfert sur les deux appareils — mais une fois que la requête IGMPv3 périodique de l'appareil amont est émise, l'appareil de version inférieure ne peut pas la traiter, l'entrée vieillit, et le flux s'arrête.
CORRECTIFConfigurez la même version IGMP / IGMP Snooping sur tous les appareils du même domaine multicast — lorsque les appareils sont mélangés, alignez-les tous sur la même version au lieu de supposer qu'un appareil de version supérieure est automatiquement rétrocompatible dans les deux sens.
<Device> display igmp snooping vlan 10
IGMP Version is Set to default 2
[Device-vlan10] igmp snooping version 3SYMPTÔMELa mosaïque apparaît spécifiquement aux heures de pointe, et display interface sur le port face à l'utilisateur montre un compteur Discard qui continue d'augmenter.
CAUSECertains encodeurs source multicast utilisent un encodage à débit binaire variable (VBR) et envoient des données en rafales courtes et extrêmement rapides plutôt qu'un flux régulier — un cas de terrain réel a mesuré la source dormant un peu plus d'une seconde, puis envoyant à près de 1 Gbit/s pendant quelques millisecondes avant de redormir, alors que le débit moyen dans le temps n'était que d'environ 10 Mbit/s. Le tampon de sortie de l'appareil, dimensionné autour de la moyenne, ne peut pas absorber une rafale de cette taille, et le débordement est perdu.
CORRECTIFLà où la source le permet, passez du VBR au débit binaire constant (CBR) pour lisser le rythme d'envoi ; sinon augmentez la bande passante du port de sortie (un Eth-Trunk, ou un port plus rapide), ou configurez un mode de rafale amélioré sur le port pour lui donner plus de tampon pour ce type de trafic précis.
[Device] interface 10GE0/0/2
[Device-10GE0/0/2] qos burst-mode enhancedSYMPTÔMEUne perte de paquets aléatoire et dispersée apparaît sur de nombreux groupes multicast différents environ deux minutes après le démarrage du flux, plutôt qu'une panne nette sur un seul groupe.
CAUSEPlus d'un requêteur IGMP existait sur le même segment utilisateur, et leurs intervalles de requête ne correspondaient pas — un intervalle de requête plus long que le temps de vieillissement par défaut du commutateur ne laisse que quelques secondes par cycle pour rafraîchir un grand nombre d'entrées multicast, et l'appareil ne peut pas traiter le rafraîchissement assez vite, donc les entrées vieillissent et sont reconstruites, ce qui se traduit par des pertes dispersées sur plusieurs groupes.
CORRECTIFDésactivez le requêteur redondant — il ne devrait y avoir qu'un seul requêteur IGMP actif sur un segment de niveau 2 donné — et si l'intervalle doit être personnalisé, réglez-le de manière cohérente sur tous les appareils du segment, pas seulement sur celui le plus proche de la source.
<Device> display igmp interface
// querier elected on a device other than expected -- check its query-interval, disable the duplicateSYMPTÔMELa lecture saccade fortement à travers un appareil d'agrégation avec de nombreux appareils en aval dans un VLAN, mais le même contenu se lit proprement quand le terminal utilisateur est connecté directement à l'appareil côté source.
CAUSEAvec un grand nombre d'appareils ramifiés sous un commutateur d'agrégation sur le même VLAN, le trafic broadcast inonde chaque port de ce VLAN et peut à lui seul consommer assez de bande passante pour priver le flux multicast partageant le lien, même si le chemin de transfert multicast lui-même fonctionne correctement.
CORRECTIFConfigurez l'isolation de port sur l'appareil d'agrégation afin que les ports aval ne puissent plus se diffuser du trafic broadcast entre eux, en gardant la bande passante partagée disponible pour le flux multicast.
[Device-Ethernet0/0/1] portswitch
[Device-Ethernet0/0/1] port default vlan 204
[Device-Ethernet0/0/1] port-isolate enable group 1Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.
IGMP est le protocole qu'un hôte utilise pour indiquer à son routeur directement connecté à quel groupe multicast il souhaite adhérer — il fonctionne au niveau 3. IGMP Snooping est une fonctionnalité de commutateur de niveau 2 qui écoute ces mêmes messages IGMP qui le traversent, afin que le commutateur puisse construire sa propre table de transfert et n'envoyer le trafic multicast que vers les ports ayant réellement des membres, au lieu de le diffuser à tout le VLAN. Un commutateur d'accès purement de niveau 2 sans interface multicast de niveau 3 a quand même besoin d'IGMP Snooping activé, sinon le multicast inconnu est diffusé comme du broadcast.
Vérifiez d'abord la table de niveau 2 — display igmp snooping router-port et display l2-multicast forwarding-table pour le VLAN en question. Si l'interface sortante vers l'utilisateur y manque, c'est un problème de niveau 2, quel que soit l'aspect du niveau 3. Si l'entrée de niveau 2 est correcte, passez à display pim routing-table et display multicast routing-table — une entrée (S,G) manquante ou bloquée là, avec le compteur Matched qui n'augmente pas, pointe plutôt vers le chemin de niveau 3.
Confirmez que multicast routing-enable est configuré globalement, et que pim sm et igmp enable sont tous deux configurés sur l'interface de niveau 3 face à l'utilisateur — IGMP seul sans PIM sur la même interface ne construira pas la table. Vérifiez ensuite display igmp snooping router-port sur l'appareil de niveau 2 entre l'utilisateur et le routeur — si le router-port n'y est pas, le message de jonction de l'utilisateur n'a jamais réellement atteint l'appareil de niveau 3.
Cette régularité temporelle pointe vers un problème de rafale ou de bande passante plutôt qu'un problème de jonction/table — vérifiez display interface pour un compteur Discard sur le port affecté qui augmente spécifiquement pendant ces heures, et miroitez le port face à la source pour vérifier les rafales de trafic de type VBR. Une panne de jonction/table (entrée IGMP Snooping manquante, incompatibilité de version) se manifeste généralement de façon constante, pas seulement à des heures précises.
Cela masque souvent le symptôme pendant un moment, mais ne répond pas à la question de savoir pourquoi la rafale ou la diffusion s'est produite en premier lieu, et elle a tendance à revenir une fois que le trafic augmente à nouveau. Confirmer le mécanisme réel — rafales VBR, entrée IGMP Snooping manquante, requêteur en double, ou diffusion broadcast partageant le VLAN — prend à peu près la même poignée de commandes display dans tous les cas, et c'est la seule façon de savoir si plus de bande passante résoudra réellement le problème ou achètera simplement quelques mois.
Cette note s'appuie sur le modèle de dépannage multicast des routeurs et commutateurs Huawei série AR et ses commandes display igmp snooping / pim routing-table / multicast routing-table, ainsi que sur les cas de terrain qui les sous-tendent — plusieurs provenant de vrais déploiements CCTV et IPTV. Si votre matériel d'accès ou d'agrégation est d'un autre fournisseur, les commandes exactes changent, mais l'ordre de vérification sous-jacent — jonction, table, capacité — s'applique directement. Elle ne couvre pas en profondeur les cas particuliers du mappage SSM ni les scénarios multicast sur overlay MPLS/VPN.
Dites-nous s'il s'agit d'IPTV ou de CCTV, si le symptôme est constant ou uniquement aux heures de pointe, plus la sortie de display igmp snooping / pim routing-table, et nous vous aiderons à l'interpréter.