Border Gateway Protocol – Protocole de routage de type PATH-vecteur [RFC 1771 - IPv4, 03/95 & RFC 2545 - IPv6, 03/99]. Chaque entité est identifiée par un numéro d’AS. La granularité du routage est le Système Autonome (AS). Le support de la session BGP est TCP (port 179). Les sessions BGP sont établies entre « borders routers », c’est un protocole point à point entre routeurs de bord d’AS, symétrique, et enfin un annonceur BGP n’est pas forcément un routeur.
Il existe 2 grandes familles de protocoles de routage :
- Les protocoles intérieurs (IGP)
- Distance-vecteur : RIP, IGRP
- État des liens : OSPF, IS-IS
- Taille <100 routeurs, 1 autorité d’administration
- Échange de routes, granularité = routeur
- Les protocoles extérieurs (EGP)
- EGP, BGP, IDRP
- Taille = Internet, coopération d’entités indépendantes
- Échange d’informations de routage, granularité = AS
Rappel sommaire sur les types de protocoles de routage :
- distance vecteur : la distance est le nombre de routeurs pour joindre une destination, chaque routeur ne connaît que son voisinage et propage les routes qu’il connaît à ses voisins (ex. RIP).
- états des liens : chaque routeur connaît la topologie et l’état de l’ensemble des liens du réseau, puis en déduit les chemins optimaux. À chaque interaction les routeurs s’envoie toute leur table de routage (ex.OSPF).
Le protocole BGP peut être considéré comme à mi-chemin entre les deux types de protocoles précédents. En effet, l’échange de chemins d’AS permet à chaque routeur de reconstruire une grande partie de la topologie du réseau, ce qui est caractéristique des protocoles de type « état des liens », mais deux routeurs voisins n’échangent que les routes qu’ils connaissent, ce qui est caractéristique d’un protocole de type « distance-vecteur ».
Règles de base pour les AS multi connectés en BGP :
- Les routeurs de bord d’un même AS échangent leurs informations de routage en I-BGP
- Les connexions en I-BGP forment un maillage complet sur les routeurs de bord d’un AS.
- Ce sont les IGP internes à l’AS qui assurent et maintiennent la connectivité entre les routeurs de bord qui échangent des informations de routage en I-BGP
- Le numéro d’AS est un numéro officiel (si connexions vers 2 AS différents)
Attention, dans un même AS, c’est bien l’IGP (ou le routage statique) qui est responsable de la connectivité interne de l’AS. Si un routeur de bord ne peut pas atteindre une route de son AS (qui lui a été annoncée par un voisin interne par exemple), il ne la propagera pas à ses voisins BGP (externes ou internes).
Détails sur un processus BGP :
Automate à 6 états, qui réagit sur 13 événements, Il interagit avec les autres processus BGP par échange de 4 types de messages :
- OPEN – 1er message envoyé après l’ouverture de la session TCP, il informe son voisin de sa version de BGP, son numéro d’AS, d’un numéro identifiant le processus BGP, propose une valeur de temps de maintien de la session (valeur suggérée : 90 secondes si 0 : maintien sans limite de durée, met le processus en attente d’un KEEPALIVE. En cas de démarrage simultané de deux sessions BGP par deux voisins, il faut choisir de ne conserver que l’une des deux connexions. Pour cela on ne conserve que celle ouverte par le processus de numéro identifiant le plus petit. Pour déterminer ce numéro identifiant, l’implémentation de Cisco choisit par défaut le plus petit numéro IP des interfaces connues.
- KEEPALIVE – Confirme un OPEN, réarme le minuteur contrôlant le temps de maintien de la session si temps de maintien non égal à 0, est réémis toutes les 30 secondes (suggéré). C’est un message de taille minimum (19 octets). En cas d’absence de modification de leur table de routage, les routeurs ne s’échangent plus que des messages KEEPALIVE toutes les 30 secondes, ce qui génère un trafic limité à environ 5bits/s au niveau BGP. L’implémentation BGP de Cisco porte par défaut à 60 secondes l’intervalle entre 2 messages KEEPALIVE.
- NOTIFICATION – Le message NOTIFICATION est envoyé au moindre incident lors du déroulement du processus BGP. Le message ferme la session BGP, fournit un code et un sous code renseignants sur l’erreur, ferme aussi la session TCP, annule toutes les routes apprises par BGP. Le fait de supprimer lors de son arrivée toutes les routes apprises par BGP peut provoquer des instabilités de routage injustifiées (un incident ne veut pas forcément dire que toutes les routes apprises précédemment sont devenues fausses). Le message est émis sur incidents lorsqu’il n’y a pas de KEEPALIVE pendant 90s (<hold time>), lorsqu’un message incorrect arrive, s’il y a détection d’un problème dans le processus BGP,… Dans son implémentation de BGP, Cisco donne la possibilité de supprimer cette fonctionnalité, en conservant telle quelle la table de routage en cas de réception d’un message NOTIFICATION.
- UPDATE – C’est le message principal du protocole. Il sert à échanger les informations de routage (routes à éliminer (éventuellement), ensemble des attributs de la route, ensemble des réseaux accessibles (NLRI – chaque réseau est défini par (préfixe, longueur)), le message est envoyé uniquement si changement, il active le processus BGP avec modification des RIB (Update, politique de routage, conf.) et génère l’émission d’un message UPDATE vers les autres voisins. Lors du paramétrage d’un processus BGP il faut aussi faire un choix entre synchroniser ou pas les annonces (update) de l’IGP et les annonces BGP.
La taille des messages de 19 à 4096 octets, ils peuvent être éventuellement sécurisés par MD5. Les messages étant de longueur variable, ils sont marqués dans le flot d’octets du canal TCP par une séquence spéciale de trois octets qui repère leur début.
La liste complète des événements pouvant arriver est la suivante :
- Démarrage BGP
- Fin BGP
- Session TCP ouverte
- Session TCP fermée
- Ouverture session TCP échouée
- Erreur fatale dans session TCP
- Minuteur ConnectRetry expiré
- Minuteur Hold Time expiré
- Minuteur KeepAlive expiré
- Réception d’un message OPEN
- Réception d’un message KEEPALIVE
- Réception d’un message UPDATE
- Réception d’un message NOTIFICATION
Les RFC et BGP4 :
- RFC1657 Définition of Managed Objects for the Fourth Version of Border Gateway Protocol (BGP-4). S.Willis, J. Burruss, and J. Chu. 06/1995.(DS)
- RFC1771 A Border Gateway Protocol 4 (BGP-4). Y. Rekhter, T. Li. 03/1995. (DS)
- RFC1772 Application of the Border Gateway Protocol in the Internet. Y Rekhter, P. Gross. 03/1995. (DS)
- RFC1773 Experience with the BGP-4 protocol. P. Traina. 03/1995. (INFO)
- RFC1774 BGP-4 Protocol Analysis. P. Traina, Editor. 03/1995. (INFO)
- RFC1966 BGP Route Reflection An alternative to full mesh IBGP. T. Bates & R. Chandrasekeran.06/1996. (EXP)
- RFC1997 BGP Communities Attribute. R. Chandra, P. Traina & T. Li. 06/1996. (PS)
- RFC1998 An Application of the BGP Community Attribute in Multi-home Routing. E. Chen & T. Bates.06/1996. (INFO)
- RFC2042 Registering New BGP Attribute Types. B. Manning. 01/1997. (INFO)
- RFC2385 Protection of BGP Sessions via the TCP MD5 Signature Option. A. Heffernan. 08/1998. (PS)
- RFC2439 BGP Route Flap Damping. C.Villamizar, R.Chandra, R.Govindan. 1/1998. (PS)
- RFC2457 Definitions of Managed Objects for Extended Border Node. B. Clouston, . Moore. 11/1998. (PS)
- RFC2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing. P. Marques, F. Dupont.03/1999. (PS)
- RFC2547 BGP/MPLS VPNs. E. Rosen, Y. Rekhter. 03/1999. (Status: INFO)
- RFC2796 BGP Route Reflection – An Alternative to Full Mesh IBGP. T. Bates, R. Chandra, E. Chen.04/2000. (Updates RFC1966) (PS)
- RFC2842 Capabilities Advertisement with BGP-4. R. Chandra, J. Scudder. 06/2000. (PS)
- RFC2858 Multiprotocol Extensions for BGP-4. T. Bates, Y. Rekhter, R. Chandra, D. Katz. 06/2000. (PS)
- RFC2918 Route Refresh Capability for BGP-4. E. Chen, 09/2000. (PS)
- RFC3065 Autonomous System Confederations for BGP. P. Traina, D. McPherson, J. Scudder. 02/2001.(PS)
Bref historique de l’évolution du protocole BGP (voir RFC1773) :
- BGP-1 : RFC1105, juin 1989
- BGP-2 : RFC1163, juin 1990
La hiérarchisation des AS est supprimée (notion de liens inter-AS haut/bas/horizontaux), introduction des attributs de routes, beaucoup de changements dans les formats des messages.
- BGP-3 : RFC1267, octobre 1991
Détection et gestion des collisions d’ouvertures de sessions BGP, introduction d’un identifiant de routeur, le NEXT_HOP peut être situé dans un autre AS que celui du routeur qui fait l’annonce.
- BGP-4 : RFC1771, mars 1995
Ajout des adresses CIDR, introduction des ensembles d’AS (non ordonnés) dans les AS_PATH, et ajout des attributs de route MED (remplace INTER-AS METRIC), LOCAL-PRFERENCE, AGGREGATOR.
- BGP-4+ : RFC2283, février 1998 et RFC2545, mars 1999