Deux démons se partagent le routage dynamique sous Linux : BIRD et FRRouting. Les deux parlent BGP, OSPF, gèrent des full-feed à plus d'un million de routes, tournent en prod chez de gros acteurs. Et pourtant le choix n'est pas une question de goût. Ils ne sont pas bons aux mêmes endroits, et prendre le mauvais pour le mauvais rôle, c'est se compliquer la vie pour rien. Le clivage tient en une opposition simple : un démon unique avec un langage de filtres puissant d'un côté, une suite multi-démon façon routeur Cisco de l'autre.
Deux architectures opposées
FRRouting descend de Quagga, lui-même héritier de Zebra. Des développeurs Quagga de longue date ont forké pour avancer plus vite, et FRR est aujourd'hui le standard de fait côté Linux. Son architecture est multi-démon : un processus par protocole. bgpd pour BGP, ospfd pour OSPF, zebra au centre qui coordonne tout le monde et parle au noyau via Netlink pour programmer la FIB. On configure via vtysh, un shell qui imite la CLI Cisco, mode enable, configure terminal, router bgp, la totale. Un admin réseau qui vient du monde Cisco ou Juniper se sent immédiatement chez lui. C'est un argument réel, pas cosmétique : la courbe d'apprentissage est plate pour qui a déjà fait du routage en entreprise.
BIRD prend le chemin inverse. Développé par CZ.NIC (les gens derrière le registre .cz), c'est un démon unique qui gère tous les protocoles dans un seul processus. Pas de vtysh, pas de mimétisme Cisco. Sa configuration est un langage déclaratif à lui, avec une notion centrale qui change tout : les filtres. Dans BIRD, un filtre est un vrai petit programme, avec des variables, des conditions, des manipulations de communities et de chemins, exécuté sur chaque route avant qu'elle entre ou sorte d'une table. Cette expressivité est la raison pour laquelle BIRD règne sur un terrain précis.
Les route-servers d'IX, terrain BIRD
Un point d'échange Internet (IX) fait dialoguer des centaines de membres. Sans route-server, chaque membre devrait monter une session BGP avec chaque autre : un full-mesh ingérable. Le route-server centralise, comme un route-reflector le fait en iBGP. Et ce route-server, dans la quasi-totalité des IX de la planète, c'est BIRD.
La raison est dans les filtres. Un route-server d'IX doit appliquer une politique fine et par membre : filtrer selon l'IRR, valider les origines RPKI, gérer des communities de contrôle qui laissent chaque membre dire « annonce-moi ça à celui-là mais pas à celui-ci ». Le langage de filtres de BIRD écrit ça naturellement, et son architecture mono-processus tient des tables énormes avec une empreinte mémoire contenue. CZ.NIC cible explicitement les IXP et les gros CDN comme utilisateurs principaux. Une session de route-server typique, côté config, ressemble à ça :
# BIRD 2.x : route-server avec filtre d'import par membre
filter rs_import_member_a {
# rejette si l'origine n'est pas RPKI valid
if (roa_check(t_roa, net, bgp_path.last) = ROA_INVALID) then reject;
# rejette les préfixes trop spécifiques
if (net.len > 24) then reject;
accept;
}
protocol bgp member_a {
local as 64500;
neighbor 198.51.100.10 as 64510;
ipv4 {
import filter rs_import_member_a;
export all;
};
}
La validation RPKI est intégrée nativement : BIRD parle RTR et applique roa_check dans ses filtres. Pour le contexte complet de la chaîne RPKI, du validateur jusqu'au rejet des Invalid, voir RPKI en production avec Routinator et Krill. Sur ce terrain des route-servers et de la politique BGP fine, FRR sait faire, mais il est plus verbeux et moins à l'aise. BIRD est l'outil taillé pour ça.
La fabric datacenter, terrain FRR
Changez de décor. Vous montez une fabric leaf-spine dans un datacenter, du BGP jusqu'au top-of-rack, de l'EVPN-VXLAN pour étirer du L2 entre racks sans STP. Ici, c'est FRR qui domine, et largement.
FRR implémente BGP-EVPN comme plan de contrôle pour transporter les adresses MAC et les routes entre VTEP, avec le support des VNI L2 et L3, des route-distinguishers et des route-targets. Il apprend la configuration des interfaces Linux via Netlink et programme la FIB du noyau directement. C'est cette intégration au plan de données Linux qui en fait le démon des distributions de fabric : Cumulus Linux le portait, SONiC s'appuie dessus, et la plupart des déploiements Kubernetes qui ont besoin de BGP (annoncer des IP de services, du pod routing) sortent FRR, pas BIRD. Le support BFD pour la détection rapide de panne de lien, indispensable dans une fabric où on veut reconverger en dizaines de millisecondes, est mûr côté FRR.
! FRR : BGP EVPN pour fabric VXLAN, plan de contrôle L2/L3
router bgp 65001
neighbor SPINE peer-group
neighbor SPINE remote-as external
neighbor swp1 interface peer-group SPINE
!
address-family l2vpn evpn
neighbor SPINE activate
advertise-all-vni
exit-address-family
!
La logique de BGP non-numéroté sur interface (neighbor swp1 interface), l'advertise-all-vni, ce sont des constructions pensées pour la fabric, et FRR les rend simples. Pour le contexte VXLAN-SDN au-dessus de l'hyperviseur, l'article sur le routeur de datacenter avec VyOS montre une autre approche du routage en bordure de DC, VyOS embarquant d'ailleurs FRR sous le capot.
Communities, filtres, exploitation
Les deux gèrent les communities standard, étendues et larges. La différence est dans l'écriture. BIRD manipule les communities comme des données de première classe dans ses filtres : on teste, on ajoute, on retire, on filtre sur des listes de communities avec une syntaxe lisible. FRR le fait via des community-list, des route-map et des set community, plus proche de la grammaire Cisco, plus segmenté. Pour une politique BGP complexe et conditionnelle, BIRD demande moins de lignes et reste plus lisible une fois qu'on a passé la barrière de son langage. Pour une politique classique de transitaire ou d'entreprise, FRR avec ses route-maps fait parfaitement le travail et parle à plus de monde.
Côté exploitation, FRR profite de son héritage Cisco : show ip bgp summary, show bgp l2vpn evpn, les commandes sont familières et la documentation abonde. BIRD a ses propres commandes (birdc show route, birdc show protocols), parfaitement utilisables mais qui demandent un temps d'adaptation. Quand une session se comporte mal, quel que soit le démon, les méthodes de debug réseau restent la première ligne : capture, état des sessions, table de routage, avant de toucher à la config.
Verdict
Pas de « ça dépend » mou. Le rôle tranche.
Route-server d'IX, politique BGP fine et conditionnelle, validation RPKI au cœur du filtrage, full-feed avec empreinte mémoire serrée : BIRD. C'est son terrain, le langage de filtres n'a pas d'équivalent et c'est ce que tournent les IX du monde entier. Ne réinventez pas la roue, prenez ce que la profession a déjà tranché.
Fabric datacenter leaf-spine, EVPN-VXLAN, BGP jusqu'au ToR, intégration Kubernetes, BFD pour reconvergence rapide, équipe qui vient du monde Cisco : FRRouting. L'intégration au plan de données Linux et le support EVPN en font le choix par défaut de la fabric moderne, et la CLI familière réduit le coût d'entrée.
Pour un routeur de bordure d'entreprise classique, du transit, du peering simple : les deux marchent, prenez celui que votre équipe sait exploiter. Si personne n'a d'historique, FRR pour la CLI familière. Si vous avez besoin de filtres tordus, BIRD. Le mauvais choix n'est pas BIRD ou FRR, c'est de prendre BIRD pour une fabric EVPN ou FRR pour un route-server d'IX exigeant : dans les deux cas, vous ramez contre l'outil.
Sources
- The BIRD Internet Routing Daemon Project : documentation officielle, architecture mono-démon et langage de filtres.
- BIRD User's Guide, Protocols : configuration BGP, route-server, validation RPKI et communities.
- FRRouting, documentation EVPN : BGP-EVPN, VNI L2/L3, fabric VXLAN.
- FRRouting, documentation Zebra : démon central, programmation de la FIB via Netlink.
- FRRouting, présentation du projet : origine Quagga, architecture multi-démon et protocoles supportés.
