Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Matériel Réseaux et Internet IP Problème de ping

Problème de ping

35 réponses
Avatar
Julien Arlandis
Bonjour,

Depuis quelques jours, je suis confronté à un problème assez déroutant
qui ralentit le chargement de mes pages google. Après bien des tests, j'en
suis arrivé à la conclusion que le problème se situait au niveau de la
route empruntée depuis ma box jusqu'aux serveurs de google.
En effet, le test suivant :
-----------------------------------------------------
ping -c 10 mail.google.com

PING googlemail.l.google.com (172.217.18.229): 56 data bytes
64 bytes from 172.217.18.229: icmp_seq=0 ttl=56 time=36.246 ms
64 bytes from 172.217.18.229: icmp_seq=1 ttl=56 time=39.651 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
64 bytes from 172.217.18.229: icmp_seq=7 ttl=56 time=34.807 ms
Request timeout for icmp_seq 8

--- googlemail.l.google.com ping statistics ---
10 packets transmitted, 3 packets received, 70.0% packet loss
round-trip min/avg/max/stddev = 34.807/36.901/39.651/2.031 ms
-----------------------------------------------------
retourne systématiquement une perte des paquets de l'ordre de 50%.

Et j'ai bien sûr vérifié que je n'avais pas de problème avec les ping
en dehors de google, et j'ai vérifié aussi que les serveurs de google
répondent parfaitement au ping d'autres clients distants.

Serait il possible que le problème vienne de mon FAI (à savoir free), que
celui-ci dégrade volontairement ou involontairement la connexion de ses
abonnés à destination de google?

Afin d'écarter cette éventualité, ceux qui me lisent derrière une
freebox, pourraient ils à leur tour me communiquer le résultat de leur
test?

Merci
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4
Avatar
Julien Arlandis
Le 08/10/2016 à 16:13, Olivier B . a écrit :
On Sat, 08 Oct 16 08:27:32 +0000, Julien Arlandis
wrote:
Bonjour,
Depuis quelques jours, je suis confronté à un problème assez déroutant
qui ralentit le chargement de mes pages google. Après bien des tests, j'en
suis arrivé à la conclusion que le problème se situait au niveau de la
route empruntée depuis ma box jusqu'aux serveurs de google.

on en a parlé sur proxad, les groupes de support free.
si tu fais un tracert tu arriveras à la conclusion que cette perte
depuis/vers google se passe hors du réseau free, donc pour moi c'est
l'interco free-google qui est au taquet et droppe outrageusement
l'icmp

Peux tu me fournir les étapes du raisonnement qui te conduisent à cette
conclusion?
comme un autre l'a précisé, depuis d'autres FAI cela ne se produit
pas, c'est pas sans me rappeler le bra de fer entre free et google
pour le financement de leur interco :-/

Si le problème se produit uniquement derrière une connexion free, je vois
mal comment free ne pourrait pas être responsable.
Avatar
Julien Arlandis
Le 08/10/2016 à 16:07, Francois Lafont a écrit :
Bonjour,
Mon FAI est Free également et j'habite en banlieue sud de Paris (Massy) et
je constate vraiment la même chose (et je crois depuis quelques jours). Par
exemple :

Vous avez vous aussi constaté un ralentissement de votre connexion lorsque
vous utilisez les services de google, le ping n'étant qu'un moyen de
constater objectivement la mauvaise qualité de la liaison?
~$ ping -n 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttlX time%.9 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttlX time%.7 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttlX time%.6 ms
64 bytes from 8.8.8.8: icmp_seq ttlX time'.1 ms
64 bytes from 8.8.8.8: icmp_seq ttlX time%.8 ms
64 bytes from 8.8.8.8: icmp_seq ttlX time%.9 ms
64 bytes from 8.8.8.8: icmp_seq ttlX time'.1 ms
64 bytes from 8.8.8.8: icmp_seq ttlX time%.9 ms
64 bytes from 8.8.8.8: icmp_seq" ttlX time&.3 ms
^C
--- 8.8.8.8 ping statistics ---
23 packets transmitted, 9 received, 60% packet loss, time 22101ms
rtt min/avg/max/mdev = 25.671/26.198/27.185/0.541 ms
Quelqu'un a-t-il une explication ? C'est Free qui déconne et il faut juste
patienter ?

