- Contenu
- TouIX
TouIX¶
Voir aussi TouSIX pour la partie SDN
Projet d'ajout de fonctionnalité au route server du TouIX via des communautés
- courriel d'annonce : http://lists.tetaneutral.net/pipermail/technique/2013-April/000833.html
- http://touix.net
- http://en.wikipedia.org/wiki/Route_server
- Voir la section Blackhole de BGP
- Manuel de BIRD http://bird.network.cz/?get_doc&f=bird.html
- A web application to assist in the management of Internet Exchange Points (IXPs) https://github.com/inex/IXP-Manager
- Project CARDIGAN An SDN Controlled Exchange Fabric Dean Pemberton http://conference.apnic.net/__data/assets/pdf_file/0011/58934/project-cardigan_1361872406.pdf
Acces au Route Server¶
- Jérôme Nicolle
- Laurent GUERBY
- Régis Séguier
Plan¶
- Etat des lieux
- Etudier les communautés proposées par les autres IX
- Regarder particulièrement le LyonIX comme le TouIX a une interco L3 avec le LyonIX
- Proposer des évolutions à valider par les utilisateurs et le bureau du TouIX
Etat des lieux¶
IPv4 + IPv6 fonctionnent via BIRD 1.3.9 sur une debian 6.0 squeeze
TODO
prefixes¶
2001:7f8:68::/48
91.213.236.0/24
Reunions¶
20130531¶
Premiere reunion fin mai debut juin :
http://framadate.org/8jloa9z1qe2pn2oo
http://lists.tetaneutral.net/pipermail/technique/2013-May/000870.html
Le vendredi 31 mai à 17h, Hotel des Telecom. Courriel par Régis :
Bonjour, Vous trouverez en PJ : - un document de travail sur les communautés BGP pouvant être utilisées avec le TouIX. - des synoptiques d'exemples d'échanges avec le fonctionnement décrit dans le document. Le document essaye de prendre en charge le plus de cas possibles (existant sur d'autres GIX) et répondre aux remarques qui ont déjà été faites (AS 16 vs 32 bits, support ou non des communautés étendues par le peer, prise en charge des routes blackholes). Plusieurs questions se posent : - permettre ou non la transparence de l'AS TouIX? permettre les deux modes (choix à l'adhésion de peer) ou qu'un seul sur le GIX? - la stratégies des échanges de routes/communautés en intra et inter GIX? propagation des communautés, limiter les communautés à destination du peer? mode de transparence ou non avec les autres GIX? n'autoriser que les annonces des routes des peers et non de leurs clients de transit (cf le cas d'IMS)? Type de connexion des GIX, LAN TouIX ou LAN autre GIX ou les deux?Passerelle? - mise en place d'une sécurité type limitation de routes? type ROA manuelle? ou évolution avec ROA dynamique via whois et/ou RPKI? (non possible sur bird pour le moment) - versionning de la configuration de bird (GIT) rendre la conf plus friendly (nommage par le nom du peer au lieux de R[AS]x[dernier octet IP]). - mise en place d'aggregations de routes (Ipv4 principalement)? (non possible sur bird pour le moment) Je me suis également imprégné de l'architecture L2 pour voir les solutions pertinentes avec l'architecture actuelle, pour, entre autres, la mise d'un second Route Serveur à plus ou moins long terme
Par Jérôme :
Le débat sur ce point se résume en théorie à : - Quand on route, on passe par l'AS du routeur qui route, et on l'ajoute au path - Quand on reflect, on passe d'un peer à l'autre sans passer par le reflector, donc pas d'AS sur le path En pratique, Mediactive a refusé la session avec l'AS du TOUIX dans le path, et je me suis fait railler à plusieurs reprises pour cette liberté qu'on a pris. ... Je préfère avoir l'AS et l'IP dans le protocole, je trouve justement ça beaucoup plus lisible. C'est aussi plus facile à parser dès lors qu'on voudra l'automatiser. Possible mais pas souhaitable. Un patch de Alexander V. Chernikov existe. OK pour le second route server, la machine d'origine est chez moi et peut être réinstallée relativement rapidement. Pour les communautés, quelques remarques : - Pas de prepending si pas de routage - Par défaut les routes sont envoyées à tout le monde, sauf si une communauté dit le contraire (inverser le sens de gix:peer, local:peer n'a pas d'utilité) - 6551x:local : les local-prefs sont toujours locales à un AS, pas d'utilité - 6552x:peer : attention, tout le monde n'utilises pas bgp deterministic-med, donc pas forcement utile. Ca se règle assez bien avec le prepend. - gix:0 : le blackhole me pose un problème de risque de nuisance de l'IX pour ses peers. Tout le monde ne pref pas l'IX de la même façon donc l'impact d'une route blackholée peut varier en fonction des peers. Enfin, il faut bien valider l'impact que ça pourrait avoir sur les GIX interconnectés en L3 : je doute que Lyonix apprécie qu'on aspire du trafic par blackhole. - NO_EXPORT et NO_ADV sont d’interprétation locale, je ne suis pas certain qu'on puisse les pousser pour compte de tiers. - Pas de subconfed : les confed sont des archis pourries qui ne devraient plus exister, on va pas les encourager ;) - les Route Origin et Route Target sont utilisées par MP-BGP pour matcher les routes sur des VRFs, elles ne doivent pas être utilisées dans un contexte Internet. - Le prepend pose le problème d'avoir l'AS du GIX dans le path, je préfèrerais que les prepends soient réalisés à la source uniquement. Si on y tiens, ce serait bien de se limiter à 3 ou 5 prepends max, au delà ça ne devrait pas servir à grand chose. Niveau implémentation on va avoir deux approches possibles en BIRD : fonction ou pipes. Les fonctions ne sont pas trop faites pour des traitements complexes de multiples cas, donc ça va peut être compliquer l'écriture et la maintenance du merdier. Les pipes rallongent significativement la conf : c'est plus pratique pour une génération de conf automatisée mais pas trop à des éditions manuelles. Cependant la génération automatique sera nécessaire si on décide de filtrer en IRR ou ROA, donc on va devoir l'envisager. Autre point : si on veut des route-servers hétérogènes (un BIRD et un OpenBGPD ou Quagga par exemple), alors il faut que la politique de traitement des routes soit implémentées de la même façon sur les deux, et j'aime autant prévenir : route-maps à rallonge et mappings, c'est horriblement chiant à maintenir ;)
Reunion 20130531 17h10
Presents :
- Claude
- Régis
- Jérôme
- Laurent
Discussion choix de /etc/rc.local via question de Regis => config plus courte que /etc/netwrok/interfaces
Modèle de switch C2960G-24TS-L- probleme detecte sur le storm control, peut-etre un pour tester chez ineonet sinon UPS
- peut-etre tester sur celui de l'HdT mais attention au waves
- nanoxion off definitif
- infomill 2 mois de delai administratif cogent
- ineonet le 10 juin au cogent
- adista a HdT peut-etre apres test switch
question regis :
Port 9 du switch neo, reponse dell R310 de tetaneutral.net en mode silencieux
- IMS AS20900 pas up sur le TouIX mais annonce son IPv6 a Paris (au moins absolight et he.net) 2001:1b08::/32
- autres IX ne l'ajoutent pas, le TouIX le fait, les adherents souhaitent le voir disparaitre du chemin
- accord de tous pour l'enlever "rs client" dans le template
- ATTENTION lors de l'enlevement de l'AS prevenir les utilisateurs de CISCO d'executer "bgp no enforce first as"
- controle d'IRR : entraide entre les membres
- controle d'IRR : Jerome dis que c'est un prerequis pour Nerim d'ici quelques semaines
- controle de communaute vers Lyonix : deja faisable avec les communautés Lyonix
- autre communauté
- Ughy dit que Level3 a une doc sur comment remplir les IRR, publique ?
- remarque de Claude : a budgeter equipements qui savent le faire pour la propal region
- on peut le faire en soft sur le R310 ttnn par exemple
- on choisit l'independance sur les communautés (proposition de Regis)
- generation de la conf BIRD a partir de fragments ou fichiers plus concis
- systeme de pipe au lyonix configure 100% web
TODO demander acces TOUIX a la web interface du Lyonix
Discussion methodes BIRD pour communaute- pipe ou import/export
- pipe avec interface web
- solution hybride
- service additionnel non present dans les ix, route vers null
- peval -e 'afi any.unicast AS197422'
- peval -e 'afi any.unicast AS-THSF-MAIN'
Attachements :
Schemas :
- Bloquée et propagation
- Mode GIX
- Prepend
- Sans Communauté
Prochaine réunion¶
TODO
Maquetage¶
Personnes interessees par une seance de maquetage BIRD- Laurent GUERBY
- Bertrand BONSIRVEN
- bikepunk
- Julien Aubé, selon disponibilité (si je suis pas là c'est pas grave)
- autre ?