Discussion de forum
Perte de paquets récurrente en soirée sur mon lien fibre - hébergeur
Bonjour Pseudonyme2
Pseudonyme2 a écrit:
Si vous preniez le temps de lire correctement le post vous auriez vu qu'un MTR a déjà été effectué.
Oui mais ton MTR/Tracert a manifestement été lancé depuis ton serveur hébergé au Pays bas (216.163.184.253) vers on ne sait où....!
Et quand on fait un tracert vers ton serveur, on ne peut pas dire que après chez Orange/Sosh, chez le transitaire twelve99.net, ça soit très glorieux.
Par exemple: depuis une connexion fibre Sosh
C:\Users\Luskell29>tracert -4 216.163.184.253
Détermination de l’itinéraire vers 216.163.184.253 avec un maximum de 30 sauts.
1 <1 ms <1 ms <1 ms livebox.home [192.168.1.1]
2 2 ms 2 ms 2 ms 80.10.252.197
3 2 ms 2 ms 2 ms ae87-0.ncren101.rbci.orange.net [193.253.150.178]
4 * * * Délai d’attente de la demande dépassé.
5 * * * Délai d’attente de la demande dépassé.
6 6 ms 6 ms 6 ms prs-b1-link.ip.twelve99.net [195.12.254.154]
7 31 ms 32 ms 32 ms prs-bb2-link.ip.twelve99.net [62.115.125.166]
8 35 ms 42 ms 49 ms adm-bb2-link.ip.twelve99.net [62.115.137.4]
9 16 ms 18 ms 17 ms adm-b14-link.ip.twelve99.net [62.115.141.241]
10 15 ms 15 ms 15 ms slashnservices-ic-398240.ip.twelve99-cust.net [62.115.211.83]
11 15 ms 16 ms 15 ms 216.163.184.253
Itinéraire déterminé.
Ton hébergeur a peut-être trop vite refilé la patate chaude.!
Petite précision sur le MTR que j'ai posté : il n'a pas été lancé "vers on ne sait où" — la commande était vers mon ip publique, donc bien depuis le serveur vers moi, dans le sens serveur → moi.
Bonne remarque sur le sens du test, mais j'ai en fait déjà testé les deux sens :
- Moi → serveur (traceroute du 17/07, pendant une coupure) : quelques sauts ne répondent pas au ping (normal, beaucoup de routeurs backbone ignorent l'ICMP), mais tous les sauts qui répondent sont propres, et le serveur final répond en 22 ms sans souci.
- Serveur → moi (MTR du 19/07) : c'est là qu'apparaît la perte, jusqu'à 99% sur le dernier saut visible côté Orange (niidf303), au moment exact d'une coupure de streaming.
Et pour le streaming, c'est justement ce deuxième sens qui compte : le flux vidéo descend du serveur vers moi, je n'envoie en retour que de petites requêtes de contrôle. Donc le sens qui montre un problème est précisément celui qui transporte le volume de données concerné par les coupures.
Les deux tests sont cohérents entre eux : rien d'anormal dans le sens qui n'impacte pas mon usage, une perte nette dans le sens qui l'impacte
