{{>toc}}

h1. TouIX

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 

h2. Acces au Route Server

# Jérôme Nicolle

# Laurent GUERBY

# Régis Séguier

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

h2. Etat des lieux

IPv4 + IPv6 fonctionnent via BIRD 1.3.9 sur une debian 6.0 squeeze

TODO

h2. Reunions

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

Par Régis :

<pre>

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

</pre>

Par Jérôme :

<pre>

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

</pre>

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

Adherents a venir

* 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

question IPv6

* IMS AS20900 pas up sur le TouIX mais annonce son IPv6 a Paris (au moins absolight et he.net) 2001:1b08::/32

Discussion sur le prepending de l'AS TouIX sur les chemins route server

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

Discussion sur les priorites

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

Discussion port mirroring pour statistiques

* 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

Discussion sur les communautés

* 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

Discussion sur les blackholes

* service additionnel non present dans les ix, route vers null

outil verification IRR

* peval -e 'afi any.unicast AS197422'

* peval -e 'afi any.unicast AS-THSF-MAIN'