Perte de paquets sur certains sites

[florentfr01]

Bonjour à tous,

depuis environ 6 jours, ma connection fibre SFR (box plus) est devenu très instable.

Si la connection est normale sur certains sites, elle est devenue très difficile sur d'autres. (même comportement quelque soit l'ordinateur utilisé, mobile, tablette, connection ethernet ou wifi), je constate beaucoup de perte de paquets ou la connection ne se fait pas du tout.

J'ai pu vérifié que le problème ne provenait pas de la box ou même du cablage fibre.

Les sites où la connection est très difficile se chargent totalement normalement quand je me connecte via un VPN ! aucun problème de perte de paquets.

Ces mêmes sites se chargent également normalement via une connection Mobile (autre opérateur).

Donc je peux en déduire que mon installation n'est pas en cause et que le problème vient de quelque part à l'intérieur du réseau SFR.

Le service client SFR contacté ne peut rien faire parce que "certains sites fonctionnent normalement et donc c'est pas notre responsabilité".

Comment résoudre ce problème ? n'y a t'il pas un problème de routeur qqpart dans le réseau SFR ?

Merci de votre aide, de vos avis et vos conseils.

Cela impacte ma connection vers des sites tels que instagram, youtube, certains services google, et pleins d'autres sites ...

Ci dessous en exemple, un tracert et pathping vers une adresse qui pose problème :

C:\Users\flore>tracert 217.182.134.3

Détermination de l’itinéraire vers ns3079202.ip-217-182-134.eu [217.182.134.3]
avec un maximum de 30 sauts :

1 4 ms 1 ms 1 ms box [192.168.1.1]
2 4 ms 2 ms 2 ms 44nts1-nro-2.nro.gaoland.net [109.24.76.98]
3 * 6 ms 3 ms 178.42.154.77.rev.sfr.net [77.154.42.178]
4 5 ms 4 ms 4 ms 111.147.6.194.rev.sfr.net [194.6.147.111]
5 14 ms 13 ms 13 ms 186.144.6.194.rev.sfr.net [194.6.144.186]
6 14 ms 14 ms 13 ms 186.144.6.194.rev.sfr.net [194.6.144.186]
7 * * * Délai d’attente de la demande dépassé.
8 * * * Délai d’attente de la demande dépassé.
9 * * * Délai d’attente de la demande dépassé.
10 * * * Délai d’attente de la demande dépassé.
11 21 ms 21 ms 16 ms be103.rbx-g4-nc5.fr.eu [54.36.50.229]
12 * * * Délai d’attente de la demande dépassé.
13 * * * Délai d’attente de la demande dépassé.
14 * * * Délai d’attente de la demande dépassé.
15 19 ms 16 ms 16 ms ns3079202.ip-217-182-134.eu [217.182.134.3]

Itinéraire déterminé.

C:\Users\flore>pathping 217.182.134.3

Détermination de l’itinéraire vers ns3079202.ip-217-182-134.eu [217.182.134.3]
avec un maximum de 30 sauts :
0 DESKTOP-SE64QAB [192.168.1.70]
1 box [192.168.1.1]
2 44nts1-nro-2.nro.gaoland.net [109.24.76.98]
3 178.42.154.77.rev.sfr.net [77.154.42.178]
4 111.147.6.194.rev.sfr.net [194.6.147.111]
5 186.144.6.194.rev.sfr.net [194.6.144.186]
6 186.144.6.194.rev.sfr.net [194.6.144.186]
7 * * *
Traitement des statistiques pendant 150 secondes...
Source vers ici Ce nœud/lien
Saut RTT Perdu/Envoyé = % Perdu/Envoyé = % Adresse
0 DESKTOP-SE64QAB [192.168.1.70]
0/ 100 = 0% |
1 3ms 0/ 100 = 0% 0/ 100 = 0% box [192.168.1.1]
0/ 100 = 0% |
2 4ms 0/ 100 = 0% 0/ 100 = 0% 44nts1-nro-2.nro.gaoland.net [109.24.76.98]
0/ 100 = 0% |
3 5ms 0/ 100 = 0% 0/ 100 = 0% 178.42.154.77.rev.sfr.net [77.154.42.178]
15/ 100 = 15% |
4 6ms 15/ 100 = 15% 0/ 100 = 0% 111.147.6.194.rev.sfr.net [194.6.147.111]
85/ 100 = 85% |
5 --- 100/ 100 =100% 0/ 100 = 0% 186.144.6.194.rev.sfr.net [194.6.144.186]
0/ 100 = 0% |
6 --- 100/ 100 =100% 0/ 100 = 0% 186.144.6.194.rev.sfr.net [194.6.144.186]

Itinéraire déterminé.

[Ryry]

Bonjour @florentfr01 

---

Cela impacte ma connection vers des sites tels que instagram, youtube, certains services google, et pleins d'autres sites ...

Ci dessous en exemple, un tracert et pathping vers une adresse qui pose problème :

---

Cela aurait été encore plus parlant de montrer un exemple avec des sites "majeurs" comme instagram ou youtube que tu citais, et pas un serveur "inconnu" dont on connait seulement l'IP

Cependant quelques remarques :

• concernant tracert

Chez moi aussi le traceroute 217.182.134.3 ne réussit pas à aller jusqu'au bout.

