La Fibre
Télécom => Réseau => 
TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: m2kx le 24 décembre 2017 à 17:13:19
-
Bonsoir à tous,
La saison de maintenance des installations familiales commence avec une petite colle ...
Ici dans l'Oise (60) sur une connexion SFR FTTH j'ai remarqué que lors d'un ping vers internet, les paquets me reviennent en duplicate (DUP).
pouet@bidule:~$ ping www.free.fr -c 4
PING www.free.fr (212.27.48.10) 56(84) bytes of data.
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=56 time=4.30 ms
64 bytes from www.free.fr (212.27.48.10): icmp_seq=1 ttl=56 time=4.33 ms (DUP!)
64 bytes from www.free.fr (212.27.48.10): icmp_seq=2 ttl=56 time=3.66 ms
64 bytes from www.free.fr (212.27.48.10): icmp_seq=2 ttl=56 time=4.19 ms (DUP!)
64 bytes from www.free.fr (212.27.48.10): icmp_seq=3 ttl=56 time=3.98 ms
64 bytes from www.free.fr (212.27.48.10): icmp_seq=3 ttl=56 time=4.00 ms (DUP!)
64 bytes from www.free.fr (212.27.48.10): icmp_seq=4 ttl=56 time=4.11 ms
--- www.free.fr ping statistics ---
4 packets transmitted, 4 received, +3 duplicates, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 3.664/4.086/4.337/0.224 ms
Impossible de savoir depuis combien de temps cela dure.
Pour info le test de ping a également été réalisé depuis le box elle même, et j'ai le même comportement, ce qui exclu un soucis de LAN.
Box + ONT redémarré mais ça ne change rien.
Box : NB6VAC-FXC-r0
Firmware : NB6VAC-MAIN-R4.0.31
Si quelqu'un à une idée, ou plutôt le même comportement avec explication de ce qui déconne chez SFR, ce serait sympa departager.
Soucis de boucle ou de routage chez eux peut-être ?
Merci d'avance et joyeuses fêtes à tous
Nico
-
Bonjour,
Je suis en train de tester une connexion directe de mon routeur sur l'ONT, donc sans NeufBox et je constate aussi ce phénomène. Je suis dans l'Oise également.
Je suis content d'être tombé sur ce message car je cherchais vainement un problème dans ma configuration réseau.
Quelle que soit la destination de ping dans le réseau public, on a systématiquement des DUP. Même si on ping le 1er maillon, le gateway, ça fait DUP!
A part cela le réseau semble fonctionner normalement...
-
Bonjour,
Le problème a été remonté au service supervision réseau.
Je vous tiens au courant dès que j'ai un retour.
-
Bonsoir,
J'ai ma ligne FTTH active depuis qqs semaine, et je constate avec suprise ces ping dupliqués aussi... Vous avez un retour depuis ?
ping yahoo.com -n
PING yahoo.com (72.30.35.9) 56(84) bytes of data.
64 bytes from 72.30.35.9: icmp_seq=1 ttl=53 time=99.8 ms
64 bytes from 72.30.35.9: icmp_seq=1 ttl=53 time=99.8 ms (DUP!)
64 bytes from 72.30.35.9: icmp_seq=2 ttl=53 time=99.4 ms
64 bytes from 72.30.35.9: icmp_seq=2 ttl=53 time=99.4 ms (DUP!)
Merci !
-
Bonjour,
Je n'ai malheureusement jamais eu de retour du conseiller à qui j'avais signalé le problème.
Peut-être pourrions-nous abuser un peu de la gentillesse de @kazyor et lui demander son avis sur ce problème ?
Les paquets ICMP Reply sont dupliqués lorsque je passe l'OLT. Si je lance un ping vers l'OLT, les ICMP Reply sont triplés.
Ce phénomène se produit aussi lorsqu'on ping une destination depuis Internet
Exemple sur http://peering.sfr.net/index.php?task=lg (http://peering.sfr.net/index.php?task=lg)
XX.XX.XX.XX xmt/rcv/%loss = 10/10/0%, min/avg/max = 2.04/2.53/3.55
1 targets
2 alive
0 unreachable
0 unknown addresses
0 timeouts (waiting for response)
10 ICMP Echos sent
19 ICMP Echo Replies received
1 other ICMP received
2.04 ms (min round trip time)
2.53 ms (avg round trip time)
3.55 ms (max round trip time)
9.011 sec (elapsed real time)
Merci d'avance
-
Bonjour,
Mmmmh ...
Auriez-vous fais le tour de la littérature sur le sujet pour donner des pistes des causes connues pour ce genre de problème ?
Je constate que vous êtes globalement plus dans l'Oise ?
Ici, à Lyon, je ne note pas ce problème (avec ou sans Bypass de la neufbox) ...
Avez-vous réalisé des mtr histoire de voir par où vous passez ?
-
Bonjour,
Merci de nous aider :)
Voila un petit mtr :
Start: Mon Apr 16 15:26:59 2018
HOST: gateway Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.1.1 0.0% 10 0.4 0.3 0.3 0.4 0.0
2.|-- 1.242.72.86.rev.sfr.net 0.0% 10 3.0 2.1 1.5 3.0 0.0
3.|-- 82.114.154.77.rev.sfr.net 0.0% 10 3.6 3.5 2.8 4.3 0.0
4.|-- 242.10.136.77.rev.sfr.net 0.0% 10 9.6 6.9 3.2 10.9 2.6
5.|-- 129.10.136.77.rev.sfr.net 0.0% 10 4.5 4.6 4.1 5.4 0.0
6.|-- 129.10.136.77.rev.sfr.net 0.0% 10 5.1 4.3 3.6 5.1 0.0
7.|-- cloudflare.par.franceix.net 0.0% 10 3.5 4.3 3.5 6.3 0.7
8.|-- 1dot1dot1dot1.cloudflare-dns.com 0.0% 10 3.5 3.7 3.3 4.1 0.0
Mon OLT (première IP du /24 du range d'ip publique auquel j'appartiens) induit cette duplication. Je le suppose car en pinguant une autre IP du range d'ip publique, les icmp reply sont dupliqués.
Cela se voit par exemple dans la capture Wireshark en pièce jointe (je l'avais envoyé au conseiller à l'époque).
Je lance des ping successivement vers mon LAN, mon FW (bypass Neufbox) (.23), mon OLT (.1) et des destinations sur Internet (8.8.8.8 et 8.8.4.4).
Cela se constate aussi avec une Neufbox.
Edit 17h27 : oubli de la PJ
-
Du coup,
Problématique connue et en investigation, je vais essayer de me tenir informé de l'avancement. Pour l'instant pas d'impacts identifiés.
Ah et ce n'est pas lié à un subnet ou à un OLT en particulier ...
J'ai d'ailleurs un exemple avec l'un de tes voisins de Essuiles sur le même NRO et avec une adresse IP dans le même subnet.
PING 86.75.yyy.xxx (86.75.yyy.xxx) 56(84) bytes of data.
64 bytes from 86.75.yyy.xxx: icmp_req=1 ttl=59 time=9.60 ms
64 bytes from 86.75.yyy.xxx: icmp_req=2 ttl=59 time=9.27 ms
64 bytes from 86.75.yyy.xxx: icmp_req=3 ttl=59 time=9.65 ms
64 bytes from 86.75.yyy.xxx: icmp_req=4 ttl=59 time=10.4 ms
64 bytes from 86.75.yyy.xxx: icmp_req=5 ttl=59 time=9.68 ms
64 bytes from 86.75.yyy.xxx: icmp_req=6 ttl=59 time=9.75 ms
-
Hello et merci d'avoir donné les infos.
J'avoue que je n'y connais pas grand chose, à un moment je m'étais dit qu'il y avait peut-être un lien entre le déploiement des nouveaux OLT/ONT Altice Lab et de ce problème (firmware/stagging de conf d'un nouveau type d'équipement).
J'ai de la famille qui avait été déployée il y a x années du temps de SFR-Vivendi et le problème n'est pas présent.
Je supposais que l'OLT étant un équipement de L3, il devait faire du forwarding (ou même du routing) et dans le cas où je ping un voisin du même subnet, le paquet était routé par mon Fw vers sa default route qui est la .1 et était forwardé directement vers la box de mon voisin. J'en avais conclu que le problème ne pouvait que se localiser sur ce dernier maillon de la chaîne (OLT<->ONT) :)
Merci pour tout en tout cas, c'est vraiment top d'avoir regardé/essayé de trouver des infos ;)
-
Bonsoir,
Merci pour ces réponses, pour ce qui me concerne je suis à Meyzieu 69, une ville qui est encore en cours de fibrage : tout est neuf.
J'ai scanné qqs IP sur le même range que moi et cette fois ce n'est pas 1 mais 3 DUP, ça voudrait dire que la réponse est reçue 4 fois ?
ping 93.6.40.160 (depuis 93.6.40.86)
PING 93.6.40.160 (93.6.40.160) 56(84) bytes of data.
64 bytes from 93.6.40.160: icmp_seq=1 ttl=61 time=3.27 ms
64 bytes from 93.6.40.160: icmp_seq=1 ttl=61 time=3.32 ms (DUP!)
64 bytes from 93.6.40.160: icmp_seq=1 ttl=61 time=3.32 ms (DUP!)
64 bytes from 93.6.40.160: icmp_seq=1 ttl=61 time=3.37 ms (DUP!)
64 bytes from 93.6.40.160: icmp_seq=2 ttl=61 time=2.62 ms
Je ne pense pas que le problème ait des conséquences importantes, pour moi cela doit être une configuration erronée.
A savoir que l'IPV6 n' a jamais marché (activé, mais non connecté). C'est peut être lié ? (NB6VAC-MAIN-R4.0.35)
Merci pour vos retours :-)
-
Hello,
Sur Grenoble, je n'étais pas touché jusqu'à présent.
Depuis une semaine je constate cette duplication également.
C'est peut-être lié à une mise à jour soft de l'OLT/coeur de réseau ?
-
Bonsoir, j'ai également le soucis (je suis sur Lyon). Ça le fait quand :
Depuis chez moi je ping un nom de domaine ou une IP
Depuis mon serveur OVH quand je ping ma propre IP / nom de domaine ça le fait également.
Donc à priori la dupli se produit aussi bien SORTANT qu'en ENTRANT.
-
Donc à priori la dupli se produit aussi bien SORTANT qu'en ENTRANT.
Merci pour la précision.
Cela dit, problème extrêmement intéressant .... ???
Ce problème peut survenir dans le cas d'un LAN mais reste circonscrit au LAN.
Mais dans notre cas ici, il s'agit du WAN, donc ...
Hypothèse : un équipement de niveau 2 ou 3 pile OSI du backbone SFR/Numéricâble produit des paquets dupliqués et ce dans les deux sens.
Il peut d'agir de :
1.Deux équipements qui répondent au ping
2.Les écho request du ping sont dupliqués
3.L'équipement final reçoit correctement un seul echo request mais la réponse echo reply est dupliquée quelque part ailleurs .
-
Un équipement L2 qui crée des paquets ICMP ? Surement pas :p
A mon avis c'est juste un LACP/LAG mal réglé, deux équipements avec la même IP, un VRRP pourri, un bug logiciel sur un routeur... Rien de bien fou.
-
Deux lignes sur le même NRO (donc à priori le même OLT, en tout cas les IP sont dans le même /24) :
- NB6V + ONT blanc Alcatel : il n'y a bien qu'une seule réponse, sauf dans le cas d'un ping vers l'autre ligne où des réponses en doubles sont visibles en faisant un tcpdump sur la box (mais elles semblent être filtrées puisque la commande ping ne voit pas de DUP)
- NB6VAC + ONT noir Altice Labs : pas de DUP visible depuis Windows 7, mais DUP visibles pour n'importe quel ping depuis depuis l'interface de la box
Donc je pense qu'il doit y avoir un bug sur les NB6VAC.
A noter les pings particulièrement mauvais entre les deux lignes : 4 à 8ms de moyenne selon les moments avec pas mal de variations.
Pourtant un traceroute ne montre qu'un seul intermédaire : 92.95.55.1 (qui ne répond quasiment jamais aux ICMP), qui a été ajouté de manière transparente puisque les deux box sont dans le même /24 donc essayent de se parler sans passerelle.
-
Bonjour,
J'ai aussi un problème de paquets DUP, apparemment le problème se situe chez moi entre ces 2 équipements réseaux :
7 205.10.136.77.rev.sfr.net (77.136.10.205) 13.427 ms
8 205.10.136.77.rev.sfr.net (77.136.10.205) 13.258 ms
9 94.142.24.109.rev.sfr.net (109.24.142.94) 13.018 ms
et peut-être même directement sur le premier rencontré depuis l'extérieur (77.136.10.205) puisqu'il répond aussi 2 fois au tracert !
En revanche, il ne répond qu'une seule fois lors d'un ping.
(109.24.142.94) a été lui configuré (surement un routeur derrière l'OLT) pour ne pas répondre aux ping et au deçà de cet équipement les adresses demandées reviennent toutes en DUP.
PS : Je suis localisé à Mérignac comme l'indique mon profil et je fais mes tests à partir du site http://networktools.nl
NB : Ma box est une NB6V
-
Savez-vous s'il existe une possibilité d'une manière ou d'une autre de contacter un tech réseau de chez SFR pour résoudre cette incohérence ?
Apparemment, vu les traceroute le problème se situe toujours au même endroit du réseau.
-
Du coup,
Problématique connue et en investigation [...] Pour l'instant pas d'impacts identifiés.
Ah et ce n'est pas lié à un subnet ou à un OLT en particulier ...
-
Bonjour,
Même problème chez moi (Lorient - Morbihan - 56) :
De l'extrieur vers mon ip public :
PING 77.128.117.102 (77.128.117.102) 56(84) bytes of data.
64 bytes from 77.128.117.102: icmp_seq=1 ttl=50 time=27.3 ms
64 bytes from 77.128.117.102: icmp_seq=1 ttl=50 time=27.3 ms (DUP!)
64 bytes from 77.128.117.102: icmp_seq=2 ttl=50 time=27.3 ms
64 bytes from 77.128.117.102: icmp_seq=2 ttl=50 time=27.4 ms (DUP!)
64 bytes from 77.128.117.102: icmp_seq=3 ttl=50 time=27.9 ms
64 bytes from 77.128.117.102: icmp_seq=3 ttl=50 time=27.9 ms (DUP!)
0 timeouts (waiting for response)
10 ICMP Echos sent
19 ICMP Echo Replies received
4 other ICMP received
1 fw01.adm-01.local (10.255.1.254) 0.141 ms 0.115 ms 0.537 ms
2 vss-3-6k.fr.eu (188.165.213.253) 0.822 ms 0.842 ms 1.038 ms
3 10.95.69.64 (10.95.69.64) 0.619 ms 0.603 ms 0.589 ms
4 10.95.66.60 (10.95.66.60) 0.558 ms 10.95.66.62 (10.95.66.62) 0.563 ms 0.667 ms
5 10.95.64.2 (10.95.64.2) 1.525 ms 2.574 ms 1.517 ms
6 be100-1043.th2-1-a9.fr.eu (94.23.122.147) 4.801 ms 5.065 ms 5.367 ms
7 * * be100-2.th2-1-a9.fr.eu (37.187.36.214) 4.936 ms
8 v3884.mas1-co-2.n9uf.net (62.39.148.250) 21.476 ms * 21.531 ms
9 v3884.mas1-co-2.n9uf.net (62.39.148.250) 25.288 ms 21.673 ms 25.297 ms
10 v3884.mas1-co-2.n9uf.net (62.39.148.250) 21.201 ms 86.0.154.77.rev.sfr.net (77.154.0.86) 17.486 ms v3884.mas1-co-2.n9uf.net (62.39.148.250) 21.177 ms
11 86.0.154.77.rev.sfr.net (77.154.0.86) 21.181 ms 102.117.128.77.rev.sfr.net (77.128.117.102) 21.985 ms 25.179 ms
12 * 102.117.128.77.rev.sfr.net (77.128.117.102) 21.935 ms 28.226 ms
De ma box vers l'exterieur :
PING 8.8.8.8 (8.8.8.8) from 77.128.117.102: 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=122 time=21.660 ms
64 bytes from 8.8.8.8: seq=0 ttl=122 time=21.808 ms (DUP!)
64 bytes from 8.8.8.8: seq=1 ttl=122 time=20.580 ms
64 bytes from 8.8.8.8: seq=1 ttl=122 time=23.247 ms (DUP!)
64 bytes from 8.8.8.8: seq=2 ttl=122 time=22.991 ms
64 bytes from 8.8.8.8: seq=2 ttl=122 time=23.113 ms (DUP!)
64 bytes from 8.8.8.8: seq=3 ttl=122 time=23.400 ms
64 bytes from 8.8.8.8: seq=3 ttl=122 time=23.536 ms (DUP!)
traceroute to 8.8.8.8 (8.8.8.8) from 77.128.117.102, 30 hops max, 38 byte packets
1 56lor1-nro-1.nro.gaoland.net (109.24.76.65) 2.739 ms
2 85.0.154.77.rev.sfr.net (77.154.0.85) 1.945 ms
3 v3884.sqy1-co-1.n9uf.net (62.39.148.249) 4.175 ms
4 v3893.ren1-co-2.n9uf.net (62.39.148.214) 4.916 ms
5 250.69.26.109.rev.sfr.net (109.26.69.250) 14.492 ms
6 229.10.136.77.rev.sfr.net (77.136.10.229) 21.161 ms
7 72.14.218.124 (72.14.218.124) 18.591 ms
8 108.170.244.225 (108.170.244.225) 20.887 ms
9 209.85.255.19 (209.85.255.19) 17.975 ms
Toujours pas ne nouvelles sur ce problème et sa provenance ? Est-ce que cela peut avoir une incidence sur la performance (latence) de la ligne ?
-
Est-ce que cela peut avoir une incidence sur la performance (latence) de la ligne ?
S'il ne s'agit que d'une duplication de paquets ICMP, pour moi, l'impact est vraiment minime, d'autant plus qu'il s'agit de lignes FTTH.
Par défaut, un ICMP reply ne pèse que quelques octets (64 octets), donc c'est vraiment peu comparé à 100 Mbps (ou plus !).
Ce n'est pas ça qui va saturer ton lien ou le dégrader significativement.
-
Bonjour,
Même chose ici au Kremlin-Bicêtre près de Paris, quelle que soit l'IP visée j'ai des duplicats systématiquement en provenance de mon LAN.
Chose que je n'ai pas dans la même configuration avec un autre FAI, ce qui écarte un problème lié à mon réseau.
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=4.19 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=120 time=4.20 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=4.23 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=120 time=4.25 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=3 ttl=120 time=3.99 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=120 time=4.01 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=4 ttl=120 time=3.86 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=120 time=4.81 ms (DUP!)
64 bytes from 8.8.8.8: icmp_seq=5 ttl=120 time=4.25 ms
Un traceroute ne me donne pas plus d'informations, le premier noeud listé en sortie de réseau local renvoit aussi des dups.
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 router.redacted (192.168.2.1) 0.212 ms 0.192 ms 0.189 ms
2 sfrbox.redacted (192.168.1.2) 0.612 ms 1.410 ms 1.542 ms
3 75mou1-nro-1.nro.gaoland.net (86.66.122.19) 3.084 ms 3.131 ms 3.024 ms
4 145.74.20.93.rev.sfr.net (93.20.74.145) 3.254 ms 3.356 ms 3.241 ms
5 229.10.136.77.rev.sfr.net (77.136.10.229) 3.399 ms 237.10.136.77.rev.sfr.net (77.136.10.237) 4.667 ms 4.854 ms
6 72.14.218.124 (72.14.218.124) 4.851 ms 237.10.136.77.rev.sfr.net (77.136.10.237) 4.184 ms 4.158 ms
7 72.14.218.124 (72.14.218.124) 5.248 ms 108.170.244.225 (108.170.244.225) 5.175 ms 72.14.218.124 (72.14.218.124) 4.713 ms
8 209.85.249.183 (209.85.249.183) 4.875 ms 108.170.244.193 (108.170.244.193) 4.364 ms 108.170.244.161 (108.170.244.161) 4.130 ms
9 google-public-dns-a.google.com (8.8.8.8) 2.916 ms 216.239.47.81 (216.239.47.81) 3.936 ms 66.249.94.177 (66.249.94.177) 5.539 ms
Je note cependant que ça ne semble affecter que l'ICMP (ou les pings), je n'observe pas de duplication de paquets UDP entre un VPS et ma ligne SFR.
J'ai déjà imaginé appeler SFR mais je ne me vois pas devoir leur expliquer le problème... (certes mineur mais bien laid et pas très sérieux).
Cordialement,
-
J'ai déjà imaginé appeler SFR mais je ne me vois pas devoir leur expliquer le problème... (certes mineur mais bien laid et pas très sérieux).
Ca ne servirait pas à grand chose d'autant que c'est déjà connu ...
-
Salut,
Avez-vous eu des nouvelles ?
Je vient d'avoir ma connexion fibre activée, en périphérie de Toulouse, et j'ai aussi ~50% des pings dupliqués ...
-
Ils m'ont installe la Fibre FTTH hier et J'ai la meme probleme. c dans 95
MacBook-Pro-2:~ $ ping google.com
PING google.com (216.58.198.206): 56 data bytes
64 bytes from 216.58.198.206: icmp_seq=0 ttl=56 time=5.698 ms
64 bytes from 216.58.198.206: icmp_seq=0 ttl=56 time=5.718 ms (DUP!)
64 bytes from 216.58.198.206: icmp_seq=1 ttl=56 time=6.113 ms
64 bytes from 216.58.198.206: icmp_seq=1 ttl=56 time=6.128 ms (DUP!)
64 bytes from 216.58.198.206: icmp_seq=2 ttl=56 time=6.297 ms
64 bytes from 216.58.198.206: icmp_seq=2 ttl=56 time=6.318 ms (DUP!)
64 bytes from 216.58.198.206: icmp_seq=3 ttl=56 time=5.935 ms
64 bytes from 216.58.198.206: icmp_seq=3 ttl=56 time=5.965 ms (DUP!)
64 bytes from 216.58.198.206: icmp_seq=4 ttl=56 time=6.367 ms
64 bytes from 216.58.198.206: icmp_seq=4 ttl=56 time=6.388 ms (DUP!)
64 bytes from 216.58.198.206: icmp_seq=5 ttl=56 time=5.685 ms
-
Même problème pour moi, dans le 91 [RED SFR]
PING google.com (216.58.206.238): 56 data bytes
64 bytes from 216.58.206.238: icmp_seq=0 ttl=55 time=4.213 ms
64 bytes from 216.58.206.238: icmp_seq=0 ttl=55 time=5.039 ms (DUP!)
64 bytes from 216.58.206.238: icmp_seq=1 ttl=55 time=7.169 ms
64 bytes from 216.58.206.238: icmp_seq=1 ttl=55 time=7.675 ms (DUP!)
64 bytes from 216.58.206.238: icmp_seq=2 ttl=55 time=6.480 ms
64 bytes from 216.58.206.238: icmp_seq=2 ttl=55 time=7.092 ms (DUP!)
64 bytes from 216.58.206.238: icmp_seq=3 ttl=55 time=6.601 ms
64 bytes from 216.58.206.238: icmp_seq=3 ttl=55 time=7.533 ms (DUP!)
64 bytes from 216.58.206.238: icmp_seq=4 ttl=55 time=9.022 ms
64 bytes from 216.58.206.238: icmp_seq=4 ttl=55 time=9.615 ms (DUP!)
-
Le problème est corrigé de mon côté :)
-
Bonjour,
Problème corrigé ici aussi. :)
-
Pas ici (Marseille, 8ième arrondissement) :
paul@paul-TERRA-MOBILE-1542:~$ ping google.fr
PING google.fr (216.58.204.131) 56(84) bytes of data.
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=1 ttl=56 time=14.1 ms
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=1 ttl=56 time=14.4 ms (DUP!)
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=2 ttl=56 time=16.1 ms
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=2 ttl=56 time=16.4 ms (DUP!)
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=3 ttl=56 time=16.9 ms
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=3 ttl=56 time=16.10 ms (DUP!)
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=4 ttl=56 time=16.2 ms
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=4 ttl=56 time=16.5 ms (DUP!)
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=5 ttl=56 time=15.8 ms
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=5 ttl=56 time=16.0 ms (DUP!)
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=6 ttl=56 time=16.7 ms
64 bytes from par21s05-in-f3.1e100.net (216.58.204.131): icmp_seq=6 ttl=56 time=16.7 ms (DUP!)
^C
--- google.fr ping statistics ---
6 packets transmitted, 6 received, +6 duplicates, 0% packet loss, time 13ms
rtt min/avg/max/mdev = 14.122/16.087/16.974/0.892 ms
-
Bonjour, problème corrigé ici également (25).
-
Ici aussi, ça date d'il y a +/- 1 semaine.