Je n'ai pas d'explication, peut être que free dégrade volontairement sa
liaison avec google comme ça avait été le cas il y a quelques années
avec youtube.
Avatar
Richard Hachel
Le 08/10/2016 à 13:17, Pascal Hambourg a écrit :
Le 08/10/2016 à 11:42, Julien Arlandis a écrit :
Peut on forcer l'usage de l'IPV6 par le navigateur lorsque le serveur
distant répond en IPV6?

C'est normalement par défaut pour les applications compatibles IPv6
comme firefox.

Firefox, c'était bien au début, mais depuis qu'ils ont mis des plugins,
ça ralenti incroyable,
et les videos youtube se bloquent même par instants.
J'ai tout viré Firefox, et j'ai mis Chrome.
Ca bloque pu.
Mais j'ai les pubs.
Des fois, je me demande même s'ils le font pas exprès pour qu'on ait les
pubs (puisqu'on vire
les plugin antipubs).
Ils ne sont pas à ça près, puisque maintenant, ils ont des "bloqueurs
de bloqueurs".
C'est à dire qu'un bloqueur te dit: "Si vous voulez entrer dans ce site,
enlever votre bloqueur Adblock,
où vous ne verrez rien du tout. Et donc, t'es obligé de l'enlever, et tu
vois les pubs".
Plus rien ne les arrête.
R.H.
Avatar
Olivier B.
On Sun, 09 Oct 16 08:18:52 +0000, Julien Arlandis
wrote:
Le 08/10/2016 à 16:13, Olivier B . a écrit :
On Sat, 08 Oct 16 08:27:32 +0000, Julien Arlandis
wrote:
Bonjour,
Depuis quelques jours, je suis confronté à un problème assez déroutant
qui ralentit le chargement de mes pages google. Après bien des tests, j'en
suis arrivé à la conclusion que le problème se situait au niveau de la
route empruntée depuis ma box jusqu'aux serveurs de google.

on en a parlé sur proxad, les groupes de support free.
si tu fais un tracert tu arriveras à la conclusion que cette perte
depuis/vers google se passe hors du réseau free, donc pour moi c'est
l'interco free-google qui est au taquet et droppe outrageusement
l'icmp

Peux tu me fournir les étapes du raisonnement qui te conduisent à cette
conclusion?

le tracer est un ping dont on augmente progressivement le TTL, dans un
premier temps il ne passe que par les routeurs de Free/reseau de free,
zero perte, ensuite ça se gate avec google, *MAIS* cela veut juste
dire qu'il y a de la perte, pas que les routeurs de google, ou son
réseau dropent les paquets.
En faisant ce même test depuis un autre FAI, tu vois un résultat
différent, qui prouve que le problème est coté interco entre free et
google
comme un autre l'a précisé, depuis d'autres FAI cela ne se produit
pas, c'est pas sans me rappeler le bra de fer entre free et google
pour le financement de leur interco :-/

Si le problème se produit uniquement derrière une connexion free, je vois
mal comment free ne pourrait pas être responsable.

c'est justement parce qu'il se prouit *que* derrière une connection
Free qu'une conclusion s'impose :-)
Tu paye free pour qu'il te donne accès à internet, c'est à lui de se
doter des tuyauxmoyens nécéssaire pour répondre à ce contrat, google
fait parti d'internet.
A+
--
pas de .turlututu. avant l'@robase
Avatar
Eric Demeester
Bonjour,
Julien Arlandis (Sat, 08 Oct 16 08:27:32 +0000 - fr.comp.reseaux.ip) :
Afin d'écarter cette éventualité, ceux qui me lisent derrière une
freebox, pourraient ils à leur tour me communiquer le résultat de leur
test?

