Border Gateway Protocol

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[1].

Pour les articles homonymes, voir BGP.

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

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é)[3]: 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 (RFC 2545[4]), les premières versions se limitant à IPv4, et l'extension multi-protocole (MP-BGP, RFC 2858[5]) permet d'utiliser BGP pour convoyer des informations de routage pour de nombreux autres protocoles, notamment les routes liées à des VPN MPLS (IPv4[6], IPv6[7], VPLS[8]...).

Fonctionnement
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 (neighbors ou peers) 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[9], un identifiant de quatre octets, unique pour chacun des routeurs d'un Autonomous Systems (AS) donné, qui peut être choisi arbitrairement mais qui est généralement une adresse IPv4[10] loopback[11],[12],[13],[14] de chaque routeur.

Il existe deux modes de fonctionnement 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 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é[15] (en général OSPF ou IS-IS) qui permet aux routeurs du réseau considéré de se joindre via leurs adresses loopback[16]. Ainsi en cas de rupture d'un lien physique, la session iBGP reste active[17] 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[18] ;
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 RFC 2918[19], 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
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 :

  1. Idle
  2. Connect
  3. Active
  4. OpenSent
  5. OpenConfirm
  6. 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 :

  • Well-Known Mandatory (WM) : ces attributs doivent être pris en charge et propagés ;
  • Well-Known Discretionary (WD) : doivent être pris en charge, la propagation est optionnelle ;
  • Optional Transitive (OT) : pas nécessairement pris en charge mais propagés ;
  • Optional Nontransitive (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 :

AttributTypeDescription
AggregatorOTSi agrégation: Identificateur et AS du routeur qui a réalisé l'agrégation
AS PathWMListe ordonnée des systèmes autonomes traversés
Atomic AggregateWDSi agrégation "atomique" (supprimant les AS agrégés): Liste des AS supprimés après l'agrégation
Cluster IDONIdentificateur du cluster de route reflector
CommunityOTMarquage de route
Local PreferenceWDMétrique destinée aux routeurs internes en vue de préférer certaines routes
Multiple Exit Discriminator (MED)ONMétrique destinée au départ aux routeurs externes en vue de leur faire préférer certains routes (utilisable finalement plus largement)
Next HopWMAdresse IP du voisin BGP
OriginWMOrigine de la route (IGP, EGP ou Incomplete)
Originator IDONIdentificateur apposé par le route reflector pour indiquer le router ID du routeur d'origine de la route
WeightO(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
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ées[20].

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 RFC 4360[21] 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 7 octets pour la valeur. L'IANA maintient un registre des valeurs type réservées[22].
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 RFC 7153[23] les extended communities sont compatibles avec les AS 32 bits.

Large Community

L'introduction de numéros d'AS sur 32 bits pose 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 RFC 8092[24] et RFC 8195[25] 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
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.

OrdreNomDescriptionPréférence
1 Weight[26] Préférence administrative localela plus élevée
2 LOCAL_PREF Préférence à l'intérieur d'un ASla plus élevée
3 Self-Originated Préférence des réseaux dont l'origine est ce routeurvrai > faux
4 AS_PATH Préférence du chemin avec les moins d'AS traversésle plus court
5 ORIGIN Préférence du chemin en fonction de la façon dont ils sont connus par le routeur d'origineIGP > EGP > Incomplete
6 MULTI_EXIT_DISC Préférence en fonction de la métrique annoncée par l'AS d'originela plus faible
7 External Préférence des routes eBGP sur les routes iBGPeBGP > iBGP
8 IGP Cost Métrique dans l'IGP du chemin vers le NEXT_HOPla plus faible
9 eBGP Peering Préfère les routes les plus stablesla plus ancienne
10 Router ID Départage en fonction de l'identifiant du routeurla plus faible

Si l'option BGP Multipath est active, les routes semblables après l'étape numéro 8 sont acceptées.

Synchronisation

Au début de BGP4, dans certaines topologies, BGP ne fonctionnait pas sur les routeurs de cœur mais uniquement en bordure (reprenant les topologies EGP de l'époque), et toutes les routes BGP étaient redistribuées vers l'IGP. Il pouvait être alors nécessaire d'attendre que la route soit présente dans l'IGP avant qu'elle soit rendue utilisable dans BGP.

Ce type de configuration étant considéré comme une mauvaise pratique à proscrire (notamment au vu de l'inflation du nombre de routes BGP sur Internet), cette contrainte de synchronisation a disparu en devenant obsolète[27].

Route reflectors et Confederations
Confederations et route reflectors

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 chaque routeur participant au routage BGP au sein d'un AS doit établir des connexions avec tous les autres (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 (RFC 4456[28]) et les confederations (RFC 5065[29]).

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 configurations, 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.

AS sur 32 bits
Croissance du nombre d'AS sur Internet depuis 1997.

Le standard RFC 1771[30] (A Border Gateway Protocol 4 (BGP-4)) prévoyait le codage des numéros d'AS sur 16 bits, c'est-à-dire 64510 AS publics possibles en tenant compte du fait que les numéros 64512 à 65534 sont réservés pour des usages privés (0 et 65535 sont interdits). En 2011, il restait environ 15000 AS libres et les projections[31] laissaient présager un épuisement complet des AS disponibles en septembre 2013.

La RFC 6793[32] étend le codage des AS de 16 vers 32 bits (reprenant de 0 à 65535 la plage des AS 16 bits, et ses AS réservés), ce qui porte le nombre d'AS disponibles à plus de quatre milliards. Une plage supplémentaire d'AS privés est également définie dans la RFC 6996[33] (de 4200000000 à 4294967294, 4294967295 étant interdit par la RFC 7300[34]).

Pour permettre la traversée des groupes de routeurs qui ne gèrent pas ces nouveaux AS, le nouvel attribut OT AS4_PATH est employé.

L'assignation des AS sur 32 bits a débuté en 2007, et depuis 2009, le RIPE NCC distribue des AS 32 bits à la demande.

Utilisation

BGP est principalement utilisé entre les opérateurs et fournisseurs d'accès à Internet pour l'échange de routes.

La plupart des utilisateurs finaux d'Internet n'ont qu'une seule connexion à un fournisseur d'accès à Internet. Dans ce cas, BGP est inutile car une route par défaut est suffisante. Cependant, une entreprise qui serait connectée de façon redondante à plusieurs FAI (multi-homing) pourrait obtenir un numéro de système autonome propre et établir des sessions BGP avec chacun des fournisseurs.

Outre Internet, des réseaux IP privés peuvent utiliser BGP, par exemple pour interconnecter des réseaux locaux utilisant OSPF.

Problèmes et solutions

Vitesse de convergence

BGP est réputé être un protocole de routage lent par rapport aux IGP qui convergent généralement en une fraction de seconde. La vitesse de convergence de BGP est tributaire de plusieurs paramètres :

  • le hold time qui détermine après combien de temps une session inactive (sans UPDATE ni KEEPALIVE) est fermée. Il peut être réduit à 3 secondes au minimum mais vaut 90 s par défaut. La session BGP est cependant close sans délai après un changement d'état de l'interface à laquelle l'adresse IP de la session est associée, ou si la connexion TCP est interrompue (RST, FIN).
  • le nombre de préfixes qui devront chacun faire l'objet de messages UPDATE.
  • les performances du CPU pour le traitement des messages UPDATE.
  • le paramètre Minimum Route Advertisement Interval (MRAI) qui définit l'intervalle de temps minimum entre deux annonces BGP pour le même ensemble de préfixes et vers le même voisin. La RFC propose un MRAI de 30 s pour eBGP et 5 s pour iBGP. Certains travaux ultérieurs indiquent qu'il existe un bénéfice à réduire ce délai[35]. Les routes devenues inaccessibles sont annoncées immédiatement.
  • l'utilisation de BGP Protocol Independent Convergence (PIC)[36], qui permet un reroutage rapide et indépendent du nombre de préfixe à rerouter.

Instabilités et damping
Illustration du damping BGP

BGP est sensible à l'oscillation rapide des routes, les annonces des routes inaccessibles devant être propagées à tous les voisins BGP, obligeant ceux-ci à recalculer leur table de routage. L'effet cumulé de ces annonces peut causer une surcharge et nuire à la stabilité du routage sur un réseau tel qu'Internet. Une route oscillante peut être causée par un lien ou une interface défectueuse (mauvaise configuration, panne) ou un routeur qui redémarre.

Une fonctionnalité nommée damping (ou parfois dampening, RFC 2439[37] BGP Route Flap Damping; damping signifie amortissement en anglais) vise à réduire les effets de l'oscillation de routes. À chaque oscillation d'une route, le damping va accroître une pénalité numérique associée à cette route. Cette pénalité va décroître exponentiellement avec le temps. Quand la pénalité dépasse un seuil prédéfini, la route sera marquée comme inaccessible et les mises à jour à son sujet ignorées, et ce jusqu'à ce qu'un seuil inférieur pour la pénalité soit atteint.

Le document RIPE-229[38] définit des paramètres recommandés pour le damping. Cependant, à la lumière de l'expérience avec cette configuration, la recommandation du groupe de travail routage du RIPE est arrivée à la conclusion que le damping n'était plus recommandé et que le document RIPE-229 devait être considéré comme obsolète[39].

Préfixe avec origines multiples

La RFC 1930[40] recommande qu'un préfixe ait toujours pour origine le même AS, à l'exception de cas particuliers (routage anycast et certains cas de multi-homing avec AS privé). Dans les autres cas, on parle de BGP Multiple AS Origin (MOAS). Les MOAS sont souvent le résultat d'une erreur de configuration et peuvent créer des incidents de type déni de service.

Si un routeur annonce un préfixe pour lequel il n'assure pas réellement le transit, ce dernier peut devenir inaccessible depuis tout ou une partie d'Internet. L'effet sera encore plus prononcé si les préfixes annoncés sont plus spécifiques (c'est-à-dire si le masque réseau est plus long) que les préfixes légitimes, car les routes plus spécifiques sont toujours préférées.

Pour se prémunir de ce problème, les fournisseurs limitent les préfixes qu'ils acceptent de leurs voisins. Ces filtres sont alors mis à jour manuellement si le voisin vient à annoncer de nouvelles routes. Vu la complexité de la gestion de ces listes de filtrage, il est plus rare que les grands opérateurs filtrent les préfixes entre eux. Certains outils permettent cependant de bâtir ces filtres automatiquement en fonction du contenu de bases de données de routage (comme celle du RIPE). D'autres approches sont S-BGP[41] et soBGP[42]. Les approches qui sécurisent l'AS d'origine d'un préfixe ne prémunissent cependant pas contre les attaques malveillantes, dans la mesure où l'AS Path peut alors avoir été construit.

Le groupe de travail Secure Inter-Domain Routing (SIDR) de l'IETF[43] travaille sur un système de validation de la source d'un préfixe appelé Resource Public Key Infrastructure (en) (RPKI)[44].

Incident AS 7007 de 1997

Le , l'AS 7007 a redistribué accidentellement BGP dans RIP et réciproquement. RIP étant un protocole classful, ceci a causé l'apparition de sous-réseaux de taille /24, plus spécifiques que les routes originales, ce qui a provoqué des instabilités importantes sur Internet[45],[46]. Cet incident a attiré l'attention sur ce type de vulnérabilité.

Incident YouTube de 2008

En février 2008, le site YouTube a été inaccessible pendant environ deux heures. Le gouvernement pakistanais avait annoncé ce jour-là un blocage de YouTube au Pakistan[47],[48],[49], ordre qui a été exécuté par l'opérateur Pakistan Telecom.

Pakistan Telecom a alors annoncé à tous les routeurs des fournisseurs d'accès qu'il était la meilleure route à qui envoyer tout le trafic YouTube, qui a alors été coupé sur l'ensemble de la planète.

Ce type d'incident est désigné sous les noms d'IP hijacking (détournement d'adresse IP) ou de black hole (trou noir).

Croissance de la table de routage
Croissance de la table de routage de 1989.

Un des problèmes auquel BGP doit faire face sur Internet est la croissance de la table de routage des routeurs de la default-free zone, c'est-à-dire ceux qui disposent d'une table de routage complète et n'utilisent pas de route par défaut. Avec le temps, les routeurs plus anciens n'ont plus les ressources mémoire ou CPU nécessaires au maintien d'une table complète. D'autre part, la taille de la table nuit à la vitesse de convergence, le CPU étant particulièrement sollicité lors de changements importants (établissement de nouvelles connexions ou changements importants de topologie).

Jusqu'à 2001, la croissance a été exponentielle, menaçant le fonctionnement d'Internet. À cette date, des efforts ont été entrepris pour réduire les préfixes en les agrégeant. Ceci a permis une croissance linéaire pendant plusieurs années. Cependant la croissance exponentielle a repris à partir de 2004 environ sous la pression du nombre croissant de réseaux finaux qui disposent de plusieurs connexions redondantes.

En 2013, le nombre de préfixes diffusés sur Internet est d'environ 400 000[50].

Équilibrage de la charge et asymétrie

BGP ne dispose pas d'un système d'équilibrage de la charge entre plusieurs liens et ne tient pas compte de la congestion éventuelle des liens : si un AS est connecté à plusieurs fournisseurs de transit vers Internet, il se peut que certains soient congestionnés tandis que d'autres sont peu utilisés. De façon générale, les AS prennent des décisions de routage de façon indépendante, un AS a donc peu d'influence sur les décisions prises par un autre AS et ne dispose pas de contrôle fin de l'équilibrage du trafic entrant.

Diverses techniques existent cependant pour tenter de rééquilibrer la charge entre ces liens :

  • l'annonce de préfixes plus spécifiques différents ;
  • l'allongement artificiel des longueurs de chemin ;
  • l'utilisation de communautés ;
  • l'utilisation de MED.

Pour les mêmes raisons, le trafic peut être asymétrique, ce qui est fréquent entre les grands opérateurs qui suivent la politique dite de la patate chaude (en), qui consiste à router un paquet destiné à un réseau externe vers l'interconnexion la plus proche, évitant ainsi la traversée de sa propre dorsale.

Incident du 19 août 2009

Le 19 août 2009, un fournisseur d'accès japonais (AS 9354) annonça une route avec un attribut AS_PATH vide. Certaines implémentations de BGP de routeurs de fournisseur d'accès interrompent la session BGP avec une erreur quand ils reçoivent celui-ci, ce qui cause des perturbations dans plusieurs dorsales de FAI[51].

Incident du 27 août 2010

Le 27 août 2010, un attribut BGP expérimental utilisé dans un projet de recherche entre le RIPE NCC et l'université Duke a été propagé sur Internet et révélé un bug dans l'implémentation BGP de certains constructeurs. Ceci a provoqué l'instabilité de plusieurs milliers de préfixes sur Internet[52],[53].

Incident du

L'opérateur Telekom Malaysia annonce un très grand nombre de nouvelles routes erronées, reprises par Level 3 Communications, un important opérateur d'Internet, qui les diffuse alors mondialement. Cette diffusion a pour effet de rediriger une part importante du trafic mondial vers Telekom Malaysia qui annonce près d'un tiers des routes Internet existantes (de l'ordre de 176 000 sur 534 000 routes). Les infrastructures de celui-ci ne peuvent absorber un flux aussi massif, ce qui entraîne un très net ralentissement et des perturbations dans les communications, ressentis à l'échelle mondiale pendant une partie de la journée[54],[55].

Looking glass

Il existe un certain nombre de routeurs sur Internet qui permettent la consultation de la table de routage globale via une interface web. Voici un exemple de consultation[56] :

> show ip bgp 91.198.174.2
BGP routing table entry for 91.198.174.0/24, version 151383419
Paths: (2 available, best #1, table Default-IP-Routing-Table)
 Advertised to non peer-group peers:
 82.115.128.225
 TDC [3292] WIKIMEDIA-EU [43821]
   82.115.128.18 from 82.115.128.18 (62.95.30.10)
     Origin IGP, localpref 100, valid, external, best
     Community: 215745616 215746418
 IPO-EU [12552] PORT80-GLOBALTRANSIT [16150] WIKIMEDIA-EU [43821]
   82.115.128.26 from 82.115.128.26 (62.109.44.1)
     Origin IGP, localpref 100, valid, external

Dans cet exemple, l'adresse IP 91.198.174.2 fait partie du préfixe le plus spécifique 91.198.174.0/24. Deux routes sont disponibles, la première a traversé deux AS (43821, son AS d'origine, puis 3292) et la seconde trois (43821, 16150 et 12552), le Local Pref étant égal, la première route, plus courte pour ce qui est du nombre d'AS traversés, est préférée.

La route dispose de deux attributs community : 3292:1104 et 3292:1906.

Les noms associés aux AS sont ajoutés par l'interface en consultant une base de données de routage publique.

Implémentation libre de BGP
  • GNU Zebra, suite de protocoles de routage supportant, entre autres, BGP.
  • Quagga Software, fork de GNU Zebra pour les systèmes dérivés d'Unix.
  • OpenBGPD, implémentation BGP, sous licence ISC, par l'équipe d'OpenBSD.
  • BIRD, suite de protocoles de routage pour les systèmes dérivés d'Unix, sous licence GPL.

Liens externes

Les principales RFC concernées sont les suivantes :

  • (en) RFC 4271[2], A Border Gateway Protocol 4 (BGP-4). Janvier 2006. Remplace la RFC 1771[30].
  • (en) RFC 4274[57], BGP-4 Protocol Analysis. Janvier 2006.
  • (en) RFC 4277[58], Experience with the BGP-4 Protocol. Janvier 2006.
  • (en) RFC 4456[28], BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP). Avril 2006. Remplace la RFC 2796[59].

Références
  1. Donna L. Harrington, CCNP Practical Studies: Troubleshooting, Cisco Press, (lire en ligne)
  2. (en) Request for comments no 4271.
  3. (en) P. Traina, « BGP-4 Protocol Analysis », sur tools.ietf.org (consulté le )
  4. (en) Request for comments no 2545.
  5. (en) Request for comments no 2858.
  6. (en) « RFC4364 », sur tools.ietf.org (consulté le )
  7. (en) « RFC4364 », sur tools.ietf.org (consulté le )
  8. (en) « RFC4364 », sur tools.ietf.org (consulté le )
  9. (en) Yuan, Jenny et Chen, Enke, « AS-wide Unique BGP Identifier for BGP-4 », sur tools.ietf.org (consulté le )
  10. (en) Hares, Susan et Rekhter, Yakov, « A Border Gateway Protocol 4 (BGP-4) », sur tools.ietf.org (consulté le )
  11. Greene, Barry Raveendran., Cisco ISP essentials, Cisco Press, (ISBN 1-58705-041-2, OCLC 52355438, lire en ligne)
  12. (en) « BGP router-id do you need a interface ip_address », sur socpuppet.blogspot.fr (consulté le )
  13. (en) « Cisco IOS XR Routing Configuration Guide for the Cisco XR 12000 Series Router, Release 3.9 - Implementing BGP [Cisco IOS XR Software Release 3.9] », sur Cisco (consulté le )
  14. Goralski, Walter., Bushong, Michael. et Bushong, Michael., Junos OS for dummies, 2nd edition, John Wiley & Sons, , 408 p. (ISBN 978-0-470-89189-6, OCLC 781262878, lire en ligne)
  15. « IBGP> BGP Fundamentals », sur www.ciscopress.com (consulté le )
  16. (en) Philip Smith, « BGP Best Practices », sur RIPE,
  17. Osterloh, Heather., IP routing primer plus, Sams, (ISBN 0-672-32210-2, OCLC 48361925, lire en ligne)
  18. Cisco utilise cependant un Keep Alive de 60 s et un Hold Time de 180 s par défaut
  19. (en) Request for comments no 2918.
  20. How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection, cisco.com technote
  21. (en) Request for comments no 4360.
  22. Border Gateway Protocol (BGP) Extended Communities, IANA
  23. (en) Request for comments no 7153.
  24. (en) Request for comments no 8092.
  25. (en) Request for comments no 8195.
  26. Cisco uniquement
  27. Doyle, Jeff,, Routing TCP/IP. Volume 2, , 1000 p. (ISBN 978-1-58705-470-9 et 1-58705-470-1, OCLC 959889046, lire en ligne)
  28. (en) Request for comments no 4456.
  29. (en) Request for comments no 5065.
  30. (en) Request for comments no 1771.
  31. 16-bit Autonomus System Report, Geoff Huston 2011
  32. (en) Request for comments no 6793.
  33. (en) Request for comments no 6996.
  34. (en) Request for comments no 7300.
  35. Revised Default Values for the BGP Minimum Route Advertisement Interval, Internet Draft, novembre 2008
  36. BGP PIC, Clarence Filsfils, NANOG 40
  37. (en) Request for comments no 2439.
  38. RIPE-229 RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parameters, octobre 2001
  39. RIPE 378 RIPE Routing Working Group Recommendations On Route-flap Damping, mai 2006
  40. (en) Request for comments no 1930.
  41. Securing the Border Gateway Protocol The Internet Protocol Journal - Volume 6, Number 3
  42. Securing BGP Through Secure Origin BGP id
  43. SIDR charter
  44. RPKI-Based Origin Validation Operation, Internet Draft, mars 2011
  45. (en) 7007 Explanation and Apology.
  46. (en) Internet routing black hole.
  47. Crashdump.fr, « Protocole BGP, l’Internet en danger ? »,
  48. « Pakistan lifts the ban on YouTube », BBC News,
  49. « YouTube Hijacking: A RIPE NCC RIS case study », RIPE NCC
  50. BGP Routing Table Analysis Reports
  51. NANOG
  52. Research experiment disrupts Internet, for some
  53. RIPE NCC and Duke University BGP Experiment, Erik Romijn
  54. Martin Untersinger, Pourquoi Internet était un peu lent vendredi matin, Le Monde, .
  55. Massive route leak cause Internet slowdown, BGPMON, .
  56. http://lg.intron.net/
  57. (en) Request for comments no 4274.
  58. (en) Request for comments no 4277.
  59. (en) Request for comments no 2796.
  • Portail de l’informatique
  • Portail des télécommunications
Cet article est issu de Wikipedia. Le texte est sous licence Creative Commons - Attribution - Partage dans les Mêmes. Des conditions supplémentaires peuvent s'appliquer aux fichiers multimédias.