Bonsoir à tous,
J'aimerais votre avis sur le type configuration et d'approche à mettre en
œuvre dans le cas suivant: j'utilise un routeur BGP avec Quagga pour gérer
un AS, lequel est raccordé à deux transitaires.
Cette solution, tout à fait fonctionnelle me pose cependant un problème :
c'est celui de la tolérance à la panne. Actuellement, le routeur principal
n'a pas de copain redondant "automatique". J'ai envisagé une série de
possibilités pour palier à ce problème, mais à chaque fois, je me heurte à
une difficulté (souvent la même d'ailleurs, directement ou indirectement).
Pour résumer, voici le type de configs que j'ai envisagées et ce à quoi je
me heurte:
1 - Le routeur principal continue à fonctionner comme à l'heure actuelle,
et, en cas de coupure, il est automatiquement secouru par un serveur de
backup en utilisant un outil de HA (Keepalived). Au moment de la panne, le
backup prend les adresses IP du master et remonte les sessions BGP. Le hic,
c'est qu'il faut plusieurs minutes pour récupérer toutes les routes, donc
une interruption de service trop longue à mon gout. :(
Schémas :
- en prod:
LAN ------ MASTER / BGP ------ NET
SLAVE DORMANT
- en panne:
LAN --\ MASTER EN PANNE /--- NET
\---SLAVE / BGP ----/
2 - Seconde solution, le master et le backup ne partagent avec Keepalived
que les IP sur la patte interne du réseau, et de l'autre côté, montent
chacun de leur côté des sessions BGP avec les transitaires. Afin de ne pas
avoir de trafic sur le slave en fonctionnement normal (il n'a pas les IP sur
la patte interne, donc il ne peut pas router le trafic), je rallonge la
route du slave d'un hop en ajoutant notre numéro d'AS dans la route vers
notre AS. En production, ça donne : le master fait son job, et le slave a
juste des routes montées, mais qui ne servent à rien tant que le master est
up. Au moment de la panne du master, il y a deux cas de figure : soit il
s'agit juste d'une rupture sur la patte interne, auquel cas le master se met
en défaut et coupe toutes les routes et sessions BGP. Le slave prend alors
le relais au pied levé puisque les transitaires ont été informés de la
coupure des sessions BGP par le master (coupure "controlée" sur la patte
publique). Le hic ce coup-ci, c'est que si le problème vient de la patte
publique sur le master, ou qu'il se gauffre complètment, le slave va prendre
le relais, mais les sessions BGP du master ne vont pas se fermer tout de
suite. Ca signifie que le trafic va continuer à arriver au master alors
qu'il est tombé dans les pommes. :( (bis)
Schémas :
- en prod:
LAN ---->>> MASTER / BGP --<<</---- NET
SLAVE / BGP -o-o-/
- en panne:
LAN ----\ MASTER EN PANNE <<</------- NET
\-- SLAVE / BGP ----->>>/
3- La troisième solution, ça a été de mixer les tests faits précédemment,
pour faire sortir une solution idéale, qui n'est jamais venue.
J'en suis donc arrivé à devoir choisir entre deux approches différentes,
mais où le resultat final est le même : en cas de coupure du master, il faut
plusieurs minutes pour remonter les sessions BGP correctement.
Je m'adresse donc à vous en espérant que ce cas de redondance des routeurs
BGP avec Quagga n'a plus de secret pour vous, et que vous voudrez bien
éclairer ma lanterne quant à la méthode à employer :)
Je ne vous demande pas de configuration complète, juste une piste à explorer
;)
A moins que vous n'ayez une astuce à me donner pour forcer les sessions BGP
à remonter en un temps record, auquel cas je peux utiliser la solution 1 ;)
D'avance merci pour votre aide.
Bonne fin de week end.
Benjamin.
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
