Lorsque des sessions BGP (Border Gateway Protocol) sont établies entre des routeurs appartenant au même système autonome (AS), cela est connu sous le nom de BGP interne (iBGP).
Il est courant d’utiliser l’adresse IP de l’interface loopback pour établir des sessions iBGP entre les routeurs, plutôt que les adresses IP des interfaces physiques. L’utilisation de l’adresse IP de l’interface loopback permet d’assurer une connectivité permanente et fiable entre les routeurs, car les interfaces loopback sont souvent configurées avec une adresse IP de bouclage qui reste active même si les interfaces physiques de l’équipement sont hors service.
Les interfaces loopback utilisées pour l’établissement des sessions iBGP sont annoncées entre les routeurs via un protocole de routage dynamique de type OSPF ou IS-IS.
Que se passe-t-il lorsque l’interface Loopback d’un routeur est injoignable ?
Chaque routeur BGP surveille en permanence l’état du prochain saut (Next-Hop) de chaque voisin pour vérifier son accessibilité. Si le Next-Hop devient indisponible, le routeur peut automatiquement retirer le chemin BGP associé de sa table de routage afin de prévenir tout risque d’acheminement de trafic vers une destination inaccessible.
Dans l’architecture ci-dessous, lorsque l’interface Loopback0 du R2 « 2.2.2.2 » devient inaccessible et que R1 et R3 ne voient plus son adresse dans leurs tables de routage, ils suppriment toutes les routes iBGP apprises de R2 après l’expiration du timer de vérification du Next-Hop (5 secondes par défaut).
Output:
Cependant, il est important de noter que la commande « nexthop trigger » ne déclenche pas la coupure de la session iBGP sur le routeur. Ainsi, la session iBGP entre les routeurs R1 et R2 restera active jusqu’à ce que le Hold-timer expire (qui est généralement de 180 secondes par défaut, soit 3 fois le temps de KeepAlive).
En effet, il est préférable que BGP désactive automatiquement la session BGP lorsque l’adresse du voisin n’est plus accessible.
Pour répondre à cette problématique, la fonctionnalité BGP Fall-Over peut être utilisée afin de provoquer la désactivation automatique de la session BGP en question.
BGP Fall-Over :
BGP Fall-over est une technique intéressante d’optimisation de la convergence BGP, dans laquelle la session BGP est arrêtée dès que la route vers le voisin disparaît de la table de routage.
La différence entre BGP externe et interne est que le premier se connecte généralement via une interface directement connectée, de sorte que lorsque l’interface vers le voisin est déconnectée, la route est retirée de la table de routage, déclenchant ainsi la chute de la session eBGP.
En revanche, iBGP utilise normalement des interfaces Loopbacks pour établir des sessions de peering. Cela signifie que s’il existe une route plus large (Summary-Route ou une route par défaut dans la table de routage (obtenus via une configuration statique ou via un IGP), il y a toujours une route vers le voisin iBGP. Dans ce cas, BGP doit attendre 180 secondes par défaut (3 x Keep Alive) pour mettre fin à la session iBGP et retirer toutes les routes apprises du voisin non acessible.
Pour surmonter ce problème, une route-map peut être associé à la commande Fall-Over, qui permet à l’utilisateur de spécifier le préfixe exact à rechercher dans la table de routage. Dans l’exemple ci-dessous, le routeur cherchera des routes hôtes spécifiques représentant les interfaces Loopback des voisins et déclenchera une reconvergence dès que ces routes disparaîtront.
Allons voir ça sur notre petite maquette :
Dans le premier scénario, on va activer la fonctionnalité FALL-OVER entre R1 et R2
Configuration :
Maintenant, allons désactiver l’interface Loopback du R2 et regarder ce qui se passe dans R1 :
Output:
Un fois l’IP de l’interface Loopback a disparu de la table de routage, R1 a déclencher immédiatement la désactivation de la session BGP. C’est pas mal !!!!
Imaginons pour l’instant, que R2 annonce en OSPF en plus son interface Loopback, une route par défaut.
Configuration :
Redésactivons l’interface Loopback du R2 pour voir et observons ce qui se passe :
Output :
Comme indiqué dans la description de FALL-OVER, l’adresse IP 2.2.2.2 a été supprimée à 08:59:59.904. Cependant, la session BGP est restée opérationnelle jusqu’à l’expiration du Hold time et n’a été déclarée non opérationnelle qu’à 09:02:40.792 (environ 3 minutes). En effet, la table de routage de R1 contenait une route plus large (route par défaut) qui l’a dirigé vers R2 malgré la disparition de l’interface Loopback du R2.
Afin de résoudre ce problème, il est nécessaire de demander à R1 de scanner sa table de routage pour trouver l’adresse IP exacte de son voisin R2 (2.2.2.2/32). En l’absence de cette route, la désactivation de la session BGP sera automatiquement déclenchée. Cette opération peut être réalisée en associant une route-map à la commande Fall-Over. La route-map doit matcher une prefix-list qui inclut toutes les routes de type « host » (/32).
Configuration :
Maintenant, « La présence de la route par défaut ne suffit plus pour maintenir la session iBGP entre R1 et R2 active. Dès que l’interface Loopback de R2 disparaît, la session est désactivée immédiatement.
Output :
En résumé, la fonctionnalité Cisco BGP Fall-Over permet de garantir la disponibilité des sessions BGP, en détectant rapidement les pannes et en effectuant des récupérations automatiques. Cette fonctionnalité est essentielle pour maintenir un réseau stable et fiable, en particulier dans les environnements critiques où les temps d’arrêt peuvent avoir des conséquences importantes.
Si vous avez des questions ou vous avez besoin d’un complément d’informations ou une consultation spécifique à votre environement, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.
