La Fibre
Télécom => Peering Transit (appairage) => 
BGP (technique, questions générales) => Discussion démarrée par: vivien le 29 juin 2013 à 18:29:53
-
Pourquoi le trafic Bouygues Telecom => K-Net passe par le transitaire de K-Net ?
Adeli et K-Net ont tous les deux pour Transitaire IELO, Cogent et Level3 et ils sont tous les deux présents sur LyonIX avec les route serveur activé.
Bouygues Telecom a les route serveur d'activé sur Equinix et donc le peering est possible entre les 3 opérateurs sans passer par un transitaire.
Pour éviter que le flux passe par un transitaire, on utilise AS-path prepend afin d'augmenter virtuellement le nombre d'AS traversé.
L'exemple ci-dessous permet de comprendre.
AS1 souhaite joindre AS4. Il y a deux chemin : Le chemin direct via le routeur Julian et le chemin via d'autres AS via le routeur Jacob.
Naturellement BGP va faire passer le trafic par Julian.
Si pour une raison ou une autre (lien plus cher, lien qui a des pertes de paquets, lien saturé,...) on souhaite faire passer le trafic par le chemin AS1 => AS2 => AS3 => AS4, on va alourdi le lien direct en répétant plusieurs fois l'AS.
On a Alors le choix entre :
- AS1 => AS2 => AS3 => AS4
- AS1 => AS1 => AS1 => AS1 => AS1 => AS4
Et BGP va choisir le chemin le plus court qui est celui qui passe par AS2 et AS3
(https://lafibre.info/images/tuto/201306_bgp_path_prepend.png)
(https://www.lafibre.info/images/adeli/logo_adeli_mini.webp) Traceroute Bouygues Telecom => Adeli
On a : Bouygues Telecom => Equinix => LyonIX => Adeli
$ mtr -rwc100 lafibre.info
HOST: testdebit.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.3 0.4 0.2 1.0 0.1
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 14.0% 100 0.3 2.3 0.3 93.5 10.8
3.|-- v210.tengec1-20g.core03-t2.club-internet.fr 0.0% 100 0.4 6.8 0.3 163.0 26.9
4.|-- ae8.tcore02-t2.net.bbox.fr 0.0% 100 49.9 11.9 0.2 99.9 22.4
5.|-- la1.rpt02-th2.net.bbox.fr 89.0% 100 1.1 2.9 0.9 9.0 2.4
6.|-- equinix-paris.rezopole.net 0.0% 100 7.1 6.8 6.6 7.3 0.1
7.|-- adeli-l2.peers.lyonix.net 0.0% 100 7.9 11.4 7.7 284.6 28.1
8.|-- lafibre.info 0.0% 100 7.9 8.0 7.8 8.5 0.1
(https://www.lafibre.info/images/k-net/logo_k-net_mini.webp) Traceroute Bouygues Telecom => K-Net
On a : Bouygues Telecom => NeoTelecom => IELO => 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.5 0.4 0.2 0.9 0.1
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 16.0% 100 0.7 10.8 0.2 236.3 43.1
3.|-- ae5.tcore01-m.net.bbox.fr 0.0% 100 0.7 11.9 0.7 85.3 20.2
4.|-- be35.cbr01-ntr.net.bbox.fr 0.0% 100 4.6 5.0 1.3 9.0 2.3
5.|-- lag13.rpt02-ix2.net.bbox.fr 74.0% 100 1.8 3.0 1.8 9.2 2.0
6.|-- 83.167.32.213.static.not.updated.neotelecoms.com 0.0% 100 1.8 1.8 1.7 2.4 0.1
7.|-- 83.167.55.46 0.0% 100 1.9 2.0 1.8 13.4 1.3
8.|-- xe2-1-0.ter1.eqx2.par.as8218.eu 0.0% 100 2.3 2.7 2.1 41.4 4.1
9.|-- ge1-5.br1.rdb.par.ielo.net 0.0% 100 1.5 3.7 1.4 12.1 3.3
10.|-- 10ge-5-2-cr2.th2.fr.rt.ielo.net 0.0% 100 1.5 3.4 1.4 11.6 3.1
11.|-- 2ge-e1-17-e1-18-cr5.le9-lyon.fr.rt.ielo.net 0.0% 100 12.5 11.1 8.4 18.9 3.3
12.|-- kwaoo.ix-customers-le9lyon.ielo.net 0.0% 100 8.6 8.9 8.1 12.0 0.8
13.|-- border1-sgp.kwaoo.net 0.0% 100 11.9 12.3 11.1 16.2 1.0
14.|-- pil.kwaoo.net 1.0% 100 13.6 13.8 12.0 18.3 1.5
Je me demande si K-Net utilise bien AS-path prepend pour recevoir le trafic en priorité par ses peering...
IELO est le transitaire de Adeli et K-Net
NeoTelecom est le transitaire de IELO
Entre NeoTelecom et Bouygues Telecom, c'est du peering privé (PNI).
-
Pour compléter les traceroutes inverse passent bien par les peering :
(https://www.lafibre.info/images/adeli/logo_adeli_mini.webp) Traceroute Adeli => Bouygues Telecom :
On a : Adeli => LyonIX => Equinix => Bouygues Telecom
$ mtr -rwc100 testdebit.info
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.2 3.7 0.1 227.6 23.9
2.|-- rr-l2-vlan500.ix.lyonix.net 0.0% 100 1.1 1.2 1.1 2.5 0.1
3.|-- equinix-paris.as5410.net 0.0% 100 8.6 8.8 8.1 13.8 1.0
4.|-- ae27.tcore02-t2.net.bbox.fr 0.0% 100 10.7 55.8 7.7 143.4 37.4
5.|-- po114.core03-t2.net.bbox.fr 0.0% 100 8.1 13.0 7.9 163.3 20.9
6.|-- v113.tengec5-10g.c6k01-t2.club-internet.fr 0.0% 100 8.0 8.1 7.9 9.4 0.2
7.|-- 89.84.127.55 0.0% 100 8.1 8.0 7.8 8.7 0.2
(https://www.lafibre.info/images/k-net/logo_k-net_mini.webp) Traceroute K-Net => Bouygues Telecom :
On a : Adeli => LyonIX => Equinix => Bouygues Telecom
tracert testdebit.info
Détermination de l'itinéraire vers testdebit.info [89.84.127.55]
avec un maximum de 30 sauts :
1 1 ms 1 ms 1 ms 192.168.1.1
2 6 ms 6 ms 5 ms 254-200-28-81.ftth.cust.kwaoo.net [81.28.200.254]
3 9 ms 8 ms 8 ms border1-lyonix.kwaoo.net [178.250.208.2]
4 8 ms 8 ms 8 ms rr-l2-vlan500.ix.lyonix.net [77.95.71.5]
5 * * * Délai d'attente de la demande dépassé.
6 39 ms 77 ms 88 ms ae27.tcore02-t2.net.bbox.fr [89.89.101.2]
7 111 ms 15 ms 15 ms po114.core03-t2.net.bbox.fr [89.89.101.78]
8 15 ms 15 ms 14 ms v113.tengec5-10g.c6k01-t2.club-internet.fr [62.34.0.170]
9 15 ms 15 ms 15 ms 89.84.127.55
Logique si le peering et le transit ont le me poids que K-Net fasse sortir le trafic par le peering.
Logique également coté Bouygues Telecom si le peering public (via GIX) et le PNI ont le même poids que le PNI soit privilégié, d'où passage par le PNI NeoTelecom
-
Merci pour l'explication :)
-
Merci pour l'explication :)
Très bon dossier effectivement :)
Merci pour les connaissances glané au passage.
Cordialement
Bensay
-
Sinon, on ma plusieurs fois demandé pourquoi les SmokePing Adeli => K-Net montre une augmentation du ping en soirée et des pertes de paquet.
Je confirme donc que ces pertes ne sont pas seulement en provenance d'Adeli mais j'observe le même souci depuis Bouygues Telecom et cela semble positionné sur le réseau K-Net, sur les deux derniers sauts :
(https://lafibre.info/images/k-net/201306_traceroute_bouygues_k-net.png)
SmokePing de la même destinations (forum.k-net.fr) mais depuis Maxnod / Adeli :
(https://lafibre.info/images/k-net/201306_smokeping_forum_k-net.png)
Le problème est également sur le site web. Graphe du site k-net.fr en IPv6 :
(https://lafibre.info/images/k-net/201306_smokeping_k-net_ipv6.png)
Entre K-Net et Adeli le traceroute passe par le CIXP (Genève) dans le sens K-Net => Adeli et par LyonIX dans le sens Adeli => K-Net.
Edit : pertes le dimanche soir :
(https://lafibre.info/images/k-net/201306_traceroute_adeli_bouygues_k-net.png)
-
Le looking glass d'HE (http://lg.he.net/) permet de voir que c'est une décision de routage venant de Bouygues:
core1.par2.he.net> show ip bgp routes detail 178.250.209.12
Number of BGP Routes matching display condition : 3
S:SUPPRESSED F:FILTERED s:STALE
1 Prefix: 178.250.208.0/21, Status: BI, Age: 9d20h34m31s
NEXT_HOP: 195.69.146.22, Metric: 110, Learned from Peer: 216.218.252.173 (6939)
LOCAL_PREF: 100, MED: 1, ORIGIN: igp, Weight: 0
AS_PATH: 24904
2 Prefix: 178.250.208.0/21, Status: E, Age: 4d21h41m12s
NEXT_HOP: 195.42.144.71, Metric: 0, Learned from Peer: 195.42.144.71 (29075)
LOCAL_PREF: 100, MED: 1, ORIGIN: igp, Weight: 0
AS_PATH: 29075 24904 24904 24904
3 Prefix: 178.250.208.0/21, Status: E, Age: 4d15h39m5s
NEXT_HOP: 195.42.144.54, Metric: 0, Learned from Peer: 195.42.144.54 (43100)
LOCAL_PREF: 100, MED: 1, ORIGIN: igp, Weight: 0
AS_PATH: 43100 24904
Last update to IP routing table: 9d19h38m9s, 1 path(s) installed:# Entry cached for another 57 seconds.
Route #1: K-Net en direct (peering sur l'AMS-IX)
Route #2: K-Net via Ielo sur Equinix Paris, prepend 2 fois
Route #3: K-Net via le route server du LyonIX pris à travers Equinix Paris
Ni le MED ni le Weight sont propagé par K-Net (autres moyens d'influence sur les décisions de routage des autres AS) donc si Bouygues prend un chemin avec un AS_PATH plus long c'est soit du à une communauté que je n'ai vu sur aucun looking glass soit une locale pref particulière.
-
K-Net via Ielo sur Equinix Paris, prepend 2 fois => Cela explique pour quoi ce chemin n'est pas choisit par Bouygues Telecom.
Par contre j'ai un peu de mal a comprendre pourquoi un traitement différent entre K-Net et Adeli, qui semblent pourtant tous les deux dans la même situation, à part que Adeli est un ancien client en direct de NeoTelecoms (Adeli ne reçois pas les routes IPv4 NeoTelecom via les route serveur alors que K-Net devrait les recevoir)
Serait-il possible que NeoTelecoms diminue AS_PATH des AS qu'il annonce sur le PNI de Bouygues Telecom afin d'être choisit en transitaire à la place de GIX ou d'autres transitaires ?
Politique de peering de NeoTelecoms : (je me demande si c'est pour un PNI ou du peering via GIX, car en réalité NeoTelecoms active les route serveur et ping largement)
Notre politique de peering ( qui n'est plus publié par manque de temps ) est la suivante :
- Nous ne peerons pas avec un client ou ancien client
- Nous ne peerons pas avec le client d'un client
- Nous ne peerons pas avec le client d'un peer existant
- Nous ne peerons pas si nous ne pouvons pas avoir plusieurs points d'interco qu'ils soient publics ou privés ( plusieurs villes ou pays )
- Avoir un minimum de 200 MBits/s échangé entre les deux réseaux.
Petit traceroute Adeli => NeoTelecoms en IPv4 :
Adeli =transit=> Ielo =transit=> NeoTelecoms
$ mtr -4rwc100 www.neotelecoms.com (http://www.neotelecoms.com)
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.2 3.0 0.2 254.6 25.5
2.|-- sw1-le9lyon-ge-1-4.ix-customers-le9lyon.ielo.net 0.0% 100 1.3 2.8 1.1 11.2 2.9
3.|-- 2ge-e1-5-e3-20-cr2.th2-prs.fr.rt.ielo.net 0.0% 100 8.3 11.0 8.2 18.9 3.4
4.|-- 10ge-5-1-cr1.eqx-pa3.fr.rt.ielo.net 0.0% 100 10.5 11.2 8.4 19.1 3.4
5.|-- ge9-1-6.tcr1.rb.par.as8218.eu 0.0% 100 8.4 9.9 8.3 85.0 8.2
6.|-- xe2-0-0.tcr2.th2.par.as8218.eu 0.0% 100 8.8 9.5 8.6 49.2 5.1
7.|-- 83.167.55.5 0.0% 100 9.0 11.4 8.9 87.7 11.7
8.|-- 83.167.55.121.static.not.updated.as8218.eu 0.0% 100 9.0 10.6 9.0 65.3 7.4
9.|-- tech.neotelecoms.com 0.0% 100 9.3 9.2 9.1 9.6 0.1
10.|-- proxy1.neotelecoms.com 0.0% 100 9.5 9.5 9.4 9.8 0.1
Le même traceroute en IPv6 donne des surprises :
Adeli =peering=> LyonIX => FranceIX => NeoTelecoms
$ mtr -rwc100 www.neotelecoms.com (http://www.neotelecoms.com)
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 2a01:6e00:10:410::1 0.0% 100 0.3 5.1 0.2 208.2 26.4
2.|-- rr-l1-vlan500.ix.lyonix.net 0.0% 100 1.8 2.8 1.7 22.5 3.6
3.|-- neotelecoms.franceix.net 0.0% 100 8.3 8.9 8.3 48.4 4.0
4.|-- 2001:1b48:2:3::72 0.0% 100 8.6 15.1 8.5 136.9 20.9
5.|-- 2001:1b48:2:3::8e 0.0% 100 27.1 16.2 8.6 121.6 17.1
6.|-- ? ? 100.0 100
-
Mauvaise analyse, K-Net non plus ne récupère pas le peering de NeoTelecoms via les "route serveur" de France-IX (https://www.franceix.net/page.php?MP=franceix&ST=membres) :
Détermination de l'itinéraire vers proxy1.neotelecoms.com [213.152.14.79] avec un maximum de 30 sauts :
1 8 ms 3 ms 2 ms 192.168.1.1
2 7 ms 9 ms 7 ms 254-200-28-81.ftth.cust.kwaoo.net [81.28.200.254]
3 11 ms 10 ms 10 ms border1-lyonix.kwaoo.net [178.250.208.2]
4 20 ms 11 ms 12 ms sw1-le9lyon-ge-1-6.ix-customers-le9lyon.ielo.net [212.85.148.105]
5 18 ms 18 ms 22 ms 2ge-e1-5-e3-20-cr2.th2-prs.fr.rt.ielo.net [212.85.145.42]
6 18 ms 18 ms 17 ms 10ge-5-1-cr1.eqx-pa3.fr.rt.ielo.net [212.85.145.90]
7 26 ms 18 ms 18 ms ge9-1-6.tcr1.rb.par.as8218.eu [83.167.52.181]
8 17 ms 18 ms 17 ms xe2-0-0.tcr2.th2.par.as8218.eu [83.167.55.112]
9 20 ms 18 ms 18 ms 83.167.55.5
10 17 ms 17 ms 18 ms 83.167.55.121.static.not.updated.as8218.eu [83.167.55.121]
11 18 ms 19 ms 18 ms tech.neotelecoms.com [83.167.57.100]
12 18 ms 18 ms 18 ms proxy1.neotelecoms.com [213.152.14.79]
En même temps K-Net étant client d'un client de NeoTelecoms (IELO) cela semble logique avec peering policy de NeoTelecoms.
Cela ne permet pas de comprendre pourquoi le chemin Bouygues Telecom => Adeli est différent du chemin Bouygues Telecom => K-Net
-
Il n'est pas possible de "réduire" l'as-path de routes en transit - cela va à l'encontre du fonctionnement BGP (ie rfc4271 5.1.2 b).
Aujourd'hui le réseau Bouygues Telecom est configuré avec la Local Pref appliquée au prefix reçue d’un PNI qui sera toujours plus forte que la Local Pref configurée sur les prefix reçue d’un GIX, eux même configuré avec une Local Pref plus favorable que le transit-IP.
On regarde ce qu'il est possible de faire.
Cordialement,
Boris de Bouygues Telecom.
-
Ce qui est étonnant, c'est que celle local pref ne fonctionne par pour Adeli en temps normal.
Pourtant quand le peering via LyonIX tombe (Le LyonIX est tombé actuellement), on passe bien par le chemin utilisé par K-Net (preuve que la route Adeli est bien annoncé à Bouygues Telecom via le PNI de NeoTelecom) :
(https://www.lafibre.info/images/adeli/logo_adeli_mini.webp) Traceroute Bouygues Telecom => Adeli
On a : Bouygues Telecom => NeoTelecom => Ielo => Adeli
$ mtr -rwc100 lafibre.info
HOST: tpr-prod.lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.3 0.4 0.3 1.0 0.1
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 8.0% 100 0.4 5.5 0.3 137.2 23.3
3.|-- ae5.tcore01-m.net.bbox.fr 0.0% 100 0.6 8.9 0.5 71.5 16.8
4.|-- be35.cbr01-ntr.net.bbox.fr 0.0% 100 7.8 5.2 1.2 9.1 2.3
5.|-- lag13.rpt02-ix2.net.bbox.fr 0.0% 100 3.8 2.6 1.9 9.6 1.2
6.|-- 83.167.32.213.static.not.updated.neotelecoms.com 0.0% 100 1.9 2.2 1.8 26.8 2.5
7.|-- 83.167.55.46 0.0% 100 1.9 2.0 1.8 11.7 1.0
8.|-- xe2-1-0.ter1.eqx2.par.as8218.eu 0.0% 100 2.1 5.4 2.0 69.3 9.3
9.|-- ge1-5.br1.rdb.par.ielo.net 0.0% 100 1.6 3.8 1.4 12.0 3.3
10.|-- 10ge-5-2-cr2.th2.fr.rt.ielo.net 0.0% 100 7.5 3.8 1.4 12.1 3.3
11.|-- 2ge-e1-17-e1-18-cr5.le9-lyon.fr.rt.ielo.net 0.0% 100 8.6 10.6 8.4 19.1 3.2
12.|-- adeli1.ix-customers-le9lyon.ielo.net 0.0% 100 9.5 10.8 9.4 107.7 10.0
13.|-- lafibre.info 0.0% 100 9.6 9.5 9.4 10.2 0.1
(https://www.lafibre.info/images/adeli/logo_adeli_mini.webp) Traceroute Adeli => Bouygues Telecom :
On a : Adeli => Cogent (transit) => Bouygues Telecom
$ mtr -rwc100 testdebit.info
HOST: lafibre.info Loss% Snt Last Avg Best Wrst StDev
1.|-- portevlan.adeli.biz 0.0% 100 0.2 5.3 0.2 233.8 30.9
2.|-- vl219.mag01.lys01.atlas.cogentco.com 0.0% 100 9.0 17.1 8.8 150.0 26.1
3.|-- te1-3.ccr01.lys01.atlas.cogentco.com 0.0% 100 49.6 39.4 8.7 332.5 65.2
4.|-- te0-0-0-8.ccr21.par01.atlas.cogentco.com 0.0% 100 9.2 9.1 8.8 10.5 0.4
5.|-- te0-6-0-0.ccr21.par04.atlas.cogentco.com 0.0% 100 9.1 9.1 8.8 9.7 0.2
6.|-- 149.6.165.82 0.0% 100 10.0 10.6 9.6 24.6 1.8
7.|-- ae27.tcore02-t2.net.bbox.fr 0.0% 100 9.3 22.8 9.2 129.2 26.1
8.|-- po114.core03-t2.net.bbox.fr 0.0% 100 16.4 20.4 9.4 325.5 43.3
9.|-- v113.tengec5-10g.c6k01-t2.club-internet.fr 0.0% 100 9.5 9.6 9.4 10.5 0.2
10.|-- 89.84.127.55 0.0% 100 9.8 9.5 9.3 10.4 0.2
-
préfixe de taille différente annoncé d'un côté par rapport à l'autre ?
-
Gagné !
La même chose que pour le 176.128.0.0/10 qui passait uniquement par Level 3 car il y avait une annonce plus précise vers ce transitaire :
Incident résolut en annonçant 176.128.0.0/10 à Level 3.
Le problème étais lié à une annonce plus précise pour Level 3 (annonce de bloc plus petit que /10) alors que les autres ne recevaient qu'un /10.
BGP priorisant les annonces des plages plus petites, tout le trafic allait vers Level 3.
Cordialement,
Boris de Bouygues Telecom.
-
Aujourd'hui le réseau Bouygues Telecom est configuré avec la Local Pref appliquée au prefix reçue d’un PNI qui sera toujours plus forte que la Local Pref configurée sur les prefix reçue d’un GIX, eux même configuré avec une Local Pref plus favorable que le transit-IP.
On regarde ce qu'il est possible de faire.
Après avoir regardé avec mes collègues, je n'ai pas de solution pour que le flux Bouygues Telecom => K-Net passe par les GIX directement sans faire NeoTelecoms => Ielo => K-Net
Si on met la local pref des PNI équivalente à celle des GIX, on se retrouve avec deux routes avec le même poids car NeoTelecoms peer également avec Bouygues Telecom sur France-IX (back-up en cas de perte du PNI qui n'est pas sécurisé)
Si vous avez une solution sans que K-Net annonce des routes plus précises sur les GIX et sans mettre en place un PNI, je suis preneur.
-
Si vous avez une solution sans que K-Net annonce des routes plus précises sur les GIX et sans mettre en place un PNI, je suis preneur.
Je ne me rappelle plus si les communautés BGP traverse les routes servers.
Mais si on part dans cette direction, c'est presque un PNI ...
-
Euh peut être invité des gens de K-net sur ce sujet ?
-
@thenico : Je préférerais une solution qui soit générique et pas spécifique AS par AS.
K-Net est un exemple, mais de nombreux autres AS doivent être impactés.
Modifier les règles d’ingénierie uniquement pour K-Net, cela va être difficile.
-
@thenico : Je préférerais une solution qui soit générique et pas spécifique AS par AS.
Génériquement, Bouygues proposerait une communauté 5410:123 qui provoquerait l'application de la route-map ayant les propriétés suivantes:
- accepté uniquement des routes serveurs
- augmente la locale pref
- n'accepte que les routes entre /19 et /24 (inclus).
- n'accepte que les routes ayant un ASPATH à <= 2
- taggue en non exportable et/ou prepend fortement (pour éviter que Bouygues se retrouve en transitaire sans le vouloir)
Après, les AS étant sur un IX pourrait tagguer 5410:123 les routes partant vers le route serveur qu'elles veulent recevoir via l'IX.
-
Si je comprends bien, ce ne sera pas automatique du coté des opérateurs présents sur les route serveurs qui devront taguer 5410:123 pour que le flux passe en peering. Il faut donc que les AS qui souhaitent utiliser cette communauté le réalisent à la main ?
Je vais soumettre l'idée.
Pourquoi n'accepter que les routes entre /19 et /24 (inclus) ? La condition ASPATH à <= 2 me semble suffisante, non ?
-
Si je comprends bien, ce ne sera pas automatique du coté des opérateurs présent sur les route serveur qui devront taguer 5410:123 pour que le flux passe en peering. Il faut donc que les AS qui souhaitent utiliser cette communauté le réalise à la main ?
Oui, ce serait totalement volontaire du coté de l'AS d'origine.
Pourquoi n'accepter que les routes entre /19 et /24 (inclus) ? La condition ASPATH à <= 2 me semble suffisante, non ?
Ces 2 conditions sont là pour éviter les surprises du style:
- une AS annonce une full table
- une AS utilise un optimiseur de route (bidule qui aggrege de force les routes pour économiser de la place) et leak par accident ces routes internes (avec un ASPATH réécris)
- une AS veut MITM/fait une typo dans sa conf et annonce une /8 voire une /1
-
J'ai retrouvé un vielle loc pref qui traînait sur le routeur de bordure de lyon que j'ai retiré. Je pense que ca datait de l'époque
ou la saturation Lyonix / FranceIX était flagrante.
Ca donne qqch de plus cohérent maintenant :
1. border1-sgp.kwaoo.net 0.0% 3 0.4 0.4 0.4 0.4 0.0
2. border1-lyonix.kwaoo.net 0.0% 3 3.4 3.4 3.3 3.5 0.1
3. rr-l2-vlan500.ix.lyonix.net 0.0% 3 3.5 3.5 3.5 3.5 0.0
4. ???
5. ae27.tcore02-t2.net.bbox.fr 0.0% 3 11.4 14.3 11.3 20.1 5.0
6. po114.core03-t2.net.bbox.fr 0.0% 3 12.4 11.8 11.4 12.4 0.5
7. v113.tengec5-10g.c6k01-t2.club-internet.fr 0.0% 2 11.6 11.6 11.5 11.6 0.1
8. 89.84.127.55 0.0% 2 11.5 11.7 11.5 11.9 0.3
Je n'ai pas vu traîner de prepend particulier sur l'AS de BT, vivient tu peux nous faire un mtr dans l'autre sens stp ?
-
Avec du retard (vacances), voici le traceroute :
$ mtr -rwc100 lafibre.info
HOST: testdebit.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.5 1.2 0.3 68.1 6.8
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 10.0% 100 0.3 8.2 0.2 215.8 32.5
3.|-- v210.tengec1-20g.core03-t2.club-internet.fr 0.0% 100 0.5 5.0 0.3 193.9 23.6
4.|-- ae8.tcore02-t2.net.bbox.fr 0.0% 100 9.7 10.2 0.2 75.4 18.2
5.|-- la1.rpt02-th2.net.bbox.fr 92.0% 100 3.8 1.8 0.6 5.9 2.0
6.|-- equinix-paris.rezopole.net 0.0% 100 7.0 6.9 6.6 9.8 0.5
7.|-- adeli-l2.peers.lyonix.net 0.0% 100 8.0 10.6 7.8 217.4 21.0
8.|-- lafibre.info 0.0% 100 8.7 8.2 7.9 11.2 0.6
J'ai pas compris, c'est une local pref coté Bouygues Telecom ou coté K-Net qui faisait qu'on passait par NeoTelecoms ?
-
Chez K-net, pour le chemin retour, tu te doute bien que l'on peu ou pas de moyens d'influer. Bon retour a toi, c'est a mon tour de partir en vacances ;)
-
Il faut que j’arrête de poster après minuit...
J'ai fait un traceroute vers lafibre.info et non K-Net.
Pour K-Net Bouygues Telecom sort toujours par le PNI de NeoTelecom :
$ mtr -rwc100 k-net.Fr
HOST: testdebit.info Loss% Snt Last Avg Best Wrst StDev
1.|-- 89.84.127.61 0.0% 100 0.4 0.7 0.3 32.8 3.2
2.|-- v113.tengec5-10g.core04-t2.club-internet.fr 11.0% 100 0.3 9.7 0.2 191.5 34.0
3.|-- ae5.tcore01-m.net.bbox.fr 0.0% 100 67.9 47.4 0.7 154.9 39.4
4.|-- be35.cbr01-ntr.net.bbox.fr 0.0% 100 6.5 5.1 1.2 9.0 2.3
5.|-- lag13.rpt02-ix2.net.bbox.fr 77.0% 100 2.1 4.7 2.0 29.5 6.9
6.|-- 83.167.32.213.static.not.updated.neotelecoms.com 0.0% 100 1.8 2.1 1.7 29.0 2.8
7.|-- 83.167.55.46 0.0% 100 1.8 1.9 1.7 9.8 0.8
8.|-- xe2-1-0.ter1.eqx2.par.as8218.eu 0.0% 100 2.2 3.3 2.1 45.6 5.9
9.|-- ge1-5.br1.rdb.par.ielo.net 0.0% 100 8.9 4.5 1.9 12.6 3.5
10.|-- 10ge-5-2-cr2.th2.fr.rt.ielo.net 0.0% 100 1.5 3.7 1.4 11.7 3.4
11.|-- 2ge-e1-17-e1-18-cr5.le9-lyon.fr.rt.ielo.net 0.0% 100 8.6 11.5 8.3 54.2 5.6
12.|-- kwaoo.ix-customers-le9lyon.ielo.net 0.0% 100 8.6 8.7 8.5 9.3 0.1
13.|-- border1-sgp.kwaoo.net 1.0% 100 11.9 11.8 11.5 12.9 0.2
14.|-- pil.kwaoo.net 1.0% 100 12.5 12.5 12.1 13.7 0.3
-
La solution a été trouvée coté K-Net : découper en deux ses plages annoncées via les peering afin de forcer une route plus précises via les peering.
En effet une annonce BGP d'une plage plus petite est prioritaire sur une annonce d'une plage plus importante. Tous les opérateur qui peer avec K-Net ont donc une priorité absolue pour envoyer le trafic via le peering même si une Local Pref indique préférer un autre chemin.
Ce découpage n'a pour l'instant été fait que pour les clients K-Net du Calvados :
4,4ms depuis le DSLAM (18,1ms bout en bout avec la latence liée a la Bbox ADSL).
Le Peering est direct entre K-Net et Bouygues Telecom sur Equinix.
$ mtr -4rwc100 185.4.76.xx
HOST: BboxAdsl Loss% Snt Last Avg Best Wrst StDev
1.|-- bbox.lan 0.0% 100 0.6 0.6 0.6 0.9 0.0
2.|-- cha92-h03-31-38-122-254.dsl.sta.abo.bbox.fr 0.0% 100 14.7 15.4 13.7 25.1 2.3
3.|-- v56.core01-m.club-internet.fr 57.0% 100 15089 16897 14760 18308 1574.0
4.|-- be11.cbr01-ntr.net.bbox.fr 0.0% 100 17.1 19.3 15.7 23.5 2.2
5.|-- lag36.rpt02-th2.net.bbox.fr 80.0% 100 15.3 16.6 15.3 20.4 1.4
6.|-- kwaoo.equinix-ix.fr 0.0% 100 15.8 15.9 14.9 17.6 0.4
7.|-- core01-toq.dea.kwaoo.net 0.0% 100 20.9 22.7 20.4 55.5 5.8
8.|-- xx-76-4-185.ftth.cust.dea.kwaoo.net 0.0% 100 19.1 19.0 18.1 20.0 0.4
cf post Calvados: baisse du ping vers Internet pour les clients K-Net (https://lafibre.info/k-net-internet/calvados-baisse-du-ping/)