Bonjour, Je vais me répondre à moi-même puisque depuis que j'ai posé la question, j'ai pu trouver une solution efficace, pas trop compliquée et qui réponde au besoin exprimé. Si ça peut interesser quelqu'un autant que ça serve ;)
Petit rappel tout d'abord : le besoin exprimé était de pouvoir mettre en œuvre des routeurs BGP redondants et tolérants à la panne. La solution la plus simple qui avait été testée était simplement d'utiliser du VRRP avec une paire d'adresses virtuelles (une publique et une privée pour la gateway). Le soucis majeur qui se pose alors, c'est le délai nécessaire à la remontée des sessions BGP qui prend plusieurs minutes, et du coup provoque une rupture de lien complète pendant cette période. Je ne vais pas vous redonner tout le détail de mes tribulations (vous en avez déjà une partie dans l'archive de la liste ;) ) mais juste aller à l'essentiel. La solution que j'ai retenue oblige au fonctionnement suivant. Tout d'abord, les deux routeurs seront actifs en même temps, pour ne pas avoir de latence en cas de panne de l'un d'eux (il n'y a pas de mystère : monter des sessions BGP, ça prend du temps). Les sessions BGP seront montées en double (sur chaque routeur), ce qui induit du trafic entrant par les deux routeurs, mais une seule gateway sera utilisée (on pourrait faire en sorte d'utiliser les deux, mais ça complique un peu la gestion des passerelles). Du coup, seul un des deux routeurs assumera la sortie du trafic. La configuration s'appuie sur une idée simple. Chaque routeur sera le backup de l'autre. Ca signifie que chaque routeur se voit attribuer une IP virtuelle sur chaque patte (donc 4 VIP : 2 publiques et 2 privées pour la gateway). En cas de panne, le routeur restant prendra alors automatiquement les IP de son homologue en perdition et récupérera tout le trafic résiduel le temps que les sessions BGP tombent. En revanche, pour ne pas provoquer de rupture au moment du retour du routeur malade, il FAUT que la pondération sur l'IP virtuelle privée qui sert de passerelle soit égale pour chaque routeur. Ca induit qu'on ne peut pas prédire quel routeur assumera le trafic, mais ça empêchera la rupture si le "master" reprend la main alors qu'il n'a pas remonté ses sessions BGP, car le VRRP, en cas de pondération égale ne "change rien" (si deux routeurs sont actifs et qu'ils veulent la même ressource avec le même poids/coef, c'est celui qui avait déjà la main qui la garde). Voila le principe général. Cependant, au moment de tester cette solution, un problème majeur apparaît. En effet, à aucun moment on ne prend en compte le fait qu'en cas de rupture d'un lien (patte externe ou interne), ça provoque un "trou noir" sur l'autre patte qui reçoit du trafic et ne sait plus comment l'acheminer. Il faudrait alors lier les instances VRRP afin qu'elles se passent le mot quand une patte est en perdition. Pour ça, il y a les groupes d'instances VRRP. Le soucis, c'est que si on groupe, non seulement on répercute l'info d'état "FAULT", mais aussi l'état "MASTER", et là, ça ne va plus, parce que dans ce cas, quand le routeur qui était en panne revient, quand il récupère son IP publique pour remonter ses sessions BGP, il récupère l'IP privée qui allait avec ce qui provoque le trou noir mentionné précédemment. Du coup, j'ai mis du temps à le trouver car l'instruction de configuration n'apparaît pas dans la doc de Keepalived, il ne faut pas utiliser de groupes, mais simplement propager un état "FAULT", sans se soucier des autres états. Cela se fait avec du "track_interface eth0 eth1" par exemple, dans chaque instance. Ca a pour effet de passer en état FAULT une instance si au moins une des interfaces listées est "malade". Une fois qu'on a mis tout ça en place, on obtient deux routeurs qui sont tolérants à la panne l'un de l'autre et qui prennent le relais en 5 secondes max ;) J'espère que mon explication était assez claire :) Bonne journée. Benjamin. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
