Un blackout IPTV total, 8 fois par heure, 20 secondes à chaque fois. Aucune alarme, aucun log, aucune boucle. Voici comment trois paquets IGMP ont fini par balancer le coupable.

Ça marche, sauf quand ça ne marche pas

Commençons par le seul chiffre qui intéresse le client : 64 minutes de télévision noire par jour.

Pas de la pixellisation. Pas du saccadé. Noir. L’écran meurt, reste mort une vingtaine de secondes, puis ressuscite comme si de rien n’était. Huit fois par heure, vingt-quatre heures sur vingt-quatre. En langage de comité de pilotage, ça donne 95,56 % de disponibilité sur un service vidéo. Autant dire que le contrat ne va pas bien.

Le décor : un cœur Catalyst en stack, un VLAN dédié à la vidéo, une dizaine d’encodeurs qui poussent leurs flux en multicast vers des groupes 239.192.0.x, des switches d’accès, et au bout de la chaîne des box de réception.

Et le réseau, lui, va très bien, merci. Zéro erreur CRC. Zéro interface down. Zéro alarme. Le monitoring est vert.

C’est exactement ce qui rend le dossier détestable. Quand tout est vert et que le client vous dit que sa télé s’éteint, vous avez déjà perdu la première réunion.

(Cas réel, données anonymisées.)

Acte 1 : je ferme ma gueule et je travaille

Point d’avancement avec le client. En face de moi, un gars de chez l’éditeur de la solution vidéo. Je sais déjà comment ça va se passer : il va expliquer que son produit est parfait, que c’est le réseau, que ça a toujours été le réseau, et on repartira chacun de son côté sans avoir avancé d’un millimètre.

Sauf qu’il ouvre son portable, sort une capture Wireshark, et commence à me parler d’une tempête à 400 Mb/s.

Là, je ferme ma gueule et je travaille.

Parce qu’un chiffre, c’est un chiffre. Ce n’est plus une opinion, ce n’est plus un procès d’intention, c’est un fait mesuré que je peux vérifier ou réfuter. Le débat vient de changer de nature.

Il me transmet sa capture : 1 Go de pcap brut, sans filtre, sans horodatage de l’incident. Wireshark, confronté à 1 Go, fait ce que fait Wireshark avec 1 Go : il rame, il gonfle, il finit par chier dans la colle. Donc on ne l’ouvre pas comme ça, on construit ses propres vues. Un I/O Graph échantillonné à la seconde, une courbe par adresse source, filtre multicast.

Figure 1 : l’I/O graph sur la fenêtre de l’incident

Voilà. Puis, en repassant la même chose sur toute la durée de capture, on obtient le contexte qui manquait :

Figure 2 : la même capture sur 6 min 38, une courbe par encodeur

Six minutes trente-huit de calme absolu. Puis :

• Montée de 0 à 425 Mb/s en deux secondes.
• Plateau parfaitement plat.
• Chute nette à zéro.
• Durée : 20 secondes.

Sept encodeurs, un à 100 Mb/s, quatre entre 58 et 68, un à 46, un dernier à 26. Tous ensemble, dans le même tuyau, au même instant.

Regardez bien cette courbe, parce qu’elle vient déjà de tuer l’hypothèse que tout le monde répétait depuis des semaines.

Une boucle ne ressemble pas à ça. Une boucle, ça croît de façon exponentielle, ça sature, ça écroule le CPU, et surtout ça ne s’arrête pas tout seul au bout de 20 secondes pour reprendre 7 minutes plus tard. Ici on a un créneau. Front montant vertical, plateau, front descendant. Du binaire. Du tout ou rien.

Ce n’est pas un emballement. C’est un interrupteur.

Reste à trouver le doigt qui appuie dessus.

Acte 2 : pourquoi c’est un blackout et pas un ralentissement

Avant de chercher le coupable, il faut comprendre pourquoi la sanction est aussi brutale. Parce que 425 Mb/s sur un cœur qui encaisse du 10 Gb/s, franchement, il s’en moque.

D’abord, situons la victime. La sonde de supervision répond en 10.20.4.1, et deux commandes suffisent à la localiser physiquement : l’ARP donne sa MAC, la table MAC donne son port.

Figure 3 : de l’IP au port physique, en deux commandes

Te1/1/0/36, description SERVEUR_IPTV. Et une ligne qui prendra tout son sens dans un instant : le port est un 10 Gigabit, mais il a négocié à 1000 Mb/s.