Mais ce premier essai avec tracert ne permet pas de conclure quoi que ce soit : en effet, comme tu le liras dans les doc réseau, pour fonctionner, cette commande a besoin que tous les maillons intermédiaires répondent au ping... Ils peuvent tout à fait fonctionner et refuser de répondre à la commande ping (c'est même archi fréquent). Ça ne veut pas dire que les services du serveur demandé sont pour autant inatteignables.

Exemple : le serveur web www.sfr.fr fonctionne très bien.

Pourtant le traceroute (ou tracert) échoue à mi-chemin et ne va pas au bout.

• concernant pathping

Je connais moins cette commande mais la doc dit qu'elle combine ping et traceroute... De ce fait on peut craindre qu'elle ait le même défaut... À creuser tout de même.

Le mieux (pour être incontestable sur la "perte" de paquets" que tu évoques) serait

1. de faire un simple ping qui marche (càd qui réussit à avoir une réponse de sa cible)
2. et de constater dans les multiples essais que répète le ping s'il y a vraiment des pertes de paquet dans l'échange avec ce serveur

Par exemple depuis chez moi

• le serveur que tu présentes réponds au ping
• et je n'ai aucune perte de paquet :

Révélation

% ping 217.182.134.3
PING 217.182.134.3 (217.182.134.3): 56 data bytes
64 bytes from 217.182.134.3: icmp_seq=0 ttl=248 time=24.316 ms
64 bytes from 217.182.134.3: icmp_seq=1 ttl=248 time=24.070 ms
64 bytes from 217.182.134.3: icmp_seq=2 ttl=248 time=23.574 ms
64 bytes from 217.182.134.3: icmp_seq=3 ttl=248 time=23.002 ms
64 bytes from 217.182.134.3: icmp_seq=4 ttl=248 time=30.745 ms
64 bytes from 217.182.134.3: icmp_seq=5 ttl=248 time=23.816 ms
64 bytes from 217.182.134.3: icmp_seq=6 ttl=248 time=29.544 ms
64 bytes from 217.182.134.3: icmp_seq=7 ttl=248 time=29.398 ms
64 bytes from 217.182.134.3: icmp_seq=8 ttl=248 time=34.628 ms
64 bytes from 217.182.134.3: icmp_seq=9 ttl=248 time=23.744 ms
64 bytes from 217.182.134.3: icmp_seq=10 ttl=248 time=30.036 ms
64 bytes from 217.182.134.3: icmp_seq=11 ttl=248 time=23.328 ms
64 bytes from 217.182.134.3: icmp_seq=12 ttl=248 time=29.187 ms
64 bytes from 217.182.134.3: icmp_seq=13 ttl=248 time=24.007 ms
64 bytes from 217.182.134.3: icmp_seq=14 ttl=248 time=27.474 ms
64 bytes from 217.182.134.3: icmp_seq=15 ttl=248 time=22.189 ms
64 bytes from 217.182.134.3: icmp_seq=16 ttl=248 time=29.338 ms
64 bytes from 217.182.134.3: icmp_seq=17 ttl=248 time=28.985 ms
64 bytes from 217.182.134.3: icmp_seq=18 ttl=248 time=23.263 ms
...

=> obtiens-tu le même résultat en ping direct ?

=> as-tu d'autres exemples, puisque tu évoques YouTube, Instagram...

Ça vaut le coup de creuser un peu plus.

À+

[florentfr01]

Bonjour et merci de ta réponse,

effectivement le problème semble plus compliqué à résoudre qu'avec le ping ou un traceroute.

J'ai testé tout à l'heure le site slate.fr, il ping normalement et le traceroute trouve le chemin et pourtant le site ne chargeait pas du tout pendant plusieurs minutes.

Je me suis connecté avec un VPN et ça marchait normalement. Bref je suis perdu.

Je vais continuer à faire des tests, mais je ne sais pas trop quels sont les outils adéquats pour ça....

[chris2704]

Bonjour,

Un site gratuit Packet Loss Test – Test Your Connection Quality permet de tester les paquets en utilisant la technologie web Real Time Communication.

Avant de lancer le test pensez que votre ordinateur peut être mis en relation avec un pair inconnu par un tiers inconnu. Pensez aussi que votre adresse IP n'est pas toujours protégée par un VPN face à cette technologie.

Même si vous ne lancez pas le test vous aurez une idée de la taille des paquets à tester suivant le but visé. Pour ce faire utiliser l'option Select a Preset Approximation.

Notez qu'il est possible que votre navigateur bloque les communications webRTC en fonction des extensions pré installées.

Après pour tester la perte de paquets  j'ai peur qu'il n'y ait pas beaucoup de logiciel totalement gratuit.

Intel conseille aux joueurs d'utiliser PingPlotter. Il est en essai libre pendant 14 jours. Après j'ai cru comprendre qu'il passe en mode dégradé. Je viens de l'installer pour voir.

Je ne crois pas que le logiciel utilise des technologies hasardeuses. Il itère ping et traceroute ce qui permet de détecter les points de ralentissement ou de blocage à un moment précis.

Par exemple joindre slate.fr a posé un bref  problème vers 15h01mn aujourd'hui. Avec un ping ou un tracert manuel il aurait été improbable de le détecter.

Enfin vous pouvez tenter votre chance avec iPerf (pas la dernière version mais la 3.0.12) à utiliser en ligne de commande (.\iperf3 -h pour les options). Le projet est en sommeil depuis juin 2016. J'ai peu utilisé et beaucoup oublié.

Bons tests.

[florentfr01 · Accepted solution]

Merci à tous pour vos réponses, le problème à disparu hier soir !

probablement corrigé par SFR à l'intérieur de leur réseau

@chris2704 je garde sous la main les outils que tu as proposé, ça pourra servir pour plus tard

Bonne journée !