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
Eric Demeester
Julien Arlandis (Sun, 09 Oct 16 15:10:38 +0000 - fr.comp.reseaux.ip) :
Le 09/10/2016 à 13:25, Eric Demeester a écrit :

[...]
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?

Les trois durées indiquées représentent l’équivalant d’un ping sur le
routeur correspondant.
Pourquoi 3 temps, alors qu'un seul suffit?

Trois pings permettent d'obtenir plus d'information qu'un seul, ça
permet de mieux faire ressortir les anomalies.
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?

Une absence de réponse au ping ou un timeout.
Avatar
Eric Demeester
Julien Arlandis (Sun, 09 Oct 16 15:22:10 +0000 - fr.comp.reseaux.ip) :
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

Aucun problème, c'est vite dit, si tu observes les temps de réponse et
que tu les compares à ceux obtenus sur la machine hébergée chez Online,
les tiens oscillent entre 22 et 40 ms, tandis qu'ils sont entre 0.6 et
1.4 ms sur le serveur hébergé.
Si on compare avec les 28 à 31 ms derrière ma Freebox, on a des temps à
peu près équivalents, tout ça à pondérer parce ce parce que n'est pas en
faisant quelques mesures ponctuelles qu'on peut tirer des conclusions
précises.
Si tu n'as pas de « trous » (d'étoiles), c'est probablement parce que la
commande sous Linux par moins vite en timeout que son équivalent sous
Windows.
J'ai la flemme de chercher quel est l'opérateur de peering ou de transit
entre Free et Google, mais d'après les données obtenues, c'est
clairement chez lui que ça rame, pas chez Free. Après, difficile de
savoir si c'est un problème d'infrastructure ou un choix délibéré.
Avatar
Julien Arlandis
Le 09/10/2016 à 17:55, Didier a écrit :
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.

Cela va permettre de voir sur quel tronçon de route il va y avoir de la
latence, mais cela ne permet pas d'en déduire sur quelle partie du réseau
se perdent les paquets ICMP.
Ce n'est pas parce qu'un tronçon de route est plus lent, qu'il est
forcément défaillant, en fait je ne vois pas le lien que l'on peut faire
entre ces deux caractéristiques.
Prenons une analogie routière, ce n'est pas parce qu'une route est
fortement embouteillée qu'elle produira plus d'accidents, une route peu
fréquentée mais verglacée pourra être mortelle.
Ce que l'on cherche, c'est le tronçon de route qui tue les paquets, pas
qui les ralentit.
Avatar
Julien Arlandis
Le 09/10/2016 à 18:24, Eric Demeester a écrit :
Julien Arlandis (Sun, 09 Oct 16 15:22:10 +0000 - fr.comp.reseaux.ip) :
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

Aucun problème, c'est vite dit, si tu observes les temps de réponse et
que tu les compares à ceux obtenus sur la machine hébergée chez Online,
les tiens oscillent entre 22 et 40 ms, tandis qu'ils sont entre 0.6 et
1.4 ms sur le serveur hébergé.

Je vois un temps de réponse moyen de mon répartiteur ADSL de 22 ms, je ne
vois pas où est le problème.
Si on compare avec les 28 à 31 ms derrière ma Freebox, on a des temps à
peu près équivalents, tout ça à pondérer parce ce parce que n'est pas
en
faisant quelques mesures ponctuelles qu'on peut tirer des conclusions
précises.
Si tu n'as pas de « trous » (d'étoiles), c'est probablement parce que
la
commande sous Linux par moins vite en timeout que son équivalent sous
Windows.
J'ai la flemme de chercher quel est l'opérateur de peering ou de transit
entre Free et Google, mais d'après les données obtenues, c'est
clairement chez lui que ça rame, pas chez Free. Après, difficile de
savoir si c'est un problème d'infrastructure ou un choix délibéré.

Que ça rame est une chose, que les ping n'aboutissent pas en est une
autre.
Avatar
Doug713705
Le 09-10-2016, Julien Arlandis nous expliquait dans
fr.comp.reseaux.ip
() :
Que ça rame est une chose, que les ping n'aboutissent pas en est une
autre.

Quand ça rame trop, boum, timeout.
Le ping est *peut-être* arrivé mais de ton coté tu n'attends déjà plus
la réponse.
Tu peux augmenter le timeout mais jusqu'à combien ?
man ping, notamment les options -w et surtout -W
--
Je ne connaîtrai rien de tes habitudes
Il se peut même que tu sois décédée
Mais j'demanderai ta main pour la couper
-- H.F. Thiéfaine, L'ascenceur de 22H43
Avatar
Olivier B.
On Sun, 09 Oct 16 16:33:41 +0000, Julien Arlandis
wrote:
Le 09/10/2016 à 17:55, Didier a écrit :
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.

