Bonjour,
Je constate des variations de latence sur ma connexion IPv6 vers mon serveur à Paris.
Je souhaiterais savoir s'il est possible de stabiliser cette latence vers mon serveur situé à Paris (2a0f:85c1:b60::1:43).
Je précise que j’utilise un tunnel EoIPv6 sur ce serveur, ce qui rend la stabilité de la connexion importante.
Relevé MTR (463 pings) :
Je vous remercie par avance pour votre retour.
Meilleure réponse par Sophie A
Bonjour,
Voici la réponse reçue :
“D’après les captures d’écran fournies, la variation de latence observée pendant l’incident n’était pas alarmante : le ping IPv4 direct (à droite) affichait une valeur stable de 9 ms, tandis que le tunnel EoIPv6 (à gauche) fluctuait entre environ 48 et environ 66 ms, soit une variation d’ environ 18 ms. Aujourd’hui, le tunnel est revenu à 15-16 ms, ce qui confirme que le problème était passager et externe au réseau Proximus.
Concernant l’instabilité observée au niveau du nœud ae-74-106.ibrstr6.isp.proximus.be dans le MTR : il s’agit d’un artefact de mesure. Le MTR utilise des paquets ICMP, que les routeurs limitent délibérément en débit ou dépriorisent au profit du trafic réel. Cela provoque des pics de latence apparents ou des pertes de paquets au niveau de ce saut spécifique, sans affecter le flux de données réel. La preuve est simple : la perte/latence ne s’est pas propagée au saut suivant. Même lorsque le problème était présent…
Pour résumer : Le réseau IPv6 de Proximus fonctionnait normalement. Même pendant le problème, le saut 5 est resté le même, c'est-à-dire en dehors du réseau Proximus.
L'instabilité du tunnel observée était très probablement un problème passager du côté dufournisseur distant
La variation delatence visible sur les captures d'écran se situe dans la fourchette normale pour un tunnel EoIPv6 acheminé via Paris.
+5Bonjour
Je transmets votre relevé à notre service réseau pour une vérification du routage et de la stabilité sur le segment concerné.
Merci pour votre patience
+5
Voici la réponse de notre service IT :
“Nous avons analysé les mesures que vous nous avez transmises. Les pertes de paquets visibles sur certains sauts intermédiaires ne reflètent pas un problème de connectivité réel, elles proviennent de mécanismes de limitation ou de dé‑priorisation du trafic ICMP sur certains routeurs.
La connectivité vers la destination, elle, reste stable.
Les résultats MTR montrent une latence moyenne autour de 48 ms, avec quelques pics ponctuels, ce qui reste dans des valeurs normales pour ce type de trajet réseau.
Afin de poursuivre l’analyse, pourriez-vous nous fournir une mesure MTR réalisée dans le sens inverse (depuis votre équipement vers notre infrastructure) ?
Pouvez-vous également confirmer si le tunnel se déconnecte réellement ou si le problème se manifeste autrement ?”
Bonjour,
Je précise mon signalement car je ne parlais pas d'une perte de paquets, mais bien d'une latence très instable.
Pour vous détailler un peu mon infra :
J'ai un routeur MikroTik (vm) chez moi connecté à ma ligne Proximus, qui monte un tunnel EoIPv6 vers un autre MikroTik situé dans le datacenter Equinix PA6 à Paris. Ce tunnel sert de lien de transport en IPv6 entre la Belgique et Paris pour acheminer et recevoir des adresses IP publiques (IPv4 et IPv6) directement sur mes machines virtuelles locales.
Sur la capture du jour du problème (prise en même temps que le MTR) :
C'est à ce moment-là que j'avais lancé le MTR, où l'on voyait un Worst à 132.4 ms et un StDev à 12.4 pour une moyenne à 12 ms, notamment sur le saut ae-74-106.ibrstr6.isp.proximus.be.
Aujourd'hui, sans rien toucher à ma configuration, tout est rentré dans l'ordre (voir la capture de ce matin) : la même VM tourne désormais à 15-16 ms bien stable vers Paris via le tunnel EoIPv6 (les 40 ms de base venaient probablement du fournisseur distant à ce moment-là).
Même si le souci semble réglé aujourd'hui, j'aimerais quand même en connaître la cause, car ce genre d'instabilité impacte directement la qualité de certains de mes projets.
Merci d'avance pour votre retour !
Pour les 40ms de base, je pense que cela venait du fournisseur, aujourd’hui je suis à 15ms vers Paris sans grosse variation de latence en passant par le tunnel EoIPV6
Le relevé MTR provient d’une machine virtuelle via le réseau local
Voici de même un relevé MTR aujourd’hui
+5Bonjour,
Je viens de faire suivre votre demande. Je reviens vers vous dès que j’ai une réponse.
+5Bonjour,
Voici la réponse reçue :
“D’après les captures d’écran fournies, la variation de latence observée pendant l’incident n’était pas alarmante : le ping IPv4 direct (à droite) affichait une valeur stable de 9 ms, tandis que le tunnel EoIPv6 (à gauche) fluctuait entre environ 48 et environ 66 ms, soit une variation d’ environ 18 ms. Aujourd’hui, le tunnel est revenu à 15-16 ms, ce qui confirme que le problème était passager et externe au réseau Proximus.
Concernant l’instabilité observée au niveau du nœud ae-74-106.ibrstr6.isp.proximus.be dans le MTR : il s’agit d’un artefact de mesure. Le MTR utilise des paquets ICMP, que les routeurs limitent délibérément en débit ou dépriorisent au profit du trafic réel. Cela provoque des pics de latence apparents ou des pertes de paquets au niveau de ce saut spécifique, sans affecter le flux de données réel. La preuve est simple : la perte/latence ne s’est pas propagée au saut suivant. Même lorsque le problème était présent…
Pour résumer : Le réseau IPv6 de Proximus fonctionnait normalement. Même pendant le problème, le saut 5 est resté le même, c'est-à-dire en dehors du réseau Proximus.
L'instabilité du tunnel observée était très probablement un problème passager du côté dufournisseur distant
La variation delatence visible sur les captures d'écran se situe dans la fourchette normale pour un tunnel EoIPv6 acheminé via Paris.
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
