BGP « Path hunting » est un phénomène dont la disparation d’une simple route BGP engendre un long temps de convergence (plus qu’une minute parfois) avant que la route soit complètement supprimée par l’ensemble des routeurs BGP.
Le but de cet article est de démystifier ce phénomène et voir comment peut-on diminuer ces dégâts sur le temps de convergence d’une architecture BGP.
À l’inverse, les protocoles dits à états de lien comme OSPF et IS-IS s’appuient sur l’algorithme de Dijkstra et chaque routeur connait l’entièreté de la topologie du réseau.
Le protocole BGP est quant à lui un protocole à vecteur de chemins (path vector), une variante des protocoles à vecteur de distances, où ce sont des tableaux de chemins qui sont échangés. Le protocole BGP fait confiance aux informations envoyées par ces voisins (Peers) pour calculer le chemin le plus courts vers la destination (chemin avec moins de sauts ou système autonome « AS »).
Pour expliquer le BGP Path Hunting, on va utiliser le schéma suivant :
Supposant pour l’instant que l’AS 1 a perdu la route vers 1.1.1.1/32 :
- L’AS 1 à l’instant T1 supprime la route de sa table de routage et informe ces voisins AS2, AS4, AS6 et AS 9 que le préfixe 1.1.1.1 n’est plus joignable via des messages BGP appelés « Widthraw »
- À l’instant T2, l’AS 2, AS 4, AS 6 et AS9 suppriment la route de leurs tables de routage et informent leurs peers AS 3, AS 5, AS 7 et AS 10 de cet événement => AS3 à cet instant-ci supprime la route vers AS2 et installe la route via l’AS5 dans la table du routage pensant que la route est toujours joignable via ce peer (AS5)
- À T3, AS 5, AS 7, AS 10 suppriment la route de leurs tables de routage et informent leurs peers AS 3, AS 8, AS 11 que le préfixe n’est plus joignable. => AS3 supprime la route via l’AS 5 et installe la route via l’AS 8 dans sa table du routage.
- À T4, l’AS 8 et l’AS 11 suppriment la route vers le 1.1.1.1/32 de leurs tables de routage et informent leurs peers AS 3 et l’AS 12 => AS3 supprime la route via l’AS 8 et installe celle en provenance de l’AS 12.
- À T5, l’AS 12 supprime la route 1.1.1.1/32 de sa table de routage et informe l’AS 3 de cet évènement => l’AS 3 n’ayant finalement plus de peer qui lui annonce cette route, décide de supprimer la route 1.1.1.1 de sa table de routage.
La route vers le prefixe 1.1.1.1/32 restait installée inutilement dans la table de routage de l’AS 3 pendant X temps (jusqu’ à T5) avant de déclarer la route injoignable.
Combien de temps faut-il pour qu’un routeur BGP annonce via un Widthraw message la perte d’un prefixe à ces voisins ?
Pratiquement, à la réception de du Withraw message, calcule le nouveau meilleur chemin vers la destination et attend un certain temps appelé Minimum Route Advertisment Interval pour (MRAI) avant d’informer ces voisins, si le temps de calcule est négligeable dans la majorité des cas sauf si on parle des routeurs qui héberge la table des routes internet. Le MRAI conditionne le temps de l’existence du phénomène « Path Hunting ». Sachant que Cisco par exemple associe une valeur de 30 secondes au paramètre MRAI, Par conséquent dans les pires des Cas, le routeur de l’AS 3 aurait besoin de 5 x 30 secondes (150 secondes) avant la suppression de du préfixe 1.1.1.1/32 de sa table de routage.
Durant mes tests dans une maquette, le temps de convergence constaté varie entre 30 et 60 secondes :
Et si on réduisait le temps du MRAI ?
En réduisant la valeur du paramètre MRAI, on accélère le passage de la tempête « Path Hunting » mais on ne la supprime pas et en contrepartie on fragilise la stabilité du protocole BGP. Comment ?
Le MRAI a pour objectif de retarder l’envoi des mises à jour afin d’en regrouper le maximum et supprimer les doublons ce qui assure la stabilité de la topologie BGP comme illustré dans le schéma ci-dessous :
En configurant le MRAI à 0 secondes, la coupure du lien entre AS 1 et AS 2 engendre deux mises à jour dans le routeur de l’AS 2 :
- Le premier message et un Widthraw pour informer AS 4 que le préfixe 1.1.1.1 n’est plus joignable via le chemin AS2 > AS 1.
- Le deuxième message et une mise à jour pour informer l’AS 4 de l’accessibilité du préfixe 1.1.1.1/32 via le chemin AS2 > AS 3 > AS 1
Par conséquent, le routeur de l’AS 4 reçoit deux messages concernant le même préfixe qui doit traiter séparément.
En revanche, en retardant l’envoi des mises à jour de quelques secondes l’AS 2 n’envoie qu’une seule mise à jour à l’AS 4 en l’informant du changement du chemin pour rejoindre le préfixe 1.1.1.1/32.
En tant qu’ingénieur/architecte réseau, Il faut toujours essayer de trouver les compromis derrière le changement de chaque paramètre. Dans cet article on a vu que le fait d’accélérer la convergence du protocole BGP en réduisant la valeur du MRAI, on augmente le nombre des messages BGP échangés entre les peers et consommer les ressources des routeurs (inutilement parfois) ce qui pourrait impacter la stabilité du protocole.
Finalement 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