Cela va permettre de voir sur quel tronçon de route il va y avoir de la
latence, mais cela ne permet pas d'en déduire sur quelle partie du réseau
se perdent les paquets ICMP.

pour moi clairement si, et ça répond au sujet initial "Problème de
ping"
Ce n'est pas parce qu'un tronçon de route est plus lent, qu'il est
forcément défaillant, en fait je ne vois pas le lien que l'on peut faire
entre ces deux caractéristiques.

personne n'a parlé de lenteur, il est question de perte, quand le
routeur N répons systmatiquement et le N+1 présente plus de 50% de
perte, j'en déduit que le problème bien de l'interco entre les deux, à
plus forte raison quand le "N+1" répond parfaite au même protocole
depuis un autre FAI
De plus sachant que l'ICMP est souvent placé en priorité basse, ça
revèle selon moi une congestion du lien ce qui recoupe exactement avec
les lenteurs dont tu te plain.
Prenons une analogie routière

heu bof ... non, parce que le propres des analogies routières, c'est
qu'elles ne tiennent pas la route ;-)
--
pas de .turlututu. avant l'@robase
Avatar
Julien Arlandis
Le 09/10/2016 à 20:21, Doug713705 a écrit :
Le 09-10-2016, Julien Arlandis nous expliquait dans
fr.comp.reseaux.ip
() :
Que ça rame est une chose, que les ping n'aboutissent pas en est une
autre.

Quand ça rame trop, boum, timeout.
Le ping est *peut-être* arrivé mais de ton coté tu n'attends déjà plus
la réponse.
Tu peux augmenter le timeout mais jusqu'à combien ?
man ping, notamment les options -w et surtout -W

J'ai tenté, mais ça ne change rien.
Avatar
Julien Arlandis
Le 09/10/2016 à 21:42, Olivier B . a écrit :
On Sun, 09 Oct 16 16:33:41 +0000, Julien Arlandis
wrote:
Le 09/10/2016 à 17:55, Didier a écrit :
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.

Cela va permettre de voir sur quel tronçon de route il va y avoir de la
latence, mais cela ne permet pas d'en déduire sur quelle partie du réseau
se perdent les paquets ICMP.

pour moi clairement si, et ça répond au sujet initial "Problème de
ping"
Ce n'est pas parce qu'un tronçon de route est plus lent, qu'il est
forcément défaillant, en fait je ne vois pas le lien que l'on peut faire
entre ces deux caractéristiques.

personne n'a parlé de lenteur, il est question de perte, quand le
routeur N répons systmatiquement et le N+1 présente plus de 50% de
perte, j'en déduit que le problème bien de l'interco entre les deux, à
plus forte raison quand le "N+1" répond parfaite au même protocole
depuis un autre FAI

Justement, je n'ai aucun routeur qui répond avec 50% de pertes. Tous les
routeurs entre google répondent à 100%, exceptés le routeur juste avant
google qui ne répond pas pour lequel j'en déduis que la réponse au ping
a été désactivée.
Avatar
Doug713705
Le 10-10-2016, Julien Arlandis nous expliquait dans
fr.comp.reseaux.ip
() :
Le 09/10/2016 à 20:21, Doug713705 a écrit :
Le 09-10-2016, Julien Arlandis nous expliquait dans
fr.comp.reseaux.ip
() :
Que ça rame est une chose, que les ping n'aboutissent pas en est une
autre.

Quand ça rame trop, boum, timeout.
Le ping est *peut-être* arrivé mais de ton coté tu n'attends déjà plus
la réponse.
Tu peux augmenter le timeout mais jusqu'à combien ?
man ping, notamment les options -w et surtout -W

J'ai tenté, mais ça ne change rien.

Evidemment puisque les paquets sont _perdus_ (ils ne sont probablement
pas arrivé à leur destination).
Tu peux mettre le timeout que tu veux, ils ne retrouveront pas leur
chemin pour autant et ça prouve bien qu'il ne s'agit pas d'un problème
de latence mais bien un problème de connectivité.
--
dis-moi qui tu suis... je te dirais qui je hais !
-- H.F. Thiéfaine, L'agence des amants de madame Müller
Avatar
Olivier B.
On Mon, 10 Oct 16 08:32:54 +0000, Julien Arlandis
wrote:
Justement, je n'ai aucun routeur qui répond avec 50% de pertes. Tous les
routeurs entre google répondent à 100%

Tu as bien de la chance, perso depuis ma connection free, loin es
heures de pointe, voilà ce que cela donne:
Statistiques Ping pour 172.217.20.35:
Paquets : envoyés = 50, reçus = 42, perdus = 8 (perte 16%),
Durée approximative des boucles en millisecondes :
Minimum = 48ms, Maximum = 54ms, Moyenne = 49ms
Aux heures de pointe, c'est pire, ça rejoint ce que disent les autres
ici.
--
pas de .turlututu. avant l'@robase
1 2 3 4