Protocole de routage BGP-IV

par Christian JACQUENET

Ingénieur de l’École Nationale Supérieure de Physique de Marseille (ENSPM)

1. Quelques rappels élémentaires ............................................................ IP 2 900 - 3

1.1 Des réseaux IP en général et des routeurs en particulier......................... — 3
1.2 De l’utilité des protocoles de routage dynamique dans les réseaux IP .. — 3
1.3 De l’inadéquation des IGP aux besoins de communication
entre systèmes autonomes......................................................................... — 4
2. Protocole BGP-IV...................................................................................... — 4
2.1 Généralités ................................................................................................... — 4
2.2 Formalisme du protocole BGP-IV ............................................................... — 5
3. Ingénierie de réseaux BGP-IV ............................................................... — 10
3.1 Typologie des systèmes autonomes.......................................................... — 10
3.2 Volumétrie du trafic BGP............................................................................. — 10
3.3 Politiques de routage BGP .......................................................................... — 11
3.4 Contraintes d’échelle ................................................................................... — 11
3.5 Politiques de redistribution......................................................................... — 14
4. Évolutions du protocole BGP-IV........................................................... — 15
4.1 Attribut COMMUNITIES (code 8)................................................................ — 15
4.2 Extensions multiprotocoles ........................................................................ — 15
4.3 Services de sécurité..................................................................................... — 16
5. Conclusion ................................................................................................. — 17
Pour en savoir plus ........................................................................................... Doc. IP 2 900

e déploiement massif du réseau Internet au cours des trois dernières décen-

L nies a été principalement caractérisé par un accroissement quasi exponen-
tiel de réseaux (IP) (Internet Protocol) placés sous la responsabilité d’entités
administratives dûment identifiées auprès de l’instance de régulation chargée
en particulier de répondre aux demandes d’attribution d’adresses IP [RFC-791]
[1].
L’acheminement du trafic IP tant au sein de ces réseaux qu’entre eux fait appel
à l’activation de protocoles de routage dynamique chargés de déterminer le
meilleur chemin possible pour atteindre une destination donnée, moyennant
l’activation d’algorithmes de calcul de routes plus ou moins complexes.

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux IP 2 900 − 1
PROTOCOLE DE ROUTAGE BGP-IV
Sigle
AFI (Address Family Identifier)
AS (Autonomous System)
ATM (Asynchronous Transfer
Mode)
BGP-IV (Border Gateway Protocol) Protocole de routage dynamique interdomaine (un domaine étant un ensemble de routeurs formant une
version 4
CIDR (Classless Inter-Domain
Routing)
EGP (Exterior Gateway Protocol)
FIB (Forwarding Information Base) Table d’acheminement d’un routeur utilisée pour identifier le next hop et, partant, l’interface de sortie vers
FSM (Finite State Machine)
HDLC (High level Data Link
Control)
IDR (Inter-Domain Routing)
IDRP (Inter-Domain Routing
Protocol)
IETF (Internet Engineering Task
Force)
IGP (Interior Gateway Protocol)
IP (Internet Protocol)
IRR (Internet Routing Registry)
ISO (International Standards
Organization)
LAN (Local Area Network)
MD5 (Message Digest, version 5)
MIB (Management Information
Base)
NAP (Network Access Point)
NLRI (Network Layer Reachability
Information)
OSI (Open Systems
Interconnection)
OSPF (Open Shortest Path First)
PDU (Protocol Data Unit)
RFC (Request For Comments)
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 900 − 2
_________________________________________________________________________________________________________
Désignation
Indication véhiculée dans certains attributs du protocole BGP-IV, pour indiquer l’identité du protocole de
communication auquel se référe l’annonce caractéristique du message de type UPDATE correspondant.
Un système autonome est une communauté de routeurs placée sous la responsabilité d’exploitation d’une
entité administrative dûment identifiée.
Mode de transmission d’informations qui s’appuie en particulier sur la commutation d’unités de longueur
fixe, appelées « cellules ».
communauté gérée par une entité administrative unique. Le domaine correspond à la notion de « système
autonome »).
Technique d’agrégation d’adresses qui permet d’optimiser la volumétrie du trafic de service lié à
l’échange d’informations de routage entre routeurs appartenant à des systèmes autonomes distincts, et
qui rend caduque la notion de classes d’adresses, telle que définie dans la spécification du protocole IPv4
[RFC-791].
Sigle générique qui s’applique à tout protocole de routage dynamique susceptible d’être activé entre deux
systèmes autonomes (AS).
laquelle un datagramme IP doit être commuté afin qu’il puisse être transmis selon l’information consignée
dans le champ «adresse destination» de son en-tête. La FIB est alimentée par des informations mainte-
nues dans la ou les table(s) de routage du routeur. Certaine littérature parle abusivement de « table de
routage » pour désigner ce qui est en réalité une table d’acheminement.
Machine d’états finis qui décrit un processus de fonctionnement applicable en particulier à un protocole.
L’un des modes de tramage utilisé par la couche liaison du modèle OSI.
Nom de l’un des groupes de travail de l’IETF, mandaté pour la production de spécifications relatives au
routage inter-domaines. C’est au sein de ce groupe de travail que les spécifications relatives au protocole
BGP évoluent.
Protocole de type EGP spécifié par l’organisme de normalisation ISO.
Organisme international impliqué dans la standardisation des protocoles, fonctions et services suscep-
tibles d’être mis en œuvre par un réseau, un service ou une application qui s’appuie sur la suite de proto-
coles TCP/IP.
Sigle générique qui s’applique à tout protocole de routage dynamique susceptible d’être activé à l’inté-
rieur d’un domaine, ou système autonome (AS).
Serveur de routes consulté par certains des routeurs BGP mis en place au sein du réseau Internet, afin
qu’ils puissent alimenter leurs tables de routage. Les informations consignées dans un IRR sont (parfois)
formalisées selon la syntaxe du langage RPSL.
Organisme de standardisation international, impliqué notamment dans la production de normes de télé-
communications.
Sigle générique utilisé pour désigner un réseau local, quelle que puisse être la méthode utilisée pour
accéder au support de ce réseau local. A titre d’exemple, la technologie Ethernet est l’une des technologies
de LAN les plus repandues.
Algorithme qui permet de mettre en œuvre un processus de signature numérique utilisé dans le contexte
de la sécurisation d’une communication.
Base de données d’informations relatives à la gestion d’un équipement, d’un réseau, d’un service.
Lieu d’échange d’informations de routage, moyennant l’hébergement de routeurs appartenant à différents
fournisseurs de services (d’accès au réseau Internet) qui ont conclu des accords (d’échange de routes)
bilatéraux (sinon multilatéraux), et, généralement, l’utilisation d’une technique de communication (de
niveau liaison, par référence au modèle OSI), choisie pour ses hautes performances (en termes de paquets
commutés par seconde, par exemple).
Information (éventuellement) consignée dans les messages de type UPDATE tels que véhiculés par le pro-
tocole BGP-IV, et renseignant l’identité d’une destination, exprimée sous la forme d’une adresse (IP).
Modèle en 7 couches défini par l’organisme de standardisation international ISO.
Protocole de routage dynamique de type IGP et de la famille «link state».
Unité de données de transmission définie dans la spécification du protocole IP [RFC-791].
Document de spécification produit par la communauté IETF. Un RFC peut constituer un standard.
© Techniques de l’Ingénieur, traité Réseaux
_________________________________________________________________________________________________________ PROTOCOLE DE ROUTAGE BGP-IV

Sigle (suite) Désignation (suite)

RIB (Routing Information Base) Table de routage maintenue par un routeur, et alimentée par des informations recueillies grâce à l’activa-
tion d’un protocole de routage dynamique.
RIP (Routing Information Protocol) Protocole de routage dynamique de type IGP, qui s’appuie sur le calcul probabiliste de Bellman-Ford,
moyennant l’utilisation d’une métrique particulière : le nombre de sauts (hop count).
RPSL (Routing Policy Specification Langage utilisé pour décrire les caractéristiques d’une politique de routage et, partant, consigner les infor-
Language) mations de routage maintenues par un équipement de type IRR.
SHA (Secure Hashing Algorithm) Algorithme qui permet de mettre en œuvre un processus de signature numérique utilisé dans le contexte
de la sécurisation d’une communication.
SNPA (Sub-Network Point Information utilisée par un routeur BGP-IV (et véhiculée dans l’attribut MP_REACH_NLRI) pour rendre
of Attachment) compte de l’identité du point d’attachement du routeur à une connexion donnée.
TCP (Transmission Control Protocole permettant de rendre un service orienté connexion.
Protocol)
TLV (Type, Longueur, Valeur) Processus de codage d’une information.

1. Quelques rappels 1.2 De l’utilité des protocoles de routage

