BGP expliqué : sessions, attributs et meilleur chemin

BGP, le Border Gateway Protocol version 4, est le moyen par lequel les systèmes autonomes échangent leurs routes. Un système autonome est un réseau soumis à une même politique de routage, identifié par son numéro d'AS.

Contrairement à OSPF, BGP ne découvre rien. Chaque pair est configuré à la main, et la session fonctionne sur TCP, port 179. Chaque route porte la liste des systèmes autonomes qu'elle a traversés, et c'est cette liste qui empêche les boucles entre eux.

Quatre messages font tout le travail. OPEN ouvre la session et transporte la version, le numéro d'AS, le hold time et l'identifiant BGP. UPDATE transporte les routes. KEEPALIVE indique que le pair est toujours là. NOTIFICATION signale une erreur et ferme la session. Huawei mentionne aussi route refresh, pour demander à un pair de renvoyer ses routes.

La session passe par six états : Idle, Connect, Active, OpenSent, OpenConfirm et Established. Un pair bloqué en Active retente la connexion TCP, sans succès.

Deux temporisateurs maintiennent une session en vie. Le hold time est la durée pendant laquelle un routeur attend sans nouvelles de son pair avant de fermer la session, et les keepalives partent à un tiers de cette valeur.

Cisco, Huawei et Aruba utilisent par défaut un keepalive de 60 secondes et un hold time de 180 secondes. Juniper et la RFC suggèrent 30 et 90. La session s'établit malgré tout, car chaque côté retient le plus petit hold time des deux messages OPEN : un routeur Cisco face à un routeur Juniper fonctionne donc à 90 secondes. Un hold time d'une ou deux secondes est refusé.

Une session entre deux systèmes autonomes relève du BGP externe, eBGP. À l'intérieur d'un même système autonome, c'est du BGP interne, iBGP, et les règles changent. Vers un pair eBGP, un routeur ajoute son propre numéro d'AS au chemin, et un routeur qui trouve son propre numéro dans un chemin reçu rejette la route. C'est la protection contre les boucles.

À l'intérieur de l'AS, le chemin ne change pas : iBGP a donc besoin d'une autre règle. Une route apprise d'un pair iBGP n'est jamais transmise à un autre pair iBGP. C'est pourquoi les routeurs iBGP doivent être maillés de façon complète (full mesh).

Un maillage complet de n routeurs exige n fois n moins un, divisé par deux, sessions. Vingt routeurs, cent quatre-vingt-dix sessions.

Un route reflector contourne la règle à dessein. Ses clients ne s'appairent qu'avec le reflector, et celui-ci relaie leurs routes. Deux attributs empêchent les boucles que cela pourrait créer : l'originator ID, le routeur qui a annoncé la route en premier, et la cluster list, les reflectors qu'elle a traversés. Un reflector rejette toute route qui mentionne déjà son propre cluster ID.

Chaque route porte des attributs. Origin indique comment la route est entrée dans BGP. AS path est la liste des systèmes autonomes. Next hop indique où envoyer le trafic.

La local preference reste à l'intérieur de votre AS, vaut 100 par défaut, et la plus haute l'emporte : c'est ainsi que vous choisissez votre sortie. Le MED, multi exit discriminator, est une indication donnée à un voisin sur celui de vos liens à utiliser, et le plus bas l'emporte. Par défaut, les routeurs ne comparent le MED qu'entre des routes issues du même AS voisin.

Quand plusieurs chemins mènent au même préfixe, Cisco les examine dans cet ordre : le weight le plus élevé, la local preference la plus élevée, une route originée localement, l'AS path le plus court, l'origin la plus basse, le MED le plus bas, eBGP plutôt qu'iBGP, la métrique IGP la plus basse vers le next hop, le chemin externe le plus ancien, le router ID le plus bas, la cluster list la plus courte et l'adresse de voisin la plus basse.

Le weight est propre à Cisco et ne quitte jamais le routeur : 32 768 pour les routes qu'il origine, zéro pour les autres. Huawei appelle la même notion PrefVal, et Aruba administrative weight.

Juniper commence ailleurs. Junos vérifie d'abord que le next hop est résolu, puis compare la préférence de protocole, 170 pour BGP, puis la local preference, et son ordre documenté ne comporte aucune étape weight. Huawei examine la cluster list avant le router ID, là où Cisco et Juniper l'examinent après. Chez Aruba, le router ID n'est comparé que si vous l'activez ; sinon, la route la plus ancienne est conservée.

Mélangez les constructeurs, et les mêmes routes peuvent être départagées différemment.

La raison la plus fréquente pour laquelle une route reste inutilisée dans la table BGP, c'est son next hop. Une route apprise en eBGP conserve son next hop lorsqu'elle est transmise aux pairs iBGP : l'adresse du voisin externe. Si vos routeurs internes ne peuvent pas joindre cette adresse, la route est dans BGP mais n'est jamais installée.

L'exemple de Huawei le montre : la route apparaît avec un i et sans marqueur de meilleur chemin, parce que le next hop est injoignable. La solution est le next hop self sur le routeur de bordure, ou l'annonce de ce lien dans l'IGP.

Chaque constructeur a une commande de synthèse. Cisco : show ip bgp summary, où la dernière colonne indique l'état ou le nombre de préfixes reçus. Huawei : display bgp peer. Aruba : show bgp all summary. Juniper : show bgp summary.

Tout ce qui n'est pas established dans cette colonne, Idle, Active ou Connect, correspond à une session tombée.

Deux réglages protègent chaque session. Le premier est le maximum prefix. Sans lui, un pair qui laisse fuir une table complète vous envoie des centaines de milliers de routes, et vous les acceptez.

Avec lui, Cisco avertit à 75 pour cent et, au-delà de la limite, coupe la session avec une NOTIFICATION : cease, maximum number of prefixes reached. La synthèse affiche alors Idle, prefix count, et la session reste tombée jusqu'à ce que vous la réinitialisiez (clear), sauf si vous définissez un temporisateur de redémarrage.

Huawei l'appelle route limit et Juniper prefix limit, et Juniper se contente de journaliser, sauf si vous ajoutez teardown.

Le second est l'authentification. L'option classique est un mot de passe TCP MD5, RFC 2385, identique aux deux extrémités. Sa propre RFC en signale les faiblesses de sécurité, et Huawei indique que MD5 présente des risques potentiels.

Son remplaçant est TCP-AO, RFC 5925, avec des key chains qui changent de clé sans faire tomber la session. Cisco, Aruba et Juniper le documentent pour BGP.

Une mise en garde : chez Cisco, ajouter un mot de passe à une session en cours ne la réinitialise pas, si bien qu'une incohérence n'apparaît qu'à la réinitialisation suivante.

NacTrack lit BGP sur chaque routeur en SSH, quel que soit le constructeur, et liste toutes les sessions sur une seule page : leur état, les préfixes reçus, la présence ou non d'un maximum prefix, et la protection ou non par BFD.

Par exemple : une table internet complète qui arrive sur une session marquée non limitée.