Un client appelle : le streaming vidéo est lent depuis mardi. Un client pro envoie la capture d'un ping à 300 ms. Depuis votre réseau, tout est au vert. La dégradation est souvent à la frontière de ce que vous contrôlez : un port de peering saturé, un transitaire qui reroute par un autre point d'échange, ou la destination elle-même. Il faut voir le chemin comme le client le voit, et depuis d'autres réseaux, avant de décider si la faute est la vôtre, celle de votre amont, ou de personne.
Un traceroute visuel depuis plusieurs points d'observation (votre région, une autre région, une sonde sur le réseau d'un concurrent) montre chaque saut avec latence, gigue, perte et ASN, et cartographie l'endroit où le trafic quitte votre AS. Les traces planifiées vous donnent la tendance avant les plaintes ; la comparaison montre le chemin avant et après un changement de routage ; l'export vous fournit un document daté, avec les données de chaque saut, à envoyer à un transitaire ou à un pair plutôt que de discuter au téléphone.
Surveiller vos frontières de peering et de transit dans le temps
Planifiez des traces depuis Falkenstein, Gravelines ou une sonde Globalping chez vos clients vers les destinations qui génèrent des plaintes : grands CDN, régions cloud, hébergeurs de jeux, résolveurs publics. Posez des alertes sur la latence, la perte de paquets et le changement de route. Un changement de route est le premier signal d'une session tombée ou d'une politique modifiée en amont. Lisez le saut où votre ASN passe la main. Si latence et gigue y montent, en heure de pointe, sur le même saut chaque soir, ce port est saturé ou le pair bride. Si elles montent deux sauts plus loin dans le réseau du transitaire, le problème est chez lui, l'export le montre. Comparez côte à côte heure creuse et heure de pointe pour chiffrer la dégradation.
Transformer une plainte en panne localisée en quelques minutes
Demandez au client la destination et l'heure. Tracez-y depuis la source la plus proche de lui et depuis une sonde hors de votre réseau. Trois issues. Les deux traces sont propres : le problème est chez le client, Wi-Fi ou CPE, ou intermittent ; demandez-lui de signaler quand cela se reproduit. Votre trace est mauvaise, l'extérieure est propre vers la même cible : la panne est de votre côté de la jonction ou sur votre transit, regardez le saut où le délai commence. Les deux sont mauvaises à partir du même saut : la destination ou son fournisseur est dégradé, et vous pouvez le dire au client preuves à l'appui. Une perte sur un seul saut intermédiaire, absente à la destination, est une limitation ICMP, rien à escalader.
Valider un changement BGP depuis l'extérieur
Après l'annonce d'un nouveau préfixe, son déplacement vers un autre transitaire ou l'ajout d'un prepend, vérifiez la propagation avec BGP Viewer : quel ASN d'origine voient les collecteurs, par quels amonts, et combien la portent. Tracez ensuite vers une adresse du préfixe depuis plusieurs pays et comparez : le trafic entrant doit arriver dans votre AS par le transitaire attendu. Si une région arrive encore par l'ancien chemin des heures plus tard, cet amont n'est pas à jour ou un filtre a rejeté votre annonce. Conservez la trace d'avant le changement et comparez-la à celle d'après ; la vue côte à côte montre le saut exact où les chemins divergent. Le routage asymétrique, sortie par un transitaire et entrée par un autre, est normal mais doit être voulu.
Lire une trace : une perte qui commence chez un transitaire
Exemple pédagogique, pas une mesure réelle. Depuis votre réseau vers un CDN vidéo, les sauts 1 à 3 restent dans votre AS, entre 2 et 4 ms, sans perte. Le saut 4, jonction avec votre transitaire : 5 ms, 0 % de perte. Le saut 5, toujours chez le transitaire, affiche 6 ms mais 30 % de perte, et les sauts 6 à 9 entre 28 et 32 %. La perte persiste jusqu'à la destination, donc elle est réelle, et elle naît chez le transitaire, un saut après votre frontière. La même trace depuis une sonde Globalping chez un autre FAI ne perd rien : le CDN est sain. Conclusion : lien dégradé ou port congestionné chez le transitaire. L'export horodaté, avec les deux traces, part vers son NOC ; une trace planifiée dira quand c'est réparé.
Les outils qui complètent le tableau
BGP Viewer montre qui annonce un préfixe, ses amonts et combien de collecteurs le voient : premier contrôle après tout changement de vos annonces. WHOIS et IP Reputation identifient une destination ou l'adresse d'un client quand une plainte évoque un blocage ou une liste noire. DNS Lookup, avec le résolveur de votre choix, confirme qu'un CDN ou un service anycast envoie vos clients vers un nœud proche. Ping sur une période confirme la gigue d'un lien avant d'ouvrir une trace, et Port Check vérifie le filtrage depuis l'extérieur.
Questions fréquentes
- Puis-je tracer du point de vue d'un client sans son équipement ?
- Choisissez une source proche de lui : Falkenstein, Gravelines ou l'une des sondes Globalping, dont certaines sont sur des réseaux résidentiels ou chez d'autres FAI. La trace n'inclura pas son saut domestique, mais elle montre le chemin d'un réseau voisin vers la destination. Si ce chemin est propre alors que la plainte persiste, le problème se trouve très probablement entre son CPE et votre premier routeur.
- Comment fonctionne une alerte de changement de route ?
- Une trace planifiée s'exécute à l'intervalle que vous fixez. Chaque exécution enregistre la séquence des adresses de sauts ; quand elle diffère de l'exécution précédente, une alerte est envoyée, avec un délai de refroidissement pour qu'un chemin instable ne vous notifie pas sans arrêt. Combinez-la avec des seuils de latence et de perte pour détecter reroutages silencieux et dégradations lentes, et ouvrez les deux traces côte à côte pour voir où elles divergent.
- Puis-je prouver à un transitaire que la panne est de son côté ?
- Vous pouvez lui remettre une trace datée depuis votre réseau et une autre depuis une sonde extérieure vers la même destination, toutes deux montrant une perte ou une latence qui apparaît dans son ASN et persiste jusqu'au bout. Exportez-les en PDF ou en JSON et joignez-les au ticket. C'est une preuve au niveau du saut, avec attribution d'ASN, ce dont son NOC a besoin pour examiner le bon lien, même s'il conteste la conclusion.