élémentaires
1.1 Des réseaux IP en général
et des routeurs en particulier
Les réseaux IP (et, en particulier, les routeurs qui les composent)
qui sont placés sous la responsabilité d’exploitation d’une entité
administrative globalement unique au sein de la communauté Inter-
net (c’est-à-dire que la notion « d’unicité globale » suppose que
l’entité administrative est dûment identifiable d’une manière univo-
que au sein de la communauté Internet), constituent un système
autonome AS (Autonomous System) (figure 1) ou domaine. D’un
point de vue topologique, un système autonome est constitué d’un
ensemble de routeurs et l’on distingue l’intérieur du système auto-
nome de son extérieur. L’extérieur d’un système autonome est
l’ensemble des autres systèmes autonomes avec lesquels il est sus-
ceptible d’échanger du trafic IP.
Système autonome (AS)
Routeur
Figure 1 – Réseau Internet organisé en systèmes autonomes
(figuration symbolique)
dynamique dans les réseaux IP
Le déploiement de réseaux IP de grande taille (tels que ceux qui
constituent aujourd’hui le réseau Internet) a rapidement nécessité la
mise au point de protocoles de routage dynamique chargés de
déterminer avec la meilleure efficacité possible (efficacité qu’il est
possible de qualifier en termes de temps de convergence, c’est-à-
dire le temps au bout duquel l’activation de l’algorithme de calcul de
route a abouti à un résultat – celui de la détermination d’une route
pour atteindre une destination donnée, cette destination étant
décrite par une adresse réseau) la meilleure route pour atteindre
une destination donnée.
Cette qualification de « meilleure » route peut varier d’un proto-
cole de routage dynamique à l’autre et en fonction de la nature et du
nombre de paramètres pris en compte par l’algorithme de calcul de
route caractéristique d’un protocole de routage dynamique donné.
De plus, l’administrateur d’un réseau IP peut aussi influer sur le pro-
cessus de qualification d’un ensemble de routes qui permettraient
d’atteindre une destination donnée.
Par ailleurs, le choix de mettre en œuvre un processus de routage
statique se révèle rapidement incompatible avec le nombre de
réseaux IP qui constituent aujourd’hui le réseau Internet, parce que
le renseignement statique des tables d’acheminement susceptibles
de consigner et de maintenir plusieurs dizaines de milliers d’entrées
est, de toute évidence, une tâche fastidieuse de nature à pénaliser
l’efficacité d’acheminement du trafic dans un réseau IP.
Les protocoles de routage dynamique permettent donc aux rou-
teurs organisés selon plusieurs systèmes autonomes d’échanger
des informations d’accessibilité à des réseaux IP. Ces informations
sont stockées dans les tables de routage des routeurs, rafraîchies
d’une manière dynamique et ces informations alimentent les tables
d’acheminement des routeurs.
L’organisation du réseau Internet en systèmes autonomes a
donné lieu à une classification des protocoles de routage dynami-
que en deux grandes familles :
— les protocoles de routage dynamique qui permettent d’échan-
ger des informations d’accessibilité à des réseaux IP au sein d’un
système autonome : ce sont les IGP (Interior Gateway Protocol) ;
— les protocoles de routage dynamique qui permettent d’échan-
ger des informations d’accessibilité à des réseaux IP entre systèmes
autonomes : ce sont les EGP (Exterior Gateway Protocol).

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux IP 2 900 − 3
PROTOCOLE DE ROUTAGE BGP-IV _________________________________________________________________________________________________________
1.3 De l’inadéquation des IGP aux besoins
de communication entre systèmes
autonomes
La découpe du réseau Internet en systèmes autonomes ne justifie
pas, a priori, la classification IGP/EGP telle qu’elle a été présentée
dans le paragraphe 1.2, puisque l’échange des informations d’acces-
sibilité à des réseaux IP entre systèmes autonomes repose sur l’acti-
vation d’un protocole de routage dynamique (un processus de
routage statique est généralement exclu pour les raisons dévelop-
pées dans le paragraphe 1.1), ce qui constitue une condition suffi-
sante.
Des lors, pourquoi ne pas mettre en œuvre un protocole de type
IGP, que celui-ci utilise les ressources d’un algorithme de calcul de
distance vectorielle, ou celles d’un algorithme de calcul de coût de
liens (à des réseaux adjacents) ? La réponse à cette question est
développée dans les lignes suivantes.
■ Un routeur qui met en œuvre un protocole de routage dynamique
de type « distance vector » annonce à ses voisins l’ensemble des
réseaux qu’il peut atteindre sous la forme d’une liste vectorielle,
laquelle consigne en particulier la valeur du chemin associé à cha-
que réseau dont le routeur a la connaissance. Chaque routeur du
réseau construit sa table de routage sur la foi des informations
consignées dans les listes vectorielles échangées, mais ces informa-
tions ne donnent aucune indication quant à l’identité des routeurs et
des réseaux qui jalonnent un chemin qui permet d’atteindre un
réseau donné, ce qui peut poser quelques difficultés lorsqu’il s’agit
d’échanger des informations d’accessibilité entre systèmes auto-
nomes :
— le protocole de routage dynamique de type « distance vector »
suppose que tous les routeurs qui l’activent ont une compréhension
commune de la métrique qui leur permet de sélectionner tel routeur
plutôt que tel autre, ce qui n’est pas forcément le cas d’un système
autonome à l’autre ;
— la politique d’acheminement du trafic au sein d’un système
autonome peut être définie de telle sorte que la communication
avec certains systèmes autonomes soit interdite pour échanger des
informations d’accessibilité de certains réseaux, alors que les infor-
mations véhiculées par les annonces échangées entre les routeurs
qui activent un protocole de routage dynamique de type « distance
vector » ne permettent pas de renseigner et, a fortiori, d’appliquer
ce genre de politique.
■ Un routeur qui met en œuvre un protocole de routage dynamique
de type « link state » annonce quant à lui des informations compo-
sées de coûts affectés aux liens qui le raccordent à autant de
réseaux adjacents à tous les autres routeurs avec lesquels il est sus-
ceptible de communiquer, de sorte que chacun de ces routeurs bâtit
une image de la topologie complète du réseau dont il acquiert ainsi
la connaissance (en termes de configuration, notamment), pour
ensuite procéder à la détermination des routes qui permettent
d’accéder à un ensemble de réseaux. Ce mode de diffusion des
informations d’accessibilité de réseaux pose là encore des difficul-
tés lorsqu’il s’agit de faire communiquer des routeurs de différents
systèmes autonomes entre eux :
— les systèmes autonomes n’ont pas nécessairement une com-
préhension identique des métriques utilisées, ce qui peut avoir des
conséquences sur la cohérence des informations consignées dans
les tables de routage de routeurs appartenant à des systèmes auto-
nomes différents ;
— le mode de diffusion d’un protocole de type « link state » peut
rapidement se révéler incompatible avec des réseaux de grande
taille, compte tenu de la volumétrie du trafic associé à la diffusion de
ces informations d’accessibilité, volumétrie qui serait de nature à
pénaliser l’acheminement du trafic utile au sein des réseaux
déployés sur les différents systèmes autonomes susceptibles de
communiquer entre eux.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 900 − 4 © Techniques de l’Ingénieur, traité Réseaux
La principale motivation qui a conduit à la spécification, à la stan-
dardisation et au développement de protocoles de type EGP est la
suivante : puisque les métriques (et leur valorisation) des protocoles
de routage dynamique de type IGP peuvent être comprises diffé-
remment par des routeurs appartenant à des systèmes autonomes
distincts, les informations d’accessibilité de réseaux échangées
entre systèmes autonomes devraient s’affranchir de l’utilisation de
métriques.
Ainsi, un routeur d’un système autonome A se contenterait
d’annoncer à un ou plusieurs routeurs appartenant aux systèmes
autonomes B, C, etc., l’ensemble des réseaux qu’il sait atteindre,
ainsi que les systèmes autonomes qu’il est nécessaire de traverser
pour atteindre ces réseaux. Ce concept quasi élémentaire est celui
qui est mis en pratique par les protocoles de routage dynamique de
type EGP, et il est appelé routage de type « chemin vectoriel » (path
vector routing) [RFC-1771] [STALLINGS98].
Un protocole de type EGP présente donc les caractéristiques
suivantes :
— les informations échangées entre routeurs de systèmes auto-
nomes différents ne contiennent aucun renseignement relatif à l’uti-
lisation d’une métrique ou à la valorisation d’un coût particulier ;
— les informations échangées entre routeurs de systèmes auto-
nomes différents sont des informations qui décrivent un ensemble
de routes qui permettent d’atteindre un ensemble de réseaux, en
termes de systèmes autonomes traversés par chaque route pour
atteindre une destination donnée.
Cette seconde caractéristique permet à un routeur de mettre en
œuvre une politique de routage définie par l’administrateur d’un
système autonome (et des routeurs qui le composent), de telle sorte
que ce routeur puisse par exemple décider d’éviter d’emprunter
telle route parce qu’elle traverse des systèmes autonomes dont le
degré de fiabilité – la fiabilité d’un système autonome est une notion
évidemment arbitraire (et donc largement discutable), mais elle
peut toutefois être caractérisée de différentes façons, telles que le
taux de perte de datagrammes observé sur les liens qui permettent
d’accéder au système autonome incriminé, ou encore les temps de
transit comparés pour atteindre une destination donnée – (tel qu’il
pourrait être perçu par un administrateur), est incompatible avec le
caractère sensible du trafic susceptible d’emprunter cette route.
L’acheminement du trafic IP sur le réseau Internet suppose donc la
traversée de plusieurs systèmes autonomes et partant, l’activation
d’un protocole de routage dynamique de type EGP entre les rou-
teurs qui composent ces différents systèmes autonomes. Le proto-
cole BGP-IV [RFC-1771] est aujourd’hui le protocole de routage inter-
AS déployé au sein du réseau Internet. Le protocole BGP est né de
l’expérience acquise au cours des premières phases de développe-
ment du réseau Internet au travers du déploiement du réseau
NSFNET (National Science Foundation NETwork), grâce à la spécifi-
cation et à l’implantation du protocole EGP [RFC-904] [RFC-1092]
[RFC-1093].
La version 4 du protocole BGP est aujourd’hui la version déployée
au sein du réseau Internet. Les paragraphes suivants proposent de
décrire le principe de fonctionnement de ce protocole, son forma-
lisme, son processus de décision, ainsi que les quelques règles
d’ingénierie élémentaires qui régissent l’interconnexion de systè-
mes autonomes.
2. Protocole BGP-IV
2.1 Généralités
La fonction principale d’un routeur qui active le protocole BGP
consiste à échanger des informations d’accessibilité de réseaux IP
_________________________________________________________________________________________________________ PROTOCOLE DE ROUTAGE BGP-IV
avec d’autres routeurs qui activent le protocole BGP. Ces informa-
tions incluent la liste des AS qu’elles ont traversés et suffisent donc
à construire un graphe représentatif de la connectivité des systèmes
autonomes, graphe à partir duquel il sera possible d’éviter des phé-
nomènes de boucles (qui conduisent à la formation de « trous
noirs » capables de rendre un réseau IP totalement inopérant) et
grâce auquel il sera possible de mettre en œuvre des politiques de
routage définies par l’administrateur d’un système autonome.
Nota : dans toute la suite de ce document, les sigles BGP et BGP-IV seront indifférem-
ment employés pour désigner le protocole BGP-IV.
Le protocole BGP s’appuie sur la couche TCP (Transmission Con-
trol Protocol) [RFC-793], port 179), ce qui permet de s’affranchir de la
nécessité de supporter explicitement (i.e. par le protocole BGP lui-
même) les fonctions de fragmentation, de retransmission, d’acquit-
tement et de séquencement qui sont des fonctions naturellement
supportées par le protocole TCP.
Le mode de fonctionnement du protocole BGP entre deux routeurs
qui l’activent peut être succinctement décrit selon la chronologie
suivante :
— les routeurs BGP établissent une connexion TCP entre eux, en
échangeant des messages destinés à ouvrir cette connexion puis à
confirmer les paramètres caractéristiques de la connexion ;
— une fois la connexion établie, le premier échange d’informa-
tions est constitué de l’intégralité du contenu de la table BGP ;
— des informations sont ensuite échangées d’une manière dyna-
mique sous forme d’annonces spécifiques à mesure que le contenu
de l’une ou l’autre des tables BGP de l’un ou l’autre des routeurs a
changé. Dans la mesure où le protocole n’impose pas un rafraîchis-
sement périodique de l’intégralité du contenu de la table de routage
BGP, chaque routeur doit conserver la version courante de l’intégra-
lité du contenu de l’ensemble des tables de routage maintenues par
les routeurs BGP avec lesquels il a établi une connexion.
Des messages spécifiques sont envoyés d’une manière périodi-
que de façon à maintenir la connexion active, tandis que des notifi-
cations sont envoyées en réponse à des erreurs de transmission ou,
d’une manière générale, sous certaines conditions. La réception
d’une notification entraîne la rupture de la connexion entre les deux
routeurs BGP incriminés, mais la brutalité de cette rupture est en
principe modulée par la souplesse fonctionnelle du protocole TCP
qui se charge normalement d’assurer la transmission effective des
données en cours d’échange avant de procéder effectivement à la
rupture de la connexion.
Si le protocole BGP-IV est un protocole de type EGP, il n’en reste
pas moins vrai que des routeurs appartenant au même système auto-
nome ont la capacité d’établir des connexions BGP entre eux, ce qui
conduit à la typologie suivante :
— les connexions établies entre des routeurs BGP appartenant à
des AS distincts sont qualifiées « d’externes » (external links). De
telles connexions sont de type « eBGP » (external BGP) ;
— les connexions établies entre des routeurs BGP appartenant au
même AS sont qualifiées « d’internes » (internal links). De telles
connexions sont de type « iBGP » (internal BGP).
Les connexions de type iBGP sont justifiées par la volonté de main-
tenir une vue cohérente de l’ensemble des routes externes au sys-
tème autonome par l’ensemble des routeurs qui composent le
système autonome. De la même façon, un protocole de routage
dynamique de type IGP permet de maintenir une vue cohérente de
l’ensemble des routes internes au système autonome.
Une route, c’est-à-dire l’information globalement véhiculée dans
le contexte d’une connexion BGP, est constituée de l’association
d’une destination (adresse IP) et des caractéristiques (ou attributs)
du chemin qui mène à cette destination. À la réception de cette infor-
mation, le routeur va stocker celle-ci dans la table de routage BGP
qui est en fait constituée de trois tables de routage distinctes :
— la table de routage Adj-RIB-In, qui consigne l’intégralité des
routes annoncées au routeur BGP par les routeurs avec lesquels une
connexion BGP a été établie. Cette table contient donc l’information
qui sera manipulée par le processus de décision BGP ;
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
— la table de routage Adj-RIB-Out, qui consigne l’intégralité des
routes qui seront annoncées par le routeur BGP. Ce sont les routes
qui ont été sélectionnées par le processus de décision évoqué
précédemment ;
— la table de routage Loc-RIB, qui consigne l’intégralité des rou-
tes qui seront utilisées par le routeur BGP et, parmi ces routes, figu-
rent celles qui seront ensuite stockées dans la table de routage Adj-
RIB-Out.
La distinction qui est faite entre ces trois tables de routage se jus-
tifie surtout d’un point de vue conceptuel, puisque la pratique des
implantations du protocole BGP-IV montre que la plupart des solu-
tions constructeurs ont choisi de n’implanter qu’une seule table de
routage, mais pourvue d’autant de pointeurs que nécessaire,
conformément à la spécification du protocole.
2.2 Formalisme du protocole BGP-IV
2.2.1 Définition d’une connexion BGP-IV
Si deux routeurs tentent d’établir d’une manière exactement
simultanée une connexion TCP vers l’autre, il y a un phénomène de
« collision de connexions ». En vertu du principe d’unicité d’une
connexion BGP entre deux routeurs, une convention est définie
pour déterminer quelle est la connexion qui doit être préservée.
Cette convention s’appuie sur la notion « d’identifiant BGP » (cf.
§ 2.2.2.2), et le principe d’unicité est respecté en comparant les iden-
tifiants BGP respectifs des deux routeurs : c’est la connexion initiali-
sée par le routeur dont l’identifiant BGP est le plus élevé qui sera
maintenue. Dans la pratique, l’identifiant BGP correspond à la
valeur numériquement « la plus élevée » (l’adresse 10.0.0.1/24 est
par exemple « plus élevée » que l’adresse 1.0.0.1/8) des adresses IP
affectées au routeur.
2.2.2 Différents types de messages BGP-IV
2.2.2.1 En-tête du message BGP-IV
Chaque message BGP-IV échangé entre deux routeurs est pourvu
d’un en-tête représenté sur la figure 2 :
— la taille minimale d’un message BGP-IV est de 19 octets (soit la
longueur de l’en-tête seul), et sa taille maximale est de 4096 octets ;
— le champ « marqueur » peut être utilisé pour détecter une
perte de synchronisation entre deux routeurs BGP, mais aussi pour
authentifier les messages BGP reçus par un routeur ;
— le champ « longueur » indique la longueur totale du message
(exprimée en octets), et cette valeur inclut l’en-tête du message ;
— le champ « type » indique le type de message BGP-IV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Marqueur
Longueur Type
Figure 2 – Format de l’en-tête d’un message BGP-IV
IP 2 900 − 5
PROTOCOLE DE ROUTAGE BGP-IV _________________________________________________________________________________________________________
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Version
Mon système autonome
Hold Time
Identifiant BGP
Opt Parm Len
Paramètres optionnels
Figure 3 – Message de type OPEN
Il existe quatre types de messages BGP-IV : OPEN (type 1),
UPDATE (type 2), NOTIFICATION (type 3) et KEEPALIVE (type 4).
2.2.2.2 Message de type OPEN
Lorsque la connexion TCP est établie entre deux routeurs, le pre-
mier message échangé est un message de type OPEN. Si le mes-
sage est acceptable par le routeur BGP qui le reçoit, celui-ci envoie
un message de type KEEPALIVE en retour. Lorsque le message de
type OPEN est confirmé, alors des messages de type KEEPALIVE,
UPDATE et NOTIFICATION peuvent être échangés entre les deux
routeurs BGP.
Le message de type OPEN contient les champs suivants
(figure 3) :
— le champ « mon système autonome » indique le numéro d’AS
du routeur qui a émis le message de type OPEN ;
— le champ « Hold Time » indique la proposition (exprimée en
secondes) de l’émetteur du message de type OPEN pour la valeur
maximale de la période de temps qui s’écoule entre la réception de
deux messages de type KEEPALIVE (et/ou de type UPDATE) consécu-
tifs. Sur réception du message de type OPEN, un routeur BGP doit
calculer cette valeur, par comparaison de celle consignée dans le
champ « Hold Time » du message reçu, et celle qui a été configurée
par le gestionnaire du routeur. La valeur du champ « Hold Time » est
soit « 0 », soit une valeur au moins égale à 3 secondes ;
— le champ « Identifiant BGP » correspond à l’adresse IP affectée
au routeur pour son identification (au sens de la connexion BGP-IV) ;
— le champ « paramètres optionnels » contient la liste des para-
mètres optionnels susceptibles d’être véhiculés dans le message de
type OPEN. Ces paramètres sont codés selon le principe TLV (Type
Longueur Valeur). La spécification actuelle [RFC-1771] n’a défini
qu’un seul paramètre (type 1) – le paramètre « Authentication
Information », destiné à être utilisé pour procéder à l’authentifica-
tion d’un routeur BGP-IV (le document [RFC-2385] définit un proces-
sus d’authentification de routeurs BGP-IV qui s’appuie sur
l’utilisation d’une signature MD5/SHA-1).
2.2.2.3 Message de type UPDATE
Les messages de type UPDATE constituent la pierre angulaire du
routage BGP puisque c’est ce formalisme qui permet de véhiculer
les informations d’accessibilité de réseaux. Les annonces consi-
gnées dans les messages de type UPDATE peuvent être utilisées par
les routeurs BGP pour construire le graphe qui permettra de décrire
les relations entre les systèmes autonomes.
Un message UPDATE contient une annonce relative à l’accessibi-
lité d’un réseau et/ou des indications relatives au retrait des routes
qui ne sont plus utilisables, conformément au formalisme décrit
dans la figure 4 suivante :
— le champ « Withdrawn Routes » (« routes retirées »), de lon-
gueur variable, contient la liste des préfixes réseau IP – La notion de
« préfixe réseau » est importante, puisqu’elle signifie que la
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 900 − 6 © Techniques de l’Ingénieur, traité Réseaux
Withdrawn Routes Length (2 octets)
Withdrawn Routes (variable)
Total Path Attribute Length (2 octets)
Path Attributes (variable)
Network Layer Reachability Information (variable)
Figure 4 – Champs (potentiellement) présents dans un message
de type UPDATE
version 4 du protocole BGP intègre la capacité d’agrégation d’adres-
ses IP, qui, au sens CIDR (Classless Inter-Domain Routing) [RFC-
1519], rend caduque la notion de classes d’adresses. Ainsi, on peut
par exemple imaginer un agrégat d’adresses de la forme 192.0.0.0/8
qui pouvaient être accessibles par les routes retirées du service ;
— le champ « Total Path Attribute Length » indique la longueur
totale du champ « Path Attributes » en octets. Lorsque le champ
« Total Path Attribute Length » est valorisé à « 0 », cela signifie qu’il
n’y a pas de champ NLRI (Network Layer Reachability Information,
cf. § 2.2.2.3.1) contenu dans le message de type UPDATE ;
— le champ « Path Attributes » contient une suite (ou une
séquence, i.e. l’ordre dans lequel les attributs et leurs valeurs asso-
ciées a un sens) d’attributs qui sont autant de caractéristiques de la
route consignée dans le champ NLRI. Chaque attribut est codé selon
le principe TLV (Type, Longueur, Valeur) (cf. § 2.2.2.3.2) ;
— le champ NLRI contient la liste des préfixes réseau qui sont
accessibles par la route décrite dans le champ « Path Attributes » ;
— la longueur minimale d’un message de type UPDATE est de
23 octets (les 19 octets de l’en-tête d’un message BGP, associés aux
2 octets du champ « Unfeasible Routes Length » et aux 2 octets du
champ « Total Path Attribute Length » ;
— un message de type UPDATE peut annoncer au maximum une
route, qui peut être décrite par plusieurs attributs. Ces caractéristi-
ques sont applicables à l’ensemble des préfixes réseau consignés
dans le champ NLRI. De même, un message de type UPDATE peut
dresser la liste de plusieurs routes retirées du service, chacune de
ces routes étant identifiée par le préfixe réseau qu’elle permettait
d’atteindre (sa destination). Un message de type UPDATE peut ne
pas contenir d’annonce de route (le champ « Total Path Attribute
Length » est alors valorisé à « 0 »), mais simplement une liste des
routes retirées du service.
2.2.2.3.1 Description du champ NLRI
Le champ NLRI contient une liste de préfixes IP et codé selon une
ou plusieurs association(s) de type [longueur (sur un octet) ; préfixe
(longueur variable)]. Le champ « longueur » indique la longueur (en
bits) du préfixe IP auquel elle se réfère. Le champ « Préfixe » con-
tient les préfixes IP accessibles par la route qui fait l’objet de
l’annonceur et dont les caractéristiques sont applicables à l’ensem-
ble des préfixes destination consignés dans le champ NLRI.
2.2.2.3.2 Attributs BGP-IV
Les attributs BGP-IV, tels qu’ils sont véhiculés dans le champ
« Path Attributes », sont classés en quatre catégories [RFC-1771] :
— les attributs de type « well-known mandatory ». Ces attributs
doivent être supportés par toute implantation du protocole BGP-IV
qui revendique une conformité au standard [RFC-1771], et doivent
être inclus dans tout message de type UPDATE qui contient un
champ NLRI ;
— les attributs de type « well-known discretionary ». Ces attributs
doivent être supportés par toute implantation du protocole BGP-IV
qui revendique une conformité au standard [RFC-1771] mais peu-
vent ne pas être inclus dans un message de type UPDATE ;
— les attributs de type « optional transitive » ;
— les attributs de type « optional non-transitive ».
_________________________________________________________________________________________________________ PROTOCOLE DE ROUTAGE BGP-IV
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Attribute Flags Attribute Type Code
Figure 5 – Champ « Attribute Type » dans le codage TLV
d’un attribut
Les attributs optionnels peuvent ne pas être supportés par les
implantations du protocole BGP qui revendiquent la conformité au
standard [RFC-1771]. Le traitement approprié de tels attributs,
lorsqu’ils ne sont pas reconnus par un routeur BGP, est conditionné
par la valorisation du bit « Transitive » dans l’octet « Attribute Flag »
du champ « Attribute Type », conformément au codage TLV des
attributs, comme l’illustre la figure 5 :
— le bit « 0 » du champ « Attribute Flags » permet d’identifier s’il
s’agit d’un attribut optionnel (le bit est alors valorisé à « 1 ») ou non
(le bit est valorisé à « 0 »). Le bit « 1 » du même champ est le bit
« Transitive », et il indique si l’attribut doit être communiqué aux
interlocuteurs BGP d’un routeur (le bit est alors valorisé à « 1 » –
tous les attributs de type « well-known » ont ce bit valorisé à « 1 »).
Les attributs optionnels non reconnus par un routeur BGP et pour
lesquels le bit « Transitive » dans l’octet « Attribute Flag » du champ
« Attribute Type » est valorisé à « 0 », devraient être ignorés par le
routeur, lequel devrait se garder de les transmettre à ses interlocu-
teurs BGP ;
— le bit « 2 » du champ « Attribute Flags » est le « Partial bit » qui
indique si l’information consignée par un attribut optionnel transitif
est partielle (l’information est complète si le bit est valorisé à « 0 »).
La valeur de ce bit est toujours « 0 » pour les attributs de type « well-
known », ainsi que pour les attributs optionnels non transitifs ;
— le champ « Attribute Type Code » indique le type de l’attribut
dont la valeur est décrite dans le reste du champ « Path Attributes »,
parmi les autres valeurs des attributs ainsi véhiculés dans le mes-
sage de type UPDATE.
Les différents attributs décrits aujourd’hui dans le standard [RFC-
1771] font l’objet des paragraphes suivants. Leur utilisation à des
fins d’ingénierie liée au déploiement de réseaux BGP-IV constitue en
partie la raison d’être du paragraphe 3 du présent article.
2.2.2.3.3 Attribut ORIGIN (code 1)
L’attribut ORIGIN est de type « well-known mandatory ». Cet attri-
but décrit l’origine de l’information de routage et trois valeurs pos-
sibles ont été définies :
— lorsque l’attribut a pour valeur « 0 », le préfixe réseau consigné
dans le champ NLRI du message de type UPDATE est interne au sys-
tème autonome qui a généré l’information ;
— lorsque l’attribut a pour valeur « 1 », le préfixe réseau consigné
dans le champ NLRI du message de type UPDATE est externe au
système autonome qui a généré l’information ;
— lorsque l’attribut a pour valeur « 2 », l’origine de l’information
consignée dans le champ NLRI est dite « INCOMPLETE » – la route
correspondante aura par exemple été « injectée dans BGP-IV » par
un processus de redistribution statique ou dynamique (§ 5.5).
2.2.2.3.4 Attribut AS_PATH (code 2)
L’attribut AS_PATH est de type « well-known mandatory ». Il iden-
tifie l’ensemble des systèmes autonomes par lesquels l’information
de routage a transité. Chacun des systèmes autonomes est repré-
senté par un triplet <Path Segment Type, Path Segment Length,
Path Segment Value> (codage TLV). Le « Path Segment Type » peut
prendre deux valeurs possibles :
— la valeur AS_SET (« 1 ») qui indique que la liste des systèmes
autonomes par lesquels l’information de routage a transité n’est pas
ordonnée ;
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
— la valeur AS_SEQUENCE (« 2 ») qui indique que la liste des sys-
tèmes autonomes par lesquels l’information de routage a transité
est ordonnée.
Lorsqu’un routeur A propage l’annonce relative à une route qu’il
a apprise d’un autre routeur B, le routeur A modifiera la valeur de
l’attribut AS_PATH, en fonction de la localisation du routeur BGP
auquel il transmettra le message de type UPDATE correspondant :
— si cette route est annoncée à un routeur avec lequel une con-
nexion iBGP est établie, l’attribut AS_PATH ne devrait pas faire
l’objet d’une modification par l’annonceur ;
— si, par contre, cette route est annoncée à un routeur avec lequel
une connexion eBGP est établie, la valeur de l’attribut AS_PATH
devra être mise à jour en incluant le numéro du système autonome
de l’annonceur.
Lorsqu’un routeur décide d’annoncer une route en utilisant une
connexion eBGP, l’attribut AS_PATH aura pour unique entrée le
numéro du système autonome auquel appartient l’annonceur ; la
même route annoncée en utilisant une connexion iBGP aura pour effet
de véhiculer un attribut AS_PATH vide, c’est-à-dire dont la valeur du
champ « longueur » est « 0 ».
2.2.2.3.5 Attribut NEXT_HOP (code 3)
L’attribut NEXT_HOP est de type « well-known mandatory ». Cet
attribut identifie (par son adresse IP) le routeur qui devrait être utilisé
comme « next hop » pour l’ensemble des préfixes destination
recensés dans le message de type UPDATE. L’adresse consignée
dans l’attribut NEXT_HOP peut être celle de l’une des interfaces de
l’annonceur, pourvu que le récepteur de l’annonce (faite en utilisant
une connexion eBGP) soit au moins connecté au réseau défini par
cette adresse – on parle alors d’attribut NEXT_HOP « first party ».
De même, l’adresse consignée dans l’attribut NEXT_HOP peut
être celle de l’une des interfaces de n’importe quel routeur qui
appartient au même système autonome que l’annonceur, pourvu
que le récepteur de l’annonce (faite en utilisant une connexion iBGP)
soit au moins connecté au réseau défini par cette adresse – l’attribut
NEXT_HOP est alors qualifié de « third party ». L’adresse consignée
dans l’attribut NEXT_HOP peut aussi être celle de l’une des interfa-
ces d’un routeur externe (au système autonome auquel appartient
l’annonceur), pourvu que le récepteur de l’annonce soit au moins
connecté au réseau défini par cette adresse.
En tout état de cause, la valeur de l’attribut NEXT_HOP est choisie
de telle sorte que la route correspondante emprunte le plus court che-
min pour atteindre l’ensemble des préfixes destination consignés
dans le champ NLRI.
De la même façon, un routeur ne doit jamais consigner dans
l’attribut NEXT_HOP l’adresse IP du récepteur de l’annonce d’une
route dont il est à l’origine. Par ailleurs, un routeur BGP ne doit
jamais installer (dans sa table d’acheminement) une route pour
laquelle il est précisément le « next hop ».
Enfin, lorsqu’une route est annoncée à un routeur interne au sys-
tème autonome auquel appartient l’annonceur, la valeur de l’attribut
NEXT_HOP ne doit pas être modifiée.
2.2.2.3.6 Attribut MULTI_EXIT_DISC (code 4)
L’attribut MED (MULTI_EXIT_DISC(riminator)) est un attribut
optionnel non transitif, représenté sous la forme d’un entier non
négatif codé sur 4 octets. Cet attribut pourra être utilisé par des con-
nexions eBGP pour pondérer le choix entre les différents points
d’entrée/sortie possibles (et connus) d’un système autonome voisin
(de celui auquel appartient l’annonceur).
L’attribut MED constitue une métrique à part entière, en ce sens où
le point d’entrée/sortie de valeur MED la plus faible devrait normale-
ment être préféré, toutes choses étant égales par ailleurs. Les
annonces comportant l’attribut MED peuvent être propagées au sein
du système autonome mais ne doivent en aucun cas être retransmi-
ses par l’un quelconque des routeurs récepteurs des annonces vers
des routeurs appartenant à d’autres systèmes autonomes.
IP 2 900 − 7
PROTOCOLE DE ROUTAGE BGP-IV _________________________________________________________________________________________________________
Système autonome (AS)
Routeur
« J'annonce 192.134.75.0/ 24 » A autonome. Si les deux types de routes (« moins » et « plus » spécifi-
« J'annonce 192.0.0.0/8 »
« J'annonce 192.134.0.0/16 »
« J'annonce 192.134.76. 4 / 30 »
Figure 6 – Cas de routes dont le champ NLRI comporte des préfixes
recouvrants
Une implantation BGP-IV doit permettre de retirer l’attribut MED
consigné dans l’annonce d’une route (par des moyens de configura-
tion appropriés), de même qu’il devrait être possible de changer la
valeur de l’attribut MED consigné dans une annonce reçue par le tru-
chement d’une connexion BGP, conformément à ce qui est indiqué
dans le standard [RFC-1771].
2.2.2.3.7 Attribut LOCAL_PREF (code 5)
L’attribut LOCAL_PREF est de type « well-known discretionary »,
représenté sous la forme d’un entier non négatif codé sur 4 octets.
Cet attribut est utilisé par un routeur pour informer les autres routeurs
internes d’un système de son propre degré de préférence pour chaque
route qui permet d’atteindre une destination externe au système
autonome auquel il appartient.
La route dont le degré de préférence a la valeur la plus élevée doit
être sélectionnée. Les messages de type UPDATE qui sont transmis à
des récepteurs externes au système autonome auquel appartient
l’annonceur ne doivent en aucun cas contenir l’attribut LOCAL_PREF.
Si tel était cependant le cas, cet attribut doit être ignoré par le récep-
teur de l’annonce.
2.2.2.3.8 Attribut ATOMIC_AGGREGATE (code 6)
L’attribut ATOMIC_AGGREGATE est un attribut de type « well-
known discretionary ». Cet attribut est utilisé par un annonceur pour
informer les récepteurs BGP avec lesquels il communique que la
route consignée dans son annonce est la moins spécifique, c’est-à-
dire que le préfixe destination consigné dans le champ NLRI du mes-
sage de type UPDATE est en fait un agrégat d’adresses (au sens
CIDR) [RFC-1519].
Par exemple, si un routeur A reçoit les annonces relatives aux pré-
fixes 192.134.0.0/16 et 192.134.76.0/24 d’un routeur B, et si les routes
correspondantes ont des attributs différents (l’attribut AS_PATH n’a
pas la même valeur, par exemple), le routeur A pourra choisir de
transmettre l’annonce de la route permettant d’atteindre le préfixe
192.134.0.0/16 moyennant l’utilisation de l’attribut
ATOMIC_AGGREGATE, de sorte que les récepteurs correspondants
sachent qu’un sous-ensemble de l’espace d’adressage puisse être
atteint par des routes qui traversent des AS non listés dans l’attribut
AS_PATH. C’est en substance ce qu’illustre la figure 6 :
— une route qui permet d’atteindre un ensemble restreint de des-
tinations (soit un préfixe réseau plus « long », c’est-à-dire que les
bits de masquage sont plus nombreux, par exemple le préfixe
192.134.76.4/30) est qualifiée de « plus spécifique » qu’une route
qui permet d’atteindre un ensemble plus important de destinations
(caractérisé par un préfixe réseau plus « court », par exemple
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 900 − 8 © Techniques de l’Ingénieur, traité Réseaux
192.134.0.0/16). Cette dernière est alors qualifiée de « moins
spécifique » ;
— lorsque des routes moins spécifiques et plus spécifiques sont
présentes dans la table Adj-RIB-In d’un routeur BGP, les routes les
plus spécifiques sont prises en considération (par le processus de
décision BGP-IV, § 2.2.3) d’une manière prioritaire par rapport aux
routes moins spécifiques ;
— si un routeur BGP reçoit des annonces relatives à des routes
recouvrantes (c’est-à-dire les informations consignées dans leurs
champs NLRI respectifs sont constituées de préfixes recouvrants), le
processus de décision devra prendre en considération l’ensemble
de ces routes, en tenant compte de la politique de routage qui aura
pu être définie par l’entité responsable de la gestion du système
ques) sont acceptables, le processus de décision doit soit installer
les deux types de routes, soit agréger les deux routes pour n’instal-
ler que la route finalement agrégée ;
— dans le cas où le processus de décision choisit d’installer
une route agrégée, le routeur devra insérer l’attribut
ATOMIC_AGGREGATE dans le message de type UPDATE
correspondant ;
— le récepteur d’une route qui est en particulier caractérisée par
l’attribut ATOMIC_AGGREGATE ne doit jamais retirer cet attribut
lorsqu’il décide de propager l’annonce à d’autres routeurs BGP. De
plus, le récepteur de telles routes ne doit jamais « désagréger » le pré-
fixe pour annoncer des routes permettant d’atteindre des destinations
plus spécifiques (le préfixe 192.134.76.4/30 dans l’exemple).
2.2.2.3.9 Attribut AGGREGATOR (code 7)
L’attribut AGGREGATOR est un attribut optionnel transitif. Cet
attribut peut être véhiculé dans les annonces correspondant à des
routes permettant d’atteindre des destinations agrégées. Un routeur
BGP capable d’agréger des adresses a ainsi la possibilité d’inclure cet
attribut dans les annonces qu’il fait aux routeurs BGP avec lesquels il
communique. La valeur de l’attribut AGGREGATOR sera alors consti-
tuée de son adresse IP (cette adresse IP correspond en pratique à son
identifiant BGP) et du numéro du système autonome auquel il appar-
tient.
2.2.2.3.10 Gestion des messages de type UPDATE
par un routeur BGP
Lorsqu’un routeur BGP reçoit un message de type UPDATE de l’un
des routeurs internes au système autonome auquel il appartient, il ne
doit en aucun cas retransmettre l’information contenue dans
l’annonce à l’un quelconque des routeurs internes au système auto-
nome.
Par contre, la réception d’une annonce en provenance d’un rou-
teur BGP externe au système autonome auquel le récepteur appar-
tient, devra faire l’objet d’une retransmission auprès de l’ensemble
des routeurs BGP internes au système autonome auquel le récep-
teur appartient et avec lesquels une connexion BGP est établie.
Cette retransmission est toutefois conditionnée par le fait que la
route correspondante a été effectivement installée dans la table Loc-
RIB du récepteur, moyennant l’activation du processus de sélection
de routes, tel qu’il est décrit dans le paragraphe 2.2.3.
Lorsque le message de type UPDATE contient un champ
« withdrawn routes » non vide, le récepteur devra retirer l’ensemble
des routes correspondantes de sa table Adj-RIB-In. Si l’une ou
l’autre de ces routes avait déjà fait l’objet d’une annonce (i.e. la
route en question a été stockée dans la table Adj-RIB-Out du routeur
après mise en œuvre du processus de sélection), le routeur devra
faire face à deux cas de figure possibles :
— il existe une route de remplacement pour les préfixes décrits
dans le champ NLRI correspondant, et cette route de remplacement
devra être annoncée par le routeur BGP à l’ensemble de ses
interlocuteurs ;
— il n’existe pas de route de remplacement pour les préfixes
décrits dans le champ NLRI correspondant, et, dans ce cas, le routeur
_________________________________________________________________________________________________________ PROTOCOLE DE ROUTAGE BGP-IV
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Error code Error subcode Données
Figure 7 – Champs spécifiques d’un message de type NOTIFICATION
BGP devra rajouter les préfixes incriminés dans le champ « withdrawn
routes » du message de type UPDATE qu’il adressera à l’ensemble
des routeurs BGP à qui il avait précédemment annoncé la route qui
permettait d’atteindre ces préfixes destination.
2.2.2.4 Message de type NOTIFICATION
Un message de type NOTIFICATION est envoyé lorsqu’une condi-
tion d’erreur a été détectée par l’un ou l’autre des routeurs BGP. La
connexion BGP entre ces derniers est immédiatement rompue après
l’émission d’un message de type NOTIFICATION.
Les champs spécifiques à un message de type NOTIFICATION sont
décrits sur la figure 7 :
— le champ de code d’erreur (Error Code) indique le type de
NOTIFICATION. Six codes d’erreur ont été définis dans [RFC-1771],
tels que : erreur détectée dans l’en-tête du message BGP (code 1),
dans un message de type OPEN (code 2), dans un message de type
UPDATE (code 3), expiration du Hold Timer (code 4), erreur de la
machine d’état fini (code 5, par exemple réception d’un événement
inattendu – se reporter à l’annexe 1 du document [RFC-1771] pour
une description in extenso de la machine d’état FSM (Finite State
Machine)), cessation de la connexion (code 6, c’est-à-dire en
l’absence d’une quelconque erreur fatale, un routeur BGP peut déci-
der à n’importe quel moment de rompre la connexion BGP en
envoyant un message de type NOTIFICATION avec un code d’erreur
valorisé à 6 (Cease)) ;
— le champ de « sous-code » d’erreur (Error Subcode) permet de
fournir une information plus précise quant à la nature de l’erreur.
C’est ainsi que ce champ peut prendre trois valeurs lorsque le code
d’erreur est valorisé à « 1 » (erreur dans l’en-tête du message BGP,
telle qu’une non synchronisation de la connexion, un type de mes-
sage erroné, ou une longueur de message erronée), six valeurs lors-
que le code d’erreur est valorisé à « 2 » (erreur dans un message de
type OPEN, telle que le non support d’une version spécifique du pro-
tocole BGP, un identifiant BGP erroné, un échec d’authentification,
une valeur inacceptable du paramètre « Hold Time », etc.) et onze
valeurs lorsque le code d’erreur est valorisé à « 3 » (erreur dans un
message de type UPDATE, telle qu’une mauvaise formation de la
liste des attributs ou l’invalidation de la valeur de certains attributs,
etc.) ;
— le champ « données » est quant à lui utilisé pour établir le dia-
gnostic lié à la réception du message de type NOTIFICATION. Le
contenu de ce champ est conditionné par les valeurs respectives des
champs « Error Code » et « Error Subcode » décrits précédemment.
La longueur minimale d’un message de type NOTIFICATION est
de 21 octets.
2.2.2.5 Message de type KEEPALIVE
Les messages de type KEEPALIVE sont échangés périodiquement
entre deux routeurs BGP, de telle sorte que le « Hold Timer »,
n’expire pas. En tout état de cause, le temps écoulé entre deux mes-
sages de type KEEPALIVE consécutifs ne saurait excéder le tiers de
l’intervalle de temps défini par le paramètre « Hold Time », et la fré-
quence d’émission de ces messages ne doit pas être plus élevée
qu’une cadence de un message par seconde.
Si la valeur négociée du paramètre « Hold Time » est de « 0 »,
alors aucun message de type KEEPALIVE ne doit être envoyé.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
Enfin, un message de type KEEPALIVE est seulement constitué de
l’en-tête du message BGP (soit une longueur de 19 octets), moyen-
nant une valorisation ad hoc du champ « Type ».
2.2.3 Processus de décision BGP-IV
Le processus de décision du protocole BGP-IV permet à un routeur
BGP-IV de sélectionner les routes qui seront annoncées à l’ensemble
des récepteurs BGP-IV avec lesquels ce routeur a établi une
connexion BGP, que celle-ci soit de type interne (au système auto-
nome auquel ce routeur appartient) ou externe.
Le processus de sélection est formalisé par la définition d’une
fonction qui considère (comme paramètres d’entrée) l’ensemble
des attributs caractéristiques d’une route donnée pour fournir un
entier non négatif représentatif du degré de préférence associé à
cette route. La sélection effective d’une route consiste donc au calcul
du degré de préférence associé à chaque route dont le routeur a la
connaissance, suivi du choix de la route associée au degré de préfé-
rence le plus élevé.
Le calcul du degré de préférence porte sur chacune des routes con-
signées dans la table Adj-RIB-In et doit permettre au routeur de déci-
der de :
— l’ensemble des routes qui feront l’objet d’une annonce auprès
des routeurs internes au système autonome auquel appartient
l’annonceur ;
— l’ensemble des routes qui feront l’objet d’une annonce auprès
des routeurs externes au système autonome auquel appartient
l’annonceur ;
— l’agrégation de routes (Cf. § 2.2.2.3.8) et, partant, de la réduc-
tion de la volumétrie du trafic caractéristique des annonces.
Le processus de décision BGP-IV se déroule en trois phases, cha-
cune de ces phases étant déclenchée par un événement différent.
2.2.3.1 Phase 1 : calcul du degré de préférence
La phase 1 est déclenchée dès la réception d’un message de type
UPDATE qui contient l’annonce d’une nouvelle route, ou celle d’une
route de remplacement, ou celle d’une route désormais inutilisée.
Pour chaque nouvelle route et pour chaque route de remplacement, le
routeur BGP devra déterminer le degré de préférence associé.
Le calcul associé dépend à la fois de la nature de l’annonce (par
exemple, si la route a été apprise suite à l’annonce envoyée par un
routeur interne au système autonome auquel le récepteur de
l’annonce appartient, le processus de calcul prendra probablement
en compte la valeur de l’attribut LOCAL_PREF comme degré de pré-
férence – probabilité modulée par la proposition spécifiée dans le
document [RFC-1997]), et des choix de configuration qui peuvent
être pris par l’entité responsable de l’administration du système
autonome – ces choix reflètent typiquement une politique de rou-
tage dynamique définie par l’entité administrative responsable de la
gestion de l’AS et mise en œuvre par les routeurs qui composent le
système autonome en question.
Quoi qu’il en soit, la nature de l’information qui sera prise en
compte par le routeur pour calculer le degré de préférence associé à
chaque route reste une affaire de configuration locale à la machine.
Des exemples d’application de politiques de routage sont donnés
dans le chapitre 5 du présent document.
2.2.3.2 Phase 2 : sélection de la route
La phase 2 est déclenchée dès que la phase 1 est terminée et le
processus associé porte sur l’ensemble des routes consignées dans
la table Adj-RIB-In d’un routeur BGP. Pour chacune des destinations
pour lesquelles il existe une route (consignée dans la table Adj-RIB-
In), le routeur BGP devra identifier :
— la route qui a la valeur la plus élevée du degré de préférence
associé à chaque route permettant d’atteindre une destination don-
née OU BIEN ;
IP 2 900 − 9
PROTOCOLE DE ROUTAGE BGP-IV _________________________________________________________________________________________________________
— la seule route qui permet d’atteindre cette destination OU
BIEN ;
— la route sélectionnée à l’issue de l’activation du mécanisme de
sélection appelé « breaking ties » (littéralement « liens de rupture »,
pour illustrer le processus de dichotomie qui caractérise ce méca-
nisme) et décrit ci-après (§ 2.2.3.2.1).
Une fois cette identification effectuée, le routeur installera la route
correspondante dans la table Loc-RIB et il devra de toute évidence
déterminer le « next hop » immédiat qui correspond à la valeur de
l’attribut NEXT_HOP consignée dans le message de type UPDATE
caractéristique de cette route, moyennant une analyse des chemins
possibles qui permettent de l’atteindre – ces chemins peuvent être
déterminés par activation d’un protocole de routage dynamique de
type IGP. Si la route qui permet d’atteindre le routeur décrit dans
l’attribut NEXT_HOP change de telle sorte que le « next hop » immé-
diat change, le processus de sélection de la route devra être réactivé.
2.2.3.2.1 Mécanisme « breaking ties »
Plusieurs routes affectées du même degré de préférence et permet-
tant d’atteindre la même destination peuvent être stockées dans la
table Adj-RIB-In, alors que le routeur BGP ne peut stocker qu’une
seule de ces routes dans sa table Loc-RIB.
L’algorithme mis en œuvre suppose que, pour chaque route
« candidate », l’ensemble des routeurs BGP internes à un système
autonome peut garantir le coût associé à l’accessibilité de l’adresse
consignée dans l’attribut NEXT_HOP de l’annonce correspondante.
Cet algorithme fonctionne selon la chronologie suivante :
1. Ne pas considérer (c’est-à-dire ne pas retenir dans le processus
de sélection) les routes qui intégrent l’attribut MED dont les valeurs
sont les plus pénalisantes, c’est-à-dire les plus élevées (les routes
qui ne comportent pas l’attribut MED dans leurs caractéristiques
seront à ce titre considérées comme des routes ayant la valeur de
MED la plus élevée, soit 232−1). La comparaison faite entre les diffé-
rentes valeurs de l’attribut MED n’est valable que dans la mesure où
les routes correspondantes ont été annoncées par des routeurs
appartenant au même système autonome.
2. Ne pas considérer les routes pour lesquelles l’accessibilité au
« next hop » (identifié par la valeur de l’attribut NEXT_HOP consi-
gnée dans l’annonce) présente un coût intérieur (c’est-à-dire la
métrique associée au(x) chemin(s) qui permet(tent) d’atteindre
l’adresse valorisée dans l’attribut NEXT_HOP – ce coût est générale-
ment obtenu moyennant l’activation d’un ou plusieurs protocoles
de routage dynamique de type IGP) pénalisant, c’est-à-dire ne pas
considérer les routes qui présentent le plus faible coût intérieur.
3. Si plusieurs routes présentent le même « plus faible coût » :
— préférer les routes annoncées par des routeurs externes au sys-
tème autonome auquel appartient le récepteur, à celles annoncées
par des routeurs internes au système autonome ;
— sinon, préférer la route annoncée par le routeur dont la valeur
de l’identification BGP est la plus faible.
2.2.3.3 Phase 3 : dissémination des routes
La phase 3 est déclenchée à l’issue de la phase 2, ou lorsque l’un
des événements suivants se produit :
— les routes stockées dans la table Loc-RIB ont changé ;
— les routes apprises par un protocole de routage autre que BGP
ont changé ;
— une nouvelle connexion BGP a été établie.
Chacune des routes stockées dans la table Loc-RIB sera traitée
comme une entrée correspondante dans la table Adj-RIB-Out asso-
ciée. La phase 3 consiste à mettre à jour le contenu de la table Adj-
RIB-Out et, le cas échéant, le contenu de la table d’acheminement du
routeur.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 900 − 10 © Techniques de l’Ingénieur, traité Réseaux
3. Ingénierie de réseaux
BGP-IV
3.1 Typologie des systèmes autonomes
Le document [RFC-1772] dresse en particulier une typologie des
systèmes autonomes qui reflète la réalité topologique du réseau
Internet. En effet, un AS peut appartenir à l’une des trois catégories
suivantes :
— les AS de type « stub » (littéralement le « bout », l’extrémité en
un certain sens géographique. Un AS de type « stub » ne véhicule
que du trafic local) : ces systèmes autonomes sont des AS qui ne
communiquent qu’avec un seul autre système autonome et un
seul ;
— les AS de type « multihomed » : ces systèmes autonomes peu-
vent communiquer avec au moins deux autres systèmes autonomes
distincts, mais la politique de routage BGP-IV mise en place au sein
d’un système autonome de type « multihomed » lui interdit de véhi-
culer le trafic échangé entre les systèmes autonomes avec lesquels il
peut communiquer. En d’autres termes, ces systèmes autonomes
ne véhiculent pas de trafic de transit ;
— les AS de type « transit» : ces systèmes autonomes peuvent
communiquer avec au moins deux autres systèmes autonomes, et la
politique de routage BGP-IV mise en place en leur sein leur permet de
véhiculer non seulement le trafic local, mais aussi le trafic de transit,
moyennant la définition d’éventuelles restrictions relatives à l’ache-
minement du trafic de transit (par exemple restreindre la retrans-
mission des annonces à celles dont le champ NLRI consigne un
ensemble de préfixes destination prédéterminés).
3.2 Volumétrie du trafic BGP
L’activation d’un protocole de routage dynamique au sein d’un
réseau IP, pour aussi efficace que ce protocole soit, génère un trafic
« de service » (par opposition au trafic correspondant aux données
utiles, i.e. le trafic généré par les utilisateurs d’un réseau IP), dont la
volumétrie ne doit en aucune manière pénaliser les performances
du réseau IP, performances qui pourraient par exemple être quali-
fiées en termes de capacité à traiter le trafic utile.
Le protocole BGP-IV permet de limiter la volumétrie du trafic lié à la
génération des messages de type UPDATE entre routeurs BGP grâce
aux moyens suivants :
— la variable bgpPeerminRouteAdvertisementInterval de la table
BgpPeer de la MIB (Management Information Base) BGP-IV [RFC-
1657] (la valeur suggérée pour cette variable est de 30 s) permet de
définir le temps minimal qui devra s’écouler entre l’émission de
deux messages de type UPDATE consécutifs par un routeur BGP.
Mentionner l’existence et l’utilisation de ces variables suppose de
toute évidence que la MIB décrite dans le document [RFC-1657] est
effectivement supportée par les routeurs BGP qui font l’objet de ce
mode de gestion. Toutefois, le document [RFC-1771] stipule que
toute implantation du protocole BGP-IV doit permettre la configura-
tion des variables citées dans ce paragraphe, mais aussi celle des
variables bgpPeerConnectRetryInterval (valeur suggérée de 2 min),
bgpPeerHoldTime (valeur suggérée de 90 s) et bgpPeerKeepAlive
(valeur suggérée de 30 s), telles qu’elles sont décrites dans le docu-
ment [RFC-1657] ;
— la variable bgpPeerminASOriginationInterval [RFC-1657] (la
valeur suggérée pour cette variable est de 15 s) définit le temps
minimal qui doit s’écouler entre l’émission de deux messages de
type UPDATE consécutifs qui font état de changements au sein du
système autonome auquel appartient l’annonceur ;
_________________________________________________________________________________________________________ PROTOCOLE DE ROUTAGE BGP-IV
— la volumétrie de l’information véhiculée dans les annonces peut
elle-même être réduite, par exemple, par la possible agrégation de
routes (cf. § 2.2.2.3.8) associée à l’utilisation de l’attribut AS_PATH
dont la valeur est exprimée sous forme de suite non ordonnée (Cf.
§ 2.2.2.3.4) de numéros de systèmes autonomes qui ne sont men-
tionnés qu’une seule fois, indépendamment du nombre de fois où
ces numéros sont apparus dans les attributs AS_PATH correspon-
dant aux différentes annonces de routes qui ont précisément fait
l’objet de l’agrégation.
Par ailleurs, le document [RFC-2439] propose un mécanisme
capable de réduire la charge des processeurs impliqués dans le trai-
tement des messages BGP, lorsqu’un phénomène d’instabilité de
routes persiste – ce phénomène conduisant systématiquement à la
réactivation du processus de décision BGP et à la mise à jour du con-
tenu des tables affectées par cette instabilité.
Ce mécanisme qui permet à la fois de s’affranchir d’un possible
phénomène d’oscillation (effet secondaire important d’un phéno-
mène d’instabilité) et de maintenir un temps de convergence (le
temps de convergence est le temps au bout duquel un routeur a
déterminé une route pour atteindre une destination donnée) compa-
rable à celui pris pour déterminer une route permettant d’accéder à
une destination donnée, s’appuie sur des techniques communé-
ment appelées « route flap damping » (littéralement, amortissement
d’oscillation (battement, sic.) de routes).
Les algorithmes d’amortissement ont pour principal objectif de limi-
ter la charge volumétrique induite par le trafic des messages de type
UPDATE sans pour autant pénaliser le temps de convergence associé
à la détermination de routes prétendument stables, ce qui impose un
effort de définition de la stabilité d’une route, de sorte qu’une partie
de l’algorithme puisse être capable de faire la distinction entre les rou-
tes stables et les routes instables.
La proposition décrite dans le document [RFC-2439] s’appuie en
particulier sur la valorisation des paramètres de configuration
suivants :
— cutoff threshold, exprimé en nombre de retraits de routes (de la
table d’acheminement du routeur, NDLA). Ce paramètre identifie la
valeur au-delà de laquelle une annonce sera supprimée ;
— reuse threshold, exprimé lui aussi en nombre de retraits de rou-
tes. Ce paramètre identifie la valeur en dessous de laquelle une route
supprimée pourra de nouveau être utilisée ;
— maximum hold down time. Ce paramètre caractérise le temps
maximum pendant lequel une route peut être supprimée, indépen-
damment de son degré d’instabilité ;
— decay half time while reachable : ce paramètre caractérise la
durée (exprimée en minutes ou en secondes) pendant laquelle la
valeur accumulée de la stabilité d’une route (extraite de ce que le
document [RFC-2439] appelle la « figure de mérite », c’est-à-dire un
moyen pour le routeur de se représenter le degré de stabilité/insta-
bilité d’une route) sera réduite de moitié, si la route est considérée
comme « accessible », i.e. utilisable pour atteindre la destination
que cette route caractérise (que cette route ait été supprimée ou non
de la table) ;
— decay half life while unreachable : ce paramètre caractérise la
durée (exprimée en minutes ou en secondes) pendant laquelle la
valeur accumulée de la stabilité d’une route sera réduite de moitié, si
la route est considérée comme inaccessible ;
— delay memory limit : ce paramètre caractérise le temps maximal
retenu par la mémoire (du routeur) d’une instabilité précédente,
pourvu que l’état de la route concernée soit demeuré inchangé, que
cette route soit accessible ou non.
Le document [RFC-2439] rend compte des développements effec-
tués par un universitaire et un constructeur en 1995, et ces techni-
ques d’amortissement d’oscillation sont mises en œuvre d’une
manière opérationnelle depuis 1996 dans certains régions du réseau
Internet. L’expérience montre que l’algorithme ne devrait pas être
appliqué aux routes apprises au travers de communications iBGP, à
cause des incohérences provoquées par la suppression de ces rou-
tes (suite à une décision de l’algorithme d’amortissement d’oscilla-
tion).
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
L’amortissement fournit un moyen de limiter la propagation de
changements de routes trop fréquents lorsque la communication est
intermittente. En appliquant ce type d’algorithme à leur propre infor-
mation de routage, les fournisseurs de services IP réduisent d’autant
leur nécessité de faire appel aux autres fournisseurs de service avec
lesquels ils échangent des informations de routage, afin que ces
derniers appliquent eux-mêmes une politique d’amortissement
d’oscillation.
3.3 Politiques de routage BGP
Le protocole BGP-IV permet d’appliquer une politique de routage
définie par l’entité responsable de la gestion du système autonome et
de ses composantes, et prise en compte en particulier dans l’activa-
tion du processus de sélection des routes qui seront installées dans
les tables Adj-RIB-Out et FIB des routeurs BGP, et qui seront annon-
cées, le cas échéant, aux composantes d’autres systèmes autono-
mes.
À titre d’exemple, le protocole BGP-IV permet :
— à un AS de type multihomed de refuser d’acheminer le trafic
de transit, en limitant les annonces à celles dont le champ NLRI est
constitué de préfixes internes au système autonome ;
— à un AS de type multihomed de restreindre l’acheminement
d’un trafic de transit à destination d’un ensemble de systèmes auto-
nomes adjacents (c’est-à-dire accessibles au travers de l’établisse-
ment de connexions BGP entre des routeurs qui partagent un
réseau IP commun), en limitant les annonces (à ces systèmes auto-
nomes adjacents) à celles dont les champs NLRI comportent non
seulement des préfixes internes au système autonome concerné,
mais aussi des préfixes caractéristiques des systèmes autonomes
pour lesquels l’AS de type « multihomed » accepte de véhiculer le
trafic de transit ;
— à un AS de privilégier certains systèmes autonomes pour
l’acheminement de son trafic de transit (par exemple l’opérateur
France Télécom peut privilégier l’utilisation du réseau Sprint plutôt
que celle du réseau MCI pour le trafic IP à destination et en prove-
nance des États-Unis) ;
— à un AS de minimiser le nombre de systèmes autonomes de
transit, en fonction des informations consignées dans l’attribut
AS_PATH d’une annonce : « plus le nombre de systèmes autonomes
traversés est faible pour atteindre une destination donnée, meilleure
sera la route » est un exemple de règle destinée à orienter le choix du
processus de sélection de routes ;
— à un AS d’apprécier la qualité d’une route en fonction des indi-
cations consignées dans l’attribut AS_PATH et de la connaissance de
l’entité gestionnaire de ce système autonome des caractéristiques
des AS consignés dans l’attribut AS_PATH d’une annonce, caracté-
ristiques telles que la capacité des liens d’interconnexion des routeurs
composant les différents systèmes autonomes identifiés dans
l’annonce, ou encore la probabilité de congestion telle qu’elle peut
être perçue (par tous moyens appropriés, non nécessairement liés au
fait d’activer le protocole BGP-IV. Parmi ces moyens, il est possible
de citer les techniques d’analyse statistique de trafic, telles que
RMON (Remote network MONitoring MIB) [RFC-2021] au sein des
NAP (Network Access Point), lieux d’échange d’informations de rou-
tage au travers de connexions eBGP entre les routeurs hébergés
dans ces NAP).
3.4 Contraintes d’échelle
L’activation du protocole BGP au sein d’un système autonome
impose un maillage complet de tous les routeurs BGP du domaine, de
façon à ce que chacune de ces machines ait une vision commune
des routes qui permettent d’accéder à l’ensemble des destinations
externes au système autonome, ce qui suppose l’établissement
IP 2 900 − 11
PROTOCOLE DE ROUTAGE BGP-IV _________________________________________________________________________________________________________

