L’oscillation des routes BGP

Le protocole BGP est utilisé principalement pour interconnecter des systèmes autonomes (Autonomous systems (AS) en anglais).

BGP est connu pour sa scalabilité et sa flexibilité, la preuve c’est qu’il est utilisé dans l’internet pour gérer la table de routage globale qu’atteint à ce jour environ 775k routes.

Finalement pour échanger les routes, chaque routeur doit monter une session appelée IBGP si les deux routeurs font partie du même système autonome et une session appelée EBGP si le routeur voisin est dans un système autonome différent.

La gestion des boucles

Comment un routeur BGP pourrait être sûr que les routes qui génère localement ne lui seront pas annoncées par un voisin ?

BGP utilise deux mécanismes pour détecter et bloquer les boucles :

Dans le cas d’EBGP:

• Chaque routeur EBGP associe son AS « Tag » à toute les routes qui annonce vers ses voisons, par conséquent quand un routeur voit arriver une route avec son AS, le routeur tout simplement refuse l’installation de cette route dans sa table BGP

Dans le cas d’IBGP:

• Le principe est différent car aucun AS n’est associé si le routeur annonce une route vers un voisin IBGP mais il se base sur un autre mécanisme pour se protéger contre les boucles .la règle c’est lorsqu’un routeur reçoit une route IBGP, il ne doit pas l’annoncer vers un autre voisin IBGP. Ceci signifie dire que les routeurs IBGP doivent établir une session IBGP vers l’ensemble des routeurs du même AS. Cette solution est acceptable jusqu’à un certain niveau où elle devient ingérable.

Imaginez pour l’instant que vous avez 100 routeurs dans le même AS donc selon la règle ci-dessus chaque routeur doit monter une session IBGP vers les 99 routeurs voisins.

Pour remédier à cette situation,il existe deux solutions:

• L’utilisation du Route Reflector (RR)
• L’utilisation du BGP Confederation

Je n’ai pas l’intention de détailler les deux solutions dans cet article mais plutôt expliquer rapidement comment les deux solutions ci-dessus remplace IBGP Full-Mesh.

Dans le cas du RR, chaque routeur ( RR client) monte une session avec un ou deux RR ( pour la redondance ) au lieu de monter une session au lieu de monter une session avec l’ensemble des routeurs de l’AS.le RR casse la règle IBGP et diffuse les routes reçues en IBGP vers les RR clients et les non RR client.

D’autre part, BGP Confederation tend à découper un AS en plusieurs sous AS afin d’utiliser des sessions EBGP entre les routeurs associés aux différents sous AS.

BGP Full-Mesh ou l’utilisation des RRs, quelle est la meilleure solution ?

La réponse tout simplement « ça dépend  » c’est une question de compromis « Trade offs » car si la première solution est rigide en termes de configuration, elle offre tout de même à chaque routeur une visibilité complète de la topologie. D’autre part le RR facilite la configuration mais il cache la visibilité car un RR n’envoie que les meilleure routes (selon sa vision de la topologie) vers ses clients et ceci pourra introduire quelques problèmes de routage dont BGP Route oscillation.

Pour expliquer le comportement du BGP Route oscillation, on utilisera le schéma ci-dessous :

• RA est le RR du RB et RC
• RE est le RR du RD
• Les chiffres en bleu à l’intérieur de l’AS représentent la métrique IGP et ceux à l’extérieur de l’AS représentent  la métrique BGP ou le MED (Multi-Exit Discriminator).

Afin de choisir la meilleure route, BGP repose sur un algorithme de sélection, voici celui utiliser par   Cisco: https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

Imaginer pour l’instant que la table BGP du RA est comme suit:

	AS-PATH	MED	Next-hop	Best
10.0.0.0/8	10   100	10	5	*
	6   100	1	4

• Après l’expiration du scan timer,le routeur BGP que cette route n’est pas la meilleure car celle avec l’AS-PATH 6 100 a une meilleure métrique IGP.Par conséquent RA mis à jour sa table BGP et envoi l’information à ses voisins.
• RD reçoit la mise à jour et sa table BGP devient comme suit :

	AS-PATH	MED	Next-hop	Best
10.0.0.0/8	6   100	0	12	*
	6   100	1	5

RD marque la route 6 100, 0 ,12 comme meilleure car les deux routes ont le même AS-PATH donc la valeur MED est comparée.RD informe ses voisins de cette nouvelle.

• RA et à la réception de la nouvelle, sa table de BGP ressemble à :

	AS-PATH	MED	Next-hop	Best
10.0.0.0/8	6   100	0	13
	6   100	1	4
	10   100	10	5	*

RA a comparé en premier les routes qu’ont le même AS-PATH,la première route a gagné car elle a le MED le moins élevé,après la route gagnante a été comparée avec la dernière et puisque elles viennent des différentes AS, le MED  est ignoré et le Next-hop est comparé.Ici 5 < 13 donc la route « 10 100,10,5 » est choisie comme meilleure.RA informe ses voisins de son choix

• RD reçoit la nouvelle du RA et lance le process de sélection

	AS-PATH	MED	Next-hop	Best
10.0.0.0/8	6   100	0	12
	6   100	10	6	*

RD a choisi la route 6 100,10,6 grâce à sa métrique du Next-Hop (moins élevée) et informe ses voisins.

• RA reçoit la mise à jour du RD et supprime la route 6 100, 0,13 ce qui laisse RA avec la table BGP suivante:

	AS-PATH	MED	Next-hop	Best
10.0.0.0/8	10   100	10	5	*
	6   100	1	4

À ce stade, on a fait une boucle complète et on est retourné à l’étape 1.

BGP route Oscillation crée une instabilité infinie dans la table BGP.

La visibilité incomplète de la topologie est la cause de ce problème qui n’aurait jamais eu lieu si les RRs avaient des sessions IBGP avec tous les autres routeurs.

Comment résoudre ce problème ? Il existe plusieurs solutions :

1. Changer la métrique du lien inter-RR en lui associant une valeur plus élevée à celle entre le RR et ses RR clients.
2. Configurer les routeurs Edge de telle manière à ce qu’ils n’acceptent pas l’attribut MED
3. Configurer un attribut BGP mieux placé dans le process de sélection pour ne pas arriver à la comparaison du MED par exemple Local-pref.
4. Utiliser l’option Always-compare-Med pour inciter les routeurs de comparer le MED même s’il vient des différents AS-PATH
5. Utiliser la fonctionnalité Add-Path qui fera partie d’un éventuel article.

J’espère que cet article vous a plu et si vous avez des questions, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter à l’adresse : contact@mhd-experts.com.