Car la télé, elle, n’est pas sur le cœur. Elle est au bout, derrière un switch d’accès, sur une box. Et les interfaces des box sont à 100 Mb/s.

• 425 Mb/s offerts / 100 Mb/s de lien = 4,25x
• Taux de perte : 1 – (100 / 425) = 76,5 %

Le switch tente de pousser 425 Mb/s dans un port qui en absorbe 100. La file de sortie sature en quelques millisecondes et jette les trois quarts de tout ce qui passe, sans distinction. Y compris, évidemment, le flux vidéo que la box était en train de regarder tranquillement.

Un MPEG-TS encaisse quelques paquets perdus. Il encaisse mal 76 %. Le décodeur ne récupère plus un seul groupe d’images complet : il ne dégrade pas l’image, il n’en a plus du tout.

Et pour bien mesurer l’enjeu, imaginons que le blackout tombe pile au moment où l’Espagne marque contre l’Argentine en finale de Coupe du monde. Vous pouvez casser la télé si ça vous soulage, ça ne la rallumera pas.

Voilà aussi pourquoi personne n’a rien vu venir. Aucun compteur d’erreur ne s’allume, parce que ce ne sont pas des erreurs : ce sont des output drops, comportement parfaitement normal d’une interface saturée.

Le réseau fonctionne. Il fonctionne même avec zèle. C’est bien le problème.

Acte 3 : l’indice à 10,000 secondes

Deuxième vue construite depuis la capture : uniquement l’IGMP. Un filtre sur un seul groupe, et surtout la colonne delta_time affichée, celle que personne n’active jamais alors qu’elle vaut de l’or.

Figure 4 : les reports IGMP et leurs écarts. Tout est dans la dernière ligne

Lisez la colonne des deltas. 60,000852. 59,499151. 65,000690. 56,499764. 58,500323. 61,499867.

Ça oscille autour de 60 secondes, et ça n’a rien d’inquiétant : c’est le timer de réponse aléatoire d’IGMP, qui fait tirer à chaque hôte un délai entre 0 et 10 secondes avant de répondre, pour éviter que tous les membres parlent en même temps.

Puis la dernière ligne : 10,999827.

Onze secondes. Un hôte ne se réabonne pas deux fois en onze secondes de sa propre initiative. Il l’a fait parce qu’on le lui a demandé deux fois.

Sauf qu’en cherchant ces queries dans la vue, on ne les trouve pas. Aucune. Pas une seule depuis le début.

Et c’est le filtre qui les cache. igmp.maddr == 224.0.0.252 sélectionne les paquets dont le champ Group Address vaut 224.0.0.252. Or une General Query porte un champ Group Address à 0.0.0.0, c’est précisément ce qui la rend générale : elle interroge tous les groupes à la fois. Elle ne peut donc jamais correspondre à un filtre sur une adresse de groupe précise.

Le piège est joli parce qu’il est silencieux. Vous filtrez sur un groupe en croyant voir toute la conversation le concernant, et vous perdez en réalité la moitié du dialogue, à savoir tout ce que le routeur demande. Le bon filtre pour l’autre moitié, c’est le type de message :

Figure 5 : les queries, invisibles avec le filtre précédent

Et là tout apparaît. Sept queries à 59,998 secondes d’intervalle, une régularité de métronome à deux millisecondes près sur soixante secondes.

Puis deux intruses. Une à +4,778955, hors cadence. Et la suivante à +10,000892.

Arrêtez-vous là une seconde. Dix secondes à moins d’une milliseconde près, ce n’est pas de la gigue, ce n’est pas un hasard, ce n’est pas un équipement fatigué.

C’est un timer.

Quelqu’un, quelque part, a écrit cette valeur dans une configuration.

Acte 4 : le coupable est dans le running-config

CORE-SW-01#show ip igmp snooping vlan 4

TCN flood query count : 2

tcn query count : 2

tcn query interval (sec) : 10

Et voilà le doigt sur l’interrupteur.

tcn query count 2, tcn query interval 10. Deux queries espacées de dix secondes : la signature relevée dans la capture correspond au millième près au comportement configuré. Ces queries ne partent pas toutes seules, elles sont déclenchées par la réception d’un Topology Change spanning-tree.

Mais le vrai coupable est sur la ligne du dessus : `TCN flood query count 2`.