d’une connexion iBGP entre chacun des routeurs concernés. Ainsi,

pour n routeurs BGP appartenant à un système autonome donné,
n(n − 1)/2 communications iBGP doivent être maintenues, ce qui Cluster
peut avoir une incidence non négligeable sur la bande passante uti- A B A B E
lisée par le trafic BGP associé, notamment.
Il va de soi que ce maillage complet constitue une contrainte
C AS C D
d’autant plus forte que le système autonome est important (en ter-
mes de nombre de routeurs qui le composent) et que les communica-
tions iBGP s’appuient souvent sur les ressources de transmission AS
Route reflector (RR)
disponibles entre les routeurs concernés.
Les paragraphes 3.4.1 et 3.4.2 donnent une description des solu- AS système autonome
tions actuellement mises en œuvre pour remédier à cette contrainte
et ainsi faire face aux problèmes d’échelle liés à l’extension (et à Figure 8 – Mise en œuvre de clusters au sein d’un système autonome
l’exploitation) d’un système autonome.

3.4.1 Clusters
Le document [RFC-1966] introduit le concept de réflexion de rou-
tes (Route Reflection), qui s’appuie sur la notion de « cluster », un
cluster étant composé de routeurs BGP qui sont clients (Client Peer)
d’un routeur particulier du cluster, appelé le « Route Reflector ». Le
principe mis en œuvre par le déploiement de clusters au sein d’un
système autonome est illustré par la figure 8 :
— dans un contexte de configuration BGP classique selon lequel
les trois routeurs de la figure bénéficient d’un maillage complet pour
l’établissement des connexions iBGP, la réception de l’annonce d’une
route par le routeur A conduira celui-ci à retransmettre cette annonce
aux routeurs B et C, pourvu que cette route ait été sélectionnée (par
le routeur A) comme le meilleur chemin pour atteindre les destinations
consignées dans l’annonce. Dès lors, les routeurs B et C, en tant que
routeurs internes au système autonome (vis-à-vis de cette route
externe), ne retransmettront pas cette annonce aux autres routeurs
iBGP du domaine. Cette règle comportementale peut être modifiée si,
par exemple, le routeur C est autorisé à rendre compte (refléter)
auprès du routeur B les routes apprises du routeur A par l’entremise
de la connexion iBGP établie entre le routeur C et le routeur A, ce qui,
ipso facto, n’impose plus l’établissement d’une communication iBGP
entre le routeur A et le routeur B ;
— le routeur C devient alors le routeur RR (Route Reflector), dont
les clients sont les routeurs A et B de la figure 8 précédente, et dont
les « non clients » sont les routeurs D et E de la figure 9. Les rou-
teurs clients d’un RR ne devraient pas établir de connexions iBGP
avec d’autres routeurs (externes au cluster composé du RR et de ses
clients), tandis que les routeurs non clients doivent établir une con-
nexion iBGP entre eux ;
— lorsque le RR reçoit une annonce (de l’un des routeurs non
clients du cluster auxquels il est connecté), celui-ci active le proces-
sus de sélection classique du protocole BGP pour déterminer le
meilleur chemin pour atteindre les destinations indiquées dans
l’annonce. Lorsque le meilleur chemin est sélectionné, l’annonce cor-
respondante sera faite à l’ensemble des routeurs clients du cluster
dont le RR fait partie ;
— si l’annonce reçue par le RR est envoyée par un client, cette
route sera reflétée (après activation du processus de sélection de rou-
tes) à l’ensemble des routeurs non clients, ainsi qu’aux routeurs
clients du cluster dont le RR fait partie, à l’exception du routeur client
à l’origine de l’annonce ;
— si l’annonce reçue par le RR est envoyée par un routeur externe
au système autonome auquel appartient le RR, celui-ci reflétera
l’annonce à l’ensemble des routeurs clients et non clients du
domaine, après activation du processus de sélection de route.
Un système autonome peut comporter plusieurs clusters (donc plu-
sieurs RR), chaque RR étant considéré comme un routeur avec lequel
une connexion iBGP a été établie avec le reste des RR du domaine. Il
est aussi possible de définir plusieurs RR au sein d’un cluster, à des
fins de redondance. Dans ce cas, l’identification des RR au sein du
cluster ne s’appuiera plus sur le classique ROUTER_ID, mais sur un
identifiant codé sur 4 octets, le CLUSTER_ID, de sorte que les routes
Cluster
A B E
C D
AS
AS système autonome
Figure 9 – Exemple de cluster
annoncées par les autres RR d’un cluster puissent être facilement dis-
tinguées des routes annoncées par les clients de ce même cluster.
Le CLUSTER_ID est en fait renseigné dans l’attribut
CLUSTER_LIST, de type « optional non transitive » (type code 10),
qui est une succession de valeurs de CLUSTER_ID qui représente le
nombre de RR au travers desquels une annonce donnée a transité.
Lorsqu’un RR reflète une route annoncée par l’un de ses clients
auprès d’un routeur non client, l’annonce correspondante doit au
moins intégrer la valeur du CLUSTER_ID caractéristique du RR annon-
ceur, de sorte que des phénomènes de bouclage peuvent ainsi être
évités (si l’identifiant du RR est consigné dans l’attribut
CLUSTER_LIST véhiculé par une annonce transmise à des clients du
RR annonceur, celle-ci sera purement et simplement ignorée).
Le document [RFC-1966] définit un autre attribut de type
« optional non transitive » (type code 9), l’attribut ORIGINATOR_ID :
cet attribut, codé sur 4 octets, sera créé par un RR et véhiculera le
ROUTER_ID caractéristique du routeur BGP à l’origine d’une
annonce au sein du système autonome (dans lequel au moins un
cluster a été mis en place). Il va de soi qu’un RR ne reflétera jamais
une route auprès du routeur (du système autonome) qui est à l’ori-
gine de l’annonce.
3.4.1.1 Du danger de déployer des clusters
Par définition du principe de réflexion des routes, chaque routeur
BGP d’un système autonome n’a pas nécessairement une vision
complète de l’ensemble des routes qui permettent d’atteindre une
destination donnée, puisque le RR d’un cluster est conduit à faire
une sélection qui fera l’objet de l’annonce correspondante auprès
des routeurs appropriés (clients et/ou non clients du cluster) : la
route ainsi reflétée est celle qui a été considérée comme la meilleure
possible par le RR, parmi les multiples chemins qu’il était possible
d’emprunter pour atteindre les destinations consignées dans le
champ NLRI.
Dans le contexte décrit sur la figure 10, le déploiement d’un clus-
ter peut conduire à une prise de décision de routage erronée :

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 900 − 12 © Techniques de l’Ingénieur, traité Réseaux
_________________________________________________________________________________________________________ PROTOCOLE DE ROUTAGE BGP-IV
AS1 Cluster # 2 - RR = D
A nombre de routeurs qui le composent, il existe de par le monde Inter-
D
B C E contrainte du maillage complet des routeurs entre lesquels une
Cluster # 1 - RR = A
G AS3
F AS2 H complexité liée à l’application d’une politique de routage BGP-IV qui
Figure 10 – Risques liés au déploiement de clusters au sein
d’un système autonome
— les routeurs B et C sont les clients du routeur RR A, tandis que
le routeur E est client du routeur RR D au sein du même système auto-
nome AS1, qui comporte ainsi deux clusters distincts. Les routeurs B
et E ont établi une communication eBGP avec les routeurs F et H d’un
système autonome AS2, tandis que le routeur C a établi une commu-
nication eBGP avec le routeur G appartenant au système autonome
AS3 ;
— les routeurs F, G, et H annoncent une route identique (c’est-à-
dire une route permettant d’atteindre la même destination, telle que
consignée dans le champ NLRI du message de type UPDATE corres-
pondant), selon les indications suivantes (tous les autres attributs
ayant des valeurs égales par ailleurs) :
Routeur AS ROUTIER_ID MED
F AS2 192.134.76.34 10
G AS3 191.134.76.34
H AS2 190.134.76.34 20
— on suppose également que le coût (tel que défini par l’activa-
tion d’un protocole de type IGP au sein du système autonome AS1)
associé pour atteindre le routeur B depuis le routeur A (et, a fortiori,
le routeur F) est identique à celui pour atteindre le routeur C depuis
le routeur A (et, a fortiori, le routeur G). De même, le coût associé
pour atteindre le routeur H depuis le routeur D est identique à celui
pour atteindre les routeurs B et C depuis le routeur D ;
— compte tenu du tableau précédent, le routeur A choisit la route
qui passe par le routeur G (à cause de la comparaison des
ROUTER_ID et de la différence de valeur de l’attribut MED pour les
routeurs F et H). Le routeur D choisit quant à lui la route qui passe par
le routeur H (compte tenu de la comparaison entre les ROUTER_ID) ;
— si le maillage était complet, le routeur D sélectionnerait la
même route que celle choisie par le routeur A (en effet, dans ce cas,
le choix de la route par le routeur F est meilleur que celui par le rou-
teur H (à cause des valeurs respectives de l’attribut MED), mais le
choix de la route par le routeur G est meilleur que celui de la route
par le routeur F (à cause des ROUTER_ID).
Le problème soulevé par ce cas de figure est lié au caractère
sélectif (quasi déterministe) des RR et à la prise en compte de l’attri-
but MED dans le processus de sélection. Une solution à ce cas de
figure consisterait à imposer aux RR de ne jamais prendre leur déci-
sion sur la base d’une analyse de l’attribut MED (ce qui est possible
pour la plupart des solutions proposées par les constructeurs).
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
3.4.2 Confédérations
Si la taille d’un système autonome peut être qualifiée en termes de
net des AS de très grande taille (au moins une centaine de routeurs,
typiquement), qu’il peut paraître utile d’organiser en sous-systèmes
autonomes, de façon à s’affranchir (autant que faire se peut) de la
communication iBGP a été établie, notamment. De plus, cette subdi-
vision permet de mieux contrôler la politique de routage mise en
place au sein du système autonome, en fonction de l’information
consignée dans l’attribut AS_PATH contenu dans les messages de
type UPDATE échangés entre les routeurs (par exemple en considé-
rant tous les routeurs confinés dans une région géographique don-
née comme une seule entité).
En contrepartie, cette subdivision provoque un accroissement de la
s’appuierait essentiellement sur les informations véhiculées dans
l’attribut AS_PATH (augmentation de la longueur de l’attribut, puis-
que la traversée d’un message de type UPDATE au travers des diffé-
rents sous-domaines d’un système autonome donné augmente
d’autant le contenu de l’attribut). De plus, la complexité de la main-
tenance des tables BGP est accrue par le fait de la nécessaire cohé-
sion entre les informations échangées au travers des commu-
nications eBGP (c’est-à-dire celles établies entre le système auto-
nome qui fait l’objet d’une subdivision et le reste du monde) et la
topologie du système autonome.
Le protocole IDRP (Inter-Domain Routing Protocol) [IDRP] défini
par ISO (International Standards Organization), a été le premier à
introduire le concept de « confédération », c’est-à-dire au sens du
protocole BGP-IV, une collection de systèmes autonomes [RFC-
1965]. Cette collection fait l’objet d’annonces (aux routeurs qui ne
sont pas membres de la confédération) qui n’indiquent en fait que le
numéro du système autonome pour lequel la confédération a été
mise en place, de sorte que les routeurs qui n’appartiennent pas à ce
système autonome n’ont pas la connaissance de la topologie de
l’AS en question.
Si le protocole IDRP permet de constituer des confédérations imbri-
quées les unes dans les autres, le protocole BGP permet de définir des
confédérations qui s’appuient notamment sur une extension du
type de l’attribut AS_PATH (cf. § 3.2.2.3.4), extension qui impose la
nature hiérarchique des confédérations BGP. Ces extensions sont
définies par les types supplémentaires suivants :
— AS_CONFED_SET (type 3), qui définit une suite non ordonnée
de systèmes autonomes définis au sein de la confédération et que le
message de type UPDATE a traversés ;
— AS_CONFED_SEQUENCE (type 4), qui définit une suite ordon-
née de systèmes autonomes définis au sein de la confédération et
que le message de type UPDATE a traversés.
Un routeur R membre d’une confédération utilisera à des fins
d’identification l’identifiant de la confédération pour toutes les tran-
sactions effectuées avec des routeurs non membres de la confédé-
ration, tandis que ce même routeur R utilisera l’identifiant du sous-
système autonome auquel il appartient au sein de la confédération
pour toutes les transactions effectuées avec les routeurs membres de
la confédération, que ceux-ci appartiennent ou non au même système
autonome que celui auquel appartient le routeur R.
Lorsqu’un routeur décide de propager une annonce de route, il
devra modifier le contenu de l’attribut AS_PATH véhiculé dans
l’annonce en fonction de la localisation du récepteur de l’annonce :
— si le récepteur est localisé dans le système autonome auquel
appartient l’annonceur, le contenu de l’attribut AS_PATH ne sera
pas modifié ;
— si le récepteur est localisé dans un système autonome voisin
(de celui auquel appartient l’annonceur) faisant partie de la confédé-
ration, le contenu de l’attribut AS_PATH sera mis à jour, de telle
sorte que :
IP 2 900 − 13
PROTOCOLE DE ROUTAGE BGP-IV _________________________________________________________________________________________________________
• si le type du premier segment de l’attribut AS_PATH est
AS_CONFED_SEQUENCE, l’annonceur devra rajouter son propre
numéro d’AS comme le dernier élément de la séquence ;
• si le type du premier segment de l’attribut AS_PATH n’est pas
AS_CONFED_SEQUENCE, l’annonceur devra rajouter un nouveau
segment de type AS_CONFED_SEQUENCE, en incluant son pro-
pre identifiant de confédération dans ce segment ;
— si le récepteur est localisé dans un système autonome voisin
qui ne fait pas partie de la confédération, l’annonceur devra modifier
le contenu de l’attribut AS_PATH, de telle sorte que :
• si le type du premier segment de l’attribut AS_PATH est
AS_CONFED_SEQUENCE, ce segment (et ceux de type
AS_CONFED_SET qui lui sont immédiatement consécutifs)
devront être RETIRES, de sorte que l’attribut AS_PATH ne consi-
gne que l’identifiant du système autonome pour lequel la confé-
dération a été mise en place (le récepteur de l’annonce n’a donc
pas la connaissance de la topologie confédératrice du système
autonome auquel appartient l’annonceur) ;
• si le type du premier segment de l’attribut AS_PATH est
AS_SEQUENCE (il n’y a donc plus de types
AS_CONFED_SEQUENCE ou AS_CONFED_SET dans l’un quel-
conque des segments de l’attribut AS_PATH), l’annonceur devra
rajouter son propre identifiant de confédération (i.e. le numéro du
système autonome auquel appartient l’annonceur, dans ce cas)
comme le dernier élément de cette séquence ;
• s’il n’y a plus de segments après le retrait de segments de
type AS_CONFED_SEQUENCE/AS_CONFED_SET dans l’attribut
AS_PATH, l’annonceur devra rajouter un segment de type
AS_SEQUENCE qui inclura son identifiant de confédération.
Lorsqu’un routeur R est à l’origine de l’annonce d’une route, R
devra inclure un attribut AS_PATH vide dans le message de type
UPDATE qui sera envoyé à l’ensemble des routeurs BGP qui appar-
tiennent au même système autonome que celui de l’annonceur.
L’attribut AS_PATH inclura un segment de type
AS_CONFED_SEQUENCE, lorsque l’annonce est destinée aux rou-
teurs d’un système autonome voisin faisant partie de la confédéra-
tion. L’attribut AS_PATH inclura un segment de type
AS_SEQUENCE, lorsque l’annonce est destinée aux routeurs d’un
système autonome voisin ne faisant pas partie de la confédération.
Par ailleurs, les attributs NEXT_HOP et MED ne devraient pas être
modifiés lorsqu’ils font partie d’un message de type UPDATE trans-
mis par un routeur membre d’une confédération et destiné à des
routeurs membres de cette même confédération.
3.5 Politiques de redistribution
La stabilité des routes au sein du réseau Internet est probablement
l’un des soucis majeurs rencontrés par les entités administratives
chargées de gérer les différentes régions du réseau. L’injection
d’informations de routage dans le protocole BGP (plus précisément,
l’alimentation des informations manipulées par le protocole BGP lors
de l’échange de messages de type UPDATE entre deux routeurs,
peut trouver son origine dans l’activation d’un protocole de routage
dynamique de type IGP au sein du système autonome, ou dans l’uti-
lisation de routes statiques) conditionne largement la stabilité des
routes annoncées par le protocole BGP-IV.
L’injection d’informations de routage apprises par le protocole
BGP dans un protocole de type IGP n’est pas recommandée parce
qu’elle augmente le risque de « trous noirs » (le risque est particuliè-
rement important lorsque le protocole OSPF [RFC-2328] est activé
au sein du système autonome, parce que ce protocole fait une dis-
tinction entre les routes internes (à une aire OSPF ou au système
autonome, c’est-à-dire les routes qui permettent d’atteindre une
destination interne à l’aire ou au système autonome) et les routes
externes, à moins d’activer des fonctions de filtrage extrêmement
rigoureuses.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 900 − 14 © Techniques de l’Ingénieur, traité Réseaux
Cette référence astronomique aux « trous noirs » doit ici être com-
prise comme une illustration pratique du phénomène de « calcul
infini » (count to infinity) qui illustre l’incapacité d’un routeur à
déterminer une route qui permettrait d’atteindre une destination
donnée, et ainsi à absorber l’intégralité du trafic correspondant, en
détruisant purement et simplement les datagrammes qui compo-
sent ce trafic...
Enfin, l’implantation de la fonction d’injection (ou de redistribution)
est dépendante de la solution constructeur qui supporte cette fonc-
tion, au moins en termes de configuration.
3.5.1 Routes statiques
Les routes statiques sont pas définition des routes qui sont instal-
lées manuellement dans la table d’acheminement d’un routeur et, par
conséquent, elles ne seront jamais retirées, à moins d’une volonté
délibérée de l’administrateur du routeur.
Lorsqu’elles sont redistribuées dans BGP, les routes statiques sont
maintenues d’une manière permanente dans les tables de routage
BGP, indépendamment du fait que ces routes peuvent être inutilisa-
bles (à cause d’une rupture de lien, par exemple). Si la redistribution
de routes statiques dans BGP offre d’assez bonnes garanties de sta-
bilité (compte tenu du caractère permanent de la maintenance de ces
routes), il n’en reste pas moins que ce type d’injection peut présenter
des inconvénients si la route en question est annoncée depuis plu-
sieurs endroits du réseau... et qu’elle est inutilisable.
Ainsi, si le routeur qui annonce cette route est en fait incapable
d’atteindre la destination consignée dans le champ NLRI correspon-
dant, les datagrammes qui composent le trafic destiné à ce préfixe
seront en revanche détruits, quand bien même il existerait un chemin
possible pour atteindre cette destination.
3.5.2 IGP
En fonction du mécanisme utilisé pour propager l’information véhi-
culée par le protocole BGP-IV au sein d’un système autonome, une
attention particulière devra être portée pour la cohésion des informa-
tions de routage véhiculées par le ou les protocole(s) de type IGP acti-
vés au sein du système autonome et celles véhiculées par le protocole
BGP, d’autant plus que les informations relatives à des changements
d’état tels que perçus par ces différents protocoles peuvent être pro-
pagés à des vitesses différentes au sein du système autonome.
De façon à minimiser autant que faire se peut les risques de trous
noirs liés à l’apparition de fenêtres temporelles (telles que celle provo-
quée par la transmission d’une annonce entre deux routeurs BGP à un
instant t0, et l’instant t1 où le protocole IGP permet effectivement
d’acheminer le trafic vers l’annonceur), les règles élémentaires sui-
vantes devraient être prises en compte [RFC-1772] : un routeur BGP
devrait s’abstenir de propager, auprès des routeurs avec lesquels
une connexion eBGP a été établie, des annonces de routes qui iden-
tifient un « next hop » (au sein du système autonome auquel appar-
tient l’annonceur) tant que l’accessibilité à ce « next hop » n’a pas
été déterminée par le protocole de type IGP activé au sein du sys-
tème autonome, ce qui introduit une fonction de synchronisation
(dès que l’accessibilité est connue, le routeur BGP envoie
l’annonce).
_________________________________________________________________________________________________________ PROTOCOLE DE ROUTAGE BGP-IV
4. Évolutions du protocole
BGP-IV
4.1 Attribut COMMUNITIES (code 8)
Le protocole BGP permet d’appliquer des politiques de routage pour
le trafic de transit (trafic transitant par un système autonome) notam-
ment, grâce à une distribution contrôlée de l’information de routage,
qui s’appuie essentiellement sur des adresses IP (préfixes) et la
valeur consignée dans l’attribut AS_PATH véhiculée dans le message
de type UPDATE.
Afin de simplifier le contrôle de l’information de routage, le docu-
ment [RFC-1997] introduit la notion de « groupe de destinations »,
groupe pour lequel une politique de routage homogène (à l’ensem-
ble des préfixes composant ce groupe) pourra être appliquée. Dans
ce contexte, une communauté est un groupe de destinations (pré-
fixes) qui partagent une caractéristique commune, telle que le fait
d’être des adresses dont la gestion a été confiée à une même entité
administrative, ou le fait que ce groupe de destinations doit néces-
sairement être accessible moyennant la traversée d’un système
autonome particulier.
Pour ce faire, le document [RFC-1997] définit un nouvel attribut,
de type « optional transitive », et de longueur variable : l’attribut
COMMUNITIES (type code 8), pour lequel les trois valeurs suivantes
ont déjà été spécifiées :
— NO_EXPORT (valeur 0xFFFFFF01) : le récepteur des annonces
qui comportent l’attribut COMMUNITIES valorisé de la sorte ne doit
pas propager cette annonce en dehors d’une confédération, ou du
système autonome auquel le récepteur appartient, si cet AS n’a pas
été décomposé en confédération ;
— NO_ADVERTISE (valeur 0xFFFFFF02) : le récepteur des annon-
ces qui comportent l’attribut COMMUNITIES valorisé de la sorte ne
doit en aucun cas propager cette annonce ;
— NO_EXPORT_SUBCONFED (valeur 0xFFFFFF03) : le récepteur
des annonces qui comportent l’attribut COMMUNITIES valorisé de
la sorte ne doit en aucun cas propager cette annonce vers des rou-
teurs avec lesquels il a établi une communication de type eBGP (ce
qui vaut en particulier pour les routeurs qui appartiennent à un sys-
tème autonome voisin du système autonome auquel appartient le
récepteur, mais faisant partie de la même confédération).
Le récepteur d’une annonce qui ne comporte pas l’attribut COM-
MUNITIES a la possiblité de rajouter celui-ci dans le message de type
UPDATE correspondant à la propagation de cette annonce à ses voi-
sins. Par ailleurs, le récepteur d’une annonce qui comporte l’attribut
COMMUNITIES a la capacité de modifier la valeur de celui-ci, afin,
par exemple, d’appliquer une politique de routage locale au système
autonome auquel appartient le récepteur.
Des exemples d’utilisation de l’attribut COMMUNITIES sont fournis
dans le document [RFC-1998] qui indique en particulier que, moyen-
nant un accord préalable entre un client et son fournisseur de ser-
vice – accord selon lequel un ensemble de communautés (groupes
de destinations) pourra être associé à autant de valorisations parti-
culières de l’attribut LOCAL_PREF –, le fournisseur pourra alors
appliquer une politique de routage homogène (par exemple, déter-
mination d’un chemin particulier qui sera emprunté par le trafic
retour conséquent à une consultation de serveurs Web transatlanti-
ques) pour l’ensemble des préfixes destinations consignés dans
chacune de ces communautés.
Les principaux avantages liés à l’utilisation de l’attribut COMMU-
NITIES sont les suivants :
— le client d’un fournisseur de service a la capacité de mieux con-
trôler les échanges d’informations de routage entre le système auto-
nome qu’il représente et celui de son fournisseur ;
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
— l’usage de l’attribut COMMUNITIES permet de s’affranchir
d’une manipulation parfois erratique de l’attribut AS_PATH.
4.2 Extensions multiprotocoles
Le document [RFC-1771] spécifie le protocole BGP-IV de telle sorte
qu’il ne permet de véhiculer que des informations caractéristiques
du protocole IPv4 [RFC-791] en mode transmission unicast, compte
tenu du type d’adresses qu’il est possible de consigner dans le
champ NLRI. Compte tenu du déploiement massif du protocole BGP
au sein du réseau Internet et de la pléthore d’applications qui
s’appuient sur les ressources d’autres protocoles de communication
(que IPv4 en mode de transmission unicast), il a paru souhaitable
d’exploiter les ressources du protocole BGP pour véhiculer des
informations de routage caractéristiques d’autres protocoles de
communication et, en particulier, les protocoles IPv4 pour le mode
de transmission multicast, et IPv6.
Conformément à la spécification actuelle [RFC-1771], seuls trois
types d’information véhiculés par le protocole BGP sont caractéristi-
ques du protocole IPv4 (en mode de transmission unicast) :
— l’attribut NEXT_HOP (dans la mesure où celui-ci contient une
adresse IPv4) ;
— l’attribut AGGREGATOR (qui comporte lui aussi des adresses
IPv4) ;
— le champ NLRI contenu dans un message de type UPDATE, qui
est composé de préfixes conformes au formalisme IPv4.
Dans l’hypothèse (rationnelle) selon laquelle l’ensemble des rou-
teurs BGP d’un système autonome est affecté d’au moins une
adresse IPv4, la capacité du protocole à véhiculer des informations
de routage caractéristiques d’autres protocoles de communication
est donc ramenée à :
— la capacité du protocole à associer un protocole de communi-
cation donné à une information de type « next hop » (décrite éven-
tuellement selon le formalisme d’adressage utilisé en relation avec
le protocole de communication en question) ;
— la capacité du protocole à associer un protocole de communi-
cation donné avec l’information consignée dans le champ NLRI
éventuellement contenu dans un message de type UPDATE.
Par ailleurs, l’information véhiculée dans l’attribut NEXT_HOP n’a
de sens que si elle est associée à un ensemble de préfixes tels que
décrits dans le champ NLRI du message de type UPDATE... et acces-
sibles au travers de l’utilisation du routeur défini dans l’attribut
NEXT_HOP. Cette observation suggère que l’annonce de routes per-
mettant d’atteindre des préfixes destination effectivement accessi-
bles soit décorrélée des annonces relatives aux routes qui ne sont
plus utilisables (préfixes inaccessibles).
C’est pourquoi le document [RFC-2283] définit deux attributs sup-
plémentaires – les attributs MP_REACH_NLRI (MultiProtocol REA-
CHable NLRI – qui véhicule l’information relative à l’ensemble des
destinations accessibles au travers du « next hop », lui-même iden-
tifié dans l’attribut), et MP_UNREACH_NLRI – MultiProtocol UNREA-
CHable NLRI, chargé de véhiculer les informations caractéristiques
de l’ensemble des destinations désormais inaccessibles (cette infor-
mation est complémentaire de celle consignée dans le champ
« withdrawn routes » d’un message de type UPDATE, parce que le
champ « withdrawn routes » ne peut consigner que des informa-
tions conformes au formalisme de l’adressage IPv4. À noter que
l’attribut MP_UNREACH_NLRI contient lui aussi un champ
« withdrawn routes »).
Ces deux attributs sont de type « optional non transitive », si bien
qu’un routeur BGP qui ne supporte pas la fonction capable de traiter
les extensions du protocole pourra ignorer l’information véhiculée
dans ces attributs, laquelle, dans ce cas, ne sera pas retransmise à
d’autres routeurs BGP.
IP 2 900 − 15
PROTOCOLE DE ROUTAGE BGP-IV _________________________________________________________________________________________________________
Address Family Identifier (2 octets)
Subsequent Address Family Identifier (1 octet)
Length of Next Hop Network Address (1 octet)
Network Address of Next Hop (variable)
Number of SNPA (1 octet)
Length of first SNPAs (1 octet)
First SNPA (variable)
Length of second SNPA (1 octet)
Second SNPA (variable)
Length of Nth SNPA (1 octet)
Nth SNPA (of Next Hop ) (variable)
Length of last SNPA (1 octet)
Last SNPA (variable)
Network Layer Reachability Information (variable)
Figure 11 – Attribut MP_REACH_NLRI
4.2.1 Attribut MP_REACH_NLRI
L’attribut MP_REACH_NLRI est formé d’un ou plusieurs triplets
<Address Family Information, Next Hop Information, NLRI> dont le
formalisme est décrit sur la figure 11 :
— le champ AFI (Address Family Identifier) identifie le protocole
de communication utilisé auquel est associée l’adresse qui suit
(champ « Network Address of Next Hop »). Le protocole de commu-
nication est identifié conformément aux valeurs définies dans le
document [RFC-1700] ;
— le champ sub-AFI (Subsequent Address Family Identifier) four-
nit une information complémentaire à celle consignée dans le
champ NLRI de l’attribut. Trois valeurs ont été définies dans le docu-
ment [RFC-2283] :
• Type 1 : l’information consignée dans le champ NLRI est asso-
ciée à un mode de transmission unicast ;
• Type 2 : l’information consignée dans le champ NLRI est alors
associée à un mode de transmission multicast ;
• Type 3 : l’information consignée dans le champ NLRI est asso-
ciée aux modes de transmission unicast et multicast.
— le champ « Nth SNPA of Next Hop » est un champ de longueur
variable qui contient un SNPA (SubNetwork Point of Attachment) du
routeur dont l’adresse réseau est renseignée dans le champ
« Network Address of Next Hop » de l’attribut ;
— l’information relative au « next hop » par lequel l’ensemble
des destinations consignées dans le champ NLRI est accessible,
définit l’adresse réseau du routeur qui devrait être utilisé pour
atteindre cet ensemble de destinations [se reporter au
paragraphe 2.2.2.3.5 pour la typologie des partis (« first » et
« third ») en fonction de la nature de l’annonceur].
Un message de type UPDATE qui contient l’attribut
MP_REACH_NLRI doit aussi contenir les attributs ORIGIN et
AS_PATH, que la communication soit de type eBGP ou de type iBGP.
Par ailleurs, dans le contexte d’une communication de type eBGP, le
récepteur de l’annonce qui contient l’attribut MP_REACH_NLRI aura
pris soin de vérifier que le premier identifiant d’AS consigné dans
l’attribut AS_PATH correspond effectivement au système autonome
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 900 − 16 © Techniques de l’Ingénieur, traité Réseaux
Address Family Identifier (2 octets)
Subsequent Address Family Identifier (1 octet)
Withdrawn Routes (variable)
Figure 12 – Attribut MP_UNREACH_NLRI
auquel appartient l’annonceur, faute de quoi le récepteur devra
envoyer un message de type NOTIFICATION qui indiquera que
l’attribut AS_PATH a été mal formé.
4.2.2 Attribut MP_UNREACH_NLRI
L’attribut MP_UNREACH_NLRI est constitué d’un ou plusieurs tri-
plets <Address Family Information, Unfeasible Routes Length,
Withdrawn Routes>, codés de la manière suivante (figure 12) :
Un message de type UPDATE qui contient l’attribut
MP_UNREACH_NLRI n’est pas censé véhiculer d’autres attributs.
4.2.3 Intégration du formalisme IPv6 ([RFC-2545])
Le formalisme IPv6 [KASSI98] définit trois types d’adresses uni-
cast [RFC-2373], les adresses globales, les adresses de type SLA
(Site Local Addresses) et les adresses de type « link-local ». Les
adresses de type SLA ne sauraient être exportées au-delà d’un site,
tandis que seules les adresses de type « link-local » sont utilisées
par certains protocoles de routage dynamique, tels que le protocole
RIP adapté au formalisme IPv6 [RFC-2080].
Les adresses de type « link local » ne sont pas adaptées pour être
utilisées par l’attribut NEXT_HOP, compte tenu de sa codification,
telle que définie par le document [RFC-1771]. Dans ces conditions,
lorsque le protocole BGP est utilisé pour véhiculer une information
d’accessibilité de réseaux IPv6, il peut être nécessaire de renseigner
le champ « Network Address of Next Hop » de l’attribut
MP_REACH_NLRI par une adresse globale et une adresse de type
« link local », dans la mesure où cette dernière est utilisée par le rou-
teur IPv6 pour générer des messages de type ICMP (Internet Control
Message Protocol) de type ICMP-Redirect [RFC-2461].
La longueur du champ « Network Address of Next Hop » de l’attri-
but MP_REACH_NLRI sera donc de 16 (lorsque le champ est valorisé
par une adresse globale uniquement) ou de 32 octets lorsque le
champ est valorisé par une adresse globale et une adresse de type
« link local ».
Les adresses de type « link local » ne seront insérées dans le
champ « Network Address of Next Hop » que si et seulement si le
récepteur partage un subnet commun avec l’annonceur. Dans tous
les autres cas, seule l’adresse globale devra figurer dans le champ
« Network Address of Next Hop ».
4.3 Services de sécurité
C’est un truisme que d’affirmer que les réseaux IP actuellement
déployés présentent des failles en matière de sécurité, de sorte que la
confidentialité des informations véhiculées par ces réseaux oblige à
déployer des trésors de précaution qui s’appuient sur différentes
solutions destinées à supporter des fonctions élémentaires telles
que les fonctions suivantes :
— la fourniture de certaines garanties quant à l’identité des utili-
sateurs d’un réseau IP, ce qui conduit à la mise en place de fonctions
d’identification et d’authentification ;
_________________________________________________________________________________________________________ PROTOCOLE DE ROUTAGE BGP-IV
— la fourniture de certaines garanties quant à la protection des
sites (et des ressources) raccordés au travers d’un réseau IP, ce qui
conduit généralement à la mise en place de solutions de type pare-
feu ;
— la fourniture de certaines garanties quant à la préservation de
la confidentialité des informations véhiculées sur un réseau IP ;
— la fourniture de certaines garanties quant à l’identité et aux
droits associés à une ressource de commutation IP donnée, suscep-
tible de fournir des informations d’accessibilité de réseaux.
Pour ce qui concerne les routeurs BGP, l’une des préoccupations
en matière de sécurité porte sur la protection de la connexion TCP
contre des attaques telles que des segments TCP simulés (spoofed
TCP segments) [RFC-2385]. Le document [RFC-2385] propose d’utili-
ser la signature MD5 (Message-Digest version 5) [RFC-1321], en
appliquant l’algorithme (MD5) sur les entités suivantes (et selon
l’ordre chronologique associé) :
— le pseudo-en-tête TCP (soit, dans l’ordre, l’adresse IP source,
l’adresse IP destination, le champ « protocol number » valorisé à
« 0 », et la longueur du segment TCP) ;
— l’en-tête TCP (options exclues), le checksum (le checksum
s’appuie généralement sur l’activation d’un code de redondance
cyclique destiné à qualifier le taux d’erreur associé à la transmission
d’un datagramme) étant à « 0 » ;
— les données contenues dans le segment TCP (s’il y en a) ;
— une clé ou un mot de passe, connue des deux routeurs BGP, et
caractéristique de la connexion BGP.
Sur réception d’un segment TCP signé, le récepteur devra le vali-
der en calculant son propre condensé (digest) à partir des mêmes
données, et en utilisant sa propre clé. Le résultat sera comparé avec
le condensé communiqué par son interlocuteur BGP, et si le résultat
de cette comparaison aboutit à deux condensés différents, le récep-
teur ne fournira aucune réponse à l’annonceur, la communication
TCP sera coupée et, par conséquent, la connexion BGP ne sera
jamais établie.
De cette façon, toute tentative d’attaque malicieuse devra non
seulement deviner les numéros de séquence TCP, mais aussi les
mots de passe/clés véhiculés dans les condensés MD5 et qui, par
nature, sont chiffrés. L’activation de ce type de mécanisme peut
avoir un impact sur le temps d’établissement de la connexion TCP,
mais le document [RFC-2385] indique que la génération d’une signa-
ture pour un segment TCP de type ACK par une machine pourvue
d’un processeur cadencé à 100 MHz prenait un temps moyen de
0,0268 ms, tandis que la génération d’une signature pour un seg-
ment TCP constitué d’un volume de données de 4096 octets prenait
un temps moyen de 0,8776 ms, ce qui reste acceptable dans le con-
texte actuel du réseau Internet. Toutefois, l’utilisation d’une signa-
ture MD5 entraîne un overhead (l’overhead est le surplus
d’information induit par l’activation d’une fonction particulière, telle
qu’une signature ou une encapsulation) d’au moins 18 octets plus
important que la longueur de l’en-tête TCP.
Le document [RFC-2385] spécifie l’utilisation de signatures MD5
pour la protection des connexions BGP, mais une signature SHA-1
(Secure Hashing Algorithm, version 1) pourrait aussi être utilisée, le
cas échéant.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
Ce mécanisme permet donc de fournir certaines garanties quant à
l’identité d’un routeur BGP avec lequel un autre routeur BGP est
censé communiquer. Il n’en reste pas moins vrai que cette solution
ne constitue que l’une des briques élémentaires à l’édifice des fonc-
tions de sécurité lorsque l’on active le protocole BGP : à titre
d’exemple, l’utilisation de signatures ne garantit en aucune façon la
validité des annonces, ce qui a conduit au développement des IRR
(Internet Route Registry) [MERIT-RA], qui assurent une sorte de fonc-
tion d’annuaires de routes.
Ces annuaires sont consultés par certains (au moins ceux qui
dépendent de la même entité administrative qui est chargée d’assu-
rer la maintenance de ces serveurs) des routeurs BGP du réseau
Internet pour alimenter les tables Adj-RIB-In, Loc-RIB et Adj-RIB-Out,
moyennant l’utilisation d’un langage spécifique RPSL (Routing
Policy Specification Language) [RFC-2622] qui permet à l’entité ges-
tionnaire de ces routeurs de mettre en œuvre une politique de rou-
tage par l’application des instructions définies dans la syntaxe de ce
langage pour ce qui concerne les informations d’accessibilité de
réseaux IP telles qu’elles sont consignées dans le serveur de routes
– RPSL est utilisé pour mettre en forme l’information consignée et
maintenue par le serveur de routes. La communication entre un rou-
teur BGP et le serveur de routes s’appuie encore (en dépit du fait
que le langage RPSL est conçu de telle sorte qu’il puisse modifier les
configurations des routeurs, moyennant une adaptation (traduction)
entre ce langage et la syntaxe de configuration utilisée par tel ou tel
constructeur. Des expérimentations ont été menées avec certains
d’entre eux dans ce sens) sur une communication BGP
« classique ».
5. Conclusion
La richesse fonctionnelle du protocole BGP-IV justifie largement
son déploiement massif au sein du réseau Internet. Les efforts de
spécification les plus récents devraient conforter cette popularité,
d’autant plus que le protocole BGP-IV permet désormais de véhicu-
ler d’autres informations de routage que celles caractéristiques du
protocole IPv4 en mode de transmission unicast.
En particulier, compte tenu des nombreuses réflexions menées
actuellement au sein de la communauté Internet pour déployer des
réseaux IP à qualités de service différenciées, le protocole BGP-IV
apparaît comme l’une des pierres angulaires de ce qu’il est convenu
d’appeler le routage à qualité de service [RFC-2386] [RFC-2676],
dans la mesure où il permet d’ores et déjà de privilégier l’emprunt
de certains chemins pour atteindre des destinations spécifiques,
conformément à une politique de routage mise en place par l’entité
gestionnaire d’un système autonome : dans ce cas, les concepts les
plus élémentaires d’ingénierie de trafic et de routage par contraintes
(par exemple, sélection d’une route spécifique en fonction de la des-
tination qu’elle permet d’atteindre, acheminement du trafic de tran-
sit au travers de systèmes autonomes particuliers, etc.) peuvent
déjà caractériser l’usage du protocole BGP-IV.
IP 2 900 − 17