0,7 ms vers 1.1.1.1 : comment une seule ancre a aveuglé notre supervision pendant trois mois

Si vous effectuez un ping sur 1.1.1.1 et qu'il répond, qu'avez-vous appris ? Pendant trois mois, nous avons cru que la réponse était : « ce point de vue peut atteindre l'internet global ». Ce n'est pas le cas. Le 23 août 2026, nous avons mesuré la même adresse depuis plusieurs points de vue en même temps, et les chiffres n'étaient pas comparables de manière utile.

Voici une note sur la manière dont nous nous sommes trompés, ce que cela nous a coûté, et comment chacun peut vérifier la même chose dans son propre système de surveillance en environ cinq minutes.

La même adresse, quatre distances très différentes

Chaque chiffre ci-dessous représente le temps aller-retour moyen sur 52 échantillons consécutifs de 20 paquets ICMP chacun, pris le même jour depuis un point de vue différent de notre réseau de mesure distribué. L'ancre est identique dans chaque ligne.

Trois de ces lignes se comportent comme des chemins internet normaux. Une ne le fait pas. Depuis Kyiv, 1.1.1.1 répond en bien moins d'une milliseconde, tandis que le résolveur de Google depuis la même machine est à 14 ms. La machine n'est pas exceptionnellement proche de l'internet en général. Elle est exceptionnellement proche de cette adresse spécifique.

Les traceroutes

Deux chemins depuis le même hôte, pris à quelques secondes d'intervalle. D'abord, vers 1.1.1.1 :

Cinq sauts, et le paquet ne quitte jamais la zone métropolitaine. Maintenant, le même hôte vers 8.8.8.8 :

Onze sauts, et vous pouvez voir exactement où le trafic quitte la ville : entre le saut 6 et le saut 8, la latence passe de 1,3 ms à 14,5 ms. Ce saut est ce que nous pensions surveiller. Sur le chemin vers 1.1.1.1, ce saut n'a jamais lieu.

Pourquoi cette différence ? Les deux adresses sont anycast, donc les réponses proviennent de l'instance topologiquement la plus proche. À Kyiv, une instance de l'une d'elles est pratiquement voisine, accessible via un peering local. Que ce soit un nœud de bordure en peering avec le réseau local ou quelque chose sur le chemin répondant pour l'adresse, nos données ne peuvent pas le déterminer, et pour la surveillance, cela n'a pas d'importance. Ce qui compte, c'est que le chemin ne traverse pas l'internet global, donc il ne peut pas rendre compte de l'internet global.

L'ancre masque même les pannes sur son propre chemin

Regardez à nouveau le saut 4 dans le premier traceroute : 33 % de perte de paquets, avec des échantillons individuels allant de 1,7 ms à 21,9 ms. C'est un saut réellement défaillant. Cela n'a aucun effet sur la mesure, car l'ancre répond avant que le chemin n'atteigne ce point. Un système de surveillance observant cette ancre signalerait un réseau parfaitement sain alors qu'il se trouve à un saut d'un lien qui perd un tiers de ses paquets.

Ce que cela nous a coûté

Nous avons effectué un test de corrélation pour voir si un facteur de stress externe documenté apparaissait dans nos séries de connectivité. Pour le point de vue de Kyiv, nous avons pris chaque jour où des alertes publiques de raid aérien ont été enregistrées pour la ville, et comparé l'intensité des alertes à la perte de paquets mesurée vers l'ancre.

Sur 69 jours de ce type, la connectivité moyenne était de 99,87 %. Soixante-sept des 69 jours affichaient une connectivité de 99,9 % ou plus, y compris chacun des jours avec la plus forte activité d'alerte. Le résultat était un nul clair.

Nous avons failli publier ce résultat nul comme une conclusion sur la résilience du réseau. Ce n'était pas une conclusion sur le réseau. C'était une conclusion sur l'ancre : nous avions mesuré un lien à l'intérieur de la ville qui n'avait aucune raison particulière de tomber en panne, et observé correctement qu'il ne tombait pas en panne. L'instrument n'avait aucune sensibilité à la question posée.

Un résultat nul provenant d'un instrument que vous n'avez pas validé n'est pas une preuve d'absence. Ce n'est la preuve de rien.

Ce que nous avons changé

Trois changements, tous ennuyeux, aucun d'entre eux n'étant astucieux.

Plus d'une ancre. Chaque point de vue mesure désormais une ancre globale, une deuxième ancre globale opérée par une autre organisation, et un pair dans la même région. Trois destinations qui échouent pour trois raisons différentes sont bien plus difficiles à tromper qu'une seule.

Le premier saut, explicitement. Chaque balayage mesure désormais également la passerelle locale. Si le premier saut est propre et que tout ce qui est au-delà ne l'est pas, le problème est en amont. Si le premier saut est dégradé, c'est le dernier kilomètre. Cette seule mesure supplémentaire permet de séparer deux classes de défaillances qu'une seule ancre fusionne en une seule catégorie « dégradée ».

Un échantillon exploitable. Nous envoyions six paquets par cycle. Six paquets ne peuvent pas distinguer une perte de 5 % d'une perte de 0 % ; le plus petit pas qu'ils peuvent exprimer est de 17 points de pourcentage. Nous en envoyons désormais vingt. Lors du premier cycle après le changement, un point de vue a enregistré 19 paquets sur 20 vers son ancre principale tandis que les deux autres ancres et la passerelle locale restaient propres, ce qui a permis de localiser une perte de 5 % sur un chemin spécifique. L'ancienne configuration aurait arrondi cela à « tout va bien ».

Nous n'avons délibérément pas changé l'ancre qui alimente le seuil d'alerte. Redéfinir une métrique tout en conservant son nom est la façon dont un historique de surveillance cesse discrètement d'avoir un sens. L'ancre principale est restée là où elle était pour que la base de référence existante reste comparable ; les nouvelles ancres sont enregistrées à côté et prendront le relais une fois qu'elles auront accumulé suffisamment d'historique pour constituer leur propre base de référence.

Vérifiez les vôtres

Depuis n'importe quel hôte que vous surveillez, exécutez un traceroute vers l'adresse que votre système de surveillance considère comme « l'internet ». Ensuite, exécutez-en un autre vers une adresse bien connue gérée par quelqu'un d'autre. Comparez le nombre de sauts et, plus important encore, recherchez l'augmentation de latence là où le trafic quitte votre zone métropolitaine. Si le chemin de votre ancre n'a pas une telle augmentation, votre vérification de la connectivité est un test de lien local déguisé en étiquette globale.

Le test coûte deux commandes. Nous ne l'avons pas exécuté pendant trois mois, ce qui est la seule raison pour laquelle cette note existe.

Limitations

Ceci est un instantané d'une journée unique d'une ancre depuis une poignée de points de vue ; la topologie anycast peut changer, et la même adresse peut se comporter de manière totalement différente le mois prochain ou depuis un autre réseau. Nous n'avons pas établi pourquoi le chemin de Kyiv se termine localement, seulement qu'il le fait. Le test de corrélation décrit ci-dessus couvre une ville et une ancre, et ne dit rien sur la résilience du réseau en général - cette question reste ouverte précisément parce que notre instrument ne pouvait pas y répondre. Nous espérons pouvoir y revenir une fois que la série multi-ancres aura accumulé suffisamment d'historique.

Toutes les données ici proviennent de notre propre réseau de mesure distribué et sont reproductibles avec des outils standards comme ping et mtr depuis n'importe quel hôte sur les mêmes réseaux.