Border Gateway Protocol
(
BGP
) est un protocole d'
echange de route
externe (un
EGP
), utilise notamment sur le reseau
Internet
. Son objectif principal est d'echanger des informations de routage et d'accessibilite de reseaux (appeles
prefixes
) entre
Autonomous Systems
(AS). Comme il circule sur
TCP
, il est considere comme appartenant a la
couche application
du
modele OSI
[
1
]
.
Contrairement aux protocoles de
routage
interne, BGP n'utilise pas de
metrique
classique mais fonde les decisions de routage sur les chemins parcourus, les attributs des prefixes et un ensemble de regles de selection definies par l'administrateur de l'AS. On le qualifie de protocole a vecteur de chemins (
path vector protocol
).
BGP prend en charge le
routage sans classe
et utilise l'agregation de routes afin de limiter la taille de la table de routage. Depuis
1994
, la version 4 du protocole est utilisee sur Internet, les precedentes etant considerees comme obsoletes. Ses specifications sont decrites dans la
RFC
4271
[
2
]
A Border Gateway Protocol 4 (BGP-4)
.
BGP a remplace
Exterior Gateway Protocol (EGP)
qui etait utilise dans la dorsale
ARPANET
et a permis la decentralisation du routage sur Internet. Il a pour interet son passage a l'echelle (
scalabilite
)
[
3
]
: il peut traiter un tres grand nombre de routes entre de nombreux
Autonomous Systems
en evitant les boucles, et masque la topologie interne des AS entre eux.
Certaines extensions de BGP permettent l'echange de routes IPv6 (
RFC
2545
[
4
]
), les premieres versions se limitant a 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 liees a des VPN
MPLS
(IPv4
[
6
]
, IPv6
[
7
]
, VPLS
[
8
]
...).
Les connexions entre deux voisins BGP (
neighbors
ou
peers
) sont configurees explicitement entre deux routeurs. Ils communiquent alors entre eux via une session
TCP
sur le port 179 initiee par l'un des deux routeurs. BGP est le seul protocole de routage a utiliser TCP comme protocole de transport.
Les routeurs voisins sont identifies par leur router ID
[
9
]
, un identifiant de quatre octets, unique pour chacun des routeurs d'un
Autonomous Systems
(AS) donne, qui peut etre choisi arbitrairement mais qui est generalement 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 utilise a l'interieur d'un Autonomous System alors que eBGP est utilise entre deux AS.
En general, les connexions eBGP sont etablies sur des connexions point-a-point ou sur des reseaux locaux (un
Internet Exchange Point
par exemple), le
TTL
des paquets de la session BGP est alors fixe a 1. Si la liaison physique est rompue, la session eBGP l'est egalement, et tous les prefixes appris par celle-ci sont annonces comme supprimes et retires de la table de routage.
A l'inverse, les connexions iBGP sont generalement etablies entre des adresses IP logiques, non associees a une interface physique particuliere: des
adresses loopback
. En effet, classiquement, un protocole de routage interne dynamique (
IGP
) est employe
[
15
]
(en general
OSPF
ou
IS-IS
) qui permet aux routeurs du reseau considere 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 etablie, ceux-ci s'echangent des informations sur les reseaux qu'ils connaissent et pour lesquels ils proposent du transit, ainsi qu'un certain nombre d'attributs associes a ces reseaux qui vont permettre d'eviter des boucles (comme
AS Path
) et de choisir avec finesse la meilleure route.
- OPEN
- ce message est utilise des que la connexion TCP est etablie entre les voisins BGP, il permet d'echanger des informations telles que les numeros d'AS respectifs et les router ID de chacun, et de negocier les capacites de chacun des pairs ;
- KEEPALIVE
- maintient la session ouverte. Par defaut le message KEEPALIVE est envoye toutes les 30 secondes, et un delai de 90 secondes sans message UPDATE ni KEEPALIVE recu entraine 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 a la suite d'une erreur ;
- ROUTE-REFRESH
- definie dans la
RFC
2918
[
19
]
, la capacite de rafraichissement des routes est negociee dans le message OPEN et permet de demander/reannoncer certains prefixes apres une modification de la politique de filtrage.
Le logiciel permettant de gerer les echanges de route doit implementer un
automate fini
constitues de six etats lies par treize evenements. Les automates dialoguent entre eux par des messages (OPEN, KEEPALIVE, UPDATE, NOTIFICATION).
Les etats sont :
- Idle
- Connect
- Active
- OpenSent
- OpenConfirm
- Established
Les changements d'etats et le comportement attendus sont les suivants :
- Idle
- Dans cet etat, le processus refuse les connexions et n'alloue aucune ressource. Quand l'evenement de demarrage (manuel ou automatique) est recu, le processus initie les ressources et une connexion avec les voisins configures, et ecoute les connexions entrantes sur le port TCP 179 et bascule dans l'etat Connect. En cas d'erreur, la connexion est coupee et le processus retourne dans l'etat Idle ;
- Connect
- attend que la connexion TCP soit etablie, puis envoie le message OPEN et bascule dans l'etat OpenSent. En cas d'erreur, attend un delai predefini et continue a ecouter sur le port 179 puis bascule dans l'etat Active ;
- Active
- Tente d'etablir une connexion TCP avec le voisin. En cas de reussite, envoie le message OPEN et bascule dans l'etat Connect, tout autre evenement provoque le retour dans l'etat Idle ;
- OpenSent
- le message OPEN a ete envoye, 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'etat Idle ;
- OpenConfirm
- attend un message KEEPALIVE et bascule alors en Established, ou bien un message NOTIFICATION et retourne dans l'etat Idle ;
- Established
- la connexion BGP est etablie, les messages UPDATE et KEEPALIVE peuvent etre echanges, un message NOTIFICATION cause le retour dans l'etat Idle.
Chaque prefixe dans BGP est associe a un certain nombre d'attributs. Ces attributs sont classes en quatre types differents :
- Well-Known Mandatory
(WM) : ces attributs doivent etre pris en charge et propages ;
- Well-Known Discretionary
(WD) : doivent etre pris en charge, la propagation est optionnelle ;
- Optional Transitive
(OT) : pas necessairement pris en charge mais propages ;
- Optional Nontransitive
(ON) : pas necessairement pris en charge ni propages, peuvent etre completement ignores s'ils ne sont pas pris en charge.
Voici quelques attributs avec leurs types :
Attribut
|
Type
|
Description
|
Aggregator
|
OT
|
Si agregation: Identificateur et AS du routeur qui a realise l'agregation
|
AS Path
|
WM
|
Liste ordonnee des systemes autonomes traverses
|
Atomic Aggregate
|
WD
|
Si agregation "atomique" (supprimant les AS agreges): Liste des AS supprimes apres l'agregation
|
Cluster ID
|
ON
|
Identificateur du cluster de
route reflector
|
Community
|
OT
|
Marquage de route
|
Local Preference
|
WD
|
Metrique destinee aux routeurs internes en vue de preferer certaines routes
|
Multiple Exit Discriminator (MED)
|
ON
|
Metrique destinee au depart aux routeurs externes en vue de leur faire preferer 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 appose par le
route reflector
pour indiquer le router ID du routeur d'origine de la route
|
Weight
|
O(N)
|
Extension Cisco en vue de preferer localement certains voisins, n'est jamais transmise aux voisins
|
L'attribut AS Path permet d'eviter les boucles. Si une route est recue d'un voisin eBGP avec son propre AS dans l'AS Path, alors la route est rejetee.
L'attribut
Multi-Exit Discriminator
permet a un AS d'indiquer un lien a preferer. Le MED est un cout numerique code sur 32 bits, il peut provenir d'un protocole de routage interne.
L'attribut MED n'est compare que si l'AS voisin est identique. Certaines implementations permettent cependant de comparer les MED meme entre AS voisins differents. En presence de plus de deux chemins possibles en provenance d'au moins deux AS voisins, dans certaines implementations la selection de la meilleure route peut par defaut dependre de l'ordre dans lequel les comparaisons sont effectuees
[
20
]
.
Une route peut disposer d'une liste d'attributs
community
. Chaque community est un nombre de 32 bits generalement represente sur la forme x:y ou x est un numero d'AS et y un nombre dont la signification est propre a l'AS. Par exemple, l'AS 100 peut avoir pour politique d'attribuer une Local Preference 200 en presence de la community 100:200, ceci permet a un AS d'influencer le routage a l'interieur d'autres AS.
La
RFC
4360
[
21
]
generalise le concept des communities avec cet attribut OT. L'
extended community
est composee 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
reservees
[
22
]
.
Pour certains types (par exemple, le type Route-Target), la valeur peut etre notamment divisee en deux champs (AS:LocalAdmin, ou IPv4:LocalAdmin). Dans ce cas la taille de chacun des deux champs (2 ou 4 octets) depend 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.
L'introduction de numeros d'AS sur 32 bits pose probleme avec l'attribut community (qui ne peut recevoir qu'un AS sur 16 bits, ce qui rend inoperante la correspondance entre ce champ et la veritable valeur de l'AS). C'est pourquoi les
RFC
8092
[
24
]
et
RFC
8195
[
25
]
introduisent un attribut
Large Community
de 12 octets, divises en trois champs de 4 octets chacun (AS:fonction:parametre).
Quand un prefixe est annonce a un voisin eBGP, l'attribut Next Hop represente l'adresse IP de sortie vers ce voisin. Cet attribut n'est pas altere 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 marquee comme inutilisable.
Les routes annoncees par les voisins BGP sont filtrees et eventuellement rejetees ou marquees en alterant les attributs de ces routes.
La table BGP est construite en comparant les routes recues pour chaque prefixe en choisissant la meilleure route.
Seule la meilleure route sera utilisee dans la table de routage et annoncee aux voisins pour autant que le filtre de sortie le permette.
Quand plusieurs routes sont possibles vers un meme reseau (ce qui implique un masque de reseau identique), BGP prefere une des routes selon les criteres suivants. Seule la meilleure route sera utilisee et annoncee aux voisins.
Ordre
|
Nom
|
Description
|
Preference
|
1
|
Weight
[
26
]
|
Preference administrative locale
|
la plus elevee
|
2
|
LOCAL_PREF
|
Preference a l'interieur d'un AS
|
la plus elevee
|
3
|
Self-Originated
|
Preference des reseaux dont l'origine est ce routeur
|
vrai > faux
|
4
|
AS_PATH
|
Preference du chemin avec les moins d'AS traverses
|
le plus court
|
5
|
ORIGIN
|
Preference du chemin en fonction de la facon dont ils sont connus par le routeur d'origine
|
IGP > EGP > Incomplete
|
6
|
MULTI_EXIT_DISC
|
Preference en fonction de la metrique annoncee par l'AS d'origine
|
la plus faible
|
7
|
External
|
Preference des routes eBGP sur les routes iBGP
|
eBGP > iBGP
|
8
|
IGP Cost
|
Metrique dans l'IGP du chemin vers le NEXT_HOP
|
la plus faible
|
9
|
eBGP Peering
|
Prefere les routes les plus stables
|
la plus ancienne
|
10
|
Router ID
|
Departage en fonction de l'identifiant du routeur
|
la plus faible
|
Si l'option
BGP Multipath
est active, les routes semblables apres l'etape numero 8 sont acceptees.
Au debut 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'epoque), et toutes les routes BGP etaient redistribuees vers l'
IGP
. Il pouvait etre alors necessaire d'attendre que la route soit presente dans l'
IGP
avant qu'elle soit rendue utilisable dans BGP.
Ce type de configuration etant considere comme une mauvaise pratique a proscrire (notamment au vu de l'inflation du nombre de routes BGP sur Internet), cette contrainte de synchronisation a disparu en devenant obsolete
[
27
]
.
Dans iBGP, les routes ne sont pas transitives, c'est-a-dire qu'une route recue 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 etablir des connexions avec tous les autres (
full mesh
) ce qui peut poser des problemes d'echelle, le nombre de connexions augmentant selon le carre du nombre de routeurs presents 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 reduire le nombre de connexions necessaires au sein d'un AS. Un seul routeur (ou deux routeurs pour la redondance) etablit des sessions avec tous les autres routeurs de son groupe. Les autres routeurs (ses
clients
) n'ont besoin que de se connecter a lui.
- confederations
- est utilise dans les tres grands reseaux ou l'AS est subdivise en petits AS internes. Les confederations peuvent etre utilisees conjointement avec les
routes reflectors
. eBGP est utilise entre les confederations. Les confederations sont masquees quand le prefixe est annonce en dehors de l'AS principal.
Pour eviter les boucles possibles avec ces configurations, des attributs supplementaires sont utilises : Cluster_ID et Originator_ID.
Lorsqu'un reseau est ajoute a un AS, il doit etre annonce au maillage BGP : soit au
route reflector
lorsqu'il existe, soit a l'ensemble des routeurs BGP de l'AS. BGP ne se substitue cependant pas a un protocole de routage interne.
Le standard
RFC
1771
[
30
]
(
A Border Gateway Protocol 4 (BGP-4)
) prevoyait le codage des numeros d'AS sur 16 bits, c'est-a-dire 64510 AS publics possibles en tenant compte du fait que les numeros 64512 a 65534 sont reserves pour des usages prives (0 et 65535 sont interdits). En 2011, il restait environ 15000 AS libres et les projections
[
31
]
laissaient presager un epuisement complet des AS disponibles en septembre 2013.
La
RFC
6793
[
32
]
etend le codage des AS de 16 vers 32 bits (reprenant de 0 a 65535 la plage des AS 16 bits, et ses AS reserves), ce qui porte le nombre d'AS disponibles a plus de quatre milliards. Une plage supplementaire d'AS prives est egalement definie dans la
RFC
6996
[
33
]
(de 4200000000 a 4294967294, 4294967295 etant interdit par la
RFC
7300
[
34
]
).
Pour permettre la traversee des groupes de routeurs qui ne gerent pas ces nouveaux AS, le nouvel attribut OT AS4_PATH est employe.
L'assignation des AS sur 32 bits a debute en 2007, et depuis 2009, le RIPE NCC distribue des AS 32 bits a la demande.
BGP est principalement utilise entre les operateurs et fournisseurs d'acces a Internet pour l'echange de routes.
La plupart des utilisateurs finaux d'Internet n'ont qu'une seule connexion a un
fournisseur d'acces a Internet
. Dans ce cas, BGP est inutile car une route par defaut est suffisante. Cependant, une entreprise qui serait connectee de facon redondante a plusieurs FAI (
multi-homing
) pourrait obtenir un numero de systeme autonome propre et etablir des sessions BGP avec chacun des fournisseurs.
Outre Internet, des reseaux IP prives peuvent utiliser BGP, par exemple pour interconnecter des reseaux locaux utilisant
OSPF
.
BGP est repute etre un protocole de routage
lent
par rapport aux
IGP
qui convergent generalement en une fraction de seconde.
La vitesse de convergence de BGP est tributaire de plusieurs parametres :
- le
hold time
qui determine apres combien de temps une session inactive (sans UPDATE ni KEEPALIVE) est fermee. Il peut etre reduit a 3 secondes au minimum mais vaut 90 s par defaut. La session BGP est cependant close sans delai apres un changement d'etat de l'interface a laquelle l'adresse IP de la session est associee, ou si la connexion TCP est interrompue (RST, FIN).
- le nombre de prefixes qui devront chacun faire l'objet de messages UPDATE.
- les performances du CPU pour le traitement des messages UPDATE.
- le parametre Minimum Route Advertisement Interval (MRAI) qui definit l'intervalle de temps minimum entre deux annonces BGP pour le meme ensemble de prefixes et vers le meme voisin. La RFC propose un MRAI de 30 s pour eBGP et 5 s pour iBGP. Certains travaux ulterieurs indiquent qu'il existe un benefice a reduire ce delai
[
35
]
. Les routes devenues inaccessibles sont annoncees immediatement.
- l'utilisation de BGP Protocol Independent Convergence (PIC)
[
36
]
, qui permet un reroutage rapide et independant du nombre de prefixe a rerouter.
BGP est sensible a l'oscillation rapide des routes, les annonces des routes inaccessibles devant etre propagees a tous les voisins BGP, obligeant ceux-ci a recalculer leur table de routage. L'effet cumule de ces annonces peut causer une surcharge et nuire a la stabilite du routage sur un reseau tel qu'Internet. Une route oscillante peut etre causee par un lien ou une interface defectueuse (mauvaise configuration, panne) ou un routeur qui redemarre.
Une fonctionnalite nommee
damping
(ou parfois
dampening
,
RFC
2439
[
37
]
BGP Route Flap Damping
;
damping
signifie
amortissement
en anglais) vise a reduire les effets de l'oscillation de routes. A chaque oscillation d'une route, le
damping
va accroitre une penalite numerique associee a cette route. Cette penalite va decroitre exponentiellement avec le temps. Quand la penalite depasse un seuil predefini, la route sera marquee comme inaccessible et les mises a jour a son sujet ignorees, et ce jusqu'a ce qu'un seuil inferieur pour la penalite soit atteint.
Le document RIPE-229
[
38
]
definit des parametres recommandes pour le damping. Cependant, a la lumiere de l'experience avec cette configuration, la recommandation du groupe de travail
routage
du RIPE est arrivee a la conclusion que le damping n'etait plus recommande et que le document RIPE-229 devait etre considere comme
obsolete
[
39
]
.
La
RFC
1930
[
40
]
recommande qu'un prefixe ait toujours pour origine le meme AS, a l'exception de cas particuliers (routage
anycast
et certains cas de
multi-homing
avec AS prive). Dans les autres cas, on parle de
BGP Multiple AS Origin
(MOAS). Les MOAS sont souvent le resultat d'une erreur de configuration et peuvent creer des incidents de type
deni de service
.
Si un routeur annonce un prefixe pour lequel il n'assure pas reellement le transit, ce dernier peut devenir inaccessible depuis tout ou une partie d'Internet. L'effet sera encore plus prononce si les prefixes annonces sont
plus specifiques
(c'est-a-dire si le masque reseau est plus long) que les prefixes legitimes, car les routes plus specifiques sont toujours preferees.
Pour se premunir de ce probleme, les fournisseurs limitent les prefixes qu'ils acceptent de leurs voisins. Ces filtres sont alors mis a jour manuellement si le voisin vient a annoncer de nouvelles routes. Vu la complexite de la gestion de ces listes de filtrage, il est plus rare que les grands operateurs filtrent les prefixes entre eux. Certains outils permettent cependant de batir ces filtres automatiquement en fonction du contenu de bases de donnees de routage (comme celle du
RIPE
). D'autres approches sont S-BGP
[
41
]
et soBGP
[
42
]
. Les approches qui securisent l'AS d'origine d'un prefixe ne premunissent cependant pas contre les attaques malveillantes, dans la mesure ou l'AS Path peut alors avoir ete construit.
Le groupe de travail
Secure Inter-Domain Routing
(SIDR) de l'IETF
[
43
]
travaille sur un systeme de validation de la source d'un prefixe appele
Resource Public Key Infrastructure
(en)
(RPKI)
[
44
]
.
Le
, l'AS 7007 a redistribue accidentellement BGP dans RIP et reciproquement. RIP etant un protocole
classful
, ceci a cause l'apparition de sous-reseaux de taille /24, plus specifiques que les routes originales, ce qui a provoque des instabilites importantes sur Internet
[
45
]
,
[
46
]
. Cet incident a attire l'attention sur ce type de vulnerabilite.
En fevrier 2008, le site
YouTube
a ete inaccessible pendant environ deux heures.
Le
gouvernement pakistanais
avait annonce ce jour-la un blocage de YouTube au Pakistan
[
47
]
,
[
48
]
,
[
49
]
, ordre qui a ete execute par l'operateur
Pakistan Telecom
.
Pakistan Telecom a alors annonce a tous les routeurs des
fournisseurs d'acces
qu'il etait la meilleure route a qui envoyer tout le trafic YouTube, qui a alors ete coupe sur l'ensemble de la planete.
Ce type d'incident est designe sous les noms d'
IP
hijacking
(detournement d'adresse IP) ou de
black hole
(
trou noir
).
Un des problemes auquel BGP doit faire face sur Internet est la croissance de la
table de routage
des routeurs de la
default-free zone
, c'est-a-dire ceux qui disposent d'une table de routage complete et n'utilisent pas de
route par defaut
. Avec le temps, les routeurs plus anciens n'ont plus les ressources memoire ou CPU necessaires au maintien d'une table complete. D'autre part, la taille de la table nuit a la vitesse de convergence, le CPU etant particulierement sollicite lors de changements importants (etablissement de nouvelles connexions ou changements importants de topologie).
Jusqu'a 2001, la croissance a ete exponentielle, menacant le fonctionnement d'Internet. A cette date, des efforts ont ete entrepris pour reduire les prefixes en les agregeant. Ceci a permis une croissance lineaire pendant plusieurs annees. Cependant la croissance exponentielle a repris a partir de 2004 environ sous la pression du nombre croissant de reseaux finaux qui disposent de plusieurs connexions redondantes.
En 2013, le nombre de prefixes diffuses sur Internet est d'environ 400 000
[
50
]
.
BGP ne dispose pas d'un systeme d'equilibrage de la charge entre plusieurs liens et ne tient pas compte de la congestion eventuelle des liens : si un AS est connecte a plusieurs fournisseurs de transit vers Internet, il se peut que certains soient congestionnes tandis que d'autres sont peu utilises. De facon generale, les AS prennent des decisions de routage de facon independante, un AS a donc peu d'influence sur les decisions prises par un autre AS et ne dispose pas de controle fin de l'equilibrage du trafic entrant.
Diverses techniques existent cependant pour tenter de reequilibrer la charge entre ces liens :
- l'annonce de prefixes plus specifiques differents ;
- l'allongement artificiel des longueurs de chemin ;
- l'utilisation de communautes ;
- l'utilisation de MED.
Pour les memes raisons, le trafic peut etre asymetrique, ce qui est frequent entre les grands operateurs qui suivent la politique dite de la
patate chaude
(en)
, qui consiste a router un paquet destine a un reseau externe vers l'interconnexion la plus proche, evitant ainsi la traversee de sa propre dorsale.
Le 19 aout 2009, un fournisseur d'acces japonais (AS 9354) annonca une route avec un attribut AS_PATH vide. Certaines implementations de BGP de routeurs de fournisseur d'acces interrompent la session BGP avec une erreur quand ils recoivent celui-ci, ce qui cause des perturbations dans plusieurs dorsales de FAI
[
51
]
.
Le 27 aout 2010, un attribut BGP experimental utilise dans un projet de recherche entre le
RIPE NCC
et l'
universite Duke
a ete propage sur Internet et revele un bug dans l'implementation BGP de certains constructeurs. Ceci a provoque l'instabilite de plusieurs milliers de prefixes sur Internet
[
52
]
,
[
53
]
.
L'operateur Telekom Malaysia annonce un tres grand nombre de nouvelles routes erronees, reprises par
Level 3 Communications
, un important operateur 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 pres 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 entraine un tres net ralentissement et des perturbations dans les communications, ressentis a l'echelle mondiale pendant une partie de la journee
[
54
]
,
[
55
]
.
Lors d'une mise a jour de routine de la configuration des routeurs gerant le trafic entre les centres de donnees de
Facebook
, un grand nombre de messages BGP de suppression de route ont ete envoyes, creant une reaction en chaine qui a abouti a une deconnexion de l'internet des AS de Facebook. Il a fallu plus de 5 heures a Facebook pour resoudre le probleme
[
56
]
.
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
[
57
]
:
> 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 prefixe le plus specifique 91.198.174.0/24. Deux routes sont disponibles, la premiere a traverse deux AS (43821, son AS d'origine, puis 3292) et la seconde trois (43821, 16150 et 12552), le
Local Pref
etant egal, la premiere route, plus courte pour ce qui est du nombre d'AS traverses, est preferee.
La route dispose de deux attributs
community
: 3292:1104 et 3292:1906.
Les noms associes aux AS sont ajoutes par l'interface en consultant une base de donnees de routage publique.
- BIRD
, suite de protocoles de routage pour les systemes derives d'Unix, sous licence GPL.
- FRRouting
(en)
, fork de Quagga. Ses predecesseurs (developpements abandonnes) sont:
- Quagga
[
58
]
, fork de GNU Zebra pour les systemes derives d'Unix.
- GNU Zebra
, suite de protocoles de routage supportant, entre autres, BGP.
- GoBGP
[
59
]
, implementation BGP sous licence Apache 2.0, ecrite en
Go
.
Les principales
RFC
concernees sont les suivantes :
- (en)
RFC
4271
[
2
]
,
A Border Gateway Protocol 4 (BGP-4)
. Janvier 2006. Remplace la
RFC
1771
[
30
]
.
- (en)
RFC
4274
[
60
]
,
BGP-4 Protocol Analysis
. Janvier 2006.
- (en)
RFC
4277
[
61
]
,
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
[
62
]
.
- ↑
Donna
L. Harrington
,
CCNP Practical Studies: Troubleshooting
, Cisco Press,
(
lire en ligne
)
- ↑
a
et
b
(en)
Request for comments
n
o
4271
- ↑
(en)
P.
Traina
, ≪
BGP-4 Protocol Analysis
≫, sur
tools.ietf.org
(consulte le
)
- ↑
(en)
Request for comments
n
o
2545
- ↑
(en)
Request for comments
n
o
2858
- ↑
(en)
≪
RFC4364
≫, sur
tools.ietf.org
(consulte le
)
- ↑
(en)
≪
RFC4364
≫, sur
tools.ietf.org
(consulte le
)
- ↑
(en)
≪
RFC4364
≫, sur
tools.ietf.org
(consulte le
)
- ↑
(en)
Yuan,
Jenny
et Chen,
Enke
, ≪
AS-wide Unique BGP Identifier for BGP-4
≫, sur
tools.ietf.org
(consulte le
)
- ↑
(en)
Hares,
Susan
et Rekhter,
Yakov
, ≪
A Border Gateway Protocol 4 (BGP-4)
≫, sur
tools.ietf.org
(consulte le
)
- ↑
Greene, Barry
Raveendran.
,
Cisco ISP essentials
, Cisco Press,
(
ISBN
1-58705-041-2
,
OCLC
52355438
,
lire en ligne
)
- ↑
(en)
≪
BGP router-id do you need a interface ip_address
≫, sur
socpuppet.blogspot.fr
(consulte le
)
- ↑
(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
(consulte le
)
- ↑
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
)
- ↑
≪
IBGP> BGP Fundamentals
≫, sur
www.ciscopress.com
(consulte le
)
- ↑
(en)
Philip Smith, ≪
BGP Best Practices
≫, sur
RIPE
,
- ↑
Osterloh,
Heather.
,
IP routing primer plus
, Sams,
(
ISBN
0-672-32210-2
,
OCLC
48361925
,
lire en ligne
)
- ↑
Cisco utilise cependant un Keep Alive de 60 s et un Hold Time de 180 s par defaut
- ↑
(en)
Request for comments
n
o
2918
- ↑
How BGP Routers Use the Multi-Exit Discriminator for Best Path Selection
, cisco.com technote
- ↑
(en)
Request for comments
n
o
4360
- ↑
Border Gateway Protocol (BGP) Extended Communities
, IANA
- ↑
(en)
Request for comments
n
o
7153
- ↑
(en)
Request for comments
n
o
8092
- ↑
(en)
Request for comments
n
o
8195
- ↑
Cisco uniquement
- ↑
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
)
- ↑
a
et
b
(en)
Request for comments
n
o
4456
- ↑
(en)
Request for comments
n
o
5065
- ↑
a
et
b
(en)
Request for comments
n
o
1771
- ↑
16-bit Autonomus System Report
, Geoff Huston 2011
- ↑
(en)
Request for comments
n
o
6793
- ↑
(en)
Request for comments
n
o
6996
- ↑
(en)
Request for comments
n
o
7300
- ↑
Revised Default Values for the BGP Minimum Route Advertisement Interval
, Internet Draft, novembre 2008
- ↑
BGP PIC
, Clarence Filsfils, NANOG 40
- ↑
(en)
Request for comments
n
o
2439
- ↑
RIPE-229
RIPE Routing-WG Recommendations for Coordinated Route-flap Damping Parameters
, octobre 2001
- ↑
RIPE 378
RIPE Routing Working Group Recommendations On Route-flap Damping
, mai 2006
- ↑
(en)
Request for comments
n
o
1930
- ↑
Securing the Border Gateway Protocol
The Internet Protocol Journal - Volume 6, Number 3
- ↑
Securing BGP Through Secure Origin BGP
id
- ↑
SIDR charter
- ↑
RPKI-Based Origin Validation Operation
, Internet Draft, mars 2011
- ↑
(en)
7007 Explanation and Apology
.
- ↑
(en)
Internet routing black hole
.
- ↑
Crashdump.fr, ≪
Protocole BGP, l’Internet en danger ?
≫,
- ↑
≪
Pakistan lifts the ban on YouTube
≫, BBC News,
- ↑
≪
YouTube Hijacking: A RIPE NCC RIS case study
≫,
RIPE NCC
- ↑
BGP Routing Table Analysis Reports
- ↑
NANOG
- ↑
Research experiment disrupts Internet, for some
- ↑
RIPE NCC and Duke University BGP Experiment
, Erik Romijn
- ↑
Martin Untersinger,
Pourquoi Internet etait un peu lent vendredi matin
,
Le Monde
,
.
- ↑
Massive route leak cause Internet slowdown
, BGPMON,
.
- ↑
Michell Clark,
[1]
,
The Verge
,
.
- ↑
http://lg.intron.net/
- ↑
(en)
≪
Is Quagga dead? · Issue #381 · serratus/quaggaJS
≫, sur
GitHub
(consulte le
)
- ↑
≪
GoBGP
≫
- ↑
(en)
Request for comments
n
o
4274
- ↑
(en)
Request for comments
n
o
4277
- ↑
(en)
Request for comments
n
o
2796