Voici ce que fait le switch quand il reçoit un TC. Il se dit, très raisonnablement, qu’un changement de topologie a pu déplacer un récepteur multicast et que sa table de snooping est peut-être devenue fausse. Plutôt que de risquer de couper un flux à quelqu’un, il choisit la sécurité maximale : il inonde tout le trafic multicast du VLAN sur tous les ports, le temps de reconstruire son état.

Combien de temps ? TCN flood query count intervalles de query. Soit 2 x 10 = 20 secondes.

Vingt secondes. La durée exacte du blackout.

Figure 6 : le déclenchement vu à 10 ms, avec les queries IGMP

Zoomé à la milliseconde, c’est encore plus net. La première trame du flood arrive à 15:35:43.430, soit 5,7 millisecondes avant la query TCN. L’ordre des opérations est donc : réception du TC, bascule immédiate en inondation, puis émission de la query. La query n’est pas le déclencheur, c’est la trace visible du déclenchement. Et d’un bout à l’autre, le flood dure 20,008 secondes.

Le switch n’est pas malade. Il protège les flux, avec une telle conviction qu’il les détruit.

Acte 5 : 24 442

Le mécanisme est identifié. Reste la vraie question : qui produit ces topology changes ?

Figure 7 : le spanning-tree du VLAN 4. Tout est là, y compris l’horloge

Vingt-quatre mille quatre cent quarante-deux. Sur le root. À ce stade ce n’est plus une infrastructure, c’est une guirlande de Noël.

Et maintenant le moment que j’aime dans ce métier. Le compteur de BPDU permet de dater la mesure, puisque la racine émet un BPDU toutes les deux secondes par port :

5 097 947 BPDU x 2 s = 10 195 894 s = 118 jours

24 442 TC / 118 jours = 207 TC/jour = 8,6 TC/heure

Le client, lui, avait compté ses blackouts à la main. 24 en 3 heures, soit 8,0 par heure.

8,6 côté switch. 8,0 côté télévision. Deux compteurs indépendants, mesurés par deux personnes différentes, sur deux équipements différents, à deux bouts opposés de la chaîne. Il n’y a plus rien à démontrer.

Le classement des BPDU reçus désigne les responsables :

Cinq liaisons concentrent 95 % du bruit. Et le syslog du cœur est propre depuis des jours, donc rien ne flappe sur le châssis lui-même : l’instabilité naît sur les switches d’accès derrière ces port-channels, et remonte sagement jusqu’à la racine, qui la rediffuse à tout le monde.

En clair : quelque part, dans un bureau, un poste ou un switch de placard s’allume et s’éteint. Et à chaque fois, la télé de tout le monde s’éteint avec lui.

Acte 6 : l’autopsie

Le dossier aurait pu s’arrêter là. Mais j’ai récupéré la capture entière, tronquée aux en-têtes pour la faire tenir. 820 417 trames. De quoi passer chaque affirmation au banc d’essai. Trois choses en sont sorties.

Le plateau n’est pas plat. Vu à la milliseconde et non plus à la seconde, le « plat » à 425 Mb/s a une médiane à 423, un p99 à 597, et des pointes à 674 Mb/s. La marge sur un lien gigabit n’est donc pas de 575 Mb/s comme le graphe le suggère, elle est de 325. Quelques chaînes de plus et les liens à 1 Gb/s commenceront eux aussi à souffrir, pas seulement les box à 100.

Figure 8 : le plateau vu à 1 ms, microrafales jusqu’à 674 Mb/s

Le cœur ne perd rien, et ça compte. L’identifiant IP s’incrémente de 1 à chaque datagramme émis par flux : il suffit de suivre la série pour détecter le moindre trou. Sur 782 978 transitions, sept sources confondues : 100,0000 % de continuité. Pas une trame perdue, ni par le cœur, ni par le lien gigabit de la sonde, ni par la capture, à 674 Mb/s de pointe. Le réseau livre absolument tout ce qu’on lui confie. Les 76 % de perte se produisent uniquement en aval, dans le goulot à 100 Mb/s. Pour clore un débat « c’est le réseau », difficile de faire mieux.

Et la découverte que personne n’attendait. Il suffisait de comparer deux chiffres que rien n’obligeait à rapprocher : le nombre de groupes que le switch sait abonnés, et le nombre de groupes réellement présents dans le flood.

Figure 9 : la table de snooping. 48 groupes connus, dont 42 pour la vidéo

Le flood, lui, contient 77 groupes multicast. Les 35 de différence n’ont aucun abonné. Personne, nulle part, depuis des semaines. Et ils pèsent 221 Mb/s, soit plus de la moitié de la tempête.

