Border Gateway Protocol (BGP) est un protocole d'échange de route externe (un EGP), utilisé notamment sur le réseau Internet. Son objectif principal est d'échanger des informations de routage et d'accessibilité de réseaux (appelés préfixes) entre Autonomous Systems (AS). Comme il circule sur TCP, il est considéré comme appartenant à la couche application du modèle OSI.

Contrairement aux protocoles de routage interne, BGP n'utilise pas de métrique classique mais fonde les décisions de routage sur les chemins parcourus, les attributs des préfixes et un ensemble de règles de sélection définies par l'administrateur de l'AS. On le qualifie de protocole à vecteur de chemins (path vector protocol).

BGP prend en charge le routage sans classe et utilise l'agrégation de routes afin de limiter la taille de la table de routage. Depuis 1994, la version 4 du protocole est utilisée sur Internet, les précédentes étant considérées comme obsolètes. Ses spécifications sont décrites dans la .

BGP a remplacé Exterior Gateway Protocol (EGP) qui était utilisé dans la dorsale ARPANET et a permis la décentralisation du routage sur Internet. Il a pour intérêt son passage à l'échelle (scalabilité): il peut traiter un très grand nombre de routes entre de nombreux Autonomous Systems en évitant les boucles, et masque la topologie interne des AS entre eux.

Certaines extensions de BGP permettent l'échange de routes IPv6 (), les premières versions se limitant à IPv4, et l'extension multi-protocole (MP-BGP, ) permet d'utiliser BGP pour convoyer des informations de routage pour de nombreux autres protocoles, notamment les routes liées à des VPN MPLS (IPv4, IPv6, VPLS...).

Fonctionnement upright=1.8|thumb|Liaisons eBGP et iBGP. La rupture du lien physique entre A et C n'interrompt pas la session iBGP entre ces routeurs si une adresse IP logique (loopback) est utilisée.

Les connexions entre deux voisins BGP ( ou ) sont configurées explicitement entre deux routeurs. Ils communiquent alors entre eux via une session TCP sur le port 179 initiée par l'un des deux routeurs. BGP est le seul protocole de routage à utiliser TCP comme protocole de transport.

Les routeurs voisins sont identifiés par leur router ID, un identifiant de quatre octets, unique pour chacun des routeurs d'un Autonomous System (AS) donné, qui peut être choisi arbitrairement mais qui est généralement une adresse IPv4 loopback. de chaque routeur.

Il existe deux modes de fonctionnement de BGP : (iBGP) et (eBGP). iBGP est utilisé à l'intérieur d'un Autonomous System alors que eBGP est utilisé entre deux AS.

En général, les connexions eBGP sont établies sur des connexions point-à-point ou sur des réseaux locaux (un Internet Exchange Point par exemple), le TTL des paquets de la session BGP est alors fixé à 1. Si la liaison physique est rompue, la session eBGP l'est également, et tous les préfixes appris par celle-ci sont annoncés comme supprimés et retirés de la table de routage.

À l'inverse, les connexions iBGP sont généralement établies entre des adresses IP logiques, non associées à une interface physique particulière: des adresses loopback. En effet, classiquement, un protocole de routage interne dynamique (IGP) est employé (en général OSPF ou IS-IS) qui permet aux routeurs du réseau considéré de se joindre via leurs adresses loopback. Ainsi en cas de rupture d'un lien physique, la session iBGP reste active si un lien alternatif existe.

Une fois la connexion entre deux routeurs établie, ceux-ci s'échangent des informations sur les réseaux qu'ils connaissent et pour lesquels ils proposent du transit, ainsi qu'un certain nombre d'attributs associés à ces réseaux qui vont permettre d'éviter des boucles (comme AS Path) et de choisir avec finesse la meilleure route.

Messages du protocole BGP

OPEN ce message est utilisé dès que la connexion TCP est établie entre les voisins BGP, il permet d'échanger des informations telles que les numéros d'AS respectifs et les router ID de chacun, et de négocier les capacités de chacun des pairs ; KEEPALIVE maintient la session ouverte. Par défaut le message KEEPALIVE est envoyé toutes les 30 secondes, et un délai de 90 secondes sans message UPDATE ni KEEPALIVE reçu entraîne la fermeture de la session. ; UPDATE ce message permet l'annonce de nouvelles routes ou le retrait de routes ; NOTIFICATION message de fin de session BGP à la suite d'une erreur ; ROUTE-REFRESH définie dans la , la capacité de rafraîchissement des routes est négociée dans le message OPEN et permet de demander/réannoncer certains préfixes après une modification de la politique de filtrage.

Machine d'états finis de BGP thumb|upright=1.5|Diagramme d'automate fini de BGP.

Le logiciel permettant de gérer les échanges de route doit implémenter un automate fini constitués de six états liés par treize événements. Les automates dialoguent entre eux par des messages (OPEN, KEEPALIVE, UPDATE, NOTIFICATION).

Les états sont : Idle Connect Active OpenSent OpenConfirm Established

Les changements d'états et le comportement attendus sont les suivants :

Idle Dans cet état, le processus refuse les connexions et n'alloue aucune ressource. Quand l'événement de démarrage (manuel ou automatique) est reçu, le processus initie les ressources et une connexion avec les voisins configurés, et écoute les connexions entrantes sur le port TCP 179 et bascule dans l'état Connect. En cas d'erreur, la connexion est coupée et le processus retourne dans l'état Idle ;

Connect attend que la connexion TCP soit établie, puis envoie le message OPEN et bascule dans l'état OpenSent. En cas d'erreur, attend un délai prédéfini et continue à écouter sur le port 179 puis bascule dans l'état Active ;

