Greg,
Je suis en train de me poser une question existentielle, peut être l'un
de vous a la réponse.
A supposer que j'aie deux sessions BGP vers un même AS, qui partent du
même routeur (chez moi), pour arriver sur deux IP de deux routeurs
différents chez l'AS avec qui je peere.
Supposons que je force, pour une somme de NRLIs (préfixes CIDR plus
attributs) donnée, vers l'un des deux next-hop (LOCAL_PREF par exemple):
dans ce cas, j'ai les deux entrées dans la table BGP locale de mon
routeur (Loc_RIB ou Adj_RIB_in, j'ai jamais vraiment trop compris le
distinguo) pour chacun des NRLI en question, l'un qui est préféré et
donc éligible et installé dans la table de routage de l'équipement.
Il y a différents éléments qui interviennent dans le calcul du temps de
failover en cas de panne de session BGP dans un réseau tel que celui-ci.
1- Temps de détection de la panne
C'est le premier élément, il dépend du mécanisme utilisé pour détecter
que la session BGP ne fonctionne plus.
La solution par défaut est de laisser BGP faire la détection (absence de
réception de messages KeepAlive). Cela prend plusieurs dizaines de
secondes en fonction du timer configuré sur la session.
Il est maintenant possible d'avoir une détection plus rapide en se
basant soit sur un trigger venant de la couche physique (par exemple
lien PoS) soit en utilisant BFD. Avec PoS, sur des liens intradomaines
il est possible de détecter les pannes en dessous de 50 msec [1],
j'imagine que cela fonctionne aussi sur les liens interdomaines. BFD
peut être configuré avec un temps de détection approprié. Ici, il y a un
compromis à trouver entre la stabilité du réseau et une détection
rapide. Sur un lien qui tombe souvent (voir par exemple certains liens
mesurés dans [2]), une détection rapide n'est pas nécessairement une
bonne idée.
2- Lorsque la panne a été détectée, le routeur doit retirer les routes
apprises via cette session de sa RIB puisque leur nexthop est maintenant
non joignable. A ma connaissance, ce retrait des routes se fait de suite
sans attendre de scan time (celui-ci n'est utilisé que lorsqu'un poids
IGP change).
Lorsqu'une route BGP est retirée de la RIB, deux cas de figure sont
possibles :
- une autre route est déjà connue par le routeur pour ce préfixe. C'est
le cas dans le réseau que tu mentionnes pour les routes apprises sur la
session BGP. Dans ce cas, le routeur relance son processus de décision
BGP, sélectionne une meilleure route est l'installe dans sa FIB. Cette
phase d'installation dans la FIB est un des goulots d'étranglement si de
nombreux préfixes sont affectés. Sur un Cisco 12K des mesures faites il
y a quelques années montraient qu'il fallait environ 100 microsecondes
pour installer un préfixe dans la FIB [1]. Sur certains plateformes, il
est maintenant possible d'aller beaucoup plus vite [4].
- aucune autre route n'est connue par le routeur pour ce préfixe. Ce
serait le cas dans un réseau avec deux routeurs d'accès et une session
eBGP sur chaque routeur et un local-pref qui favorise un routeur par
rapport à l'autre. Dans ce cas, le routeur non favorisé n'annonce aucune
de ses routes dans iBGP et donc le routeur primaire n'a pas de route
alternative. Dans ce cas, il faut attendre une convergence iBGP pour que
le routeur apprenne les routes dont il a besoin, convergence qui peut se
mesurer en secondes [3]
3- Il faut informer les autres routeurs de l'AS de la panne de la
session eBGP et leur permettre de mettre à jour leurs FIB. Ici aussi, le
temps de convergence dépendra de différents facteurs. Par exemple, si la
session est configurée avec nexthop-self, alors c'est BGP qui doit
annoncer la panne avec autant d'updates (modulo le packing) que de
préfixes affectés. Si la session n'est pas configurée avec nexthop-self,
alors l'IGP peut annoncer la panne du lien de peering et tous les
routeurs de l'AS peuvent être informés rapidement (la rapidité dépendra
de la configuration de l'IGP, [1], mais cela peut normalement se faire
en quelques centaines de millisecondes avec une bonne configuration).
Bien entendu, il y a de nombreux détails "vendor-specific" qui peuvent
affecter ce temps de convergence...
Olivier
[1] Pierre Francois, Clarence Filsfils, John Evans and Olivier
Bonaventure. Achieving sub-second IGP convergence in large IP networks.
ACM SIGCOMM Computer Communication Review, 35(3):33-44, July 2005.
http://inl.info.ucl.ac.be/publications/achieving-sub-second-igp-convergence-
[2] Olivier Bonaventure, Clarence Filsfils and Pierre Francois.
Achieving Sub-50 Milliseconds Recovery Upon BGP Peering Link Failures.
Proceedings of the 2005 ACM CoNext, pages 31-42, 2005.
http://inl.info.ucl.ac.be/publications/achieving-sub-50-milliseconds-recover
[3] Olivier Bonaventure, Clarence Filsfils and Pierre Francois.
Achieving Sub-50 Milliseconds Recovery Upon BGP Peering Link Failures.
IEEE/ACM Transactions on Networking, 15(5):1123 - 1135, October 2007.
http://inl.info.ucl.ac.be/publications/achieving-sub-50-milliseconds-recove-0
[4] Clarence Filsfils, BGP Convergence in much less than a second,
NANOG, http://www.nanog.org/mtg-0706/filsfils.html
--
http://inl.info.ucl.ac.be , UCLouvain, Belgium
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
