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?
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?
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Le 08/10/2016 à 10:27, Julien Arlandis a écrit :
ping -c 10 mail.google.com
(...)
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?
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP
issues de la résolution de mail.google.com, 0% depuis un autre FAI.
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?
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Julien Arlandis
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous serions face à une situation très inquiétante. Si ce n'est pas indiscret depuis quel lieu géographique /région avez vous lancé le test?
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP
issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous
serions face à une situation très inquiétante. Si ce n'est pas indiscret
depuis quel lieu géographique /région avez vous lancé le test?
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous serions face à une situation très inquiétante. Si ce n'est pas indiscret depuis quel lieu géographique /région avez vous lancé le test?
Pascal Hambourg
Le 08/10/2016 à 11:19, Julien Arlandis a écrit :
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous serions face à une situation très inquiétante. Si ce n'est pas indiscret depuis quel lieu géographique /région avez vous lancé le test?
La Freebox (qui n'est pas chez moi) est en région toulousaine.
Le 08/10/2016 à 11:19, Julien Arlandis a écrit :
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP
issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous
serions face à une situation très inquiétante. Si ce n'est pas indiscret
depuis quel lieu géographique /région avez vous lancé le test?
La Freebox (qui n'est pas chez moi) est en région toulousaine.
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous serions face à une situation très inquiétante. Si ce n'est pas indiscret depuis quel lieu géographique /région avez vous lancé le test?
La Freebox (qui n'est pas chez moi) est en région toulousaine.
Pascal Hambourg
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Pour info je ne constate aucune perte en IPv6 depuis la Freebox.
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP
issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Pour info je ne constate aucune perte en IPv6 depuis la Freebox.
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Pour info je ne constate aucune perte en IPv6 depuis la Freebox.
Julien Arlandis
Le 08/10/2016 à 11:35, Pascal Hambourg a écrit :
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Pour info je ne constate aucune perte en IPv6 depuis la Freebox.
C'est une bonne remarque et c'est effectivement ce que je constate. Peut on forcer l'usage de l'IPV6 par le navigateur lorsque le serveur distant répond en IPV6?
Le 08/10/2016 à 11:35, Pascal Hambourg a écrit :
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP
issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Pour info je ne constate aucune perte en IPv6 depuis la Freebox.
C'est une bonne remarque et c'est effectivement ce que je constate.
Peut on forcer l'usage de l'IPV6 par le navigateur lorsque le serveur
distant répond en IPV6?
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Pour info je ne constate aucune perte en IPv6 depuis la Freebox.
C'est une bonne remarque et c'est effectivement ce que je constate. Peut on forcer l'usage de l'IPV6 par le navigateur lorsque le serveur distant répond en IPV6?
Julien Arlandis
Le 08/10/2016 à 11:29, Pascal Hambourg a écrit :
Le 08/10/2016 à 11:19, Julien Arlandis a écrit :
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous serions face à une situation très inquiétante. Si ce n'est pas indiscret depuis quel lieu géographique /région avez vous lancé le test?
La Freebox (qui n'est pas chez moi) est en région toulousaine.
Il faudrait maintenant savoir si le paquet ICMP est bloqué à l'envoi ou au retour, comment faire?
Le 08/10/2016 à 11:29, Pascal Hambourg a écrit :
Le 08/10/2016 à 11:19, Julien Arlandis a écrit :
Le 08/10/2016 à 11:15, Pascal Hambourg a écrit :
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP
issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous
serions face à une situation très inquiétante. Si ce n'est pas
indiscret
depuis quel lieu géographique /région avez vous lancé le test?
La Freebox (qui n'est pas chez moi) est en région toulousaine.
Il faudrait maintenant savoir si le paquet ICMP est bloqué à l'envoi ou
au retour, comment faire?
Perte entre 26% et 45% depuis une freebox vers diverses adresses IP issues de la résolution de mail.google.com, 0% depuis un autre FAI.
Mes craintes semblent se préciser, si elles devaient se confirmer nous serions face à une situation très inquiétante. Si ce n'est pas indiscret depuis quel lieu géographique /région avez vous lancé le test?
La Freebox (qui n'est pas chez moi) est en région toulousaine.
Il faudrait maintenant savoir si le paquet ICMP est bloqué à l'envoi ou au retour, comment faire?
Pascal Hambourg
Le 08/10/2016 à 11:43, Julien Arlandis a écrit :
Il faudrait maintenant savoir si le paquet ICMP est bloqué à l'envoi ou au retour, comment faire?
Je ne vois pas comment c'est possible sans être présent aux deux bouts.
Le 08/10/2016 à 11:43, Julien Arlandis a écrit :
Il faudrait maintenant savoir si le paquet ICMP est bloqué à l'envoi ou
au retour, comment faire?
Je ne vois pas comment c'est possible sans être présent aux deux bouts.
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.
Francois Lafont
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 : ~$ 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 ? -- François Lafont
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 :
~$ 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 ?
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 : ~$ 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 ? -- François Lafont
Olivier B.
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 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 :-/ A+ -- pas de .turlututu. avant l'@robase
On Sat, 08 Oct 16 08:27:32 +0000, Julien Arlandis
<julien.arlandis@laposte.net> 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
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 :-/
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 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 :-/ A+ -- pas de .turlututu. avant l'@robase
