La Fibre
Télécom => Peering Transit (appairage) => 
Peering entre opérateurs => Discussion démarrée par: jeremyp3 le 21 mars 2013 à 23:23:07
-
bonjour a tous,
je constate un bridage depuis sfr vers ovh en fibre parcontre depuis ovh vers sfr, pas de bridage, le débit tourne bien a son maxi
donc un petit wget -O /dev/null vers le serveur proof.ovh.net
0% [ ] 75 643 168 2,59M/s eta 58m 21s
même avec un wget vers mon serveur dédier j'ai a peut prêt le même débit
maintenant vers test-debit.info
11% [=========> ] 119 760 871 9,07M/s eta 1m 58s
32% [==========================> ] 322 307 111 9,31M/s eta 82s
ici, je retrouve le débit correct ...
suis-je le seul ?
jerem
-
Depuis ma Bbox fibre, je suis a 11,1 Mo/s pour proof.ovh.net et testdebit.info donc pas de saturation du serveur il me semble.
-
Peut-être une saturation du peering dans un sens entre OVH et SFR. La weathermap OVH ne donne malheureusement pas l'info correcte sur l'état du lien (volontairement ou non) :
http://weathermap.ovh.net/paris (http://weathermap.ovh.net/paris)
-
Je me demande si il n'y a pas autre chose, parce que j'ai vraiment du mal à croire à une saturation à 07H26 !
Là je prends 2Mo/s de moins vers OVH que vers testdebit.info, c'est pas rien.
pi@raspberrypi ~ $ wget -O /dev/null http://proof.ovh.net/files/100Mio.dat (http://proof.ovh.net/files/100Mio.dat)
--2013-03-22 06:24:03-- http://proof.ovh.net/files/100Mio.dat (http://proof.ovh.net/files/100Mio.dat)
Resolving proof.ovh.net (proof.ovh.net)... 188.165.12.106, 2001:41d0:2:876a::1
Connecting to proof.ovh.net (proof.ovh.net)|188.165.12.106|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: `/dev/null'
100%[======================================>] 104,857,600 8.61M/s in 12s
2013-03-22 06:24:15 (8.39 MB/s) - `/dev/null' saved [104857600/104857600]
pi@raspberrypi ~ $ wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
--2013-03-22 06:25:02-- http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
Resolving testdebit.info (testdebit.info)... 89.84.127.55
Connecting to testdebit.info (testdebit.info)|89.84.127.55|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1000000000 (954M) [application/x-ns-proxy-autoconfig]
Saving to: `/dev/null'
28% [==========> ] 283,323,559 10.9M/s eta 70s ^C
-
Bon depuis un serveur 1Gb/s sur le réseau Bouygues Telecom, je télécharge a 97,5 Mo/s de moyenne (le fichier se télécharge en une seconde)
97,5 Mo/s = 818 Mb/s
$ wget -O /dev/null http://proof.ovh.net/files/100Mio.dat (http://proof.ovh.net/files/100Mio.dat)
--2013-03-22 08:15:15-- http://proof.ovh.net/files/100Mio.dat (http://proof.ovh.net/files/100Mio.dat)
Résolution de proof.ovh.net (proof.ovh.net)... 188.165.12.106, 2001:41d0:2:876a::1
Connexion vers proof.ovh.net (proof.ovh.net)|188.165.12.106|:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 104857600 (100M) [application/octet-stream]
Sauvegarde en : «/dev/null»
100%[======================================>] 104 857 600 97,5M/s ds 1,0s
2013-03-22 08:15:16 (97,5 MB/s) - «/dev/null» sauvegardé [104857600/104857600]
jeremyp3, sur ton serveur dédié (kimsufi sur Roubaix), je télécharge à 11,2 Mo/s tout le temps, ce qui correspond au maximum sur un lien de 100 Mb/s :
$ wget -O /dev/null http://91.121.96.xx/image.iso (http://91.121.96.xx/image.iso)
--2013-03-22 08:16:53-- http://91.121.96.xx/image.iso (http://91.121.96.xx/image.iso)
Connexion vers 91.121.96.xx:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 678526976 (647M) [application/x-iso9660-image]
Sauvegarde en : «/dev/null»
100%[======================================>] 678 526 976 11,2M/s ds 58s
2013-03-22 08:17:50 (11,2 MB/s) - «/dev/null» sauvegardé [678526976/678526976]
-
bonjour,
ok merci vivien, je voulais être sur que ma configuration du serveur été hors de cause, donc tout va bien de ce coté
a cette heure ci,
sur mon serveur dédier,
je tourne entre 2 et 5 MO/s ce qui est insufisant des 11,2 Mo/s d'avant ...
il y a eu un changement, mais lequel ?
-
Je pense a des pertes de paquets, car la saturation, c'est peu probable vu l'heure.
Tu nous ferais une capture Wireshark ? (coté client ou coté serveur, peu importe)
A ces débits là pour ne pas avoir de paquets perdus pour cause d’accès disque, je te conseille de ne capturer que les 100 premiers octets de chaque paquet.
Sur ton serveur, la commande # tcpdump -i eth0 -n -s 100 -w fichier.pcap devrait fonctionner.
Utiliser un outil spécialisé dans la capture (Wireshark n'est pas optimisé pour faire de la capture, pour ne pas avoir de pertes, il est conseillé de passer par un outil qui fait de la capture uniquement, source : http://wiki.wireshark.org/Performance (http://wiki.wireshark.org/Performance)). Une fois la capture réalisée vous pourrez l'ouvrir avec Wireshark pour appliquer vos filtres et analyser la trace. Ces outils sont :
- DumpPcap installé avec Wireshark
- WinDump sous windows
- TcpDump sous linux.
-
J'ai fais l'analyse de la capture Wireshark réalisée ce matin par jeremyp3.
Je confirme un problème sur un routeur ou une fibre qui engendre beaucoup de pertes de paquet, même en heure creuse (donc ce n'est pas de la saturation).
TCP a bien un mécanisme de "Sélective Acquittement" pour continuer sans perte de débit malgré des paquets perdus, là on est dans des proportions assez importantes et le paquet perdu n'a pas été ré-envoyé qu'on perd de nouveau d'autres paquets.
On se retrouve acquitter des pages : les paquets d’acquittements indiquent avoir reçus des AAA à BBB , de CCC à DDD, de EEE à FFFF et de GGG à HHH. Entre chacune de ces plages, ce sont des paquets perdus.
-
salut vivien,
a quelle iveau sont les paquet perdu ? je veux dire entre quel et quel routeur ?
et a qui faut le dire ? parce que ça fais plusieurs mois que c'est ainsi ...
-
Je ne sais pas où sont les pertes de paquets.
Par contre je constate que ce sont elles qui sont bien a l’origine des lenteurs rencontrées.
A noter que l'impact est moindre sur Paris du fait de la latence plus faible : plus le ping est faible, plus il est possible d'avoir un débit élevé pour un même pourcentage de perte de paquet.
-
un petit wget a cette heure ci
--2013-03-24 00:02:59-- http://ipv4.proof.ovh.net/files/10Gb.dat (http://ipv4.proof.ovh.net/files/10Gb.dat)
Résolution de ipv4.proof.ovh.net... 188.165.12.106
Connexion vers ipv4.proof.ovh.net|188.165.12.106|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1250000000 (1,2G) [application/octet-stream]
Sauvegarde en : «/dev/null»
1% [> ] 23 686 034 707K/s eta 24m 7s
faut vraiment faire quelque chose, je suis plus rapide avec mon adsl free a coté ...
jerem
-
Je t'ai fais un petit script pour linux pour tester chaque heure le débit entre le serveur hébergé par d'OVH (http://proof.ovh.net/files/ (http://proof.ovh.net/files/)) et le serveur de Bytel (https://testdebit.info/ (https://testdebit.info/))
Il est téléchargeable sur https://lafibre.info/testdebit/scripts/test_debit_ovh_bytel.pl (https://lafibre.info/testdebit/scripts/test_debit_ovh_bytel.pl)
Il faut le rendre exécutable : bouton droit sur le fichier puis dans permissions cocher la "Autoriser l’exécution du fichier comme un programme"
Ensuite pour qu'il soit exécuté chaque heure, il faut le mettre dans le crontab.
Dans un terminal, il faut taper la commande crontab -e
Si il propose un choix d'éditeur, choisir /bin/nano
Pour que le test soit lacé à la 16ème minute de chaque heure, il faut mettre cette ligne de commande :
16 * * * * /home/scripts/test_debit_ovh_bytel.pl >> /home/scripts/test_debit.csv
/home/scripts/test_debit_ovh_bytel.pl est l'emplacement complet du script (a adapter en fonction de là où il est réellement)
/home/scripts/test_debit.csv est l'emplacement complet du fichier .csv qui sera crée
Je te conseille d'éditer le fichier .csv avec un éditeur de texte afin d'y rajouter la ligne de titre :
Date;Heure;Debit Moyen1;Temps DNS1;Temps connect1;Temps start transfer1;Temps total1;Taille1;Debit Moyen2;Temps DNS2;Temps connect2;Temps start transfer2;Temps total2;Taille2
Pour lire les résultats (après 1 à 2 jours de test), il suffit de double cliquer sur le fichier, il s'ouvre directement avec LibreOffice ou Excel.
Le téléchargement "1" OVH
Le téléchargement "2" est Bouygues Telecom.
-
re,
voila j'ai mis le script en crontab penses tu qu'on pourrai faire quelque chose avec ça ? ou c'est seulement a titre de comparaison ?
parce que si personne ne fais rien ça ne bougera jamais
jerem
-
Cela permet d'avoir des mesures précises et objectives (les deux tests sont réalisés a quelques secondes d'interval) régulièrement (heure de pointe, nuit, journée)
Ensuite cela sera transmis à SFR (il y a des personnes bien placées chez SFR qui lisent ce forum, pour ce type d'incident, c'est plus pertinent que la hotline)
-
bonjour,
voici le petit fichier qui a été exécuter de mercredi après midi a ce soir toute les 16 de chaque heure
201303_jeremyp3_test_debit_ovh_bytel.xls (https://lafibre.info/testdebit/scripts/resultats/201303_jeremyp3%20_test_debit_ovh_bytel.xls)
si je regarde sur la globalité, ovh 50 mbit et lafibre.info 80 / 95 mbit
jerem
-
Tu regardes la mauvaise colonne.
J'ai mis le fichier au format Excel (lisible sans souci avec LibreOffice) et j'ai mis en gras la colonne des débits : 201303_jeremyp3_test_debit_ovh_bytel.xls (https://lafibre.info/testdebit/scripts/resultats/201303_jeremyp3%20_test_debit_ovh_bytel.xls).
Débits moyens des 60 tests : 15,9 Mb/s avec OVH et 41,2 Mb/s avec Bytel.
Ce sont des petits fichiers, c'est normal de ne pas avoir le débit max vu que le débit monte lentement.
C'est par contre anormal d'avoir des différences entre OVH et Bytel de cet ordre (sur un fichier plus grand, la différence est plus importante car Bytel arriverait a monter en débit et pas OVH)
Le débit est toujours le même, que ce soit en heure creuse ou en heure pleine.
Ce n'est donc pas une saturation mais des pertes de paquets sur une fibre / un routeur, sans lien avec la charge.
-
Chez moi de SFR à OVH je suis à 800ko/s, ca commence a vraiment me souler.
Dès que orange arrive sur Pau bye SFR !
-
je remonte le sujet pour essayer d'avoir une réponse, une amélioration, d'autres témoignages pour faire bouger sfr
en parler sur n9ws pourrait il faire bouger les choses ?
-
Voilà pour moi :
(https://www.speedtest.net/result/2632040458.png)
(http://www.vinal.fr/upload/images/capturzjz.png)
-
salut,
j'ai ouvert un tiquet OVH hier répondu aujourd’hui et on ma dis la chose suivante :
Bonjour,
Je vous remercie pour ces informations .
Je remonte les résultats à nos administrateurs réseau et je reviens vers vous.
Cordialement,
Meryam
j'ai transmis un trace route dans les deux sens ainsi que un wget vers ovh et autres ou le débit est a son maxi
-
bon je viens avec des bonnes nouvelles
cette nuit la route a changer pendants un petit moment on passer plus par 86.64.159.106 mais par l'autre route 86.64.177.33 a paris durant un petit moment (j'ai l'impréssion que c'est la route de secours).
désormais on est revenu par la route normal et voici un wget depuis mon serveur ovh a 4h46
--2013-04-12 04:48:09-- http://91.121.xx.xx/image.iso (http://91.121.xx.xx/image.iso)
Connexion vers 91.121.xx.xx:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 678526976 (647M) [application/x-iso9660-image]
Sauvegarde en : «/dev/null»
7% [=====> ] 54 188 880 11,2M/s eta 68s
ouaiiiii ! pourvu que ça dure !!
merci vivien si tu as pu faire quelque chose au niveau de sfr
je suis intérressé par ton retour
jerem
edit 19h
7% [=====> ] 50 004 909 1012K/s eta 9m 55s ^
grrrr !
-
bonjour,
je viens de me rendre compte que c'est encore la mizère entre sfr fibre et OVH
traceroute de chez moi vers mon serveur OVH
traceroute to 91.121.96.xx (91.121.96.xx), 30 hops max, 60 byte packets
1 * * *
2 106.159.64.86.rev.sfr.net (86.64.159.106) 21.705 ms 21.775 ms 21.829 ms
3 105.159.64.86.rev.sfr.net (86.64.159.105) 19.550 ms 19.644 ms 19.653 ms
4 154.61.6.109.rev.sfr.net (109.6.61.154) 27.529 ms 27.529 ms 27.532 ms
5 * * *
6 gsw-g1-a9.fr.eu (213.186.32.210) 21.232 ms 21.403 ms 21.375 ms
7 rbx-g2-a9.fr.eu (91.121.215.151) 25.121 ms 24.955 ms rbx-g2-a9.fr.eu (91.1
21.131.213) 25.417 ms
8 rbx-1-6k.fr.eu (91.121.131.13) 95.407 ms * *
9 rbx-30-m1.fr.eu (213.251.191.85) 24.912 ms 25.200 ms 24.811 ms
10 ks285xx.kimsufi.com (91.121.96.xx) 24.554 ms 24.454 ms 24.511 ms
[/code
traceroute inverse
[code]
traceroute to 93.31.xxx.xx (93.31.xxx.xx), 30 hops max, 60 byte packets
1 rbx-30-m2.fr.eu (91.121.96.252) 0.806 ms 1.008 ms 1.240 ms
2 * * *
3 rbx-g1-a9.fr.eu (94.23.122.106) 1.797 ms 1.807 ms 1.798 ms
4 th2-g1-a9.fr.eu (91.121.215.132) 4.745 ms th2-g1-a9.fr.eu (91.121.131.210)
4.421 ms th2-g1-a9.fr.eu (91.121.215.132) 4.742 ms
5 * * *
6 te4-1.th21-co-3.n9uf.net (86.66.127.117) 11.529 ms 7.798 ms 7.756 ms
7 229.220.96.84.rev.sfr.net (84.96.220.229) 5.404 ms 5.378 ms 5.367 ms
8 213.122.3.109.rev.sfr.net (109.3.122.213) 5.324 ms 5.309 ms 5.398 ms
9 210.122.3.109.rev.sfr.net (109.3.122.210) 5.934 ms 13.246 ms 13.243 ms
10 113.12.6.109.rev.sfr.net (109.6.12.113) 5.430 ms 5.445 ms 5.384 ms
11 106.159.64.86.rev.sfr.net (86.64.159.106) 6.554 ms 6.451 ms 5.984 ms
12 1.xxx.31.93.rev.sfr.net (93.31.xxx.1) 25.546 ms 25.568 ms 25.542 ms
13 xx.xxx.31.93.rev.sfr.net (93.31.xxx.xx) 24.524 ms 24.504 ms 24.545 ms
mais un wget ne reste pas au maximum comme avant
--2014-01-18 18:06:00-- http://ipv4.proof.ovh.net/files/10Gb.dat
Résolution de ipv4.proof.ovh.net... 188.165.12.106
Connexion vers ipv4.proof.ovh.net|188.165.12.106|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1250000000 (1,2G) [application/octet-stream]
Sauvegarde en : «/dev/null»
0% [ ] 8 108 756 4,22M/s ^
5% [=> ] 72 467 084 3,35M/s eta 7m 6s
un wget sur testdebit.info
--2014-01-18 18:07:26-- http://1.testdebit.info/fichiers/1000Mo.dat
Résolution de testdebit.info... 89.84.127.54
Connexion vers testdebit.info|89.84.127.54|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 1000000000 (954M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
6% [=> ] 66 257 274 7,19M/s eta 2m 15s ^
15% [====> ] 150 792 962 9,16M/s eta 1m 42s
quelqu'un rencontre-t-il encore les même soucis que l'an dernier ?
jerem
-
re,
ça persiste encore ce soir.
vivien si je te met une capture tu accepte de la regarder si il y a une histoire de perte de paquet ?
jerem
-
Bien sur mais l'idéal serait de faire coté client et coté serveur.
Ne pas avoir les deux coté ne permet pas de voir tous les problèmes.
Il me semble que tu as un serveur OVH.
Voici les commandes à passer pour faire la capture :
sudo tcpdump -i eth0 -n -s 200 -w fichier.pcap port 80
-
jeremyp3 a réalisé une capture coté client et coté serveur. Ce qu'il faut préciser, c'est que ses problématique de débit n’apparaissent que sur certains serveurs.
Voici ce que l'on observe : Les 3,8 premières secondes du transfert tout se passe bien, la connexion monte en débit et ne doit pas être loin du débit maximum quand brusquement il y a une perte de paquet (un paquet perdu pas plus, ce n'est pas la catastrophe).
A partir de ce moment là le serveur va èmettre une petite quantité de données puis attendre des acquittements. C'est un mode de transmission qui pourait se comprendre sur une liaison de très mauvaise qualité mais là je ne comprends pas.
Il y a donc une question sur la perte de paquet, mais surtout pourquoi le serveur se met dans cette situation et pourquoi uniquement sur le réseau SFR sur l'extension Axione. Malheureusement je n'ai pas la réponse.
Ci-dessous, un graphe de la trace serveur on voit bien le comportement qui change après la perte de paquet (en bleu) :
(https://lafibre.info/images/wireshark/201401_jeremyp3_sfr_pau_broadband_country.png)
-
bonjour,
il y a eu des modifications coté sfr aujourd'hui durant quelques minutes mais cela na pas durée malheureusement ... vu que j'ai un sms qui me prévien quand ma ligne est down, je m'en suis rendu compte de suite
petit traceroute modifier
1 1 ms <1 ms <1 ms [192.168.80.1]
2 * * * Délai d'attente de la demande dépassé.
3 20 ms 20 ms 20 ms 106.159.64.86.rev.sfr.net [86.64.159.106]
4 * * * Délai d'attente de la demande dépassé.
5 24 ms 23 ms 23 ms 114.12.6.109.rev.sfr.net [109.6.12.114]
6 * 140 ms 138 ms 222.220.96.84.rev.sfr.net [84.96.220.222]
7 20 ms 20 ms 20 ms 150.61.6.109.rev.sfr.net [109.6.61.150]
8 30 ms 23 ms 23 ms 154.61.6.109.rev.sfr.net [109.6.61.154]
9 * 41 ms * th2-5-6k.fr.eu [94.23.122.213]
10 20 ms 20 ms 21 ms gsw-g1-a9.fr.eu [213.186.32.210]
11 24 ms 24 ms 24 ms rbx-g2-a9.fr.eu [91.121.215.151]
12 24 ms * 26 ms rbx-1-6k.fr.eu [91.121.131.13]
13 24 ms 24 ms 24 ms rbx-30-m1.fr.eu [213.251.191.85]
14 24 ms 24 ms 24 ms ks285xx.kimsufi.com [91.121.96.xx]
et le wget
63% [=====================================================> ] 433 156 696 11,2M/s eta 22s ^
comme on peut le voir il semblait bien parti
mais la la route est revenu normal et les même problème survienne
40% [=================================> ] 275 933 384 4,71M/s eta 90s
jerem
-
encore moi...
la, je ne comprends plus rien de chez plus rien !
je viens de tester avec une ip fail over de mon serveur, donc ip qui es sur le même serveur on s'entend, et la j'ai le débit max ! jy comprend rien !:
traceroute de l'ip fail over
traceroute to 46.105.xx.xxx (46.105.xx.xxx), 30 hops max, 60 byte packets
1 * * *
2 106.159.64.86.rev.sfr.net (86.64.159.106) 22.739 ms 22.819 ms 22.846 ms
3 105.159.64.86.rev.sfr.net (86.64.159.105) 20.323 ms 20.378 ms *
4 154.61.6.109.rev.sfr.net (109.6.61.154) 22.093 ms 22.088 ms 22.137 ms
5 th2-5-6k.fr.eu (94.23.122.213) 20.869 ms * *
6 th2-g1-a9.fr.eu (213.186.32.202) 21.097 ms 21.033 ms 21.049 ms
7 rbx-g1-a9.fr.eu (91.121.131.209) 24.829 ms 24.869 ms 25.185 ms
8 * * *
9 rbx-30-m1.fr.eu (213.251.191.85) 24.744 ms 25.110 ms 25.219 ms
10 46-105-xx-xxx.kimsufi.com (46.105.xx.xxx) 24.666 ms 24.664 ms 24.652 ms
le traceroute dans l'autre sens en ayant modifier iptables pour sortir via l'ip fail over
traceroute to 93.31.xxx.xx (93.31.xxx.xx), 30 hops max, 60 byte packets
1 rbx-30-m1.fr.eu (91.121.96.253) 0.804 ms 0.857 ms 1.028 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.363 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.10) 0.949 ms 1.200 ms 1.195 ms
4 gsw-g1-a9.fr.eu (91.121.215.150) 4.552 ms 4.453 ms 4.514 ms
5 * * *
6 te4-1.th21-co-3.n9uf.net (86.66.127.117) 11.320 ms 11.080 ms 9.640 ms
7 229.220.96.84.rev.sfr.net (84.96.220.229) 5.449 ms 5.424 ms 5.393 ms
8 213.122.3.109.rev.sfr.net (109.3.122.213) 5.380 ms 5.407 ms 5.373 ms
9 210.122.3.109.rev.sfr.net (109.3.122.210) 13.656 ms 13.639 ms 10.336 ms
10 113.12.6.109.rev.sfr.net (109.6.12.113) 5.491 ms 5.527 ms 5.669 ms
11 106.159.64.86.rev.sfr.net (86.64.159.106) 6.490 ms 5.833 ms 5.805 ms
12 1.135.31.93.rev.sfr.net (93.31.135.1) 25.865 ms 25.864 ms 24.943 ms
13 xx.xxx.31.93.rev.sfr.net (93.31.xxx.xx) 24.652 ms 24.487 ms 24.616 ms
voilà, a toutes fins utile ...
-
J'ai un peu de mal a comprendre...
Le ping est identique mais le traceroute SFR => IP principale passe par beaucoup plus de routeurs que le traceroute SFR => IP fail over.
Je me dit de plus en plus que le fautif est chez SFR et non chez Axione...
-
Peut-être une saturation du peering dans un sens entre OVH et SFR. La weathermap OVH ne donne malheureusement pas l'info correcte sur l'état du lien (volontairement ou non) :
http://weathermap.ovh.net/paris (http://weathermap.ovh.net/paris)
Il me semble que la weathermap Paris n'est plus maintenue. Il faut regarder sur "Backbone". Tous les liens y sont, et sont à jour.
Aloïs
-
Si ca peut aider de ma connection fibre SFR toulouse je suis au max :
wget http://ipv4.proof.ovh.net/files/10Gb.dat (http://ipv4.proof.ovh.net/files/10Gb.dat)
--12:35:20-- http://ipv4.proof.ovh.net/files/10Gb.dat (http://ipv4.proof.ovh.net/files/10Gb.dat)
=> `10Gb.dat'
Resolving ipv4.proof.ovh.net... done.
Connecting to ipv4.proof.ovh.net[188.165.12.106]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,250,000,000 [application/octet-stream]
53% [==================> ] 672,215,770 33.83M/s ETA 00:16
-
J'ai déplacé les posts qui parlait d'une limitation de débit en IPv6, après analyse du à la neufbox ici : Limitation de débit NeufBox IPv6 (https://lafibre.info/ipv6/limitation-de-debit-neufbox-ipv6/).
A noter que SFR a prévu de faire un IPv6 natif bientôt avec un PPP IPv4 et un PPP IPv6.
-
petit changement de route
vers mon dédier
traceroute to 91.121.xx.xx (91.121.xx.xx), 30 hops max, 60 byte packets
1 * * *
2 34.177.64.86.rev.sfr.net (86.64.177.34) 46.612 ms 46.711 ms 46.743 ms
3 33.177.64.86.rev.sfr.net (86.64.177.33) 19.761 ms 19.806 ms 19.865 ms
4 198.61.6.109.rev.sfr.net (109.6.61.198) 20.530 ms 194.61.6.109.rev.sfr.net
(109.6.61.194) 20.586 ms 20.569 ms
5 th2-5-6k.fr.eu (94.23.122.213) 211.347 ms * *
6 gsw-g1-a9.fr.eu (213.186.32.210) 20.636 ms 20.768 ms 20.736 ms
7 rbx-g2-a9.fr.eu (91.121.131.213) 24.574 ms rbx-g2-a9.fr.eu (91.121.215.151)
24.566 ms 24.210 ms
8 rbx-1-6k.fr.eu (91.121.131.13) 23.860 ms * *
9 rbx-30-m1.fr.eu (213.251.191.85) 24.361 ms 23.846 ms 24.065 ms
10 ks285xx.kimsufi.com (91.121.xx.xx) 23.697 ms 23.739 ms 23.737 ms
dans l'autre sens
traceroute to 93.31.xxx.xx (93.31.xxx.xx), 30 hops max, 60 byte packets
1 rbx-30-m1.fr.eu (91.121.96.253) 0.775 ms 0.841 ms 0.971 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.385 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.10) 0.894 ms 1.129 ms 1.129 ms
4 gsw-g1-a9.fr.eu (91.121.131.214) 4.562 ms 4.813 ms gsw-g1-a9.fr.eu (91.121
.215.150) 4.561 ms
5 * * *
6 te4-1.th21-co-3.n9uf.net (86.66.127.117) 15.437 ms 15.141 ms 13.387 ms
7 193.61.6.109.rev.sfr.net (109.6.61.193) 4.488 ms 4.516 ms 4.556 ms
8 162.66.0.109.rev.sfr.net (109.0.66.162) 5.988 ms 6.332 ms 5.687 ms
9 * * 1.135.31.93.rev.sfr.net (93.31.135.1) 24.366 ms
10 xx.xx.31.93.rev.sfr.net (93.31.xxx.xx) 23.723 ms 23.671 ms 23.714 ms
le wget reste au max
100%[======================================>] 678 526 976 11,2M/s ds 58s
vivien ou quelqu'un j'ai fais des captures dites moi si elle vous interresse
si il pouvait garder cette route ...
jerem
edit de 1h37
route revenu normal et
100%[======================================>] 678 526 976 5,85M/s ds 82s
je suis découragé
jerem
-
jerem, tu nous refais un traceroute dans les deux sens quand cela pose problème ?
-
donc la ça pose problème vu que c'est la route normal
voici le traceroute
de ma fibre a mon ks
traceroute to 91.121.xx.xx (91.121.xx.xx), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 105.159.64.86.rev.sfr.net (86.64.159.105) 19.391 ms 19.407 ms 19.410 ms
4 154.61.6.109.rev.sfr.net (109.6.61.154) 30.062 ms 30.100 ms 30.109 ms
5 th2-5-6k.fr.eu (94.23.122.213) 52.765 ms * *
6 gsw-g1-a9.fr.eu (213.186.32.210) 21.119 ms 21.583 ms 21.594 ms
7 rbx-g2-a9.fr.eu (91.121.131.213) 25.024 ms rbx-g2-a9.fr.eu (91.121.215.151)
26.150 ms rbx-g2-a9.fr.eu (91.121.131.213) 25.219 ms
8 rbx-1-6k.fr.eu (91.121.131.13) 24.561 ms * *
9 rbx-30-m1.fr.eu (213.251.191.85) 24.637 ms 24.599 ms 24.615 ms
10 ks285xx.kimsufi.com (91.121.xx.xx) 24.542 ms 24.533 ms 24.540 ms
de mon ks a ma fibre
traceroute to 93.31.xxx.x (93.31.xxx.xx), 30 hops max, 60 byte packets
1 rbx-30-m1.fr.eu (91.121.96.253) 0.894 ms 1.101 ms 1.224 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.412 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.10) 0.773 ms 1.026 ms 1.437 ms
4 gsw-g1-a9.fr.eu (91.121.131.214) 4.628 ms gsw-g1-a9.fr.eu (91.121.215.150)
5.780 ms gsw-g1-a9.fr.eu (91.121.131.214) 5.780 ms
5 * * *
6 te4-1.th21-co-3.n9uf.net (86.66.127.117) 15.808 ms 15.491 ms 13.717 ms
7 229.220.96.84.rev.sfr.net (84.96.220.229) 5.430 ms 5.433 ms 5.397 ms
8 213.122.3.109.rev.sfr.net (109.3.122.213) 5.348 ms 5.344 ms 5.347 ms
9 210.122.3.109.rev.sfr.net (109.3.122.210) 10.387 ms 10.364 ms 8.552 ms
10 113.12.6.109.rev.sfr.net (109.6.12.113) 5.407 ms 5.392 ms 5.372 ms
11 106.159.64.86.rev.sfr.net (86.64.159.106) 6.815 ms 5.930 ms 6.203 ms
12 * * 1.135.31.93.rev.sfr.net (93.31.135.1) 25.230 ms
13 xx.xxx.31.93.rev.sfr.net (93.31.xxx.xx) 24.528 ms 24.520 ms 24.508 ms
le traceroute habituel
un wget a 05h05
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 678526976 (647M) [application/x-iso9660-image]
Sauvegarde en : «/dev/null»
7% [=> ] 48 476 896 7,13M/s eta 83s ^
14% [====> ] 99 090 288 5,24M/s eta 83s ^
17% [=====> ] 118 677 384 5,51M/s eta 83s ^
19% [======> ] 129 860 288 2,16M/s eta 93s ^
22% [=======> ] 155 717 224 3,91M/s eta 96s ^
24% [========> ] 169 066 336 3,42M/s eta 99s ^
28% [==========> ] 196 552 272 3,92M/s eta 98s ^
32% [===========> ] 217 850 904 4,88M/s eta 93s ^
38% [=============> ] 259 069 672 5,16M/s eta 85s ^
41% [===============> ] 284 894 752 4,46M/s eta 79s ^
46% [=================> ] 315 987 656 3,55M/s eta 76s ^
57% [=====================> ] 387 216 224 6,70M/s eta 63s ^
61% [=======================> ] 420 659 232 2,68M/s eta 56s ^
67% [=========================> ] 455 796 400 3,74M/s eta 50s ^
74% [===========================> ] 503 122 832 4,47M/s eta 39s ^
77% [=============================> ] 525 016 592 5,68M/s eta 35s ^
78% [=============================> ] 533 278 880 6,23M/s eta 31s ^
un petit wget vers testdebit.info
56% [=====================> ] 564 437 088 11,0M/s eta 40s ^
...
jerem
-
salut,
alors aujourd'hui j'ai fais un nouveau test chez quelqu'un qui a la fibre ip 109.7.xxx.xx
même sur mon ip 91.121.96.xx je suis au max !
la je commence a me poser certaines questions je vais tester la fibre sur un autre équipements je commence a douter de mon serveur @home ...
edit 21h48
bon, serveur@home hors de cause, sur mon portable c'est la même histoire, j'ai même désactiver le firewall du serveur@ovh pour voir, mais hidem ...
voila pour les test complèmentaires
jerem
-
Salut,
attention, sur kimsufi, la BP est non garantie / best effort / etc ...
Si tous tes voisins de baies ont une utilisation normale, çà passe. si il y a des seedbox, serveur utilisant bcp de BP and co, beh tu as ce qu'il reste comme BP ...
-
bonjour,
j'up le sujet parce que la route a changer, et le soucis est résolu, du moins pour le moment ...
route vers mon ks depuis ma fibre :
traceroute to 91.121.96.x (91.121.96.xx), 30 hops max, 60 byte packets
1 * * *
2 106.159.64.86.rev.sfr.net (86.64.159.106) 21.171 ms 21.246 ms 21.283 ms
3 105.159.64.86.rev.sfr.net (86.64.159.105) 19.656 ms 19.685 ms 19.702 ms
4 th2-5-6k.fr.eu (94.23.122.213) 20.669 ms * *
5 gsw-g1-a9.fr.eu (213.186.32.210) 21.319 ms 21.359 ms 21.207 ms
6 rbx-g2-a9.fr.eu (91.121.131.213) 24.719 ms rbx-g2-a9.fr.eu (91.121.215.151) 24.786 ms rbx-g2-a9.fr.eu (91.121.131.213)
25.167 ms
7 rbx-1-6k.fr.eu (91.121.131.13) 24.606 ms * *
8 rbx-30-m1.fr.eu (213.251.191.85) 25.004 ms 25.034 ms 25.181 ms
9 ksxxxxx.kimsufi.com (91.121.xx.xx) 24.316 ms 24.280 ms 24.870 ms
il ny a plus le 109.6.61.154
dans l'autre sens pour avoir un historique enfin une trace
traceroute to ip.de.ma.fibre (93.31.xxx.xx), 30 hops max, 60 byte packet
s
1 rbx-30-m1.fr.eu (91.121.96.253) 0.650 ms 0.689 ms 0.803 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.362 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.10) 0.917 ms 1.143 ms 1.129 ms
4 gsw-g1-a9.fr.eu (91.121.131.214) 4.808 ms 4.777 ms 4.470 ms
5 th2-5-6k.fr.eu (213.186.32.209) 4.761 ms * *
6 * * *
7 242.29.3.109.rev.sfr.net (109.3.29.242) 8.465 ms 8.435 ms 8.422 ms
8 54.224.65.86.rev.sfr.net (86.65.224.54) 30.228 ms 30.201 ms 27.718 ms
9 222.29.3.109.rev.sfr.net (109.3.29.222) 13.811 ms 13.794 ms 13.773 ms
10 73.224.65.86.rev.sfr.net (86.65.224.73) 5.348 ms 5.329 ms 5.309 ms
11 106.159.64.86.rev.sfr.net (86.64.159.106) 8.295 ms 8.276 ms 8.305 ms
12 1.135.31.93.rev.sfr.net (93.31.135.1) 27.345 ms 27.375 ms 27.387 ms
13 ip.de.ma.fibre.rev.sfr.net (ip.de.ma.fibre) 24.344 ms 24.301 ms 24.264 ms
-
Il faudrait une personne de SFR ou Axione prête à investiguer sur cet incident (pertes de paquets)...