La Fibre
Télécom => Peering Transit (appairage) => 
IXP => Discussion démarrée par: Boris de Bouygues Telecom le 26 juillet 2012 à 13:32:20
-
Bonjour,
Bouygues Telecom vient de mettre en place un peering avec les "route serveur" de FranceIX et indirectement LyonIX.
Concrètement Bouygues Telecom Telecom peer avec tous ceux qui ont activé les "route serveur" même ceux qui n'ont pas fait de demande spécifique de Peering avec Bouygues Telecom.
K-Net fait parti des nouveaux peers de ce matin. Contrairement aux abonnés Kiwi fibre optique qui ont gagné 15,3ms le 23 juillet (https://lafibre.info/kiwi-internet/ping-mediocre/msg54220/#msg54220) suite à la mise en place d'un peering sur Paris avec leur transitaire, ici aucun gain de ping n'est attendu car le chemin était déjà optimal (le peering avec le transitaire de K-Net se faisait sur France-IX). On passe par un routeur de moins soit un gain moyen de 0,1ms.
Cela fait un chemin de plus pour échanger le trafic entre Bouygues Telecom et K-Net. Il me semble que les abonnés K-Net on compris qu'il était important d'avoir plusieurs liens pour joindre une même destination.
Voici le traceroute vers k-net.fr en IPv4 depuis Paris / Telehouse2 :
Loss% Snt Last Avg Best Wrst StDev
1.|-- ae5.tcore02-t2.net.bbox.fr 0.0% 100 20.6 15.3 0.4 76.1 22.4
2.|-- la3.rpt01-th2.net.bbox.fr 40.0% 100 0.5 0.6 0.5 1.0 0.1
3.|-- 193.105.232.240 0.0% 100 7.5 7.6 7.4 16.6 0.9
4.|-- knet-xlrender.peers.lyonix.net 0.0% 100 7.6 7.7 7.6 8.1 0.1
5.|-- border1-sgp.kwaoo.net 0.0% 100 10.2 10.1 9.9 10.4 0.1
6.|-- admin-knet.kwaoo.net 0.0% 100 10.4 10.5 10.2 11.1 0.1
L'IPv6 sera probablement activé demain.
L'étape suivante est la venue de Bouygues Telecom sur LyonIX, ce qui permettra de joindre les abonnés de la région sans passer par Paris. Là le gain en ping sera important.
Cordialement,
Boris de Bouygues Telecom.
-
Bonjour Boris,
Excellente nouvelle que voila.
L'IPv6 sera probablement activé demain.
Et nous peerons avec le RS de Lyonix en IPV6 également.
L'étape suivante est la venue de Bouygues Telecom sur LyonIX, ce qui permettra de joindre les abonnés de la région sans passer par Paris. Là le gain en ping sera important.
K-Net utilise une politique de peering ouverte. Si vous acceptez le peering direct pour réduire l'AS PATH d'un AS, ce sera avec plaisir.
-
J'ai été un peu vite pour vous annoncer la bonne nouvelle. Nous allons couper le peering.
Le lien qui relie le LyonIX aux GIX parisiens n'est pas suffisamment dimensionné pour le trafic de Bouygues telecom. Ce soir on est limité a 2 Mo/s par connexion TCP soit 16 Mb/s.
Vous pouvez observer les mêmes limitations depuis le réseau K-Net en réalisant le téléchargement du fichier http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat) qui est hébergé par Bouygues Telecom.
$ wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
--2012-07-27 19:49:02-- http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
Résolution de testdebit.info (testdebit.info)... 89.84.127.55
Connexion vers testdebit.info (testdebit.info)|89.84.127.55|:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 125000000 (119M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
100%[======================================>] 125 000 000 2,00M/s ds 61s
2012-07-27 19:50:03 (1,96 MB/s) - «/dev/null» sauvegardé [125000000/125000000]
La coupure sera probablement effectuée lundi (pas de modification un vendredi soir).
Le peering sera remis en place une fois Bouygues Telecom présent directement sur le LyonIX.
Cordialement,
Boris de Bouygues Telecom.
PS: Traceroute ver le LyonIX :
$ mtr -4rwc100 www.lyonix.net (http://www.lyonix.net)
HOST: testdebit.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.4 0.5 0.3 5.0 0.5
2.|-- V113.TenGEC5-10G.core04-t2.club-internet.fr 54.0% 100 0.3 4.3 0.3 95.3 15.8
3.|-- ae5.tcore01-m.net.bbox.fr 0.0% 100 0.6 10.3 0.6 65.6 18.4
4.|-- po109.core02-c.net.bbox.fr 43.0% 100 0.9 9.4 0.8 122.1 25.6
5.|-- ? ? 100.0 100 0.0 0.0 0.0 0.0 0.0
6.|-- ge0-1.sfr.c7301-1.ven01.phibee-telecom.net 0.0% 100 7.2 9.0 7.1 184.4 17.7
7.|-- c6506-1.ge3-13.ven01.phibee-telecom.net 0.0% 100 7.4 9.1 7.3 163.8 15.6
8.|-- c7301-1.ge0-0.ven01.phibee-telecom.net 0.0% 100 7.3 8.4 7.2 82.1 7.7
9.|-- transit-lyonix.phibee-telecom.net 0.0% 100 8.4 10.5 8.0 106.9 12.7
10.|-- lb.ix.lyonix.net 0.0% 100 8.4 8.0 7.8 8.5 0.1
-
J'ai été un peu vite pour vous annoncer la bonne nouvelle. Nous allons couper le peering.
Ca n'aura point duré longtemps ;)
Le lien qui relie le LyonIX aux GIX parisiens n'est pas suffisamment dimensionné pour le trafic de Bouygues telecom. Ce soir on est limité a 2 Mo/s par connexion TCP soit 16 Mb/s.
effectivement :
wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat
--2012-07-27 22:41:22-- http://1.testdebit.info/fichiers/1000Mo.dat
Rà©solution de testdebit.info... 89.84.127.55
Connexion vers testdebit.info|89.84.127.55|:80...connectà©.
requàªte HTTP transmise, en attente de la rà©ponse...200 OK
Longueur: 125000000 (119M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
100%[===============================================>] 125 000 000 2,17M/s ds 63s
La coupure sera probablement effectuée lundi (pas de modification un vendredi soir).
En attendant, j'ai exclu nos annonces vers l'AS 5410 au travers du Route Server du Lyonix et baissé la préférence en sortie (lyonix) de façon à repasser le trafic par nos transits.
Cela semble être effectivement tout de suite mieux :
wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat
--2012-07-27 22:48:01-- http://1.testdebit.info/fichiers/1000Mo.dat
Résolution de testdebit.info... 89.84.127.55
Connexion vers testdebit.info|89.84.127.55|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 125000000 (119M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
100%[===============================================>] 125 000 000 29,2M/s ds 4,2s
2012-07-27 22:48:05 (28,4 MB/s) - «/dev/null» sauvegardé[125000000/125000000]
Le peering sera remis en place une fois Bouygues Telecom présent directement sur le LyonIX.
N'hésitez pas à mailer peering@kwaoo.net pour ce genre de choses.
-
C'est pour cette raison que K-Net ne peer pas avec OVH sur LyonIX mais préfère récupérer le trafic via IELO ?
Si K-Net arrive a récupéré Bouygues Telecom sur les route serveur, il devrait aussi récupérer OVH !
OVH (AS16276) est bien présent sur les routes serveur de LyonIX => https://noc.rezopole.net/as_list.html (https://noc.rezopole.net/as_list.html)
C'est sur que c'est risqué de faire passer la VoIP sur un lien saturé...
Pour faire un test de débit avec OVh voici les fichiers a utiliser :
IPv4 : wget -O /dev/null http://ipv4.proof.ovh.net/files/1000Mo.dat (http://ipv4.proof.ovh.net/files/1000Mo.dat)
IPv6 : wget -O /dev/null http://ipv6.proof.ovh.net/files/1000Mo.dat (http://ipv6.proof.ovh.net/files/1000Mo.dat)
Pourtant sur la wethermap du LyonIX, le lien vers Paris est loin d'être saturé...
(https://lafibre.info/testdebit/weathermap/201207_weathermap_lyonIX_1.png)
-
C'est pour cette raison que K-Net ne peer pas avec OVH sur LyonIX mais préfère récupérer le trafic via IELO ?
Assez précisèment.
C'est sur que c'est risqué de faire passer la VoIP sur un lien saturé...
C'est surtout un problème de jitter qui nous à poussé à faire ca.
-
Je pense que la piste de la saturation du lien Paris <=> Lyon de LyonIX est une mauvaise piste.
J'ai fait quelques tests depuis LaFibre.info, hébergé au Maxnod et qui utilise le peering avec Bouygues Telecom via les routes serveur.
Il semblerait que la dégradation soit lié a un équipement sur le chemin qui triture les paquets.
Bref, je me dit qu'il est peux être possible de résoudre le problème et j'aurais besoin d'un test que je ne peux pas réaliser pour confirmer mon diagnostique.
Cela se met plus en évidence avec un ping important.
J'utilise pour ce faire le serveur 90ms.testdebit.info, serveur plus en ligne aujourd'hui avec un ping supplèmentaire de 90ms (latence générée artificiellement avec NetEm (https://lafibre.info/tutoriels/generer-des-pertes-de-paquets/))
Depuis LaFibre.info sur Maxnod :
$ wget -O /dev/null http://90ms.testdebit.info/fichiers/1000Mo.dat (http://90ms.testdebit.info/fichiers/1000Mo.dat)
100%[=========================================================================================================>] 125 000 000 247K/s ds 7m 5s
2012-07-28 17:15:06 (287 KB/s) - «/dev/null» sauvegardé [125000000/125000000]
$ ping 90ms.testdebit.info
PING 90ms.testdebit.info (89.82.180.22) 56(84) bytes of data.
64 bytes from 89.82.180.22: icmp_req=1 ttl=56 time=99.0 ms
64 bytes from 89.82.180.22: icmp_req=2 ttl=56 time=99.0 ms
Depuis un serveur OVH :
$ wget -O /dev/null http://90ms.testdebit.info/fichiers/1000Mo.dat--2012-07-28 (http://90ms.testdebit.info/fichiers/1000Mo.dat--2012-07-28) 17:09:13-- http://90ms.testdebit.info/fichiers/1000Mo.dat (http://90ms.testdebit.info/fichiers/1000Mo.dat)
100%[======================================>] 125 000 000 4,59M/s ds 27s
2012-07-28 17:09:40 (4,47 MB/s) - «/dev/null» sauvegardé [125000000/125000000]
$ ping 90ms.testdebit.info
PING 90ms.testdebit.info (89.82.180.22) 56(84) bytes of data.
64 bytes from 89.82.180.22: icmp_req=1 ttl=56 time=94.4 ms
64 bytes from 89.82.180.22: icmp_req=2 ttl=56 time=94.5 ms
Même système d’exploitation sur laFibre.info et OVH, seul la configuration matérielle change (petit serveur OVH avec 1go de ram)
Le ping est presque le même (à 4% prés).
Pourtant on a 4,59 Mo/s a la fin du téléchargement sur OVH et 247 Ko/s à la fin du téléchargement sur LaFibre.info (fichier téléchargé en 27 secondes sur OVH et 7minutes 5 sec sur LAFibre.info)
La différence est incroyable et ce n'est pas une saturation qui explique un si petit débit sur lafibre.info car sans les +90ms, on est à un débit de 2 Mo/s.
-
Ce n'est pas une saturation, mais des micro-coupures sur le lien qui dégradent fortement le débit (et la VoIP).
J'ai réalisé un téléchargement avec une capture coté client (LaFibre.info sur le Maxnod) et coté serveur (testdebit.info chez Bouygues Telecom) afin de comprendre pourquoi le débit est autant dégradé via le lien qui relie LyonIX aux GiX parisiens => J'observe de nombreuses micro-coupures du lien.
Ce ne sont pas des pertes de petites pertes de paquets, mais des coupure dans le sens Paris -> Lyon ou Lyon -> Paris.
Exemple n°1 : dés le début du téléchargement la connexion va être coupé dans le sens Lyon-> Paris pendant plusieurs dizaines de ms.
L'ensemble des acquittements sont perdus. Le client a envoyé ses acquittements et attend tranquillement le paquet suivant. Le serveur lui aussi a envoyé 32 Ko de données et donc attend un acquittement du client pour continuer. Cet acquittement ne venant pas, il va attendre 206ms avant de renvoyer le dernier paquet non acquitté. Ce paquet a déjà été reçu par le client mais cela va permettre la reprisse de la connexion, le client envoyant un acquittement qui correspond a tous les acquittements non reçus par le serveur.
La connexion repart prudemment. Cela signifie que le serveur ne va pas remplir complètement la fenêtre de réception. Il va attendre régulièrement des acquittements.
(https://lafibre.info/testdebit/pcap/201207_micro-coupures_lyonix_client_1.png)
(https://lafibre.info/testdebit/pcap/201207_micro-coupures_lyonix_serveur_1.png)
Exemple n°2 : Peu de temps après la connexion coupe dans le sens Paris -> Lyon. Là aussi ce n'est pas un paquet de donné mais 12 Ko qui sont perdus. Le serveur stop l'envoi de données n'ayant reçu aucune demande de retransmission du client car l'intégralité des paquets ont été perdus. Après 216ms de pause le serveur va renvoyer le dernier paquet non acquitté. Le client envoi l’accusé de réception. Le serveur va continuer avec le paquet suivant et attend l’acquittement. En effet après ces phénomènes anormaux, le serveur va attendre un acquittement avant d'envoyer le paquet suivant. Là le client va s'apercevoir qu'il lui manque 11 Ko de données. Le client va donc demander une retransmission de tous ces paquets. A la réception de cette demande, le serveur renvoi le reste des paquets perdus.
Suite à ces incidents, La connexion repart prudemment : non seulement le serveur ne va pas remplir complètement la fenêtre de réception et le client ne va pas faire augmenter sa fenêtre de réception qui est adaptative.
=> Les débits entre les coupures de connexions ne seront pas bon.
(https://lafibre.info/testdebit/pcap/201207_micro-coupures_lyonix_serveur_2.png)
(https://lafibre.info/testdebit/pcap/201207_micro-coupures_lyonix_client_2.png)
Cela explique les problèmes de faible débit sur ce lien et les problèmes de mauvaise qualité de la voix sur IP.
J'ai mis à disposition les capture Wireshark dans les des deux sens ici (https://lafibre.info/testdebit/pcap/201207_micro-coupures_lyonix.tar.xz)
Weathermap LyonIX au moment de la capture (https://lafibre.info/testdebit/weathermap/201207_weathermap_lyonIX_2.png)
Voici le wget sur lequel porte la capture :
$ wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
--2012-07-28 21:11:28-- http://1.testdebit.info/fichiers/1000Mo.dat (http://1.testdebit.info/fichiers/1000Mo.dat)
Résolution de testdebit.info (testdebit.info)... 89.84.127.55
Connexion vers testdebit.info (testdebit.info)|89.84.127.55|:80... connecté.
requête HTTP transmise, en attente de la réponse... 200 OK
Longueur: 125000000 (119M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
100%[=============================================>] 125 000 000 2,78M/s ds 54s
2012-07-28 21:12:22 (2,20 MB/s) - «/dev/null» sauvegardé [125000000/125000000]
-
J'ai mis en place un script pour télécharger un fichier de 30Mo chaque heure depuis LaFibre.info vers deux serveurs Speedtest : Bouygues Telecom et OVH.
#!/bin/dash
wget -O /dev/null http://89.84.127.55/speedtest/random4000x4000.jpg -o /tmp/test_debit_wget.tmp
cat /tmp/test_debit_wget.tmp | grep "31625365/31625365" >> /home/scripts/speedtest_bouygues.txt
wget -O /dev/null http://speedtest1.proof.ovh.net/speedtest/random4000x4000.jpg -o /tmp/test_debit_wget.tmp
cat /tmp/test_debit_wget.tmp | grep "31625365/31625365" >> /home/scripts/speedtest_ovh.txt
On voit bien que ce n'est pas une saturation, le débit étant le même quel que soit l'heure.
Voici les résultats pour OVH : (OVH est récupéré via le SFINX sur Paris suivit du lien Paris => LyonIX)
2012-07-28 21:05:32 (1,67 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 22:05:36 (1,50 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 23:05:32 (1,60 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 00:05:34 (1,49 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 01:05:30 (1,73 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 02:05:30 (1,71 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 03:05:38 (1,31 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 04:05:26 (2,04 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 05:05:27 (1,86 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 06:05:27 (2,00 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 07:05:27 (2,00 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 08:05:25 (2,17 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 09:05:31 (1,66 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 10:05:34 (1,53 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 11:05:32 (1,62 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 12:05:44 (1,15 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 13:05:33 (1,45 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 14:05:31 (1,67 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 15:05:35 (1,58 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 16:05:37 (1,33 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 17:05:37 (1,37 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 18:05:38 (1,32 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 19:05:30 (1,71 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 20:05:36 (1,42 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 21:05:34 (1,56 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 22:05:34 (1,61 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 23:05:38 (1,38 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 00:05:34 (1,49 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 01:05:33 (1,53 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 02:05:32 (1,69 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 03:05:39 (1,25 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 04:05:29 (1,88 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 05:05:30 (1,65 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 06:05:36 (1,28 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 07:05:27 (1,88 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 08:05:29 (1,80 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 09:05:39 (1,30 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 10:05:38 (1,30 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
Voici les résultats pour Bouygues Telecom : (Bouygues Teleocm est récupéré via le FranceIX sur Paris suivit du lien Paris => LyonIX)
2012-07-28 00:05:18 (1,70 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 01:05:12 (2,65 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 02:05:11 (2,93 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 03:05:12 (2,56 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 04:05:12 (2,79 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 05:05:12 (2,87 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 06:05:11 (2,92 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 07:05:11 (2,97 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 08:05:11 (3,03 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 09:05:13 (2,64 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 10:05:14 (2,36 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 11:05:14 (2,33 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 12:05:18 (1,72 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 13:05:19 (1,72 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 14:05:17 (1,92 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 15:05:17 (1,90 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 16:05:15 (2,16 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 17:05:15 (2,21 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 18:05:14 (2,36 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 19:05:14 (2,32 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 20:05:14 (2,35 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 21:05:14 (2,26 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 22:05:16 (2,10 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-28 23:05:13 (2,48 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 00:05:14 (2,45 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 01:05:12 (2,77 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 02:05:13 (2,53 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 03:05:15 (2,16 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 04:05:11 (2,89 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 05:05:11 (3,11 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 06:05:11 (2,95 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 07:05:12 (2,76 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 08:05:11 (3,03 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 09:05:12 (2,59 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 10:05:14 (2,28 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 11:05:13 (2,40 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 12:05:18 (1,81 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 13:05:13 (2,60 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 14:05:13 (2,68 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 15:05:16 (1,99 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 16:05:15 (2,23 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 17:05:15 (2,03 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 18:05:15 (2,12 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 19:05:12 (2,62 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 20:05:15 (2,23 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 21:05:14 (2,29 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 22:05:15 (2,14 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-29 23:05:16 (2,00 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 00:05:14 (2,39 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 01:05:13 (2,55 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 02:05:15 (2,18 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 03:05:15 (2,18 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 04:05:13 (2,61 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 05:05:12 (2,68 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 06:05:13 (2,44 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 07:05:11 (3,06 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 08:05:12 (2,62 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 09:05:15 (2,11 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 10:05:15 (2,07 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
-
Serveur SpeedTest Bouygues Telecom depuis LaFibre.info (Maxnod) après avoir coupé le peering :
2012-07-30 09:05:15 (2,11 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 10:05:15 (2,07 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 10:57:38 (56,1 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 11:05:02 (48,8 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 12:05:01 (51,6 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
2012-07-30 13:05:01 (49,3 MB/s) - «/dev/null» sauvegardé [31625365/31625365]
On dépasse 70 Mo/s avec des fichiers un peu plus gros (là c'est un fichier de 30 Mo qui est téléchargé)
-
En attendant, j'ai exclu nos annonces vers l'AS 5410 au travers du Route Server du Lyonix et baissé la préférence en sortie (lyonix) de façon à repasser le trafic par nos transits.
Cela semble être effectivement tout de suite mieux :
wget -O /dev/null http://1.testdebit.info/fichiers/1000Mo.dat
--2012-07-27 22:48:01-- http://1.testdebit.info/fichiers/1000Mo.dat
Résolution de testdebit.info... 89.84.127.55
Connexion vers testdebit.info|89.84.127.55|:80...connecté.
requête HTTP transmise, en attente de la réponse...200 OK
Longueur: 125000000 (119M) [application/x-ns-proxy-autoconfig]
Sauvegarde en : «/dev/null»
100%[===============================================>] 125 000 000 29,2M/s ds 4,2s
2012-07-27 22:48:05 (28,4 MB/s) - «/dev/null» sauvegardé[125000000/125000000]
Il est possible de remonter le peering avec OVH, Bouygues Telecom et les autres qui avait été coupé, Rezopole / LyonIX a basculé la liaison Lyon <=> Paris sur un nouveau lien 1Gb/s, hier à 15h00.
Le nouveau lien permet de gagner 1ms vers Paris et il n'y a plus de pertes de paquets.
Concrètement le débit de téléchargement moyen d'un petit fichier sur un serveur OVH passe de 800 Kb/s à 42 Mb/s (C'est un débit moyen sur un petit fichier, le débit en fin de téléchargement est bien plus important que ce débit moyen)
-
du coup le ping entre les abonnées bouygues et ceux qui sont chez un autre fai sur lyon devrait être amélioré?
(je n'est pas vus de changement sur mon graph smokeping)
-
1/ Ce n'est pas encore fait pour Adeli/Maxnod qui héberge LaFibre.info
2/ La différence sera faible vu que aujourd’hui ça utilise un transitaire (peut-être sur le même lien physique) pour monter à Paris.
Par contre on va réduire le nombre de routeur.
Voici ce que cela donne actuellement vers Bouygues Telecom. Cogent est un transitaire commun a Adeli et Bouygues Telecom :
$ mtr -rwc100 testdebit.bbox.bouyguestelecom.fr
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.2 2.0 0.2 101.4 10.6
2.|-- vl219.mag01.lys01.atlas.cogentco.com 0.0% 100 13.7 30.0 13.3 214.0 43.0
3.|-- te2-3.ccr01.lys01.atlas.cogentco.com 0.0% 100 13.3 35.7 13.2 199.1 48.5
4.|-- te0-7-0-4.mpd22.par01.atlas.cogentco.com 0.0% 100 18.6 18.5 18.3 19.8 0.2
5.|-- te0-5-0-2.ccr21.par04.atlas.cogentco.com 0.0% 100 19.0 18.9 18.5 19.3 0.2
| `|-- 130.117.0.158
| |-- 130.117.1.142
| |-- 130.117.50.210
| |-- 130.117.1.62
| |-- 154.54.58.234
6.|-- 149.6.165.82 0.0% 100 218.1 11.1 8.3 218.1 21.0
7.|-- ae27.tcore02-t2.net.bbox.fr 0.0% 100 7.9 19.0 7.9 153.6 26.4
8.|-- po114.core03-t2.net.bbox.fr 2.0% 100 8.3 10.7 8.0 81.8 11.3
9.|-- v113.tengec5-10g.c6k01-t2.club-internet.fr 0.0% 100 8.3 8.5 8.1 17.3 1.2
10.|-- 194.158.102.114 0.0% 100 8.2 8.0 7.9 8.3 0.1
Voici ce que cela donne actuellement vers OVH. Level3 est un transitaire commun a Adeli et Bouygues Telecom :
$ mtr -rwc100 ipv4.proof.ovh.net
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.3 2.1 0.2 101.9 10.8
2.|-- ge-6-8.car1.Geneva1.Level3.net 0.0% 100 3.9 18.7 3.8 158.2 37.3
3.|-- ae-5-5.car1.Lyon1.Level3.net 0.0% 100 12.8 34.9 12.7 212.6 50.2
4.|-- ae-9-9.ebr2.Paris1.Level3.net 0.0% 100 12.8 12.8 12.6 14.8 0.4
5.|-- ae-59-224.csw2.Paris1.Level3.net 0.0% 100 17.5 15.5 12.7 25.9 4.0
6.|-- ae-2-52.edge3.Paris1.Level3.net 0.0% 100 12.8 13.4 12.7 41.8 3.7
7.|-- ? ? 100.0 100
8.|-- th2-g1-a9.fr.eu 0.0% 100 10.9 10.8 10.6 11.1 0.1
9.|-- rbx-g1-a9.fr.eu 0.0% 100 15.2 15.0 14.5 17.1 0.4
10.|-- rbx-s3-6k.fr.eu 5.0% 100 14.2 22.1 14.2 216.1 35.0
11.|-- proof.ovh.net 0.0% 100 14.4 14.3 14.0 14.6 0.1
Je referais les mêmes tests après la mise en service du peering sur LyonIX.
-
okay merci des précisions!
-
Le peering est de nouveau en place pour K-Net :
Traceroute K-Net depuis OVH :
$mtr -rwc100 k-net.fr
Loss% Snt Last Avg Best Wrst StDev
1.|-- rbx-22-m2.fr.eu 0.0% 100 0.8 0.8 0.4 11.1 1.1
2.|-- rbx-2-6k.fr.eu 15.0% 100 0.3 4.5 0.3 137.5 20.0
3.|-- rbx-g1-a9.fr.eu 0.0% 100 0.9 1.0 0.6 4.9 0.5
4.|-- th2-g1-a9.fr.eu 0.0% 100 4.2 4.3 4.1 5.5 0.2
5.|-- th2-5-6k.fr.eu 7.0% 100 4.1 14.6 4.0 184.1 35.0
6.|-- equinix-paris.rezopole.net 0.0% 100 10.3 10.4 10.3 11.1 0.1
7.|-- knet-xlrender.peers.lyonix.net 0.0% 100 10.4 10.5 10.3 10.9 0.1
8.|-- border1-sgp.kwaoo.net 0.0% 100 13.3 13.4 13.2 14.0 0.1
9.|-- admin-knet.kwaoo.net 0.0% 100 13.8 13.9 13.6 15.5 0.3
Traceroute K-Net depuis Bouygues Telecom :
$ mtr -rwc100 k-net.fr
Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.4 0.4 0.3 4.8 0.5
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 30.0% 100 0.3 6.5 0.3 98.0 21.7
3.|-- v211.tengec3-20g.core02-t2.club-internet.fr 0.0% 100 91.9 5.5 0.3 271.1 30.3
4.|-- ae5.tcore02-t2.net.bbox.fr 0.0% 100 0.8 14.7 0.3 71.4 21.0
5.|-- la3.rpt01-th2.net.bbox.fr 74.0% 100 0.5 0.6 0.5 1.0 0.1
6.|-- 193.105.232.240 0.0% 100 6.6 6.6 6.5 7.2 0.1
7.|-- knet-xlrender.peers.lyonix.net 0.0% 100 6.7 6.8 6.6 7.0 0.1
8.|-- border1-sgp.kwaoo.net 0.0% 100 9.9 9.8 9.6 10.0 0.1
9.|-- admin-knet.kwaoo.net 0.0% 100 10.1 10.2 9.9 13.7 0.4
Le peering est de nouveau en place pour Adeli :
Traceroute Adeli depuis OVH :
s mtr -rwc100 lafibre.info
Loss% Snt Last Avg Best Wrst StDev
1.|-- rbx-22-m2.fr.eu 0.0% 100 0.5 3.0 0.4 227.4 22.7
2.|-- rbx-1-6k.fr.eu 17.0% 100 0.3 5.8 0.3 114.3 20.3
3.|-- rbx-g1-a9.fr.eu 0.0% 100 0.8 0.9 0.6 3.0 0.3
4.|-- th2-g1-a9.fr.eu 0.0% 100 4.2 4.2 4.1 5.0 0.1
5.|-- th2-5-6k.fr.eu 3.0% 100 4.0 13.9 4.0 201.9 34.2
6.|-- equinix-paris.rezopole.net 0.0% 100 10.4 10.5 10.3 15.7 0.5
7.|-- adeli-l2.peers.lyonix.net 0.0% 100 14.1 17.1 13.8 249.4 24.4
8.|-- lafibre.info 1.0% 100 14.0 14.1 14.0 14.9 0.1
Traceroute Adeli depuis Bouygues Telecom :
$ mtr -rwc100 lafibre.info
Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.4 0.4 0.3 1.1 0.1
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 35.0% 100 91.0 10.4 0.3 182.2 31.6
3.|-- v211.tengec3-20g.core02-t2.club-internet.fr 0.0% 100 0.4 3.7 0.3 169.8 19.9
4.|-- ae5.tcore02-t2.net.bbox.fr 0.0% 100 30.7 12.2 0.4 76.8 21.2
5.|-- la3.rpt01-th2.net.bbox.fr 79.0% 100 0.6 0.6 0.5 0.8 0.1
6.|-- 193.105.232.240 0.0% 100 6.6 6.6 6.5 7.1 0.1
7.|-- adeli-l2.peers.lyonix.net 0.0% 100 8.2 12.0 8.0 160.9 21.8
8.|-- lafibre.info 1.0% 100 8.3 8.2 8.0 8.5 0.1
-
Aucun contact peering pour Bouygues sur la liste des participants lyonix?
-
Bonjour Tel&Go !
La liste des contacts Peering est à jour sur http://www.peeringdb.com/view.php?asn=5410 (http://www.peeringdb.com/view.php?asn=5410)
Nous seront présent dans le prochain "RezoLink" de Rezopole, la fiche a été remplie.
Toutefois il n'a pas été possible de mettres tous les contacts présents sur http://www.peeringdb.com/view.php?asn=5410 (http://www.peeringdb.com/view.php?asn=5410)
(https://lafibre.info/images/peering/201407_rezolink_lyonix_bouygues_telecom.png)
Cordialement,
Boris de Bouygues Telecom.
-
Merci je regardais là -> http://www.lyonix.net/fr/a-propos-de-lyonix/participants-lyonix (http://www.lyonix.net/fr/a-propos-de-lyonix/participants-lyonix)
Bref c'est pas bien grave.
Une petite question à poser ;-)
-
Je ne connaissais pas.
Je ferais corriger.
-
Il manque aussi mes infos sur cette page ;-) je ne sais pas si ils mettent à jour souvent.
-
@Boris: Merci pour les infos.
Mais tu es en train de dire que si j'envoie un mail à peering@as5410.net je n'aurai pas un retour du genre "DNS Error: Domain name not found" ou un "Recipient address rejected: Access Denied" :)
Ont-ils corrigé/amélioré leur routage car je ne vois pas à quoi sert de monter des sessions avec eux sur des IX s'ils mettent toujours des localpref énormes sur leur PNI avec Néotelecom mise à part pour mon trafic qui sortira toujours au plus tôt mais pour le retour ça sera toujours NEO --> IELO -> K-NET.
J'espère qu'ils verront mon post afin de changer leur algorithme et ainsi honorer les routes qu'ils apprennent des GIX choisissant la route ayant le moins d'as-path à traverser.
-
L'adresse mail indiqué doit être corrigé depuis un bon moment.
Bouygues Telecom => Neo-Telecom --> IELO -> K-NET c'est ancien !
Depuis début 2014, c'est Bouygues Telecom => Hopus --> IELO -> K-NET
On paye tous les deux (dans l'autre sens, c'est un peering sur Equinix-Paris avec FranceIX en back-up)
Traceroute de Bouygues Telecom vers K-Net :
$ mtr -rwc100 k-net.fr
HOST: testdebit.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.3 0.4 0.2 11.3 1.1
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 0.0% 100 0.3 3.2 0.3 161.1 17.9
3.|-- ae5.tcore01-m.net.bbox.fr 0.0% 100 2.9 11.6 0.4 74.7 19.2
4.|-- be35.cbr01-ntr.net.bbox.fr 0.0% 100 7.2 4.8 1.0 8.7 2.3
5.|-- lag36.rpt02-th2.net.bbox.fr 83.0% 100 4.7 2.9 1.9 6.0 1.5
6.|-- bouygues.th2-1.rt.hopus.net 0.0% 100 1.5 1.5 1.4 1.7 0.0
7.|-- ielo.th2-1.rt.hopus.net 0.0% 100 10.1 3.4 1.0 11.6 3.4
8.|-- 2ge-e1-17-e1-18-cr5.le9-lyon.fr.rt.ielo.net 0.0% 100 8.1 10.4 8.1 18.6 3.3
9.|-- 2ge-e1-1-e1-2-cr10.eqx1-gnv.ch.rt.ielo.net 0.0% 100 10.7 12.1 10.7 20.8 2.8
10.|-- kwaoo.ix-customers-gva1.ielo.net 0.0% 100 11.3 11.2 10.9 15.1 0.7
11.|-- smtp.kwaoo.net 0.0% 100 11.8 11.8 11.5 12.0 0.1
Il ne faut pas hésiter a nous signaler ces anomalies.
Pour Hopus, l’ingénierie demande que tous les opérateurs participant mettent des local perf afin que le trafic passe par Hopus dans les deux sens. Hopus coupe les annonces des opérateurs que nous avons en PNI (Orange n'est pas annoncé à Bouygues Telecom sur Hopus). Cela serait trop facile de recevoir le trafic par Hopus et l'envoyer par un autre chemin. Le cas des clients d'un membre de Hopus qui ont leur propre peering, cas de K-Net, va être traité.
Il ne faut pas hésiter a envoyer des mails aux adresses proposées sur PeeringDB pour signaler des problématiques de peering qui ne fonctionne pas dans l'autre sens.
Pour un opérateur comme Bouygues Telecom présent sur de nombreux GIX, de nombreuses règles sont nécessaire pour stabiliser les gros peer. Nous n’apprécions pas les opérateurs qui nous envoient 20 Gb/s sur un GIX le 1er jour, 20 Gb/s sur un second GIX le 2ème jour et 20 Gb/s sur un 3ème GIX le 3ème jour. C'est a cause de ces bascules que nous avons déjà été obligés dans le passé de couper des peerings pour ne pas saturer le lien.
Pour LyonIX, on a désagrégé les plages IP de nos clients Lyonnais afin de favoriser le passage par Lyon-IX. Les plages agrégées de Bouygues Telecom sont également annoncées, mais avec du prepend.
-
@Boris: Merci pour les infos.
Mais tu es en train de dire que si j'envoie un mail à peering@as5410.net je n'aurai pas un retour du genre "DNS Error: Domain name not found" ou un "Recipient address rejected: Access Denied" :)
Ont-ils corrigé/amélioré leur routage car je ne vois pas à quoi sert de monter des sessions avec eux sur des IX s'ils mettent toujours des localpref énormes sur leur PNI avec Néotelecom mise à part pour mon trafic qui sortira toujours au plus tôt mais pour le retour ça sera toujours NEO --> IELO -> K-NET.
J'espère qu'ils verront mon post afin de changer leur algorithme et ainsi honorer les routes qu'ils apprennent des GIX choisissant la route ayant le moins d'as-path à traverser.
Personnellement j'ai réglé ce genre de problème en envoyant une communauté pour ne pas annoncer mes préfixes sur Hopus :D Ca m'évite d'être mêlé aux histoires de trafic influencé par les politiques financières et les tests Hopus.
Sinon peering ne renvoie aucune erreur. T'as pas forcèment de réponse mais ils le reçoivent bien.