Border Gateway Protocol - Définition

Introduction

Pile de protocoles

7 • Application 6 • Présentation 5 • Session 4 • Transport 3 • Réseau 2 • Liaison 1 • Physique

Modèle Internet Modèle OSI

Border Gateway Protocol (BGP) est un protocole d'échange de route utilisé notamment sur le réseau Internet. Son objectif est d'échanger des informations d'accessibilité de réseaux (appelés préfixes) entre routeurs par le biais de sessions TCP (sur le port 179).

BGP est utilisé pour véhiculer des réseaux entre Autonomous Systems (AS) car il est le seul protocole à supporter de très grands volumes de données et à disposer de possibilités étendues de sélection.

Contrairement aux protocoles de routage interne, BGP n'utilise pas de métrique classique mais base 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 chemin (path vector protocol).

BGP supporte 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 RFC 4271 A Border Gateway Protocol 4 (BGP-4).

D'autres versions de BGP permettent l'échange de routes IPv6 (RFC 2545) et l'extension multi-protocole (MP-BGP, RFC 2858) qui permet l'utilisation de BGP dans un réseau MPLS.

Fonctionnement

Les connexions entre deux voisins BGP (neighbours ou peers) sont configurées manuellement 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.

Il existe deux versions de BGP : Interior BGP (iBGP) et Exterior BGP (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 établies entre des adresses logiques, non associées à une interface physique particulière. Ceci permet, en cas de rupture d'un lien physique, de conserver la session iBGP active si un lien alternatif existe et si un protocole de routage interne dynamique est employé (par exemple OSPF).

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 une sélection fine de 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 tels que les numéros d'AS respectifs et de négocier les capacités de chacun des pairs ;

KEEPALIVE 

maintien la session ouverte. Par défaut le message KEEPALIVE est envoyé toutes les 60 secondes, et trois messages manqués entraînent 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 suite à une erreur.

Machine à états finis 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 :

1. Idle
2. Connect
3. Active
4. OpenSent
5. OpenConfirm
6. Established

Les événements :

1. BGP Start
2. BGP Stop
3. BGP Transport connection open
4. BGP Transport connection closed
5. BGP Transport connection open failed
6. BGP Transport fatal error
7. ConnectRetry timer expired
8. Hold Timer expired
9. KeepAlive timer expired
10. Receive OPEN message
11. Receive KEEPALIVE message
12. Receive UPDATE message
13. Receive NOTIFICATION message

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

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ée à un certain nombre d'attributs. Ces attributs sont classés en quatre types différents :

• Well-Known Mandatory (WM) : ces attributs doivent être supportés et propagés ;
• Well-Known Discretionary (WD) : doivent être supportés, la propagation est optionnelle ;
• Optional Transitive (OT) : pas nécessairement supportés mais propagés ;
• Optional Nontransitive (ON) : pas nécessairement supportés ni propagés, peuvent être complètement ignorés s'ils ne sont pas supportés.

Voici quelques attributs avec leurs types :

Attribut	Type	Description
Aggregator	OT	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	Liste des AS supprimés après une agrégation
Cluster ID	ON	Cluster d'origine
Community	OT	Marquage de route
Local Preference	WD	Métrique destinée aux routeurs internes en vue de préférer certaines routes externes
Multiple Exit Discriminator (MED)	ON	Métrique destinée aux routeurs externes en vue de préférer certaines routes internes
Next Hop	WM	Adresse IP du voisin eBGP
Origin	WM	Origine de la route (IGP, EGP ou Incomplete)
Originator ID	ON	Identificateur du route reflector
Weight	O(N)	Extension Cisco en vue de préférer localement certains voisins, n'est jamais transmise aux voisins

Sélection de la meilleure route

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

Ordre	Nom	Description	Préférence
1	Weight	Préférence administrative locale	la plus élevée
2	Local Preference	Préférence à l'intérieur d'un AS	la plus élevée
3	Self-Originated	Préférence des réseaux dont l'origine est ce routeur	vrai > faux
4	AS Path	Préférence du chemin avec les moins d'AS traversés	le plus court
5	Origin	Préférence du chemin en fonction de la façon dont ils sont connus par le routeur d'origine	IGP > EGP > Incomplete
6	MED	Préférence en fonction de la métrique annoncée par l'AS d'origine	la plus faible
7	External	Préférence des routes eBGP sur les routes iBGP	eBGP > iBGP
8	IGP Cost	Métrique du Next-Hop dans l'IGP	la plus faible
9	eBGP Peering	Préfère les routes les plus stables	la plus ancienne
10	Router ID	Départage en fonction de l'ID du routeur	la plus faible

Route reflectors et Confederations

Dans iBGP, les routes ne sont pas transitives, c'est-à-dire qu'une route reçue via iBGP n'est pas transmise aux voisins iBGP, ce qui implique que tous les routeurs participant au routage BGP au sein d'un AS doivent établir des connexions entre eux (full mesh) ce qui peut poser des problèmes d'échelle, le nombre de connexions augmentant selon le carré du nombre de routeurs présents dans l'AS. Deux solutions sont disponibles pour passer outre cette limite : les route reflectors et les confederations.

route reflectors 

cette extension protocolaire permet de réduire le nombre de connexions nécessaires au sein d'un AS. Un seul routeur (ou deux routeurs pour la redondance) établit des sessions avec tous les autres routeurs de son groupe. Les autres routeurs (ses clients) n'ont besoin que de se connecter à lui.

confederations 

est utilisé dans les très grands réseaux ou l'AS est subdivisé en petits AS internes. Les confédérations peuvent être utilisées conjointement avec les routes reflectors. eBGP est utilisé entre les confédérations. Les confédérations sont masquées quand le préfixe est annoncé en dehors de l'AS principal.

Pour éviter les boucles possibles avec ces configuration, des attributs supplémentaires sont utilisés : Cluster_ID et Originator_ID.

Lorsqu'un réseau est ajouté à un AS, il doit être annoncé au maillage BGP : soit au route reflector lorsqu'il existe, soit à l'ensemble des routeurs BGP de l'AS. BGP ne se substitue cependant pas à un protocole de routage interne.