La Fibre
Télécom => Réseau => 
Comment tester son débit ? => Discussion démarrée par: rke29 le 04 juin 2018 à 23:33:16
-
Serveur de Massy hs et celui de Rennes? Depuis quelques jours je ne les vois plus.
-
Je confirme, depuis au moins 2 jours impossible de trouver Massy dans la liste des serveurs. :(
-
C'est tous les serveurs de lafibre.info qui sont plus sur speedtest
-
Tous les serveurs speedtest LaFibre.info, TestDebit.info et iperf.fr hébergés sur le réseau Bouygues (AS 5410) ont disparu si l'on compare les disparitions avec la liste de serveurs présente ici : https://lafibre.info/tester-son-debit/speedtest-net.
De plus, le serveur speedtest de Bouygues Télécom à Paris à également disparu dans la nuit du 31/05/2018 au 01/06/2018.
-
Ookla ne souhaites plus avoir de serveur de test de débit en anycast (anycast = réseau qui détermine le serveur le plus proche)
=> https://fr.wikipedia.org/wiki/Anycast
On va probablement passer en unicast (si vous sélectionnez le serveur de Lyon, mais que c'est Paris le plus proche, le test en unicast le test se fera quand même sur Lyon alors qu'en anycast peu importe la ville, c'était le serveur le plus proche qui répondait).
-
Ce qui était quand même un peu douteux comme pratique...
-
+1, un serveur speedtest anycasté c'est bien en interne, pas pour un site comme speedtest.
-
On peut définir deux type de test :
- Les tests "mire proche" avec un serveur au plus prés des clients
- Les tests "mires lointaine" avec un serveur le plus représentatif d'un usage réel en utilisant les transitaire
Pour l'usage "mire proche" l'anycast n'est pas déconnant, pour deux raisons :
- les tests de débit sur un navigateur web localisent généralement grâce à l'IP et cette information est dans un nombre de cas non négligeable complétement erronée.
- quand il localise bien, le serveur le plus proche géographiquement n'est pas forcèment le plus proche point de vue réseau. Avec une architecture où les PE sont connecté au P en direct sans passer par les autres PE, c'est très fréquent.
-
Pour information, voici le trafic généré par les tests SpeedTest, au niveau du serveur :
On voit la baisse quand la grosse partie des SpeedTests ont été supprimés de la carte
(https://lafibre.info/images/stats/201806_trafic_servuer_speedtest_paris_1.png)
Sur cette capture on voit bien que le trafci baisse la nuit pas dans des proportion folles :
(https://lafibre.info/images/stats/201806_trafic_servuer_speedtest_paris_2.png)
Sur cette image, le trafic en moyenné sur la journée (1 point = trafic moyen sur 24h)
(https://lafibre.info/images/stats/201806_trafic_servuer_speedtest_paris_3.png)
Le week-end du 3 mars, j'ai regardé l'évolution du pourcentage de trafic IPv6 entre K-Net et Bouygues Telecom et j'ai eu une bonne surprise :
(https://lafibre.info/images/k-net/201803_trafic_bougues_k-net.png)
35% du trafic échangé entre les deux opérateurs qui est en IPv6, c'est énorme, sachant que plusieurs délégation de service public FTTH ne sont pas compatible IPv6 et donc que tous les clients K-Net ne sont pas en IPv6.
Je me suis demandé si cela signifiait que Bouygues Telecom avait massivement activé IPv6 sur les mobiles android ou si c'était IPv6 qui était massivement activé sur les Bbox ADSL.
A la réflexion, je pense que c'est trop beau pour être vrai. J'ai bien peur que ce soit un client a un script qui tourne (par exemple avec du speedtest-cli. Bouygues Telecom hébergeant de nombreux serveur SpeedTest, cela pourrait être par exemple un script qui utilise speedtest-cli, un client non officiel et opensource de SpeedTest pour la ligne de commande Linux. Pour une raison que j'ignore, je vois beaucoup de trafic speedtest-cli sur les serveurs SpeedTest que j'administre (trafic permanent de 600 Mb/s 24h/24 365 jours/an avec un user-agent qui contient speedtest-cli - le trafic speedtest-cli est le même le jour et la nuit contrairement au trafic du vrai client SpeedTest qui est faible la nuit).
(https://lafibre.info/images/k-net/201803_trafic_bougues_k-net_ipv4.png)(https://lafibre.info/images/k-net/201803_trafic_bougues_k-net_ipv6.png)
(source : https://as24904.kwaoo.net/as-stats/top.php)
-
Ce qui était quand même un peu douteux comme pratique...
+1. j'eu pensé que cela fût le cas dès le départ même.....
-
underground78, willemijns et Hugues serait-il possible de me détailler point de vue sur un test de débit anycast, cela m'intéresse.
Chez nPerf c'est affiché directement :
(https://lafibre.info/images/barometre/201806_nperf_mire_anycast.png)
-
on teste sur un trio localisation/opérateur/capacité max (CPU/network).
l'absence de certitude sur l'un de des éléments (surtout le premier qui est facilement communiquable) fait sauter une forme de garantie morale sur sa qualité.
si speedtest.net dit BoT Massy, moi je veux que ca sorte pas de... Massy.
sinon le second etant tracable plus ou moins via traceroute/traceroutetcp et le troisième bah on fait plus ou moins confiance car peu de service affichement clairement le dimensionnement de leur serveur de speedtest.
-
Déjà que taguer des faux serveurs dans des villes où on n’est pas je trouve ça limite. Si en plus le serveur n’est pas unicast, autant taper chez Online quoi.
-
underground78, willemijns et Hugues serait-il possible de me détailler point de vue sur un test de débit anycast, cela m'intéresse.
Moi ça ne me dérange pas SI c'est indiqué à la place d'avoir un nom de ville. Par contre si on te donne l'impression que ça va vers un serveur donné alors que ce n'est pas vrai alors je trouve que c'est trompeur (et c'est le cas également si le nom de la ville ne correspond pas à la localisation réelle du serveur dans le cas d'un serveur unicast).
-
+1 :)
-
Voila, on va déjà faire repartir ces 4 serveurs, où j'ai mis à jour les DNS avec des IP unicast à la place des IP anycast :
Massy TestDebit.info (massy.testdebit.info) :
IP unicast : 89.84.1.202 / 2001:860:de01:1102::2
Douai LaFibre.info (douai.lafibre.info) :
IP unicast : 89.84.1.236 / 2001:860:de12:200::4
Lyon LaFibre.info (lyon.lafibre.info) :
IP unicast : 89.84.1.244 / 2001:860:de11:100::4
Marseille TestDebit.info (marseille.testdebit.info) :
IP unicast : 89.84.1.252 / 2001:860:de14:200::4
Ils seront sur la carte après validation de Ookla.
-
ca fait tache quand meme que http://bouyguestelecom.speedtest.net/ n'affiche aucun serveur bytel :)
(cette url est utilisée dans l'interface d'admin de la bbox par exemple).
chez moi (Paris) ca envoi sur stella-telecom.fr par défaut :)
-
Lui aussi il va être réactivé.
Par contre, lui, il sera en anycast.
Paris Bouygues Telecom (www.testdebit.bbox.fr) :
IP anycast : 89.84.1.230 / 2001:860:deff:1002::2
-
Cette nuit les 5 serveurs suivants ont été ré-activés :
- Massy TestDebit.info (massy.testdebit.info)
- Douai LaFibre.info (douai.lafibre.info)
- Lyon LaFibre.info (lyon.lafibre.info)
- Marseille TestDebit.info (marseille.testdebit.info)
- Paris Bouygues Telecom (www.testdebit.bbox.fr)
Les 4 premiers sont en unicast et le dernier en anycast.
Par chance cela arrive en même temps qu'un peering Orange / Bouygues Telecom sur Lyon de 100 Gb/s.
Normalement, les clients Orange sur le sud-est peuvent joindre le serveur de Lyon sans passer par Paris, en IPv4 comme en IPv6.
En anycast, vous pouvez voir quel serveur vous répond en regardant la localisation du serveur sur la page
- http://ipv4.1.testdebit.info/
- http://ipv6.1.testdebit.info/
Vous pouvez avoir :
- Serveur hébergé sur Paris (Île-de-France - France)
- Serveur hébergé sur Lyon (Auvergne-Rhône-Alpes - France)
- Serveur hébergé sur Aix-Marseille (PACA - France)
- Serveur hébergé sur Lille (Hauts-de-France - France)
A noter que le serveur de Vitry sur Online DC3 avait été désactivé en même temps et je n'ai pas pensé à demander sa réactivation.
Il sera de retour dans quelques jours.
-
- Paris Bouygues Telecom (www.testdebit.bbox.fr)
Pourquoi le nommer "Paris" s'il est anycast ?
-
En fait le choix de l’appellation n'est pas laissé à l’utilisateur.
Dans le passé c'était le serveur d'Aubervilliers, mais Ookla a du considérer que Aubervilliers était trop près de Paris et brusquement sans m'avertir il est passé sur Paris.
nPerf est plus flexible et le terme anycast est utilisé.
-
- Paris Bouygues Telecom (www.testdebit.bbox.fr)
ca donne un 403 Forbidden
~$ dig www.testdebit.bbox.fr aaaa +short
2001:860:deff:1002::2
~$ dig www.testdebit.bbox.fr a +short
89.84.1.230
-
j'ai indiqué le nom de domaine utilisé par SpeedTest pour joindre le servuer, mais ce n'est pas utilisable en http depuis un navigateur.
Voici l'outil pour vérifier si un serveur ookla fonctionne bien : https://www.ookla.com/host-tester
Les informations à remplir pour le serveur de Paris :
- Host : www.testdebit.bbox.fr:8080
- Legacy http url : http://www.testdebit.bbox.fr/speedtest/upload.php
- Legacy http url #2 : http://www.testdebit.bbox.fr/speedtest/upload.php
Aujourd'hui tout le trafic speedtest se fait sur le port 8080, sauf speedtest-cli un outil non officiel qui utilise les serveurs legacy sur le port 80.
L'erreur https est normal: il n'y a pas de https possible pour une utilisation sur https://www.speedtest.net/fr
(il est par contre possible de mettre du https sur un test sur mesure payant)
-
j'ai indiqué le nom de domaine utilisé par SpeedTest pour joindre le servuer, mais ce n'est pas utilisable en http depuis un navigateur.
certes mais 'www' en général ca indique la présence d'un serveur web derrière ;)
c'est juste curieux comme nommage dns.
-
certes mais 'www' en général ca indique la présence d'un serveur web derrière ;)
c'est juste curieux comme nommage dns.
C'est historique. Il y avait un test de débit (peu performant) hérité de Club-internet sur cette url il y a longtemps...
-
Massy TestDebit.info (massy.testdebit.info) :
IP unicast : 89.84.1.202 / 2001:860:de01:1102::2
Douai LaFibre.info (douai.lafibre.info) :
IP unicast : 89.84.1.236 / 2001:860:de12:200::4
Lyon LaFibre.info (lyon.lafibre.info) :
IP unicast : 89.84.1.244 / 2001:860:de11:100::4
Marseille TestDebit.info (marseille.testdebit.info) :
IP unicast : 89.84.1.252 / 2001:860:de14:200::4
4 serveurs avec des IP très proches, mais localisés dans 4 villes différentes? Comment est-ce possible?
Est-ce que Bouygtel utilise en interne des tables de routages très fines, dans son IGP (BGP ou OSPF...)?
Ou alors est-ce que ce sont des techno d'encapsulation type VxLAN ou autre qui permettent ça au niveau "serveur"?
Est-ce que cette différence de localisation se voir aussi dans les interco avec les autres interco? Je pense que non, les routes sont beaucoup trop fines...
Pour finir, est-ce qu'il faut comprendre que ces serveurs de test sont compatible avec plusieurs tests de débit, et donc embarquent plusieurs softs selon le type de test? Nperf, Speedtest, etc...
Leon.
-
En IPv4, Bouygues Telecom n'a malheureusement pas régionalisé ses plages IP.
Tu as donc souvent des abonnés éloignés sur un même /24. Par exemple à l'époque où les IP étaient portées par les DSLAM, les attributions étaient réalisé par /25 donc tu peut avoir un abonné à nice et un à Lille sur un même /24.
Ici les plages pour les serveurs sont plus petites : ce sont des plages /29 pour chaque serveur. En effet SpeedTest et nPerf utilisent les mêmes ports.
nPerf utilise le port 80 en legacy via Apache, 443 en chiffré pour les tests en standard, 8080 en clair (aujourd'hui inutilisé) et 8443 en chiffré (utilisé uniquement si le port 443 est bloqué). Les ports 443, 8080 et 8443 sont écoutés par un logiciel propriétaire.
SpeedTest utilise le port 80 en legacy via Apache et 8080 pour les tests en standard. Le port 8080 est écouté en TCP et en UDP par un logiciel propriétaire Ookla.
De plus nPerf va probablement faire évoluer son logiciel serveur pour écouter sur le port 80.
Bref, il est impossible de faire cohabiter sur une même IP nPerf et SpeedTest (une alternative est possible en demandant à nPerf d'utiliser d'autres ports, mais c'est moins représentatif d'un usage réel)
Pour les IP anycast, c'est des plages /30 (une IP pour le serveur, une IP réseau, une IP routeur, une IP broadcast) car sur Paris, car le trafic était trop important pour utiliser un seul serveur (uniquement SpeedTest pouvait faire un trafic moyen de 2 Gb/s en heure de pointe sur le serveur): j'ai donc 3 serveurs avec chacun une plage anycast en 10 Gb/s de réseau. En province, un même serveur reçois les 3 plages anycast (en réalité 3 plages anycast IPv4 + 3 plages anycast IPv6 en plus des plages unicast IPv4 et IPv6)
Je n'ai pas osé utiliser des plages /31 ou /32 vu mon utilisation un peu spécifique avec de nombreuses plages sur le même OS et qu'il ne m'était pas possible de tester la chose simplement. Il y a des choses qui fonctionnent en théorie mais pas en pratique. Certains équipements refusent par exemple que mon serveur utilise une IPv6 ::0 alors que c'est théoriquement possible et cela fonctionne chez certains hébergeurs. C'est pour ça que mes IPv6 sont en ::2 (::1 c'est le routeur)
Je n'utilise pas de virtualisation car mon expérience montre que cela peut dégrader les performances et ces serveurs sont là pour permettre de bonnes performances tout en restant représentatif (je me refuse à tuner la pile TCP pour être plus agressive que la réalité, il y a d'autres serveurs qui le font)
Coté IPv6, vous pouvez voir que ce sont des plages compétemment distinctes, vu que les IPv6 sont régionalisées par POP (chaque couple de bsr01 / bsr02, le routeurs de collecte des flux clients, a ses propres plages IPv6).
-
Merci pour toutes ces explications détaillées, Vivien. C'est très intéressant.
En IPv4, Bouygues Telecom n'a malheureusement pas régionalisé ses plages IP.
C'est vraiment dommage. Tu connais la raison de ce choix initial de Bouygtel?
Ca veut dire que pour les interconnexions de peering/transit, même pour les interconnexions régionales, Bouygtel annonce systématiquement toutes ses IPv4 à son peer/transitaire?
Si oui, est-ce qu'on n'arrive pas à des situations tordues si le peer utilise une politique de routage différente du "hot potato"?
Bon, à l'échèle de la France, ça n'est pas forcèment dramatique, mais quand même, c'est dommage.
Leon.
-
Il me semble que c’est en cours de changement, je reçois des belles plages régionalisées à Lyon.
J’ajouterais quand même que régionaliser ses IP, ce n’est pas un pré requis pour faire du peering régional. Il suffit de router au plus proche.
-
Le problème d'un réseau, c'est qu'il y a un historique et qu'il y a 15 ans, il n'y avait pas de régionalisation possible.
Aujourd'hui Marseille est un point d'échange qui est en train d'exploser, mais c'est récent.
-
J’ajouterais quand même que régionaliser ses IP, ce n’est pas un pré requis pour faire du peering régional. Il suffit de router au plus proche.
Oui, totalement d'accord, c'est ce que j'ai appelé le routage "hot potato". Mais il faut que les 2 acteurs qui peerent entre plusieurs endroits appliquent tous les 2 cette politique "hot potato" pour que ça fonctionne si un des 2 acteur n'a pas régionalisé ses IP.
Le problème d'un réseau, c'est qu'il y a un historique et qu'il y a 15 ans, il n'y avait pas de régionalisation possible.
Je comprends bien...
Mais pour une entreprise dont le réseau est le coeur de métier, n'est-il vraiment pas possible de remettre en cause les règles imposées au début? Les technologies et les contraintes évoluent. Avec du matériel et des logiciels modernes, il doit être possible de gérer une telle migration en douceur, non? Mais bon, si l'entreprise n'y voit pas d'intérêt...
Faut-il comprendre que côté Bouygtel, tout est encore centralisé à Paris? Tous les services (voix, télévision) sont construits à Paris? La VoD est produite depuis Paris uniquement? Ou alors les services (voix, télévision) passent par des IPv4 privées côté abonnés totalement différentes, et régionalisées elles?
Leon.
-
donc vu qu'il y a maintenant une interco Orange - Bytel a Lyon:
- un abonné Orange de Lyon qui fait un speedtest sur lyon.lafibre.info va pas remonter en IDF ? donc bytel annonce son /29 a Orange en privé ?
- un abonné Orange de Paris qui fait un speedtest sur lyon.lafibre.info passe par ou ? Orange propage t'il le /29 de bytel a tout son réseau ou non et ca passe chez Bytel dès Paris puis ca fait Paris->Lyon par le réseau de Bytel et pas celui d'Orange ?
-
donc bytel annonce son /29 a Orange en privé ?
Pas besoin, cf hot potato
-
- un abonné Orange de Paris qui fait un speedtest sur lyon.lafibre.info passe par ou ? Orange propage t'il le /29 de bytel a tout son réseau ou non et ca passe chez Bytel dès Paris puis ca fait Paris->Lyon par le réseau de Bytel et pas celui d'Orange ?
Généralement, me semble-t-il, on cherche à faire sortir son trafic au plus tôt/plus proche.
-
Rien à voir, mais je viens de faire un tracert sur Massy et je vois que je passe par Strasbourg pour atteindre Paris... ::) (je suis pile entre les 2)
1 <1 ms <1 ms <1 ms livebox.home [192.168.1.1]
2 1 ms 1 ms <1 ms 80.10.235.221
3 3 ms 3 ms 3 ms ae109-0.ncncy102.Vandoeuvre-les-nanc.francetelecom.net [193.253.90.254]
4 9 ms 8 ms 9 ms ae43-0.nrstr202.Strasbourg.francetelecom.net [193.252.160.146]
5 22 ms 17 ms 17 ms ae45-0.nridf302.Paris13eArrondissement.francetelecom.net [193.251.126.22]
6 17 ms 17 ms 20 ms ae44-0.noidf002.Aubervilliers.francetelecom.net [193.252.99.106]
7 18 ms 17 ms 17 ms la105.rpt01-ix2.net.bbox.fr [62.34.0.209]
8 26 ms 25 ms 25 ms be12.cbr01-ntr.net.bbox.fr [212.194.171.87]
9 24 ms 24 ms 24 ms la20.bsr01-ntr.net.bbox.fr [212.194.171.23]
10 24 ms 24 ms 24 ms 89.89.101.141
11 24 ms 24 ms 24 ms 89.84.1.202
-
et pour atteindre Lyon ca passe par ou ?
-
::)
1 <1 ms <1 ms <1 ms livebox.home [192.168.1.1]
2 2 ms <1 ms 1 ms 80.10.235.221
3 3 ms 3 ms 3 ms ae109-0.ncncy102.Vandoeuvre-les-nanc.francetelecom.net [193.253.90.254]
4 9 ms 9 ms 8 ms ae43-0.nrstr202.Strasbourg.francetelecom.net [193.252.160.146]
5 17 ms 17 ms 17 ms ae45-0.nridf302.Paris13eArrondissement.francetelecom.net [193.251.126.22]
6 21 ms 17 ms 17 ms ae44-0.noidf002.Aubervilliers.francetelecom.net [193.252.99.106]
7 17 ms 17 ms 17 ms la105.rpt01-ix2.net.bbox.fr [62.34.0.209]
8 26 ms 25 ms 25 ms be12.cbr01-ntr.net.bbox.fr [212.194.171.87]
9 25 ms 25 ms 25 ms be1.cbr01-cro.net.bbox.fr [212.194.171.0]
10 24 ms 31 ms 31 ms be5.cbr01-lyo.net.bbox.fr [212.194.171.140]
11 24 ms 24 ms 24 ms la44.bsr01-lyo.net.bbox.fr [212.194.171.149]
12 24 ms 24 ms 24 ms 212.194.172.129
13 24 ms 24 ms 24 ms 89.84.1.244
-
Pas choquant, tout ton trafic sort par Strasbourg.
-
haha.
Orange n'a peut-être pas de lien(s) Strasbourg <-> Lyon
ou le nouveau peering a Lyon n'est pas encore totalement en place .
-
Oui c'est pas très grave, mais bar > strasbourg > paris > lyon, c'est un peu idiot je trouve :/
-
donc vu qu'il y a maintenant une interco Orange - Bytel a Lyon:
- un abonné Orange de Lyon qui fait un speedtest sur lyon.lafibre.info va pas remonter en IDF ? donc bytel annonce son /29 a Orange en privé ?
- un abonné Orange de Paris qui fait un speedtest sur lyon.lafibre.info passe par ou ? Orange propage t'il le /29 de bytel a tout son réseau ou non et ca passe chez Bytel dès Paris puis ca fait Paris->Lyon par le réseau de Bytel et pas celui d'Orange ?
La première interconnexion test, via Lyon-Ix était réalisée comme suit :
- Orange annonce les préfixes des clients Orange du sud-est (y compris Hopus Lyon qui annonce sur Lyon les préfixes de tout Hopus. Cela avait fait pas mal parler ici)
- Bouygues Telecom annonçait toutes les plages IP
Pour le trafic poussé sur l'interconnexion :
- Orange envoyait le trafic des clients du sud-est sur le peering de Lyon (c'était donc à Bouygues d'acheminer le trafic pour les clients Bbox sur Paris)
- Bouygues Telecom avait priorisé le peering Orange, donc toute la France sortait par Lyon pour les IP Orange du sud-est y compris Hopus Paris.
J’espère que le nouveau peeing est mieux fait...
Orange annonce tout Hopus à Bouygues Telecom sur le peering de Lyon
Petit traceroute Bouygues Telecom (Bbox câble sur Paris) => Gandi (Paris)
Réseau Numericable => Collecte Bouygues Telecom sur Courbevoie (ncc-cbv.net.bbox.fr) => Lyon IX => Perring avec AS3215 sur Lyon-IX=> Hopus Lyon => Hopus Paris => Gandi
$ mtr -rwc100 gandi.net
Start: Sat Sep 26 12:08:48 2015
HOST: vivien Loss% Snt Last Avg Best Wrst StDev
1.|-- bbox.lan 0.0% 100 5.9 3.2 0.9 22.4 4.1
2.|-- 10.112.0.1 0.0% 100 10.3 11.5 7.4 57.5 6.1
3.|-- eps1rj-ge-0-1-5.100.numericable.net 0.0% 100 10.1 12.6 7.8 38.4 5.1
4.|-- ip-53.net-80-236-1.static.numericable.fr 1.0% 100 22.2 13.2 7.8 39.9 6.8
5.|-- ip-49.net-80-236-1.static.numericable.fr 0.0% 100 12.4 11.5 8.2 23.7 2.9
6.|-- lag101.350.ncc-cbv.net.bbox.fr 1.0% 100 10.8 17.0 8.6 81.2 12.4
7.|-- ? ? 100.0 100
8.|-- la10.bsr02-cbv.net.bbox.fr 66.0% 100 12.4 13.3 10.3 23.7 2.9
9.|-- be16.cbr01-cro.net.bbox.fr 0.0% 100 18.5 15.7 11.5 25.3 3.1
10.|-- be5.cbr01-lyo.net.bbox.fr 1.0% 100 26.7 24.1 18.2 38.7 4.1
11.|-- la44.bsr01-lyo.net.bbox.fr 89.0% 100 23976 23339 21638 24386 901.6
12.|-- la10.bsr02-lyo.net.bbox.fr 1.0% 100 18.6 20.8 16.2 61.3 6.1
13.|-- 193.253.13.85 0.0% 100 20.9 22.2 17.4 79.0 8.1
14.|-- 193.252.227.98 0.0% 100 20.4 22.1 17.9 44.8 4.9
15.|-- lag-pop-ly-1.th2-1.rt.hopus.net 0.0% 100 19.7 22.0 17.7 34.7 3.8
16.|-- lag-pop-th2-1.std-1.rt.hopus.net 0.0% 100 34.7 22.3 18.0 43.6 4.3
17.|-- gandi.std-1.rt.hopus.net 0.0% 100 25.2 25.5 18.2 51.6 6.4
18.|-- xe0-0-2-2-core3-d.paris.gandi.net 0.0% 100 20.0 22.3 18.3 39.6 3.8
19.|-- xe1-6-5-gdist3-d.paris.gandi.net 0.0% 100 27.1 22.7 18.3 52.3 4.7
20.|-- website.vip.gandi.net 0.0% 100 19.1 22.7 17.4 72.3 7.5
Note : 193.253.13.85 et 193.252.227.9 sont des IP appartenant à Orange AS3215
-
Salut Vivien,
Sais-tu répondre à la question que je posais un peu plus haut?
Faut-il comprendre que côté Bouygtel, tout est encore centralisé à Paris? Tous les services (voix, télévision) sont construits à Paris? La VoD est produite depuis Paris uniquement? Ou alors les services (voix, télévision) passent par des IPv4 privées côté abonnés totalement différentes, et régionalisées elles?
Leon.
-
Oui c'est pas très grave, mais bar > strasbourg > paris > lyon, c'est un peu idiot je trouve :/
T'es tu plains que pour aller aux USA il faille passer des fois par AMS ou frankfurt et non par londres ???
-
Je ne me plains pas ? J'ai juste dit que je trouve bête de faire de tels allers-retours.
-
Faut-il comprendre que côté Bouygtel, tout est encore centralisé à Paris? Tous les services (voix, télévision) sont construits à Paris? La VoD est produite depuis Paris uniquement? Ou alors les services (voix, télévision) passent par des IPv4 privées côté abonnés totalement différentes, et régionalisées elles?
Dés qu'un opérateur a plusieurs millions de clients, il devient un opérateur d'importance vitale (OIV), un opérateur qui a des activités indispensables pour la population.
La régionalisation est donc indispensable car concentrer sur un même point de nombreux clients accroît les obligation de sécurité imposé à l’opérateur, donc même financièrement, la régionalisation est pertinente.
Bouygues Telecom régionalise la plupart de ses services en province. Coté mobile cela fait des années que les appels province <=> province ne passent plus par Paris. La data mobile cela a été mis en place plus récemment. Vous avez aussi vu ici que Bouygues Telecom avait plusieurs transitaires sur Marseille, ce qui a particulièrement énervé Azie147 => NTT Marseille ByTel - Routage qui part en vrille. (https://lafibre.info/peering/ntt-marseille-bytel-routage-qui-part-en-vrille/)
Bref, les services et le transit peuvent être régionalisés, tout en ayant un historique à porter coté IPv4. Cela s'est peut être amélioré avec les changements d'IPv4 l'année dernière pour les clients ADSL (IP portée par le routeur BSR et non plus par le DSLAM)
Voici une contribution de Benoît Plessy, le responsable de l'architecture Backbones IP et peering manager : dans le rapport 2018 sur l'état d'internet en France de l'Arcep (https://lafibre.info/arcep/rapport-2018-sur-letat-dinternet-en-france/)
(https://lafibre.info/images/doc/201806_arcep_rapport_etat_internet_2018_Interco_bouygues.png)
-
J’espère que le nouveau peeing est mieux fait...
J'ai l'impression que tout le trafic vers Orange passe par Lyon maintenant...
Une Bbox Paris qui joint une Box Orage sur Paris force le passage par Lyon dans un sens.
-
je pense qu il y a un souci avec upload sur douai
(https://www.speedtest.net/result/7422153179.png) (https://www.speedtest.net/result/7422153179)
Sur lyon en upload
(https://www.speedtest.net/result/7422161751.png) (https://www.speedtest.net/result/7422161751)
Debit normal
(https://www.speedtest.net/result/7422168915.png) (https://www.speedtest.net/result/7422168915)
-
Le débit upload baisse avec la latence. La ce qui est complétement anormal c'est d'avoir une latence aussi importante vers Douais.
Pourrais-tu me faire un traceroute vers ces deux IP du serveurs :
- 2001:860:de12:200::4
- 89.84.1.236
Tu es en IPv6 donc normalement seul l'IPv6 est utilisé, mais cela peut être pertinent de comparer avec l'IPv4.
Je te ferais le reverse traceroute pour voir par ou cela passe dans l'autre sens.
-
Petite comparaison si ça peut être utile. Je suis à 90km de Nancy en direction de Douai.
(https://www.speedtest.net/result/7422994344.png)
D'ailleurs depuis mon nouvel abonnement Orange, en speedtest et en téléchargement ça télécharge à fond (~122mo/s) et ça tombe à 90/100 pour remonter lentement, retombé etc... comme si ça ne tenait pas la charge. Je surveille ça avec NetSpeedMonitor.
Je n'avais jamais eu ce "soucis" il y à encore 1 mois avec mon ancienne Fibre Jet. Quelqu'un aurait une idée ? :-\
-
Quand tu télécharge sur quel site ? (désolé mais cela a son importance)
-
Je ne regarde pas toujours mais tout ceux où j'ai pensé à regarder en fait.
Tous les serveurs de speedtest ; 1fichier.com ; uptobox etc... avec 16 connexions en parallèle. Je restais constemment à 122mo/s avec mon ancien Jet, mais le nouveau agit comme si il ne tenait pas la charge. Il n'y a eu aucun changement sur le PC entre le moment où j'ai effectué Orange > Free > Orange.
J'ai oublié de rajouter le tracert pour comparer avec DJ54 ;)
Détermination de l’itinéraire vers 89.84.1.236 avec un maximum de 30 sauts.
1 <1 ms <1 ms <1 ms livebox.home [192.168.1.1]
2 1 ms 1 ms 1 ms 80.10.235.221
3 3 ms 5 ms 3 ms ae109-0.ncncy102.Vandoeuvre-les-nanc.francetelecom.net [193.253.90.254]
4 9 ms 8 ms 9 ms ae43-0.nrstr202.Strasbourg.francetelecom.net [193.252.160.146]
5 17 ms 17 ms 17 ms ae45-0.nridf302.Paris13eArrondissement.francetelecom.net [193.251.126.22]
6 18 ms 17 ms 17 ms ae44-0.noidf002.Aubervilliers.francetelecom.net [193.252.99.106]
7 18 ms 17 ms 17 ms la105.rpt01-ix2.net.bbox.fr [62.34.0.209]
8 29 ms 29 ms 29 ms be12.cbr01-ntr.net.bbox.fr [212.194.171.87]
9 28 ms 28 ms 28 ms la28.bsr01-lil.net.bbox.fr [212.194.171.71]
10 28 ms 28 ms 28 ms la2.rpt02-th2.net.bbox.fr [89.89.100.97]
11 28 ms 28 ms 36 ms 10.131.51.54
12 28 ms 28 ms 28 ms 89.84.1.236
Itinéraire déterminé.
Détermination de l’itinéraire vers 2001:860:de12:200::4 avec un maximum de 30 sauts.
1 <1 ms 1 ms <1 ms livebox.home [2a01:cb11:46d:de00:327c:b2ff:febc:bd6]
2 1 ms <1 ms <1 ms 2a01cb08a00402100193025300760137.ipv6.abo.wanadoo.fr [2a01:cb08:a004:210:193:253:76:137]
3 15 ms 14 ms 14 ms 2a01:cfc0:200:8300:193:252:102:50
4 13 ms 13 ms 13 ms 2a01:cfc4:0:e00::5
5 * * * Délai d’attente de la demande dépassé.
6 26 ms 26 ms 26 ms 2001:860:bbe0:af::2
7 26 ms 26 ms 26 ms 2001:860:b212::3:2
8 26 ms 25 ms 25 ms 2001:860:de12:200::4
Itinéraire déterminé.
-
J'ai fait une petite capture pour montrer ce que ça fait.
Réalisé à l'instant sur Massy ; Avant ça monter à ~122mo/s et ça ne bougeait pas jusqu'à la fin.
L'upload se comporte normalement.
Ça m'intrigue je dois dire ???
https://youtu.be/JHiEZLRfTJc (https://youtu.be/JHiEZLRfTJc)
-
Reverse traceroute : le chemin n'est pas optimal car si je lit bien :
on part de Lille BSR02 pour aller sur Paris (probablement car le lien entre BSR01 et BSR02 sur Lille est temporairement HS)
De Parus on re-va sur Lille BSR01 puis on va sur Crosnes en ile de France pour aller sur Lyon joindre Orange :
$ mtr -zrwc100 83.196.93.xxx
Start: Tue Jun 26 09:30:15 2018
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS5410 89.84.1.233 0.0% 100 0.6 1.0 0.4 14.7 2.3
2. AS??? 10.131.51.53 0.0% 100 0.5 0.5 0.4 3.8 0.2
3. AS5410 la2.rpt01-th2.net.bbox.fr 65.0% 100 8292. 8339. 8262. 8415. 52.9
4. AS5410 la10.bsr02-lil.net.bbox.fr 0.0% 100 0.4 0.4 0.3 0.7 0.0
5. AS5410 be28.cbr01-cro.net.bbox.fr 0.0% 100 13.1 13.4 12.3 14.6 0.3
6. AS5410 be5.cbr01-lyo.net.bbox.fr 0.0% 100 18.4 15.8 11.9 19.9 2.3
7. AS5410 la44.bsr01-lyo.net.bbox.fr 54.0% 100 11.9 12.3 11.8 29.0 2.5
8. AS5410 la10.bsr02-lyo.net.bbox.fr 15.0% 100 11.9 11.9 11.7 12.2 0.0
9. AS??? 193.253.12.9 0.0% 100 12.4 12.4 12.2 21.4 0.9
10. AS??? ae43-0.nrlyo202.Lyon3eArrondissement.francetelecom.net 0.0% 100 12.3 12.7 12.3 24.1 1.7
11. AS??? ae42-0.nridf102.Aubervilliers.francetelecom.net 0.0% 100 11.2 11.2 11.1 13.8 0.3
12. AS??? ae41-0.nridf302.Paris13eArrondissement.francetelecom.net 0.0% 100 11.5 12.2 11.3 45.8 3.9
13. AS??? ae41-0.nrstr202.Strasbourg.francetelecom.net 0.0% 100 36.4 20.9 19.8 38.0 3.2
14. AS??? ae43-0.ncncy102.Vandoeuvre-les-nanc.francetelecom.net 0.0% 100 25.1 25.3 25.0 41.6 1.6
15. AS??? lag-109.nebrd291.Bar-le-duc.francetelecom.net 0.0% 100 3716. 591.9 28.1 7522. 1672.6
16. AS??? ? ? 100.0 100
Reverse traceroute en IPv6 :
$ mtr -zrwc100 2a01:cb11:46d:xx00:xxxx
Start: Tue Jun 26 09:32:26 2018
HOST: Loss% Snt Last Avg Best Wrst StDev
1. AS5410 2001:860:de12:200::1 0.0% 100 0.8 1.1 0.8 9.9 1.2
2. AS5410 2001:860:b212::3:1 0.0% 100 0.8 0.8 0.7 0.9 0.0
3. AS5410 2001:860:bbe0:af::1 82.0% 100 8326. 8225. 8054. 8399. 102.5
4. AS5410 2001:860:bbee:27::2 99.0% 100 8304. 8304. 8304. 8304. 0.0
5. AS5511 2a01:cfc4:0:1500::e 0.0% 100 12.3 12.6 12.3 22.2 1.2
6. AS3215 2a01cb08a00402100193025300760137.ipv6.abo.wanadoo.fr 0.0% 100 26.0 29.7 25.8 49.2 5.2
7. AS3215 2a01:cb11:46d:de00:327c:b2ff:febc:bd6 0.0% 100 26.1 26.1 26.0 28.1 0.2
8. AS??? ? ? 100.0 100
Donc la latence importante est liée :
- 3 passages aller-retour entre Paris et Lille (je mets aller-retour car c'est aussi le cas dans ton traceoute)
- Passage par Lyon pour joindre Orange (là le pb n'est que dans un seul sens)
Bref, tant que ce n'est ps réglé, il faut choisir un autre serveur.
-
voici le traceroute
mtr -zrwc100 89.84.1.236
Start: 2018-06-26T10:00:57+0200
HOST: ns1 Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway 0.0% 100 0.5 0.7 0.4 1.9 0.3
2. AS??? 80.10.235.217 0.0% 100 1.6 1.5 1.2 5.3 0.5
3. AS??? ae111-0.ncncy102.Vandoeuvre-les-nanc.francetelecom.net 0.0% 100 1.3 1.7 1.1 8.5 1.0
4. AS??? ae43-0.nrstr202.Strasbourg.francetelecom.net 0.0% 100 5.0 5.3 4.5 15.1 1.1
5. AS??? ae45-0.nridf302.Paris13eArrondissement.francetelecom.net 0.0% 100 26.9 13.8 12.9 26.9 1.4
6. AS??? ae44-0.noidf002.Aubervilliers.francetelecom.net 0.0% 100 12.6 13.3 11.5 49.2 4.6
7. AS5410 la105.rpt01-ix2.net.bbox.fr 0.0% 100 12.9 12.7 11.7 24.9 1.3
8. AS5410 be12.cbr01-ntr.net.bbox.fr 0.0% 100 27.5 26.5 24.8 30.7 0.9
9. AS5410 la28.bsr01-lil.net.bbox.fr 0.0% 100 25.4 24.9 24.1 33.6 1.1
10. AS5410 la2.rpt02-th2.net.bbox.fr 0.0% 100 24.5 25.0 24.2 31.8 0.9
11. AS??? 10.131.51.54 0.0% 100 24.8 24.9 24.2 25.9 0.4
12. AS5410 89.84.1.236 0.0% 100 25.3 24.7 24.0 32.0 0.8
mtr -zrwc100 2001:860:de12:200::4
Start: 2018-06-26T10:05:08+0200
HOST: ns1 Loss% Snt Last Avg Best Wrst StDev
1. AS3215 2a01:cb11:2:f400:86a4:23ff:fef3:9540 0.0% 100 0.7 1.0 0.7 2.9 0.4
2. AS3215 2a01cb08a00402100193025300760131.ipv6.abo.wanadoo.fr 0.0% 100 2.7 2.3 1.7 3.4 0.4
3. AS5511 2a01:cfc0:200:8300:193:252:102:50 0.0% 100 13.7 14.7 12.8 33.2 3.6
4. AS5511 2a01:cfc4:0:e00::5 0.0% 100 13.3 13.3 12.3 22.8 1.0
5. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
6. AS5410 2001:860:bbe0:af::2 0.0% 100 25.9 26.1 25.4 34.9 1.0
7. AS5410 2001:860:b212::3:2 0.0% 100 25.8 27.4 25.4 53.4 4.5
8. AS5410 2001:860:de12:200::4 0.0% 100 25.8 25.5 24.7 26.5 0.4
.