Figure 10 : répartition par groupe, abonnés contre fantômes

Des encodeurs diffusent en permanence 35 chaînes que rien ne consomme. En temps normal le snooping les jette silencieusement au niveau du cœur, donc personne ne les voit et personne ne s’en plaint. Pendant un flood, elles partent sur tous les ports avec les autres. On était venu chercher une cause, on est reparti avec la moitié de la tempête qui n’aurait jamais dû exister.

Comment on l’a réglé

Le réflexe, une fois le mécanisme compris, c’est de couper le flood TCN partout. Mauvaise idée, et pour une raison contre-intuitive : ce mécanisme existe pour protéger les récepteurs pendant que le snooping se réapprend. Le désactiver sur une liaison qui porte de vrais abonnés, c’est leur offrir 10 à 20 secondes de gel à chaque topology change. Vous auriez remplacé un blackout par un autre, avec le bonus de ne plus comprendre d’où il vient.

Alors on l’a coupé uniquement là où personne ne reçoit, ce qui soulage immédiatement sans rien casser. On a mis les ports encodeurs en portfast edge, parce qu’ils n’y étaient pas et qu’un simple redémarrage d’encodeur suffisait à éteindre la télé de tout le monde. Puis on a suivi le champ from de proche en proche, de port-channel en port-channel, jusqu’au port d’accès qui flappait. Et on a déployé PortFast et BPDU guard sur tout le domaine.

Conclusion

Ce qui frappe, dans ce dossier, c’est que rien n’était en panne.

Pas un équipement défaillant. Pas une erreur CRC, pas une interface down, pas une alarme, pas une ligne de log. Le cœur a délivré 100,0000 % de ce qu’on lui a confié, pointes à 674 Mb/s comprises. Le mécanisme incriminé, le flood TCN, faisait exactement ce que la documentation Cisco promet qu’il fasse, et il le faisait pour protéger les utilisateurs. La configuration était celle par défaut.

Et pourtant : 64 minutes d’écran noir par jour.

Parce qu’une instabilité spanning-tree parfaitement banale, invisible, sans conséquence apparente, s’est propagée jusqu’à un mécanisme de protection multicast, qui l’a amplifiée d’un facteur 430, avant de la déverser dans un lien quatre fois trop petit. Aucun de ces trois maillons n’est fautif tout seul. C’est leur enchaînement qui produit la panne.

C’est là que ce métier devient intéressant, et c’est aussi ce qui le rend difficile à expliquer en réunion. On nous demande quel équipement est tombé. La réponse, ici, est qu’aucun n’est tombé. Le symptôme est apparu à un endroit (la box), l’amplification à un autre (le cœur), et la cause à un troisième (un port d’accès qui flappe, trois étages plus bas, sur un switch dont personne n’avait prononcé le nom depuis le début du dossier).

Deux réflexes en sortent, que je garde pour la suite.

Le premier : « aléatoire » n’existe pas. Un phénomène qualifié d’aléatoire est périodique avec une période que vous n’avez pas encore trouvée, ou déclenché par un événement que vous ne mesurez pas. Ici, deux compteurs qui n’avaient rien à voir, 8 blackouts par heure côté client et 8,6 topology changes par heure côté switch, ont refermé le dossier à eux seuls.

Le second : écoutez le gars d’en face quand il sort un chiffre. J’étais persuadé d’aller vers une énième réunion où l’on blâme le réseau par principe. Il a ouvert Wireshark, et il avait raison. Le réseau était bien en cause, simplement pas de la façon dont l’un ou l’autre l’imaginait.

Le plus dangereux, sur une infrastructure, ce n’est jamais ce qui tombe en panne. Ce qui tombe en panne, ça se voit, ça s’alarme, ça se remplace. Le vrai danger, c’est ce qui fonctionne trop bien.

Un mot pour finir

Votre monitoring est au vert, vos utilisateurs disent le contraire, et personne n’arrive à reproduire la panne ? C’est exactement le genre de dossier qu’on aime démonter chez MHD-EXPERTs : les incidents intermittents, les tempêtes multicast, les spanning-tree qui clignotent, et tout ce qui ne déclenche aucune alarme tout en rendant un service inutilisable.

On travaille sur pièces. Une capture, des compteurs, des chiffres qui se recoupent, et une cause démontrée plutôt qu’une hypothèse plausible. Écrivez-nous.