GuiGui's Show - Liens« commit e8d3d2991f72613edb76dea244a8c8e4684873dd
Author: Christian Franke <chris@opensourcerouting.org>
Date: Fri Jul 5 15:35:39 2013 +0000
zebra: implement NEXTHOP_FLAG_ONLINK
On Linux, the kernel will only allow for a route to be installed when
its gateway is directly attached according the kernel fib.
There are cases when this restriction by the kernel is too strong, in
those cases, we deploy the RTNH_F_ONLINK netlink flag.
Signed-off-by: Christian Franke <chris@opensourcerouting.org>
Signed-off-by: David Lamparter <equinox@opensourcerouting.org> »
Soit 2 machines :
* A - ip a a 192.0.2.1/32 dev eth1 + ip r a 192.0.2.2/32 dev eth1
* B - ip a a 192.0.2.2/32 dev eth1 + ip r a 192.0.2.1/32 dev eth1
On monte une session iBGP entre 192.0.2.1 et 192.0.2.2. La session monte, les préfixes sont échangés.
Mais, dans Zebra, on a ceci (sh ip bgp) : B>* 172.16.23.49/32 [200/0] via 192.0.2.1 (recursive is directly connected, eth1), 00:00:13
Et dans la FIB (ip r s dev proto zebra) : 172.16.23.49 dev eth1
Il manque le next-hop. Zebra croit que 172.16.23.49 est directement connecté sur eth1. Ce qui n'est pas le cas. C'est bien un problème Zebra, puisque BGPd voit le bon next-hop : *>i172.16.23.49/32 192.0.2.1 0 100 0 i
Que se passe-t-il ? Nous utilisons une route de type kernel, par une route de type interface pour joindre l'autre routeur. Or, Linux veut une route d'interface : le routeur doit être directement connecté. Il faut donc positionner le flag « onlink ». Le man ip route nous dit : « onlink pretend that the nexthop is directly attached to this link, even if it does not match any interface prefix. ». Cette fonctionnalité a été ajouté dans Quagga 0.99.23. C'est indépendant du noyau, qui supporte déjà ce flag en 2.6.32, par exemple.
Avec une version récente :
B> 172.16.23.49/32 [200/0] via 198.18.0.1 (recursive), 00:55:26
* via 198.18.0.1, eth1 onlink, 00:55:26
172.16.23.49 via 198.18.0.1 dev eth1 onlink
Et BIRD dans tout ça ? Avant BIRD 1.4, le protocole kernel n'arrive pas à récupérer la route vers 198.18.0.X (le pair BGP) donc la session BGP n'est pas montée. Avec BIRD >= 1.4, la session BGP monte et le comportement est semblable à d'habitude :
sh routes : 192.0.2.42/32 via 198.18.0.2 on eth1 [bgp_test 15:47:56] ! (100/0) [i]
ip r s proto bird : 192.0.2.42 via 198.18.0.2 dev eth1
Évidemment, si vous montez une session iBGP, il ne faut pas utiliser la directive « direct » puisque la connexion au pair BGP se fait en utilisant une route. ;)
(
Permalink)