BIRD/Quagga : différences et cas d'usage particuliers
jeudi 6 août 2015 à 02:06GuiGui's Show - Liens
Quagga et BIRD sont tous deux d'excellentes suites de logiciels de routage (création automatique des tables de routage, utilisées pour transférer les paquets IP).
Les deux sont très bons pour faire des tests et des maquettes mais en production (route server, routeur d'un FAI associatif ou autre petite structure,...), certaines contraintes apparaissent. Actuellement, ma préférence va à BIRD (pour les raisons que je vais exposer ci-dessous) mais sur un même réseau, même associatif, on peut vouloir de la diversité du code pour éviter les embrouilles (exemple : attribut 99 - https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/). Mais la diversité a un coût en maintenance : il faut maintenir deux fichiers de conf', dans deux syntaxes différentes et trouver les équivalences entre les syntaxes.
Bien que j'ai utilisé BIRD et Quagga dans différents contextes (RPKI+ROA (http://www.guiguishow.info/2013/09/18/securiser-le-routage-sur-internet/), OSPF (http://www.guiguishow.info/2013/07/27/routeurs-logiciels-et-ospf/), route reflector BGP (http://www.guiguishow.info/2013/09/15/mettre-en-place-un-route-reflector-bgp-avec-quagga-pour-samuser/)), je parlerai uniquement de BGP dans la suite de ce shaarli.
Différences entre BIRD et Quagga :
* Protocoles de routage supportés. BIRD : BGP, OSPF, BFD, RIP, static, RA. Quagga : BGP, OSPF, ISIS, RIP, static et, en dehors du package : OLSR et LDP.
* De par sa popularité, c'est souvent dans Quagga que sont développés des fonctionnalités/protocoles (exemples : Babel fût un temps ; RPKI-RTR ; Graceful Router Updates for Link-State Protocols,...)
* La modularité en démons (zebra, ospfd, bgpd,...) de Quagga semble mieux comprise que la modularité en protocoles de BIRD (kernel, ospf, bgp,...) alors qu'il s'agit de la même chose. Notons que l'un comme l'autre peut être compilé avec le support d'un nombre restreint de protocoles de routage (pour les adeptes du code minimal sur un router ;) ).
* BIRD est à la fois plus brut de fonderie (la syntaxe de la configuration, les filtres, bref tout ressemble à un langage de programmation avec sa syntaxe propre) mais est aussi plus simple, plus concis et plus compréhensible que l'enchaînement des commandes IOS que l'on retrouve dans Quagga. Ça se vérifie particulièrement pour l'usage de sessions BGP over IPv6. BIRD : fichier de configuration séparé, CLI séparée,... Quagga : il faut penser à virer le support IPv4 over IPv6 (no neighbor 2001:db8::1 activate) pour ne pas avoir de préfixes IPv4 qui circulent sur la session IPv6 puis à activer la capability Multiprotocol Extensions pour IPv6 (address-family ipv6 + neighbor 2001:db8::1 activate) puis bien positionner les filtres et compagnie dans le bloc de la capability. En ce sens, Quagga est plus brut de fonderie, respecte l'aspect extensions de BGP et le format des paquets alors que BIRD offre une abstraction : je veux faire de l'échange de préfixes IPv6 sur une session BGP over IPv6, point, active les extensions kiVontBien tout seul.
* BIRD supporte les tables de routage multiples (une par instance du protocole « kernel », directive « kernel table <table_ID> »). Quagga ne supporte pas les tables de routage multiples, seulement le changement de la table utilisée (directive « table » dans Zebra).
* BIRD permet de spécifier l'adresse source à indiquer lors de l'export des routes vers le kernel. Cela permet de faire en sorte que le routeur lui-même (ça ne concerne pas les paquets qui transit par le routeur mais dont le routeur n'est pas l'émetteur) utilise cette adresse IP lorsqu'il sortira un paquet vers une destination donnée en utilisant la route injectée par BIRD. Cela permet donc de jouer sur l'algorithme de sélection de l'adresse source à utiliser. Puisque certains prestataires (transitaires IP) bloquent le trafic sur les IPs d'interconnexion, cette directive permet de spécifier une IP de votre propre allocation et permet donc au routeur d'émettre avec cette IP plutôt qu'avec l'IP d'interconnexion. Il s'agit de la directive « krt_prefsrc = <IP_à_utiliser> » à spécifier dans un export filter dans le protocole « kernel » sous BIRD. Sous Quagga, l'équivalent est d'utiliser, dans Zebra, la directive « ip protocol bgp route-map <nom_routemap> » ainsi qu'une route-map avec la directive « set src <IP_à_utiliser> ». Cette directive n'est pas disponible en IPv6 sous Quagga... Voir ci-desous pour un contournement.
Quelques petits trucs à connaître :
* Lors de l'établissement d'une session iBGP directe (sans routeur intermédiaire), il faut ajouter la directive ... « direct » dans la configuration du protocole bgp de BIRD. Dans le cas contraire, BIRD s'attend à devoir utiliser une route existante pour transférer les paquets au next-hop indiqué dans les annonces BGP et, n'en trouvant pas, indique que toutes les routes échangées sont « unreachable ». Ce point ne concerne pas Quagga ;
* Si la session BGP over IPv6 est montée sur un adressage link-local (fe80::/10), il faut spécifier l'interface : « neighbor fe80::1%eth0 as 65000 » pour BIRD, «
neighbor fe80::1%eth0 interface eth0 » pour Quagga. Les adresses link-local IPv4 (169.254.0.0/16) ne sont pas concernées car pas considérées comme de véritables link-local (regardez un output de ip a s, le scope sera bien global ;) ) ;
* Pour reproduire le comportement de krt_prefsrc en IPv6 avec Quagga, il faut ruser : il faut utiliser une interface dummy avec l'IP globale à utiliser en « scope global » et indiquer un scope link pour toutes les autres interfaces réseau, même celles adressées avec des IPs globales. Ainsi, pour sortir, le noyau sera forcément obligé d'utiliser la seule IP dont la portée est globale, c'est-à-dire celle de la dummy. « ip a a <IP>/<netmask scope link dev eth0 » ou « scope link » dans /etc/network/interfaces pour rendre ça persistant. :)
* Il est d'usage de laisser les démons de routage créer une route de blackhole correspondante à l'allocation qui sera annoncée en BGP. Cela permet au routeur de se débarrasser au plus tôt d'un paquet pour lequel il ne connaît aucune route pour joindre la destination (cas d'une IP ou d'un sous réseau, que vous n'avez pas encore attribué). Cela permet également que ces paquets ne soient pas renvoyés sur l'interface de transit si vous n'avez pas filtré votre allocation en input de votre BGP. ;)
Sur BIRD, en IPv4, comme en IPv6 : « route <allocation> unreachable; » dans un protocole static.
Sous Quagga :
En IPv4 : « ip route <allocation> <netmask> Null0 » dans Zebra.
En IPv6, la cible blackhole (traduction de Null0 sous Linux) n'existe pas dans les vieux kernel (3.2). Or, Quagga souhaite rester compatible. Il faut donc ruser et utiliser la cible lo + reject : « ipv6 route <allocation> ::1 reject ».
Pour info, dans Linux : reject = unreachable = on rejette le paquet en envoyer un message ICMP à la source présumée du paquet ; drop = blackhole = on supprime le paquet sans rien dire.
* Soit l'interface tap d'une machine virtuelle configuée avec « ip a a 198.18.0.1/24 dev tap1 » et « ip r a 192.0.2.0/24 via 198.18.0.2 dev tap1 ». On sait que, lors de la destruction d'une interface, Linux nettoie les routes associées à cette interface. Que se passe-t-il à l'arrêt de la VM (ou sa migration à chaud avec Ganeti) ? BIRD : BIRD prend en compte la disparition de l'interface (protocole device) et fait aussi le ménage dans ses routes importées. Quagga : Quagga détecte bien la disparition de l'interface mais garde la route ... avec une interface inconnue (exemple : « 149.11.26.41, via unknown ») et continue à l'annoncer en iBGP ou en OSPF...
(Permalink)
Quagga et BIRD sont tous deux d'excellentes suites de logiciels de routage (création automatique des tables de routage, utilisées pour transférer les paquets IP).
Les deux sont très bons pour faire des tests et des maquettes mais en production (route server, routeur d'un FAI associatif ou autre petite structure,...), certaines contraintes apparaissent. Actuellement, ma préférence va à BIRD (pour les raisons que je vais exposer ci-dessous) mais sur un même réseau, même associatif, on peut vouloir de la diversité du code pour éviter les embrouilles (exemple : attribut 99 - https://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment/). Mais la diversité a un coût en maintenance : il faut maintenir deux fichiers de conf', dans deux syntaxes différentes et trouver les équivalences entre les syntaxes.
Bien que j'ai utilisé BIRD et Quagga dans différents contextes (RPKI+ROA (http://www.guiguishow.info/2013/09/18/securiser-le-routage-sur-internet/), OSPF (http://www.guiguishow.info/2013/07/27/routeurs-logiciels-et-ospf/), route reflector BGP (http://www.guiguishow.info/2013/09/15/mettre-en-place-un-route-reflector-bgp-avec-quagga-pour-samuser/)), je parlerai uniquement de BGP dans la suite de ce shaarli.
Différences entre BIRD et Quagga :
* Protocoles de routage supportés. BIRD : BGP, OSPF, BFD, RIP, static, RA. Quagga : BGP, OSPF, ISIS, RIP, static et, en dehors du package : OLSR et LDP.
* De par sa popularité, c'est souvent dans Quagga que sont développés des fonctionnalités/protocoles (exemples : Babel fût un temps ; RPKI-RTR ; Graceful Router Updates for Link-State Protocols,...)
* La modularité en démons (zebra, ospfd, bgpd,...) de Quagga semble mieux comprise que la modularité en protocoles de BIRD (kernel, ospf, bgp,...) alors qu'il s'agit de la même chose. Notons que l'un comme l'autre peut être compilé avec le support d'un nombre restreint de protocoles de routage (pour les adeptes du code minimal sur un router ;) ).
* BIRD est à la fois plus brut de fonderie (la syntaxe de la configuration, les filtres, bref tout ressemble à un langage de programmation avec sa syntaxe propre) mais est aussi plus simple, plus concis et plus compréhensible que l'enchaînement des commandes IOS que l'on retrouve dans Quagga. Ça se vérifie particulièrement pour l'usage de sessions BGP over IPv6. BIRD : fichier de configuration séparé, CLI séparée,... Quagga : il faut penser à virer le support IPv4 over IPv6 (no neighbor 2001:db8::1 activate) pour ne pas avoir de préfixes IPv4 qui circulent sur la session IPv6 puis à activer la capability Multiprotocol Extensions pour IPv6 (address-family ipv6 + neighbor 2001:db8::1 activate) puis bien positionner les filtres et compagnie dans le bloc de la capability. En ce sens, Quagga est plus brut de fonderie, respecte l'aspect extensions de BGP et le format des paquets alors que BIRD offre une abstraction : je veux faire de l'échange de préfixes IPv6 sur une session BGP over IPv6, point, active les extensions kiVontBien tout seul.
* BIRD supporte les tables de routage multiples (une par instance du protocole « kernel », directive « kernel table <table_ID> »). Quagga ne supporte pas les tables de routage multiples, seulement le changement de la table utilisée (directive « table » dans Zebra).
* BIRD permet de spécifier l'adresse source à indiquer lors de l'export des routes vers le kernel. Cela permet de faire en sorte que le routeur lui-même (ça ne concerne pas les paquets qui transit par le routeur mais dont le routeur n'est pas l'émetteur) utilise cette adresse IP lorsqu'il sortira un paquet vers une destination donnée en utilisant la route injectée par BIRD. Cela permet donc de jouer sur l'algorithme de sélection de l'adresse source à utiliser. Puisque certains prestataires (transitaires IP) bloquent le trafic sur les IPs d'interconnexion, cette directive permet de spécifier une IP de votre propre allocation et permet donc au routeur d'émettre avec cette IP plutôt qu'avec l'IP d'interconnexion. Il s'agit de la directive « krt_prefsrc = <IP_à_utiliser> » à spécifier dans un export filter dans le protocole « kernel » sous BIRD. Sous Quagga, l'équivalent est d'utiliser, dans Zebra, la directive « ip protocol bgp route-map <nom_routemap> » ainsi qu'une route-map avec la directive « set src <IP_à_utiliser> ». Cette directive n'est pas disponible en IPv6 sous Quagga... Voir ci-desous pour un contournement.
Quelques petits trucs à connaître :
* Lors de l'établissement d'une session iBGP directe (sans routeur intermédiaire), il faut ajouter la directive ... « direct » dans la configuration du protocole bgp de BIRD. Dans le cas contraire, BIRD s'attend à devoir utiliser une route existante pour transférer les paquets au next-hop indiqué dans les annonces BGP et, n'en trouvant pas, indique que toutes les routes échangées sont « unreachable ». Ce point ne concerne pas Quagga ;
* Si la session BGP over IPv6 est montée sur un adressage link-local (fe80::/10), il faut spécifier l'interface : « neighbor fe80::1%eth0 as 65000 » pour BIRD, «
neighbor fe80::1%eth0 interface eth0 » pour Quagga. Les adresses link-local IPv4 (169.254.0.0/16) ne sont pas concernées car pas considérées comme de véritables link-local (regardez un output de ip a s, le scope sera bien global ;) ) ;
* Pour reproduire le comportement de krt_prefsrc en IPv6 avec Quagga, il faut ruser : il faut utiliser une interface dummy avec l'IP globale à utiliser en « scope global » et indiquer un scope link pour toutes les autres interfaces réseau, même celles adressées avec des IPs globales. Ainsi, pour sortir, le noyau sera forcément obligé d'utiliser la seule IP dont la portée est globale, c'est-à-dire celle de la dummy. « ip a a <IP>/<netmask scope link dev eth0 » ou « scope link » dans /etc/network/interfaces pour rendre ça persistant. :)
* Il est d'usage de laisser les démons de routage créer une route de blackhole correspondante à l'allocation qui sera annoncée en BGP. Cela permet au routeur de se débarrasser au plus tôt d'un paquet pour lequel il ne connaît aucune route pour joindre la destination (cas d'une IP ou d'un sous réseau, que vous n'avez pas encore attribué). Cela permet également que ces paquets ne soient pas renvoyés sur l'interface de transit si vous n'avez pas filtré votre allocation en input de votre BGP. ;)
Sur BIRD, en IPv4, comme en IPv6 : « route <allocation> unreachable; » dans un protocole static.
Sous Quagga :
En IPv4 : « ip route <allocation> <netmask> Null0 » dans Zebra.
En IPv6, la cible blackhole (traduction de Null0 sous Linux) n'existe pas dans les vieux kernel (3.2). Or, Quagga souhaite rester compatible. Il faut donc ruser et utiliser la cible lo + reject : « ipv6 route <allocation> ::1 reject ».
Pour info, dans Linux : reject = unreachable = on rejette le paquet en envoyer un message ICMP à la source présumée du paquet ; drop = blackhole = on supprime le paquet sans rien dire.
* Soit l'interface tap d'une machine virtuelle configuée avec « ip a a 198.18.0.1/24 dev tap1 » et « ip r a 192.0.2.0/24 via 198.18.0.2 dev tap1 ». On sait que, lors de la destruction d'une interface, Linux nettoie les routes associées à cette interface. Que se passe-t-il à l'arrêt de la VM (ou sa migration à chaud avec Ganeti) ? BIRD : BIRD prend en compte la disparition de l'interface (protocole device) et fait aussi le ménage dans ses routes importées. Quagga : Quagga détecte bien la disparition de l'interface mais garde la route ... avec une interface inconnue (exemple : « 149.11.26.41, via unknown ») et continue à l'annoncer en iBGP ou en OSPF...
(Permalink)