> Ben .. ca permet de ne pas avoir a attendre que > les sessions BGP remontent sur le slave quand le > master se prends un mur. La contrepartie c'est > que tu n'a qu'un transitaire a dispo quand tu fonctionne en mode dégradé
C'est pour ça que dans la seconde solution que j'ai testée, chaque routeur monte ses propres sessions BGP en permanence, et le second rallonge volontairement ses routes d'un hop pour empêcher le trafic d'arriver par lui tant que le master est up. > Si tu veux pouvoir exploiter tes deux > transitaires, il faut que ton master connaissent > les meilleurs routes du transitaire du slave ==> ibgp obligé. Dans le schéma que tu expliques, je comprends l'utilité de l'iBGP :) > J'echange un schema sur papier contre une biere Tu as une marque préférée ? ;) > > Bonne nouvelle :) Il ne me reste plus qu'à trouver comment indiquer aux > > routeurs BGP des transitaires comment leur envoyer l'info depuis le routeur > > de secours pour qu'ils coupent les routes le plus rapidement possible. > Ca, tu pourra pas. Mais peu importe. Si tu fais > bien ton VRRP, ton master s'isolera de lui meme > sur toutes ses pattes et basta :) Le soucis, c'est que même quand le VRRP fonctionne dans les 2 secondes qui suivent, si le master a une rupture uniquement au niveau de la patte interne, pas de soucis, il tombe "proprement" ses connexions BGP et ses routes, ce qui prend moins de secondes. Mais dans le cas où le serveur tombe complètement (alim cramée, carte mère en vrac, kernel panic ...), il ne peut pas fermer les sessions BGP proprement. Ca signifie qu'il reste des routes montées du côté des transitaires qui utilisent le master jusqu'à ce qu'il y ait un timeout. Et le problème est toujours le même : ce timeout est trop long :( Benjamin. --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
