Projet

Général

Profil

BIRD » Historique » Version 53

« Précédent - Version 53/55 (diff) - Suivant » - Version actuelle
Laurent GUERBY, 14/05/2014 18:08


BIRD

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

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

Support ou Donation

Site : http://bird.network.cz/?support
Courriel de présentation : http://lists.tetalab.org/pipermail/tetaneutral/2013-May/001742.html

  • Pour
  1. Laurent GUERBY (entre 100 et 500 euros suivant dispo)
  2. Solarus
  3. bikepunk
  4. Matthieu Herrb
  5. Mehdi Abaakouk
  6. Autre
  • Contre
    1. Autre

Volontaires

  • Laurent GUERBY
  • autre

HOWTO

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

Spécification du projet

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

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

Misc

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.

Misc

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.

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.

Static

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;

     };

   };

};

Configuration

# 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;
}