Souci de latence sur Yutz (57)

[lonewulf]

Salut, merci du retour,

Je n'ai pas tout à fait le même concept de 'léger' que les ingés réseau quand la latence augmente de l'équivalent d'un aller retour Paris-Nice

Après je suis tout à fait conscient que ça rentre dans les critères de conformité pour une connexion grand public, mais je trouve tout de même ça dommage pour une connexion fibre d'avoir plus de latence que mon ancienne connexion ADSL

Vu que je suppose que ça ne bougera donc pas, je vais pouvoir passer aux autres sujets que j'ai, mais ça sera dans d'autres threads, dans tous les cas, encore merci d'avoir pris le temps de remonter les infos dans un sens et dans l'autre.

[ToFoo93]

Merci pour ta compréhension, je ne sais pas si ça re bougera, c'est des éléments qui sont assez lourd il est vrai...

Je laisse ouvert en tout cas si jamais tu constaté un retour à la situation d'avant...

Bien à toi

[lonewulf]

Salut,

J'aimerais juste remonter une petite chose qui me chiffonne:

La modification en question impacte uniquement la latence certes, mais elle a aussi un effet de bord qui me gène un peu, je m'explique:

La latence la plus faible semble être vers les destinations en région parisienne, sauf que... je bosse dans un pays frontalier et je télétravaille de temps en temps, sauf que la sélection du meilleur site pour le VPN ne choisi pas celle dans le pays en question mais une dans le nord de la France, et vu le bouzin que c'est ça joue sur la téléphonie en ligne et les appels visio.

Si il était possible de remonter cette problématique; ça serait sympa !

[ToFoo93]