Active Tente d'établir une connexion TCP avec le voisin. En cas de réussite, envoie le message OPEN et bascule dans l'état Connect, tout autre événement provoque le retour dans l'état Idle ;

OpenSent le message OPEN a été envoyé, attend le message OPEN en retour et s'il ne se produit pas d'erreur, envoie un KEEPALIVE et bascule dans OpenConfirm, dans les autres cas, envoie un message NOTIFICATION et retourne dans l'état Idle ;

OpenConfirm attend un message KEEPALIVE et bascule alors en Established, ou bien un message NOTIFICATION et retourne dans l'état Idle ;

Established la connexion BGP est établie, les messages UPDATE et KEEPALIVE peuvent être échangés, un message NOTIFICATION cause le retour dans l'état Idle.

Attributs Chaque préfixe dans BGP est associé à un certain nombre d'attributs. Ces attributs sont classés en quatre types différents : (WM) : ces attributs doivent être pris en charge et propagés ; (WD) : doivent être pris en charge, la propagation est optionnelle ; (OT) : pas nécessairement pris en charge mais propagés ; (ON) : pas nécessairement pris en charge ni propagés, peuvent être complètement ignorés s'ils ne sont pas pris en charge.

Voici quelques attributs avec leurs types :

Attribut Type Description Aggregator OT Si agrégation: Identificateur et AS du routeur qui a réalisé l'agrégation AS Path WM Liste ordonnée des systèmes autonomes traversés Atomic Aggregate WD Si agrégation "atomique" (supprimant les AS agrégés): Liste des AS supprimés après l'agrégation Cluster ID ON Identificateur du cluster de route reflector Community OT Marquage de route Local Preference WD Métrique destinée aux routeurs internes en vue de préférer certaines routes Multiple Exit Discriminator (MED) ON Métrique destinée au départ aux routeurs externes en vue de leur faire préférer certains routes (utilisable finalement plus largement) Next Hop WM Adresse IP du voisin BGP Origin WM Origine de la route (IGP, EGP ou Incomplete) Originator ID ON Identificateur apposé par le route reflector pour indiquer le router ID du routeur d'origine de la route Weight O(N) Extension Cisco en vue de préférer localement certains voisins, n'est jamais transmise aux voisins

AS Path

L'attribut AS Path permet d'éviter les boucles. Si une route est reçue d'un voisin eBGP avec son propre AS dans l'AS Path, alors la route est rejetée.

MED thumb|upright=1.8|BGP MED : les routeurs de l'AS 100 préféreront le lien A-C pour le réseau 10.1.1.0/24 en raison du MED inférieur.

L'attribut Multi-Exit Discriminator permet à un AS d'indiquer un lien à préférer. Le MED est un coût numérique codé sur 32 bits, il peut provenir d'un protocole de routage interne.

L'attribut MED n'est comparé que si l'AS voisin est identique. Certaines implémentations permettent cependant de comparer les MED même entre AS voisins différents. En présence de plus de deux chemins possibles en provenance d'au moins deux AS voisins, dans certaines implémentations la sélection de la meilleure route peut par défaut dépendre de l'ordre dans lequel les comparaisons sont effectuéesHow BGP Routers Use the Multi-Exit Discriminator for Best Path Selection, cisco.com technote.

Famille des communautés

Community

Une route peut disposer d'une liste d'attributs community. Chaque community est un nombre de 32 bits généralement représenté sur la forme x:y où x est un numéro d'AS et y un nombre dont la signification est propre à l'AS. Par exemple, l'AS 100 peut avoir pour politique d'attribuer une Local Preference 200 en présence de la community 100:200, ceci permet à un AS d'influencer le routage à l'intérieur d'autres AS.

Extended community

La généralise le concept des communities avec cet attribut OT. L'extended community est composée d'un ou deux octets pour le type, et de 6 ou pour la valeur. L'IANA maintient un registre des valeurs type réservées..Pour certains types (par exemple, le type Route-Target), la valeur peut être notamment divisée en deux champs (AS:LocalAdmin, ou IPv4:LocalAdmin). Dans ce cas la taille de chacun des deux champs (2 ou 4 octets) dépend de la taille de l'autre (pour un total de 6 octets).

Note: dans ce dernier type de cas, depuis la les extended communities sont compatibles avec les AS 32 bits.

Large Community L'introduction de numéros d'AS sur 32 bits pose un problème avec l'attribut community (qui ne peut recevoir qu'un AS sur 16 bits, ce qui rend inopérante la correspondance entre ce champ et la véritable valeur de l'AS). C'est pourquoi les et introduisent un attribut Large Community de 12 octets, divisés en trois champs de 4 octets chacun (AS:fonction:paramètre).

Next Hop

Quand un préfixe est annoncé à un voisin eBGP, l'attribut Next Hop représente l'adresse IP de sortie vers ce voisin. Cet attribut n'est pas altéré quand il est transmis aux voisins iBGP, ceci implique que la route vers l'adresse IP du voisin eBGP est connue via un IGP. Si ce n'est pas le cas, la route BGP est marquée comme inutilisable.

Processus de décision thumb|upright=1.8|Représentation simplifiée du processus de décision de BGP.

Les routes annoncées par les voisins BGP sont filtrées et éventuellement rejetées ou marquées en altérant les attributs de ces routes. La table BGP est construite en comparant les routes reçues pour chaque préfixe en choisissant la meilleure route. Seule la meilleure route sera utilisée dans la table de routage et annoncée aux voisins pour autant que le filtre de sortie le permette.

Choix de la meilleure route

Quand plusieurs routes sont possibles vers un même réseau (ce qui implique un masque de réseau identique), BGP préfère une des routes selon les critères suivants. Seule la meilleure route sera utilisée et annoncée aux voisins.