ping -n 10 mail.google.com
Envoi d'une requête 'ping' sur googlemail.l.google.com [216.58.208.197]
avec 32 octets de données :
Délai d'attente de la demande dépassé.
Réponse de 216.58.208.197 : octets2 temps% ms TTLU
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Délai d'attente de la demande dépassé.
Statistiques Ping pour 216.58.208.197:
Paquets : envoyés = 10, reçus = 4, perdus = 6 (perte 60%),
Durée approximative des boucles en millisecondes :
Minimum = 25ms, Maximum = 26ms, Moyenne = 25ms
Il y a le même problème sur Paris, le traceroute indique que les pertes
de paquets se situent après la sortie du réseau de Free, le problème
vient donc a priori de son partenaire de peering / transit et pas du
réseau free.
(J'ai copié / collé comme citation sinon les lignes sont coupées.)
tracert mail.google.com
Détermination de l'itinéraire vers googlemail.l.google.com [216.58.208.197]
avec un maximum de 30 sauts :
1 <1 ms 1 ms 1 ms 192.168.0.254
2 28 ms 27 ms 26 ms lab75-5-88-166-115-254.fbx.proxad.net [88.166.115.254]
3 31 ms 30 ms 25 ms 78.254.13.190
4 26 ms 26 ms 26 ms p19-6k-2-v910.intf.routers.proxad.net [78.254.254.13]
5 27 ms 31 ms 31 ms p11-crs16-1-be1004.intf.routers.proxad.net [78.254.249.129]
6 27 ms 27 ms 26 ms cbv-crs8-1.intf.routers.proxad.net [78.254.249.102]
7 * 26 ms 26 ms 72.14.211.26
8 26 ms * 26 ms 72.14.239.205
9 * 26 ms 26 ms 209.85.143.241
10 27 ms * 26 ms par10s21-in-f197.1e100.net [216.58.208.197]
Itinéraire déterminé
Avatar
Eric Demeester
Eric Demeester (Sun, 09 Oct 2016 13:25:44 +0200 - fr.comp.reseaux.ip) :
ping -n 10 mail.google.com
Envoi d'une requête 'ping' sur googlemail.l.google.com [216.58.208.197]
avec 32 octets de données :
Délai d'attente de la demande dépassé.
Réponse de 216.58.208.197 : octets2 temps% ms TTLU
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Délai d'attente de la demande dépassé.

Par comparaison, les mêmes demandes depuis un serveur dans un datacenter
chez Online montrent que la réponse est quasi instantanée (on notera que
ce n'est pas la même IP qui répond) :
:~$ ping mail.google.com
PING googlemail.l.google.com (216.58.211.69) 56(84) bytes of data.
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=1 ttlY time=1.09 ms
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=2 ttlY time=0.945 ms
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=3 ttlY time=1.00 ms
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=4 ttlY time=0.994 ms
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=5 ttlY time=0.952 ms
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=6 ttlY time=0.960 ms
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=7 ttlY time=0.931 ms
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=8 ttlY time=0.987 ms
64 bytes from par03s14-in-f5.1e100.net (216.58.211.69): icmp_seq=9 ttlY time=0.949 ms
^C
--- googlemail.l.google.com ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8004ms
rtt min/avg/max/mdev = 0.931/0.980/1.099/0.058 ms
:~$ traceroute mail.google.com
traceroute to mail.google.com (216.58.211.69), 30 hops max, 60 byte packets
1 62-210-74-1.rev.poneytelecom.eu (62.210.74.1) 0.602 ms 0.669 ms 0.753 ms
2 195.154.1.244 (195.154.1.244) 0.981 ms 1.024 ms 195.154.1.242 (195.154.1.242) 0.900 ms
3 google.bb1.dc3.poneytelecom.eu (195.154.3.226) 1.038 ms 72.14.218.182 (72.14.218.182) 1.056 ms 1.056 ms
4 72.14.238.234 (72.14.238.234) 1.432 ms 1.408 ms 72.14.239.145 (72.14.239.145) 1.457 ms
5 72.14.233.81 (72.14.233.81) 1.286 ms 1.320 ms 1.295 ms
6 par03s14-in-f5.1e100.net (216.58.211.69) 1.299 ms 1.219 ms 0.952 ms
Avatar
Julien Arlandis
Le 09/10/2016 à 13:06, Olivier B . a écrit :
On Sun, 09 Oct 16 08:18:52 +0000, Julien Arlandis
wrote:
Le 08/10/2016 à 16:13, Olivier B . a écrit :
On Sat, 08 Oct 16 08:27:32 +0000, Julien Arlandis
wrote:
Bonjour,
Depuis quelques jours, je suis confronté à un problème assez
déroutant
qui ralentit le chargement de mes pages google. Après bien des tests,
j'en
suis arrivé à la conclusion que le problème se situait au niveau de
la
route empruntée depuis ma box jusqu'aux serveurs de google.

on en a parlé sur proxad, les groupes de support free.
si tu fais un tracert tu arriveras à la conclusion que cette perte
depuis/vers google se passe hors du réseau free, donc pour moi c'est
l'interco free-google qui est au taquet et droppe outrageusement
l'icmp

Peux tu me fournir les étapes du raisonnement qui te conduisent à cette
conclusion?

le tracer est un ping dont on augmente progressivement le TTL, dans un
premier temps il ne passe que par les routeurs de Free/reseau de free,
zero perte, ensuite ça se gate avec google, *MAIS* cela veut juste
dire qu'il y a de la perte, pas que les routeurs de google, ou son
réseau dropent les paquets.

Le traceroute va t'indiquer la liste des routeurs entre ta box et la
destination.
Soit le résultat suivant :
A tA
B tB
C tC
D tD
E tE
F tF
G tG
Dans le cas présent A B C D E F G les routeurs respectifs entre ta box (A)
et google (G) et tA tB tC tD tE tF tG les temps de réponse respectifs.
Supposons que A B C et D fassent partie du réseau de free.
Quel(s) test(s), quelles valeurs de tA tB tC tD tE tF tG te permet
d'affirmer que le problème viendrait de E ou F et pas de B C ou D?
Avatar
Julien Arlandis
Le 09/10/2016 à 13:25, Eric Demeester a écrit :
Bonjour,
Julien Arlandis (Sat, 08 Oct 16 08:27:32 +0000 - fr.comp.reseaux.ip) :
Afin d'écarter cette éventualité, ceux qui me lisent derrière une
freebox, pourraient ils à leur tour me communiquer le résultat de leur
test?

ping -n 10 mail.google.com
Envoi d'une requête 'ping' sur googlemail.l.google.com [216.58.208.197]
avec 32 octets de données :
Délai d'attente de la demande dépassé.
Réponse de 216.58.208.197 : octets2 temps% ms TTLU
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Délai d'attente de la demande dépassé.
Statistiques Ping pour 216.58.208.197:
Paquets : envoyés = 10, reçus = 4, perdus = 6 (perte 60%),
Durée approximative des boucles en millisecondes :
Minimum = 25ms, Maximum = 26ms, Moyenne = 25ms
Il y a le même problème sur Paris, le traceroute indique que les pertes
de paquets se situent après la sortie du réseau de Free, le problème
vient donc a priori de son partenaire de peering / transit et pas du
réseau free.
(J'ai copié / collé comme citation sinon les lignes sont coupées.)
tracert mail.google.com
Détermination de l'itinéraire vers googlemail.l.google.com
[216.58.208.197]
avec un maximum de 30 sauts :
1 <1 ms 1 ms 1 ms (A) 192.168.0.254
2 28 ms 27 ms 26 ms (B) lab75-5-88-166-115-254.fbx.proxad.net
[88.166.115.254]
3 31 ms 30 ms 25 ms (C) 78.254.13.190
4 26 ms 26 ms 26 ms (D) p19-6k-2-v910.intf.routers.proxad.net
[78.254.254.13]
5 27 ms 31 ms 31 ms (E)
p11-crs16-1-be1004.intf.routers.proxad.net [78.254.249.129]
6 27 ms 27 ms 26 ms (F) cbv-crs8-1.intf.routers.proxad.net
[78.254.249.102]
7 * 26 ms 26 ms (G) 72.14.211.26
8 26 ms * 26 ms (H) 72.14.239.205
9 * 26 ms 26 ms (I) 209.85.143.241
10 27 ms * 26 ms (J) par10s21-in-f197.1e100.net
[216.58.208.197]
Itinéraire déterminé


Merci pour le test, maintenant interprétons le résultat du tracert.
Déjà, pour chaque routeur, je vois 3 temps affichés, à quoi
correspondent ils exactement?
Pourquoi 3 temps, alors qu'un seul suffit?
Deuxième question :
Je vois sur la 7ème, 8ème et 9ème ligne un temps indéterminé
matérialisé par une "*". Que cela signifie t-il?
Avatar
Julien Arlandis
Le 09/10/2016 à 13:25, Eric Demeester a écrit :
Bonjour,
Julien Arlandis (Sat, 08 Oct 16 08:27:32 +0000 - fr.comp.reseaux.ip) :
Afin d'écarter cette éventualité, ceux qui me lisent derrière une
freebox, pourraient ils à leur tour me communiquer le résultat de leur
test?

ping -n 10 mail.google.com
Envoi d'une requête 'ping' sur googlemail.l.google.com [216.58.208.197]
avec 32 octets de données :
Délai d'attente de la demande dépassé.
Réponse de 216.58.208.197 : octets2 temps% ms TTLU
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Délai d'attente de la demande dépassé.
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Réponse de 216.58.208.197 : octets2 temps& ms TTLU
Délai d'attente de la demande dépassé.
Statistiques Ping pour 216.58.208.197:
Paquets : envoyés = 10, reçus = 4, perdus = 6 (perte 60%),
Durée approximative des boucles en millisecondes :
Minimum = 25ms, Maximum = 26ms, Moyenne = 25ms
Il y a le même problème sur Paris, le traceroute indique que les pertes
de paquets se situent après la sortie du réseau de Free, le problème
vient donc a priori de son partenaire de peering / transit et pas du
réseau free.
(J'ai copié / collé comme citation sinon les lignes sont coupées.)
tracert mail.google.com
Détermination de l'itinéraire vers googlemail.l.google.com
[216.58.208.197]
avec un maximum de 30 sauts :
1 <1 ms 1 ms 1 ms 192.168.0.254
2 28 ms 27 ms 26 ms lab75-5-88-166-115-254.fbx.proxad.net
[88.166.115.254]
3 31 ms 30 ms 25 ms 78.254.13.190
4 26 ms 26 ms 26 ms p19-6k-2-v910.intf.routers.proxad.net
[78.254.254.13]
5 27 ms 31 ms 31 ms p11-crs16-1-be1004.intf.routers.proxad.net
[78.254.249.129]
6 27 ms 27 ms 26 ms cbv-crs8-1.intf.routers.proxad.net
[78.254.249.102]
7 * 26 ms 26 ms 72.14.211.26
8 26 ms * 26 ms 72.14.239.205
9 * 26 ms 26 ms 209.85.143.241
10 27 ms * 26 ms par10s21-in-f197.1e100.net
[216.58.208.197]
Itinéraire déterminé


Chez moi, je n'ai aucun problème de route :
traceroute to googlemail.l.google.com (172.217.18.229), 64 hops max, 52
byte packets
1 192.168.1.254 (192.168.1.254) 1.486 ms 1.594 ms 0.972 ms
2 dom95-2-82-239-131-254.fbx.proxad.net (82.239.131.254) 23.464 ms
22.230 ms 24.114 ms
3 213.228.28.126 (213.228.28.126) 22.570 ms 22.716 ms 21.833 ms
4 p11-crs16-1-be1121.intf.routers.proxad.net (194.149.163.133) 28.775 ms
30.622 ms 31.977 ms
5 cbv-crs8-1.intf.routers.proxad.net (78.254.249.102) 25.879 ms 25.472
ms 29.378 ms
6 72.14.211.26 (72.14.211.26) 29.472 ms 30.786 ms 31.047 ms
7 72.14.239.205 (72.14.239.205) 39.968 ms 31.935 ms 29.270 ms
8 209.85.243.47 (209.85.243.47) 32.275 ms 28.186 ms 26.099 ms
9 par10s10-in-f229.1e100.net (172.217.18.229) 26.244 ms 27.181 ms
26.129 ms
Avatar
Didier
Le 09/10/2016 à 16:56, Julien Arlandis a écrit :
Le 09/10/2016 à 13:06, Olivier B . a écrit :
le tracer est un ping dont on augmente progressivement le TTL, dans un
premier temps il ne passe que par les routeurs de Free/reseau de free,
zero perte, ensuite ça se gate avec google, *MAIS* cela veut juste
dire qu'il y a de la perte, pas que les routeurs de google, ou son
réseau dropent les paquets.

Le traceroute va t'indiquer la liste des routeurs entre ta box et la
destination.
Soit le résultat suivant :
A tA
B tB
C tC
D tD
E tE
F tF
G tG
Dans le cas présent A B C D E F G les routeurs respectifs entre ta box (A)
et google (G) et tA tB tC tD tE tF tG les temps de réponse respectifs.
Supposons que A B C et D fassent partie du réseau de free.
Quel(s) test(s), quelles valeurs de tA tB tC tD tE tF tG te permet
d'affirmer que le problème viendrait de E ou F et pas de B C ou D?

Tu devrais bien lire la réponse D'olivier B. : le tracert s'utilise en
augmentant progessivement le TTL, on voir donc bien entre quel routeur
et son suivant ça se gate.
Didier.
1 2 3 4