En l'état ça reste compliqué c'est structurel, avec ton témoignage j'ai pu leur montrer que même si les services n'était pas impacté une "légère" (je minimise pas c'est simplement une vue au global) hausse du ping lié à la route...

J'essaierai de voir si un échange est possible et de considérer au mieux ce point... après ce sont des compromis

[lonewulf]

Un grand merci dans tous les cas !

[WhiteCat]

Bonjour à tous,

Je me permet de remonter ce topic, étant dans la même zone géographique et rencontrant un problème avec le même équipement mentionné.

Je souhaite donc partager mon retour d'expérience concernant ma récente souscription à l'offre Bbox Fibre (ligne activée le 16 avril dernier), afin d'apporter un éclairage technique sur un problème de routage qui semble structurel et d'échanger sur l'impasse totale dans laquelle je me trouve avec le service client.

Le constat est le suivant : la connexion est tout juste passable en journée, avec un manque de fluidité déjà perceptible, et devient totalement inutilisable en soirée. On observe alors des ralentissements massifs, des décompositions de flux, des déconnexions de VPN professionnels et des gels d'image en visioconférence.

Pour identifier précisément l'origine du problème, j'ai mis en place un monitoring continu via PingPlotter (serveurs Google et Cloudflare, résultats similaires). Les résultats excluent mon installation domestique et localisent l'anomalie sur le réseau de l'opérateur :

Le segment local (Saut 1 - 192.168.1.1) : La liaison entre mon ordinateur et la Bbox est irréprochable. La latence est stable à 1 ms et le taux de perte de paquets est de 0%, de jour comme de nuit. La puissance optique mesurée est par ailleurs excellente (-17 dBm).

La passerelle opérateur (Saut 2 - 176.165.224.2) : C'est le point de rupture. Dès l'entrée sur cet équipement de collecte Bouygues Telecom, la latence s'effondre avec des pics atteignant régulièrement 2000 ms, accompagnés d'une perte de paquets constante située entre 15% et 20%.

Le cœur de réseau (Sauts suivants) : Sur les nœuds d'infrastructure immédiatement suivants (notamment les routeurs 62.34.3.213 et 62.34.3.196), le trafic subit un rejet en cascade pouvant dépasser les 75% de perte de paquets.

Ce comportement est caractérisé par une saturation de charge ou d'un phénomène de Bufferbloat sur le lien de collecte régional, qui peine en journée et s'asphyxie complètement lors des pics d'affluence du soir.

La principale difficulté réside dans le refus d'instruction du support technique. Bien qu'un ticket d'incident ait été ouvert dès le 24 avril, le dossier n'évolue pas. À chaque appel, les conseillers du 1064 rejettent systématiquement la faute sur mon infrastructure locale, alors même que les mesures de métrologie prouvent le contraire. Plus grave encore, le SAV refuse catégoriquement de prendre en compte les informations et les rapports de diagnostic que je leur transmets, m'indiquant textuellement que ce n'est « pas leur problème ». Le support de premier niveau se retranche derrière une analyse superficielle rejetant la cause sur le client; ignorant superbement les défauts de routage et les pertes de paquets massives.

Je publie ce retour pour savoir si d'autres utilisateurs dépendant de cette même passerelle IP (176.165.224.2) se heurtent au même déni du SAV, ou si certains ont trouvé un levier pour forcer une escalade efficace vers la cellule d'expertise réseau face à un support qui refuse d'écouter.

Merci d'avance

[ToFoo93]

Bonjour,

Alors, j’ai quand même l’impression, à la lecture de ton retour, que nous ne parlons pas exactement de la même chose. Je m’explique :

À l’origine, le constat faisait état d’une latence légèrement dégradée sur cette plaque/zone, ce qui avait pour principale conséquence une petite montée du ping ou, comme mentionné plus haut, un VPN qui basculait automatiquement sur une autre zone. En aucun cas il n’était question d’une dégradation sensible. Or, dans ton retour, tu évoques une fluidité moindre, voire un service inutilisable. (En revanche, pour le VPN qui se déconnecte, cela peut être lié au fait que le trafic passe par un tunnel spécifique qui peut rencontrer d'autres problèmes non connexes ; je ne saurais l'affirmer en l'état).

Concernant le support, même si tu ne partages pas forcément leur avis, leur position est parfaitement logique. S'il y a un incident de dégradation de la navigation, cela n'est pas directement de leur ressort. Ils ouvrent un ticket réseau qui est d'abord traité comme une plainte unitaire. S'il n’y a pas d'autres tickets similaires sur le même secteur, la plainte est rejetée. En effet, le monitoring émet déjà des alertes préventives. Ensuite, si pour une raison X ou Y le problème passe sous les radars, le nombre de plaintes unitaires est censé augmenter, ce qui force à déclencher de nouvelles analyses. Il est fort à parier qu’il n’y a pas eu d’alarme (ou que celles qui ont été remontées ont été jugées sans incidence). Combiné à un volume de plaintes resté sous le seuil critique (qui est pourtant très bas), ton ticket tourne en rond et le support client ne dispose d'aucun autre levier d'action.

Cependant, je vais alerter quelques personnes. Nous allons creuser pour voir s’il y a eu zéro alerte ou s’il y a eu des incidents ponctuels, et vérifier le volume de plaintes au cas où elles seraient trop espacées et passeraient sous les radars habituels.

Relance moi mercredi, si je n’ai pas laissé un petit message d'ici demain en fin de journée.

Enfin, il n’est pas impossible que je divise le sujet selon l'évolution de la situation ; tu le retrouveras donc peut-être sur un fil dédié.

[lonewulf]

Salut,

Je n'observe pas tout à fait la même chose que toi:

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms bbox.lan [192.168.1.254]
2 1414 ms 1385 ms 1423 ms static-176-165-224-2.ftth.abo.bbox.fr [176.165.224.2]
3 12 ms 12 ms 12 ms i15-lef01-t2-62-34-3-213.ft.lns.abo.bbox.fr [62.34.3.213]
4 15 ms 15 ms 16 ms i15-lef01-t2-62-34-3-198.ft.lns.abo.bbox.fr [62.34.3.198]
5 * * * Request timed out.
6 15 ms 16 ms 16 ms 142.250.175.198
7 16 ms 15 ms 15 ms 108.170.255.223
8 16 ms 16 ms 16 ms 72.14.237.93
9 15 ms 16 ms 16 ms dns.google [8.8.8.8]

Ping statistics for 176.165.224.2:
Packets: Sent = 100, Received = 97, Lost = 3 (3% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 2668ms, Average = 419ms

Ping statistics for 62.34.3.213:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 1983ms, Average = 88ms

Les pings peuvent paraître catastrophiques vers la 176.165.224.2 et 62.34.3.213 mais je pense que c'est normal, ils n'ont pas que ça à faire que de répondre en ICMP

MAIS:

Ping statistics for 8.8.8.8:
Packets: Sent = 300, Received = 300, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 28ms, Average = 15ms

Donc pour moi rien de très anormal, je joue une bonne heure en ligne chaque soir, et je n'ai pas observé de soucis de latence plus élevée que la normale (qui est trop élevée à mon goût mais bon )

Mais ça ne veut pas dire que y'a pas un souci de ton coté sur un équipement autre qui pourrait saturer le soir.

[WhiteCat]

Bonjour messieurs,

Tout d’abord merci d’avoir pris le temps de me répondre. Pour ajouter un élément au contexte, je ne connaissais aucun de ces problèmes chez Orange chez qui j’étais juste avant.

Entre-temps, à part l’opérateur et la box, rien n’a changé de mon côté.

Comme vous me l’avez gentiment proposé, je me permets de vous relancer aujourd’hui sur ce sujet. De mon côté, les perte de paquets sont toujours présentes et m’impactent quotidiennement donc à ce stade je ne pense pas persévérer et revenir chez l’opérateur précédent.

[ToFoo93]

Hello,

Merci pour le UP, tu as bien fait et je partage pour voir si on peut faire une analyse sur ton retour, même si ça semble isolé à première vue.

Je ne peut rien garantir, mais à suivre.

Bonne journée