{{>toc}}

h1. BIRD

Implémentation GPL du protocole [[BGP]]

http://bird.network.cz/

h2. Liens

cheat sheet

http://bird.mpls.in/projects/mpls-bird/wiki/Bird_cheatsheet

http://vincent.bernat.im/en/blog/2011-dns-anycast.html

https://git.nic.cz/redmine/projects/bird/wiki/OSPF_example

bird related software

https://redmine.labs.nic.cz/projects/bird/wiki/Related

bird to mail

http://sourceforge.net/projects/swatch/

http://mmonit.com/monit/

http://simple-evcorr.sourceforge.net/

a tool that maintains the ROA table in BIRD, i.e.,  automatically adds and deletes ROA information

https://github.com/rtrlib/bird-rtrlib-cli

h2. Support ou Donation

Site : http://bird.network.cz/?support

Courriel de présentation : http://lists.tetalab.org/pipermail/tetaneutral/2013-May/001742.html

* Pour

# Laurent GUERBY (entre 100 et 500 euros suivant dispo)

# Solarus

# bikepunk

# Matthieu Herrb

# Mehdi Abaakouk

# Autre

* Contre

# Autre

h2. Volontaires

* Laurent GUERBY

* autre

h2. HOWTO

* ou intervenir sur le code de BIRD ?

* proposition ici

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

<pre>

% 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

</pre>

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:

<pre><code class="C">

    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;

</pre>

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

Jérémie

Date: Sun, 11 Mar 2012 13:05:28 +0100

J'ai rajouté l'accès à deux attributs depuis les filtres: krt_source et krt_proto.

Ils ont la même signification, la seule différence c'est que krt_proto est plus précis et est OS-dependent

mais n'est renseigné qu'avec netlink.

Le code est ici:

http://solaria.dimino.org/gitweb/?p=bird.git;a=summary

Les valeurs possibles pour krt_source sont:

* @KRT_SRC_BIRD@

* @KRT_SRC_REDIRECT@

* @KRT_SRC_ALIEN@

* @KRT_SRC_KERNEL@

et pour krt_proto (avec netlink uniquement):

* @KRT_PROTO_UNSPEC@

* @KRT_PROTO_REDIRECT@

* @KRT_PROTO_KERNEL@

* @KRT_PROTO_BOOT@

* @KRT_PROTO_STATIC@

* @KRT_PROTO_GATED@

* @KRT_PROTO_RA@

* @KRT_PROTO_MRT@

* @KRT_PROTO_ZEBRA@

* @KRT_PROTO_BIRD@

* @KRT_PROTO_DNROUTED@

* @KRT_PROTO_XORP@

* @KRT_PROTO_NTK@

* @KRT_PROTO_DHCP@

Jérémie

h2. Misc

<pre>

From: 	Ondrej Zajicek <santiago@crfreenet.org>

To: 	Tapio Haapala <tapio.haapala@f-solutions.fi>

Cc: 	bird-users@network.cz

Subject: 	Re: bgp community loggin/export

Date: 	Thu, 8 Mar 2012 11:29:25 +0100

As cmmunities already answered by others, i just note that for traffic

accounting probably the better way than using iptables is to use ip

realms for routes (route attribute krt_realm in BIRD), kernel

automatically keeps statistics for different realms.

</pre>

h2. Misc

h3. Misc Routes

If you need to create some routes just for the purpose of exporting them

to BIRD, you could create them as unreachable routes:

ip route add unreachable 192.168.1.0/24

So you don't have to specify a next hop or an iface. When such route is

exported to OSPF, only the prefix matters.

h3. import or export

So for each protocol :

- you *import* route from the protocol to the bird routing table

- you *export* route to the protocol from the birdrouting table

Reminber also, that the bird routing table is not the kernel routing table.

h3. Static

<pre>

Subject: 	RE: BGP and Redistribute Static with AS-Prepend

Date: 	Thu, 3 Jan 2013 07:49:55 +0000 (01/03/2013 08:49:55 AM)

protocol static {

  route 2.2.2.2/32 via 10.1.2.1; 

}

protocol bgp test {

   local as 65501;

   neighbor 10.2.3.3 as 65501;

   export filter {

     if ( source = RTS_STATIC && net = 2.2.2.2/32 ) then {

       bgp_path.empty;

      bgp_path.prepend(65502);

       bgp_path.prepend(65501);

       accept;

     };

   };

};

</pre>

h2. Configuration

<pre>

# cat /etc/bird.conf

router id 91.224.148.2;

define myas = 197422;

protocol device {

	scan time 10;

}

protocol static static_bgp {

	import all;

	route 91.224.148.0/23 reject; # PI

        route 80.67.182.0/24 reject; # PA gitoyen

        route 89.234.156.0/23 reject; # PAopdop

}

protocol kernel {

	import all;

	export all;

	learn;

}

filter bgp_OUT {

	if (net ~ [91.224.148.0/23, 80.67.182.0/24, 89.234.156.0/23]) then {

          accept;

        }

	reject;

}

filter bgp_IN {

        accept;

}

protocol bgp TOUIX {

        local as myas;

        neighbor 91.213.236.1 as 47184;

        preference 400;

        import filter bgp_IN; 

        export filter bgp_OUT;

}

protocol bgp FULLSAVE_COGENT {

         local as myas;

         neighbor 93.93.40.152 as 39405;

         import filter bgp_IN;

         export filter bgp_OUT;

}

</pre>