Auteur Sujet: AS-path prepend utilisé par K-Net ? (Lu 39847 fois)

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

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

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).

vivien · « **Réponse #1 le:** 29 juin 2013 à 18:38:57 »

Pour compléter les traceroutes inverse passent bien par les peering :

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

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

Snickerss · « **Réponse #2 le:** 29 juin 2013 à 19:11:25 »

Merci pour l'explication

Bensay · « **Réponse #3 le:** 29 juin 2013 à 19:44:18 »

Citation de: Snickerss le 29 juin 2013 à 19:11:25

Merci pour l'explication

Très bon dossier effectivement

Merci pour les connaissances glané au passage.

Cordialement

Bensay

vivien · « **Réponse #4 le:** 29 juin 2013 à 22:29:31 »

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 :

SmokePing de la même destinations (forum.k-net.fr) mais depuis Maxnod / Adeli :

Le problème est également sur le site web. Graphe du site k-net.fr en IPv6 :

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 :

thenico · « **Réponse #5 le:** 30 juin 2013 à 01:18:04 »

Le looking glass d'HE permet de voir que c'est une décision de routage venant de Bouygues:

Code: [Sélectionner]

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.

vivien · « **Réponse #6 le:** 30 juin 2013 à 09:43:29 »

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)

Citation de: rmaunier le 30 mars 2012 à 01:47:27

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 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 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

vivien · « **Réponse #7 le:** 30 juin 2013 à 10:20:21 »

Mauvaise analyse, K-Net non plus ne récupère pas le peering de NeoTelecoms via les "route serveur" de France-IX :

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

Boris de Bouygues Telecom · « **Réponse #8 le:** 01 juillet 2013 à 17:39:00 »

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.

vivien · « **Réponse #9 le:** 11 juillet 2013 à 11:10:16 »

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) :

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

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

Synack · « **Réponse #10 le:** 13 juillet 2013 à 11:14:44 »

préfixe de taille différente annoncé d'un côté par rapport à l'autre ?

vivien · « **Réponse #11 le:** 13 juillet 2013 à 11:16:49 »

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 :

Citation de: Boris de Bouygues Telecom le 23 mai 2013 à 10:43:40

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.