BIRD¶

Implémentation GPL du protocole BGP
http://bird.network.cz/

Volontaires¶

• Laurent GUERBY
• autre

HOWTO¶

• ou intervenir sur le code de BIRD ?
• proposition ici

Spécification du projet¶

• http://lists.tetaneutral.net/pipermail/technique/2012-March/000230.html
• http://www.toulibre.org/archives/toulouse-ll/2012-March/006926.html

Temps estimé une semaine pour quelqu'un qui connait le C mais pas le code de BIRD.

From: Benjamin Cama
To: Laurent GUERBY
Cc: adminsys
Subject: Proposition d'amélioration pour BIRD
Date: Tue, 06 Mar 2012 01:18:31 +0100

Bonjour,

BIRD est un démon de routage qui est utilisé chez FDN pour gérer le
routage de ses abonnés, de ses services, et également des FAI locaux
avec qui il partage sa collecte ADSL. Ce démon est configuré sur deux
machines qui collectent les lignes ADSL avec basculement automatique
(failover) de l'une à l'autre en cas de besoin ou de problème. Ces
lignes sont collectées en L2TP grâce au logiciel l2tpns.

Actuellement, l2tpns ajoute/supprime les routes des abonnés quand il se
connectent/déconnectent automatiquement, dans la table de routage du
kernel. BIRD extrait ces informations du kernel pour les propager en BGP
à d'autres routeurs. Les FAI locaux ayant des interconnexions diverses
avec FDN et des adressages différents, filtrer les routes ainsi
importées du kernel fait intervenir des filtres qui peuvent devenir
complexes.

Une solution serait de filtrer uniquement sur le « protocole » de la
route, ainsi qu'indiqué par le kernel. En effet, chaque route contenue
dans les tables de routage du kernel contient un champ qui indique le
« protocole » qui a ajouté cette route, et l2tpns renseigne cette
information quand il en ajoute une (c'est une version patchée pour faire
ça, cf http://dolka.fr/code/l2tpns.git ). Cela est visible par le
mot-clé « proto » dans les routes affichées par l'utilitaire iproute2
(le protocole n'est pas visible avec l'ancien utilitaire « route »).
Nous pourrions ainsi importer les routes de l2tpns uniquement en
filtrant sur cet attribut.

Malheureusement, BIRD ne sait actuellement pas filtrer sur cet attribut
(cf le thread
http://www.mail-archive.com/bird-users@atrey.karlin.mff.cuni.cz/msg01425.html
entre autres). Le travail consisterait donc en l'implémentation d'un
attribut « kernel protocol » (ou autre meilleur nom) dans les
“route entry” de BIRD afin de pouvoir filtrer dessus.

Le site de BIRD est http://bird.network.cz/ et présente leur dépôt git
où se trouve le code. Une bonne compréhension des principes de BIRD
(assez déroutant quand on est habitué à d'autres démons de routage) est
nécessaire avant de se lancer dans le projet.

Merci et bon courage à celui qui voudra bien se lancer là-dedans !

benjamin

Date: Tue, 06 Mar 2012 12:06:52 +0100

Je viens de voir qu'il existe déjà certains attributs spécifiques aux
routes kernel de linux qui sont utilisés dans bird, cf
http://bird.network.cz/?get_doc&f=bird-6.html#ss6.4
en particulier krt_realm (qui pourrait être intéressant pour nous pour
classifier les routes des FAI locaux ; je ne connaissais pas cet
attribut). Ça ne devrait pas être trop dur de se baser dessus pour faire
l'équivalent « krt_proto ».

Date: Tue, 06 Mar 2012 12:28:21 +0100

Pour préciser ma pensée, j'ai lu
http://www.policyrouting.org/PolicyRoutingBook/ONLINE/CH07.web.html
et des realms différents pourraient être assignés à chaque FAI local dès
qu'un paquet rentre du tun depuis ses IP, ou de l'interco. Ainsi, on
pourrait facilement les repérer, et par exemple les null-router s'ils
veulent passer par la route par défaut de FDN. Comme ça, on « sépare »
bien les trafics.

Juste une idée comme ça.

Date: Tue, 06 Mar 2012 12:18:35 +0100

Et des fois, on se demande WTF ? :

% cat /etc/iproute2/rt_realms
#
# reserved values
#
0       cosmos
#
# local
#
#1      inr.ac
#2      inr.ruhep
#3      freenet
#4      radio-msu
#5      russia
#6      internet

benjamin

Date: Sun, 11 Mar 2012 02:26:46 +0100

J'ai commencé à regarder. En fait le champ protocol est déjà présent
dans les structures de données de bird et netlink le renseigne correctement;
fichier nest/route.h, ligne 209:

    struct {                /* Routes generated by krt sync (both temporary and inherited ones) */
      s8 src;                /* Alleged route source (see krt.h) */
      u8 proto;                /* Kernel source protocol ID */
      u8 type;                /* Kernel route type */
      u8 seen;                /* Seen during last scan */
      u32 metric;            /* Kernel metric */
    } krt;

Du coup il faut juste adapter le parser et l'interpréteur.

Jérémie