Les Pro Toc Oles BGP 25

WWW.RESEAUMAROC.
COM
Cours/formation /Video en informatique:Réseaux,Linux,Cisco,2003 Server,securité,
Contact : tssri-reseaux@hotmail.fr TEL : 00212669324964
Protocole de passerelle frontière permettant l'interconnexion des domaines de routage
Rappel : Un protocole routable est un protocole qui fournit les instructions nécessaires au niveau de la couche 3 du
modèle OSI pour router les paquets.
Un protocole de routage est un protocole qui fournit les mécanismes qui permet à un routeur de construire une table
de routage, de partager des informations de routage avec les autres routeurs auxquels il est connecté et de déterminer
le meilleur itinéraire pour déplacer les données au sein d’un inter réseau.
Il existe plusieurs types de protocoles de routage (RIP, OSPF, EIGRP…) qui utilisent des méthodes différentes pour
aider le routeur à collecter des informations de routage spécifiques à un protocole routé (routable) tel que la pile
TCP/IP.
Algorithmes de routage : processus mathématique que le protocole de routage utilise afin d’évaluer l’intérêt des
différents itinéraires. On peut classer les algorithmes de plusieurs façons : statique ou dynamique, à vecteur de
distance ou à état de liens.
Un système autonome est un ensemble de routeurs fonctionnant sous une seule administration technique, utilisant
un protocole de passerelle intérieure (IGP) et des métriques communs pour router les paquets à l’intérieur du système
autonome et utilisant un protocole de passerelle extérieur (BGP par exemple) pour router les paquets vers les autres
systèmes autonomes.
Introduction :
Internet a été conçu comme un réseau unifié dans lequel tous les routeurs partageaient leurs informations via le
protocole "de gateway à gateway" (GGP), appelé également "à vecteur de distance".
Cette structure arborescente du réseau devenant un maillage de plus en plus important, la notion de système
autonome a été introduite.
Il s'agit du regroupement de plusieurs routeurs sous une administration unique.
Le BGP utilise cette caractéristique.
Le protocole BGP 4 permet de choisir dynamiquement le réseau de transit Internet le plus performant à un instant
donné.
Il répond à deux besoins:
 La sécurité: votre connexion internet n'est jamais interrompue

 L'optimisation: vos temps de réponse internet sont constamment améliorés
Avec le protocole BGP, la mise à jour de routage transporte la liste complète des réseaux de transit (systèmes
autonomes traversés).
De plus, l'échange d'information sur la disponibilité du réseau avec d'autres systèmes BGP, comme par exemple la liste
des chemins AS, permet de construire un graphe de la connectivité des systèmes autonomes.
L'algorithme de protection contre les boucles est donc très simple et assure une autonomie de décision à chaque relais.
Il suffit que le choix effectué par le relais soit enregistré.
Le protocole BGP (Border Gateway Protocol) Protocole de passerelle frontière, fait partie de la famille de protocole EGP
(Exterior Gateway Protocole) dont le rôle est de déplacer les données entre les domaines de routage
Le protocole BGP gère le routage entre plusieurs routeurs qui servent de routeurs frontières entre des systèmes
autonomes donnés. Ces routeurs frontières sont également appelés routeurs principaux. Ils jouent principalement le
rôle de voisins et partagent les informations de leurs tables de routages entre eux. Ce système leur permet d’élaborer
une liste de tous les chemins qui permettent d’atteindre un réseau donné.
Pour définir l’ensemble des mécanismes de décisions qui sont utilisés par BGP, nous devons mettre l’accent sur le fait
qu’un routeur utilisant BGP fait connaître à ses pairs (autres routeurs BGP avec lesquels il communique) seules les
routes qu’il utilise lui même. Cette règle reflète le paradigme de routage « hop by hop » qui est généralement utilisé à
travers Internet.
WWW.RESEAUMAROC.COM
BGP utilise le protocole de transport TCP, qui est un protocole fiable. BGP n’a donc pas besoin implémenter de
méthodes de fragmentation, retransmission , accusé de réception : TCP s’en charge pour lui.
BGP utilise le port TCP 179 pour établir ses communications.
Quelle route emprunter pour faire communiquer l’ordinateur A avec le B ?
I- Généralités sur BGP.

WWW.RESEAUMAROC.COM
Deux système développent une connexion à protocole de transport entre eux. Ils échangent des messages pour ouvrir
et maintenir les paramètres de la connexion. Le premier flot de données est la table entière de routage BGP. Les mises
à jours incrémentielles sont envoyées lorsque la table de routage change : BGP ne nécessite pas de mises à jour
périodiques des tables de routage.
Par contre un routeur BGP doit retenir la totalité des tables de routage courantes de tous ses pairs durant le temps de
la connexion.
Des messages « keepalive » sont envoyés périodiquement pour assurer la durée de vie de la connexion.
Des messages de notification sont envoyés en réponse à une erreur ou à des conditions spéciales ; dans ce cas la
connexion est alors interrompue.
Les hôtes qui exécutent BGP ne sont pas forcément des routeurs, c’est pourquoi on parlera plus généralement de
système ou de paire BGP.
Tous les périphériques BGP à l’intérieur d’un système autonome maintiennent des connexions BGP directes entre eux ,
et utilisent un ensemble de règles communes pour savoir quel routeur frontière servira de point d’entrée/sortie pour
une destination particulière en dehors du système autonome.
Cette information est communiquée à tous les routeurs du système autonome via un protocole de passerelle intérieur.
II- Routes : échange et stockage.
Les routes sont échangées entre les pairs de périphériques BGP dans des messages de mises à jour. La destination de
ce message est les systèmes autonomes dont les adresses IP sont indiquées dans le champ NLRI (Network Layer
Reachablility Information), et le chemin qui va être utilisé est indiqué dans le champ Attributes path.
Les routes sont stockées dans les bases d’information de routage (RIB). Il y a trois types de base d’information :
ü Adj-RIB-Out : pour les informations de routage qui seront envoyées aux autres périphériques BGP ;
ü Adj-RIB-In : pour les informations de routage qui ont été envoyées par les autres périphériques BGP ;
ü Loc-RIB : pour les informations utilisées par le périphérique BGP local.

WWW.RESEAUMAROC.COM
BGP fournit des mécanismes pour permettre à un système de signaler à un autre système BGP qu’une route
initialement fonctionnelle ne l’est plus. Il y a trois mécanismes différents :
ü Le préfixe IP qui indique la route de destination n’étant plus accessible est indiqué dans le champ WITHDRAWN
ROUTES dans le message de mise à jour.
ü Une route de remplacement est indiquée dans le champ Attributes path en gardant la même valeur dans le
champs NLRI. Ceci est possible que s’il existe une autre route bien évidemment.
ü La connexion BGP est fermée, ce qui ferme toutes les routes.
Nous allons voir dans les paragraphes suivants les formats des messages afin de situer ce que sont ces champs (tels
que les champs WITHDRAWN ROUTES et NLRI dont nous venons de parler).
III- Format du message d’en-tête.
Chaque message possède une en-tête dont la taille est fixe. Il peut y avoir ou non une portion de données à la suite de
l’en-tête.
Marker : ce champ de 16 octets permet d’authentifier les messages BGP entrants, de détecter une perte de
synchronisation entre deux périphériques BGP. Si le type du message est OPEN ou si le message OPEN ne fournit pas
d’information d’authentification, alors tous les bits de Marker doivent être à 1.
Autrement la valeur de ce champs est calculée suivant le mécanisme d’authentification utilisé.
Length :ce champ de deux octets indique la taille totale du message, en-tête comprise. La taille d’un message est
minimum de 19 octets et maximum de 4096 octets.
Type : ce champ de 1 octet définit le type de message envoyé :
valeur 1 : OPEN
valeur 2 : UPDATE
valeur 3 : NOTIFICATION
valeur 4 : KEEPALIVE
IV- Format du message OPEN.
Une fois que la connexion à transport de protocole est établie le premier message envoyé de chaque côté est un
message OPEN.Si le message OPEN est acceptable, alors un message KEEPALIVE est envoyé en retour. Une fois le
message OPEN confirmé, les messages UPDATE, NOTIFICATION, KEEPALIVE peuvent être échangé. Nous verrons plus
en détail au chapitre VIII – f) le processus de synchronisation entre deux paires BGP.
En plus de l’en-tête BGP, le message OPEN contient les champs suivants :

WWW.RESEAUMAROC.COM
Version : sur un octet, il indique la version du protocole BGP utilisé. (4 par exemple)
My Autonomous System : cette valeur sur 2 octets indique le numéro de système autonome de l’émetteur.
Hold Time : Champ de 2 octets qui indique le nombre de secondes que l’émetteur propose pour le compteur de retenue
(le compteur de retenue permet d’éviter les bouclages infinis dans les systèmes autonomes). Une fois qu’un
périphérique BGP reçoit un message OPEN il doit calculer la valeur du compteur de retenue qui va être utilisée ; pour
cela il choisit la plus petite valeur entre le compteur de retenue qu’il vient de recevoir dans son message OPEN et la
propre valeur qui a été configurée pour lui-même.
La valeur choisie est en fait le nombre de secondes qu’il peut se passer entre la réception successive et respective de
message KEEPALIVE et UPDATE envoyés par l’émetteur.
BGP Identifier : champ de 4 octets indiquant l’identifiant BGP.(basé sur l’adresse IP assignée au périphérique BGP).
Optional Parameters Length : Champ d’un octet indiquant la taille totale du champ Optional Parameters en octet. Si la
valeur est 0, c’est qu’il n y a pas de Paramètres optionnels.
Optional Parameters : ce champ contient la liste des paramètres optionnels qui sont représentés par des triplets :
« Parameter Type, Parameter Length, Parameter Value ».
Le champ « parameter Type» identifie de manière unique chaque paramètre optionnel.
Le champ « Parameter Length » indique la taille en octet du champ Parameter Value.
Le champ « Parameter Value » est un champ à taille variable (c’est pourquoi sa taille est indiquée dans le champ
Parameter Length. Il contient le paramètre optionnel en lui même.
Un des paramètres optionnels que l’on peut définir est le paramètre Authentication Information ; il permet
d’authentifier une paire BGP.
C’est un option de type 1 (on retrouve donc la valeur 1 dans le champ Parameter type).
Dans Parameter value on va retrouver plusieurs champs : le champ « Auth.Code » et le champ « Authentication
Data ».
Le code d’authentification indique le mécanisme utilisé pour déchiffrer les informations d’authentification.
WWW.RESEAUMAROC.COM
Authentication Data est le champ qui contient les informations d’authentification.
La taille minimale d’un message OPEN est de 29 octets (en-tête incluse).
V- Format du message UPDATE.
Les messages UPDATE sont utilisés pour envoyer les informations de routage entre les paires BGP. Ces informations
permettent de construire un graphique décrivant les relations entre les divers systèmes autonomes.
Un message UPDATE permet de faire connaître une unique route utilisable à une paire BGP et/ou d’annuler plusieurs
routes à présent inutilisables.
Le message UPDATE contient toujours la partie en-tête (voir paragraphes III) et peut contenir les autres champs ci-
dessous :
Unfeasible Routes Length : taille totale du champ Withdrawn Routes en octets. Une valeur de zéro indique qu’aucune
route n’est devenue impraticable ; à ce moment là on ne retrouvera pas le champ withdrawn routes dans le message
UPDATE.
Withdrawn Routes : champ de taille variable contenant la liste des préfixes d’adresses IP pour les routes devenues
impraticables.
Total Path Attributes Length: indique la taille totale en octet du champ Path Attributes. Une valeur de zéro précise qu’il
n’y a pas de champ Path Attributes dans le message UPDATE.
Path Attributes : il s’agit d’un triplet de taille variable: Attribute Type, Attribute Length et Attribute Value.
WWW.RESEAUMAROC.COM
Comme l’indique le schéma ci-dessus, la partie Attribute Type du champ Path Attribute est composée de deux octets :
l’octet Attribute Flags et Attribute Type Code.
Voyons en détail l’octet Attribute Flags :
- Le premier bit de poids fort (le plus à gauche) définit si l’attribut est optionnel (mis à 1) ou déjà connu (mis à 0).
Le terme exact pour un Attribut déjà connu est Well-known. Ces attributs sont reconnus par toutes les
implémentations BGP. Certains de ces attributs sont dits Mandatory, c’est à dire obligatoire et doivent être inclus dans
tous les messages UPDATE. Les autres sont dits Discretionary (discrets) et peuvent ou non être inclus dans les
messages UPDATE. Tous les attributs Well-known doivent être propagés aux autres systèmes BGP.
En plus des attributs Well-known, chaque chemin peut inclure un attribut optionnel. On ne peut pas attendre de tous
les systèmes (implémentations) BGP de comprendre les attributs optionnels.
- Le second bit définit si l’attribut optionnel est transitif (mis à 1) ou non transitif (mis à 0). Pour les attributs déjà
connus, ce bit est mis à 1.
L’utilisation d’un attribut optionnel non reconnu est déterminée par la configuration du bit transitif (mis à 0), alors les
chemins avec des attribut optionnels non reconnus seront acceptés.
- Le troisième bit définit si l’attribut optionnel transitif est partiel (mis à 1) ou complet (mis à 0). Pour les attributs
déjà connus et les attributs optionnels non transitifs ce bit doit être à 0.
Si un chemin avec un attribut optionnel non reconnu transitif est accepté et véhiculé vers les autres systèmes BGP, cet
attribut doit se propager vers les autres systèmes BGP avec le bit Partiel mis à 1.
Notes : les attributs optionnels non transitifs et non reconnus sont ignorés et ne sont pas propagés vers les autres
systèmes BGP.
Les nouveaux attributs transitifs peuvent être attachés au chemin par le créateur du message UPDATE ou par
n’importe quel autre système autonome dans le chemin. S’ils ne sont pas attachés par le créateur du message, alors le
bit partiel doit être à 1.
- Le quatrième bit définit si Attribute Length (partie du champ Path Attributes, voir schéma du format du message
UPDATE) est sur un octet (mis à 0) ou sur 2 octets (mis à 1).
Les quatre bits suivants (bits de poids faibles) sont inutilisés.
L’émetteur d’un message UPDATE doit ordonner les attributs de chemin dans l ‘ordre croissant, cependant le récepteur
doit être en mesure de manier ces attributs même s’ils sont dans le mauvais ordre.
Le même attribut ne peut être présent qu’une seule fois dans le champ Path Attributes d’un message UPDATE
particulier.
WWW.RESEAUMAROC.COM
L’octet Attribute Type Code contient le code type de l’attribut.
Code 1 : ORIGIN (origine du chemin de l’information).
Valeur 0 : IGP (Interior Gateway Protocol)à la NLRI (Information sur l’accessibilité du réseau) est interne au système
autonome.
Valeur 1 : EGP (Exterior Gateway Protocol)àla NLRI est apprise grâce au protocole EGP (l’information vient d’un autre
système autonome).
Valeur 2 : INCOMPLETE àla NLRI a été apprise d’une autre manière.
ORIGIN est un attribut well-known obligatoire (mandatory). Cet attribut est généré par le système autonome à l’origine
de l’information de routage. Il doit être présent dans tous les messages UPDATE que les systèmes BGP choisissent de
propager cette information aux autres systèmes BGP.
Code 2 : AS_PATH est représenté par un triplet : Path Segment Type, Path Segment Length, Path Segment Value.
Valeur 1 pour le Path Segment Type : AS_SET : le message UPDATE a traversé de façon désordonnée les
Valeur 2 pour le Path Segment Type : AS_SEQUENCE : le message UPDATE à traversé de façon ordonnée les
Le Path Segment Length indique le nombre de systèmes autonomes dans le champ Path Segment Value.
Le Path segment Value contient un ou plusieurs numéros de systèmes autonomes.
AS_PATH est un attribut well-known obligatoire qui identifie les systèmes autonomes à travers lesquelles les
informations de routage présentes dans ce message UPDATE sont passées.
Les éléments de cette liste peuvent être AS_SETs ou AS_SEQUENCEs.
Quand un système BGP propage une liste qu’il a apprise par un autre système BGP, il doit modifier l’attribut AS_PATH
de la route en se basant sur la location du système BGP à qui la route (information) doit être transmise. Il le modifie de
la façon suivante :
- Si le premier chemin du AS_PATH est de type AS_SEQUENCE, le système local ajoute son propre numéro de
système autonome comme dernier élément de la liste.
- Si le premier chemin du AS_PATH est de type AS_SET, le système local ajoute un nouveau chemin de type
AS_SEQUENCE incluant on propre numéro de système autonome
Notes : quand un système BGP propage une route à un autre système BGP situé dans le même système autonome, il
ne doit pas modifier l’attribut AS_PATH associée à cette route.
Code 3 : NEXT_HOP : il définit l’adresse IP du routeur frontière pour le prochain saut vers la destination listée dans le
champ NLRI du message UPDATE.
Un système BGP peut définir un routeur frontière local comme Next Hop (prochain saut) à condition que l’interface
associée avec l’adresse IP de ce routeur frontière partage un réseau commun avec le système BGP local et les
systèmes BGP externes au système autonome.
Un système BGP peut définir un routeur frontière externe comme Next Hop à condition que l’adresse IP de ce routeur
frontière ait été apprise par un des systèmes BGP, et que l’interface associée à l’adresse IP de ce routeur partage un
réseau commun avec les systèmes BGP locaux et distants.
WWW.RESEAUMAROC.COM
Notes : un système BGP ne doit jamais définir une adresse d’une paire BGP comme Next Hop pour cette paire, tout
comme un système BGP ne peut définir sa propre adresse comme Next Hop.
Quand un système BGP fait connaître une route à un autre système BGP dans son propre système autonome, le
système générateur du message ne doit pas modifier l’attribut Next Hop associé à cette route.
Quand le système BGP reçoit le message UPDATE d’un autre système BGP du même système autonome, il transfert les
paquets à l’adresse donnée par Next Hop, à condition que l’adresse contenue dans l’attribut fasse partie d’un réseau
commun entre les système BGP locaux et distants.
Code 4 : MULTI_EXIT_DISC : il s’agit d’un attribut optionnel non transitif utilisé par un périphérique BGP pour
distinguer des points d’entrées/sorties vers des systèmes autonomes voisins.
La valeur de cet attribut est un nombre de 4 octets appelé Metric.(métrique en français).
Si tous les facteurs de mesure utilisés pour prendre la décision d’une route par rapport à une autre sont identiques, le
système BGP utilisera la route dont la métrique est la plus faible.
Code 5 : LOCAL_PREF : il indique aux périphériques BGP à l’intérieur du système autonome le degré de préférence
du périphérique générateur du message UPDATE pour une route particulière.
LOCAL_PREF est un attribut well-known discret qui est inclus dans tous les messages UPDATE envoyés aux autres
systèmes BGP du même système autonome.
Un système BGP doit calculer son degré de préférence pour chaque route externe (vers d’autres systèmes autonomes)
et le faire connaître aux autres paires BGP de son système autonome.
Un système BGP doit utiliser le degré de préférence appris via LOCAL_PREF dans son processus de décision (choix de la
route à emprunter).
Un système BGP ne doit pas inclure cet attribut dans les messages UPDATE destinés aux systèmes autonomes voisins ;
toutefois, si cela se produit le système BGP qui reçoit un message UPDATE avec l’attribut LOCAL_PREF d’un système
autonome voisin, alors cet attribut sera ignoré.
Code 6 : ATOMIC_AGGREGATE : il permet d’informer les autres périphériques BGP que le périphérique générateur
du message UPDATE a choisi une route moins spécifique plutôt qu’une route plus spécifique.
Il s’agit d’un attribut well-known discret. Si un système BGP choisit la route la moins spécifique plutôt qu’une route
plus spécifique, alors il attache l’attribut ATOMIC_AGGREGATE au message UPDATE. Le récepteur de ce message ne
doit pas retirer cet attribut avant de propager l’information de routage, et ne doit pas définir de route plus spécifique
dans la NLRI.
Code 7 : AGGREGATOR : c’est un attribut optionnel transitif qui contient le dernier numéro de système autonome
dans lequel la route a été construite, suivi de l’adresse IP du périphérique qui a construit la route.
Voyons maintenant le dernier champ d’un message UPDATE : le champ Network Layer Reachability Information.
Le champ NLRI est composé de deux informations :

WWW.RESEAUMAROC.COM
Le champ Length indique la taille du champ Prefix. Une taille de zéro précise qu’un préfixe mappe toutes les adresses
IP.
Le champ préfixe contient les préfixes d’adresses IP suivi d’un nombre nécessaire de bit inutiles pour l’information et
dont le seul but est de rendre la taille du champ Prefix multiple d’un octet. (puisque le champ Length indique la taille
en octet).
Un message UPDATE peut au plus faire connaître UNE route, cette dernière pouvant être décrite par plusieurs attributs
de chemin (Path Attributes).
Tous les attributs de chemin sont appliqués aux destinations contenues dans le champ NLRI du message UPDATE.
Un message UPDATE peut distinguer plusieurs routes ; chacune de ces routes est identifiée par sa destination (sous la
forme d’un préfixe IP) ce qui identifie sans ambiguïté cette route pour le système BGP.
VI- Format du message KeepAlive.
Les messages KeepAlive sont échangés aussi souvent qu’il faut entre les systèmes BGP pour ne dépasser le Hold Timer
(compteur de retenue). Ce compteur de retenue a été défini entre les interlocuteurs BGP lors de la transmission du
message OPEN.
Un temps maximum raisonnable entre deux messages KeepAlive serait de 1/3 du temps convenu pour le compteur de
retenue. Ils doivent donc être envoyés plus d’une fois par seconde. Une implémentation peut permettre de définir la
fréquence d’échange de ces messages en fonction du compteur de retenue.
Si le temps pour le compteur de retenue convenu est de zéro, les messages KeepAlive ne peuvent pas être échangés.
Les messages KeepAlive sont uniquement composés du message d’en-tête et ont donc un taille de 19 octets.
VII- Format du message NOTIFICATION.
Un message de notification est envoyé lorsqu’une condition d’erreur est détectée. La connexion BGP est close aussitôt
l’envoi de ce message.
En plus de l’en-tête BGP, le message de notification contient les champs suivants :

WWW.RESEAUMAROC.COM
Le champ Error Code indique le type du message NOTIFICATION. Les codes suivants ont été définis :
Le champ Error Subcode fournit une description plus spécifique sur la nature de l’erreur reportée.
Chaque Error Code peut avoir une ou plusieurs Error Subcode.
Si aucune Subcode Error n’est définie, alors une valeur de zéro (erreur non spécifique) est mise dans le champ
Subcode.
Voici la liste exhaustive des sous codes d’erreur :
Pour les erreurs concernant l’en-tête (Error Code = 1)
Pour les erreurs concernant les messages OPEN (Error Code = 2)

WWW.RESEAUMAROC.COM
Pour les erreurs concernant les messages UPDATE (Error Code = 3)
Le champ DATA dans le message NOTIFICATION est utilisé pour diagnostiquer la raison d’être du message
NOTIFICATION. Son contenu dépend du code l’erreur et de son subcode.
La taille minimale d’un message NOTIFICATION est de 21 octets en incluant l’en-tête.

WWW.RESEAUMAROC.COM
VIII- Prise en charge des erreurs.
Ce chapitre décrit les actions prises lors de la détection d’une erreur. A chaque fois qu’une erreur est détectée un
message de notification est envoyé avec le code de l’erreur, son Subcode et le champ Data ; et la connexion est
arrêtée.
Les entrées de la table de routage associées avec le système distant sont notifiées comme invalides avant de les
supprimer.
a) Erreur concernant l’en-tête.
Toutes les erreurs détectées concernant l’en-tête aboutissent à l’envoi d’un message NOTIFICATION avec pour code de
l’erreur la valeur 1, et un subcode dépendant du type de l’erreur.
Si le champ Marker de l’en-tête n’est pas celui attendu, alors c’est une erreur de synchronisation (subcode = 1).
Si la taille indiquée dans le champ Length est inférieure à 19 ou plus grande que 4096, si la taille d’un message (OPEN,
UPDATE, KEEPALIVE, NOTIFICATION) est inférieure à la taille minimale d’un message (OPEN,UPDATE, KEEPALIVE,
NOTIFICATION) alors le message d’erreur est Mauvaise taille du message (subcode = 2). Dans ce cas le champ Data
du message de notification contiendra la taille erronée du message.
Si le type du message indiqué dans le champ Type n’est pas reconnu alors une erreur Mauvais type de Message
(subcode = 3) est envoyée et le champ Data du message de notification est le type de message erroné
b) Erreur concernant les messages OPEN.
Le code pour ce type d’erreur est le code 2 (Open Message Error)
Si le récepteur ne reconnaît pas la version indiquée dans le champ VERSION du message OPEN, le subcode de l’erreur
est 1 (Numéro de version non supportée. On retrouvera dans le champ Data du message de notification le plus grande
nombre possible de versions supportées par le système local.
Si le numéro de système autonome est non valide alors le subcode de l’erreur est Bad Peer AS. (la décision sur
l’acceptabilité d’un système autonome n’est pas rattachée au protocole BGP, c’est pourquoi nous ne nous intéresserons
pas à ce mécanisme.)
Si la valeur retenue pour le compteur de retenue est non valide, alors le subcode de l’erreur est Unacceptable Hold
Time. Une implémentation doit rejeter un temps pour le compteur de une ou deux secondes. Une implémentation peut
rejeter n’importe quel temps, et finalement une implémentation qui accepte le temps proposé doit utiliser cette valeur
pour le Hold Time.
Si l’identifiant BGP est syntaxiquement incorrect, le subcode de l’erreur est Bad BGP Identifier
Si une des options dans le champ Optional Parameters n’est pas reconnue, alors le subcode de l’erreur est Unsupported
Optional Parameter.
Si le message OPEN porte une Information d’Authentification (comme paramètre optionnel), alors la procédure
d’authentification est invoquée. Si cette procédure échoue, le subcode de l’erreur est Authentication Failure.
c) Erreurs concernant les messages UPDATE.
Le dépistage d’une erreur concernant les messages UPDATE commence par l’examen des Attributs de chemin.
Si la taille des routes impraticables (Unfeasible routes Length) ou si la taille totale des attributs (Total Attribute Length)
est trop importante, le subcode de l’erreur est Malformed Attribute List.
Si un attribut reconnu à un flag d’attribut en conflit avec le code type de l’attribut, le subcode de l’erreur est Attribute
Flags Error. Le champ DATA du message de notification contient les attributs erronés. (type, length et value)
WWW.RESEAUMAROC.COM
Si la taille de l’attribut est en conflit avec la taille attendue (basée sur le code type de l’attribut) alors le subcode de
l’erreur est Attribute Length Error. Le champ DATA du message de notification contient les attributs erronés (type,
length et value).
Si un des attributs well-known obligatoires est absent, le subcode de l’erreur est Missing Well-known Attribute. Le
champ DATA du message de notification contient le code type de l’attribut manquant.
Si un attribut well-known obligatoire n’est pas reconnu, le subcode de l’erreur est Unrecognized Well-known Attribute.
Le champ DATA du message de notification contient l’attribut non reconnu (type, length et value).
Si l’attribut ORIGIN n’a pas de valeur définie, le subcode de l’erreur est Invalid Origin Attribute. Le champ DATA du
message de notification contient l’attribut non reconnu (type, length et value).
Si l’attribut NEXT_HOP n’est pas correct syntaxiquement, le subcode de l’erreur est Invalid NEXT_HOP Attribute. Le
champ DATA du message de notification contient l’attribut incorrect.
Syntaxiquement correct signifie que l’attribut NEXT_HOP représente une adresse IP valide.
Sémantiquement correct s’applique seulement aux systèmes BGP extérieurs au système autonome ; c'est-à-dire que
l’interface associée à l’adresse IP spécifiée dans l’attribut NEXT_HOP partage un réseau commun avec avec le système
BGP receveur.
Si l’attribut est sémantiquement incorrect, l’erreur est enregistrée et la route sera ignorée, mais aucun message de
notification ne sera envoyé.
L’attribut AS_PATH est vérifié pour voir s’il est syntaxiquement correct. S’il est incorrect alors le subcode de l’erreur est
Malformed AS_PATH.
Si un attribut optionnel est incorrect, il est écarté et le subcode de l’erreur est Optional Attribute Error. Le champ DATA
du message de notification contient l’attribut (type, length, Value).
Si un attribut apparaît plus d’une fois dans un message UPDATE, le subcode de l’erreur est Malformed Attribute List.
Le champ NLRI est vérifié d’un point de vue syntaxique. S’il est incorrect, le subcode de l’erreur est Invalid Network
Field.
d) Erreurs concernant les messages de notification.
Si un système BGP reçoit un message de notification contenant une erreur, il n’y a aucun moyen de reporter cette
erreur grâce à un message de notification ultérieur.
e) Erreur concernant le Hold Timer.
Si un système BGP ne reçoit pas de messages KEEPALIVE et/ou UPDATE et/ou NOTIFICATION dans la période de
temps définie par le compteur de retenue dans le champ Hold Time, un message de notification doit être envoyé avec
le code erreur Hold Timer Expired Error.
f) Erreur concernant la Machine à l’état fini.
Chaque erreur concernant la machine à l’état fini se traduit par l’émission d’un message de notification avec pour code
erreur Finite State Machine Error.
Voici les différents états finis de la machine :
Nous allons répertorier un par un tous les différents états possibles d’un système BGP et définir toutes les erreurs qui
peuvent intervenir lors de ces différents états.
WWW.RESEAUMAROC.COM
Idle State (état ralenti) : dans cet état, BGP refuse toutes les connexions BGP entrantes. Aucune ressource n’est
allouée au système BGP.
En réponse à un événement de début (Start Event), le système local initialise toutes les ressources BGP, déclenche le
temporisateur de nouvelle tentative de connexion (ConnectRetry Timer), engage une connexion de transport avec une
autre paire BGP, tout en écoutant une connexion éventuelle mise en place par cette paire BGP distante, puis change
son état à Connect.
La valeur exacte du ConnectRetry Timer ne concerne que le système BGP local, mais doit être suffisamment
importante pour permettre l’initialisation de la connexion TCP.
Si un système BGP détecte une erreur, il ferme la connexion et remet son état sur Idle.
La sortie de l’état Idle demande la génération d’un Start Event ; si un tel événement est généré automatiquement, des
erreurs persistantes vont apparaître (le système BGP va sans arrêt vouloir repasser en mode Connect). Pour éviter
cela, il ne faut pas générer ce Start Event immédiatement pour une paire qui est repassée en mode Idle dû à une
erreur. Dans ce cas, si l’événement Start Event est généré automatiquement, il faut que le temps consécutif entre
deux Start Event augmente de manière exponentielle.
Dans l’état Idle, seul le Start Event est pris en compte.
Connect State (état d’attente de connexion) : dans cet état, le système BGP attend que la connexion du protocole
de transport soit complet.
Quand la connexion est terminée, le système local remet à zéro le ConnectRetry Timer, complète l’initialisation, envoie
un message OPEN à sa paire et change son état sur OpenSent.(message open envoyé)
Si la connexion échoue, le système local redémarre son ConnectRetry Timer, continue d’écouter une connexion
entrante par la paire BGP distante et change son état sur Active State.
Si le ConnectRetry Timer expire, le système local redémarre son ConnectRetry Timer, engage une connexion de
transport avec la parie BGP distante, continue d’écouter une connexion entrante de la part de la paire BGP distante, et
reste en état Attente de connexion (Connect State).
L’événement de début (Start Event) est ignoré dans l’état actif (Active state).
Dans le cas de n’importe quelle autre événement, le système local libère toutes les ressources associées à cette
connexion et passe à l’état Idle.
Active State (état actif) : dans cet état, BGP essaie de saisir une paire BGP en engageant un connexion à protocole
de transport. Si cette connexion réussit, le système local met à zéro son ConnectRetry Timer, complète l’initialisation ,
envoie un message OPEN à sa paire BGP, met son Compteur de retenue (Hold Timer) à une valeur plus élevée et
change son état à OpenSent. Une valeur pour le Hold Timer suggérée est de 4 minutes.
OpenSent State (état durant l’envoi du message OPEN) : dans cet état BGP attend un message OPEN provenant
de sa paire BGP. Quand le message OPEN est reçu, il est vérifié pour s’assurer qu’il ne contient pas d’erreur. S’il y a
une erreur, le système local change son état sur Idle.
S’il n’y a pas d’erreur, BGP envoie un message KEEPALIVE et met en place un temporisateur de message keepalive
(KeepAlive Timer). Le compteur de retenue (Hold Timer) qui avait été mis à une valeur plus importante est remplacé
par la valeur Hold Timer négociée. Si la valeur négociée est de zéro, le Hold Timer et le KeepAlive Timer ne sont pas
démarrés. Finalement l’état est changé sur OpenConfirm.
Si une notification de déconnexion apparaît, le système local ferme la connexion BGP, redémarre son ConnectRetry
Timer, pendant qu’il écoute une éventuelle connexion entrante d’une paire BGP distante, et passe en Active State.
WWW.RESEAUMAROC.COM
Si le compteur de retenue (Hold Timer) expire, le système local envoie un message de notification avec pour code de
l’erreur Hold Timer Expired et change son état sur Idle.
En réponse à un événement de fin (Stop Event), le système local envoie un message de notification avec le code erreur
Cease et change son état sur Idle.
En réponse à n’importe quel autre événement, le système local envoie un message de notification avec le code erreur
Finite State Machine Error.
Un événement Start Event est ignoré dans l’état OpenSent.
OpenConfirm State (état d’attente de confirmation du message OPEN) : dans cet état, BGP attend la réception
d’un message KEEPALIVE ou NOTIFICATION.
Si le système local reçoit un message KEEPALIVE, il change son état sur Established (établi).
Si le compteur de retenue expire avant la réception d’un message KEEPALIVE, le système local envoie un message de
notification avec le code erreur Hold Timer Expired et change son état sur Idle.
Si le système local reçoit un message de notification, il change son état sur Idle. Si le KeepAlive Timer expire, le
système local envoie un message KeepAlive et rédemarre son KeepAlive Timer et reste en état OpenConfirm.
Si une notification de déconnexion est reçue, le système local change son état sur Idle.
En réponse à un événement de fin, le système local envoie un message de notification avec le code erreur Cease et
change son état sur Idle.
En réponse à n’importe quel autre événement, le système local envoie un message de notification avec le code erreur
Finite State Machine Error et change son état sur Idle.
Established State (Etat établi) : dans cet état, BGP peut échanger des messages UPDDATE, NOTIFICATION et
KEEPALIVE avec ses paires.
Quand le système local reçoit un message UPDATE ou KEEPALIVE, il redémarre son compteur de retenue, si le Hold
Timer négocié est différent de zéro.
Si le système local reçoit un message NOTIFICATION, il change d’état et se met sur Idle. Si le système local reçoit un
message UPDATE et que la procédure de détection d’erreur en décèle une, le système local envoie un message de
notification et change son état sur Idle.
Si un message NOTIFICATION de déconnexion est reçu, le système change son état sur Idle.
Si le compteur de retenue (Hold Timer) expire, le système local envoie un message de NOTIFICATION avec le code
erreur Hold Timer Expired et change son état sur Idle.
Si le KeepAlive Timer expire , le système local envoie un message KEEPALIVE et redémarre son KeepAlive Timer.
Chaque fois que le système local envoie un message KEEPALIVE ou UPDATE, il redémarre son KeepAlive Timer, à
moins que la valeur du compteur de retenue négociée soit de zéro.
En réponse à un événement de fin (Stop Event), le système local envoie un message de notification avec le code erreur
Cease et change son état sur Idle.
Les événements de débuts (Start Event) sont ignorés dans l’état Established.
En réponse de n’importe quel autre événement, le système local encoie un message de notification avec le code erreur
Finite State Machine Error et change son état sur Idle.
WWW.RESEAUMAROC.COM
g) Coupure (Cease)
En l’absence de toute erreur fatale, un système BGP peut choisir à n’importe quel moment de terminer la connexion
BGP en envoyant un message de notification avec le code erreur Cease.
WWW.RESEAUMAROC.COM
XI- Prise en charge du message UPDATE.
Un message UPDATE ne peut être reçu que si le système est dans l’état établi (Established). Quand il est reçu, chaque
champ est vérifié afin de contrôler son intégrité (cf. § VIII).
Si le message contient des données dans son champ Withdrawn Routes (routes qui ne sont plus valides), les routes
indiquées dans ce champ sont retirées de la base d’information Adj-RIB In.(cf. § II). Le système BGP devra alors revoir
son processus de décision tant que ces routes ne seront plus valides.
Si le message contient une route praticable, il devra l’inscrire dans la base Adj-RIB In, puis il devra prendre les
mesures suivantes :
- Si le champ NLRI du message UPDATE est identique à une des routes actuellement stockées dans sa base Adj-RIB
In, il remplace la route ancienne par la nouvelle, rendant impraticable l’ancienne route. Le système BGP revoit alors
son processus de décision.
- Si la nouvelle route est une route redondante incluse dans une route présente dans la base Adj-RIB In, le système
BGP doit revoir son processus de décision tant que le route la plus spécifique fait partie de la route moins spécifique qui
est devenue indisponible.
- Si la nouvelle route a les mêmes attributs de chemin (Path Attribute) qu’une route contenue dans la base Adj-RIB
In, et qu’elle est plus spécifique que cette route, alors aucune action n’est à prendre.
- Si la nouvelle route à une NLRI qui n’est présente dans aucune des routes actuellement présentes dans la base
Adj-RIB In, alors la nouvelle route devra être placée dans la base et le système devra revoir son processus de décision.
- Si la nouvelle route est redondante et moins spécifique qu’une route contenue dans la base Adj-RIB In, le système
doit revoir son processus de décision en se basant sur les destinations décrites seulement par la route la moins
spécifique.
a) Processus de décision.
Le processus de décision sélectionne les routes pour un usage futur en appliquant les règles indiquées dans la PIB
(Policy Information Base) pour les routes stockées dans la base Adj-RIB In.
La sortie de ce processus de décision est l’ensemble des routes qui seront propagées à toutes les paires.
Les routes sélectionnées seront stockées dans la base Adj-RIB Out du système local.
Le processus de décision est formalisé en définissant une fonction qui prend l’attribut d’une route donnée et retourne
un entier non négatif indiquant le degré de préférence pour cette route.
La fonction qui donne le degré de préférence pour une route donnée ne doit pas prendre en compte les critères
suivants : l’existence d’autres routes, la non existence d’autres routes, ou les attributs de chemins (Path attributes)
des autres routes.
La sélection de la route consiste ensuite à l’application individuelle de la fonction du degré de préférence pour chaque
route praticable (feasible routes), suivi par le choix de la route qui a le plus fort degré de préférence.
Le processus de décision se fait sur les routes contenues dans la base Adj-RIB In, et est responsable de :
- La sélection des routes que le système local va faire connaître à ses paires dans le système autonome.
- La sélection des routes que le système local va faire connaître à ses paires dans les systèmes autonomes voisins.
- L’agrégation de route et la réduction des informations de routage(que nous ne verrons pas dans cet essentiel).
WWW.RESEAUMAROC.COM
Le processus de décision prend place en trois étapes :
Phase 1 :Calcul du degré de préférence
La phase 1 est responsable du calcul du degré de préférence pour chaque route reçue d’un système BGP situé dans un
système autonome voisin, et de la propagation des routes qui ont le plus haut degré de préférence pour chaque
destination.
La fonction de décision de la phase 1 doit verrouiller une base Adj-RIB In avant d’opérer à des calculs dedans et la
réouvrir après avoir terminé les calculs sur les routes contenues dans cette base.
Pour chaque nouvelle route reçue, ou chaque remplacement de route praticable (dans les deux cas) le système BGP
doit déterminer le degré de préférence. Si la route a été apprise d’un système BGP à l’intérieur du système autonome,
le système local devra prendre comme degré de préférence soit la valeur de l’attribut LOCAL_PREF, soit le calculer
selon les règles préétablies dans la PIB (Policy Information Base).
Si la route est apprise d’un système BGP d’un système autonome voisin, le degré de préférence sera calculé selon les
règles de la PIB.
Phase 2 :Sélection de la route
Le système local BGP doit ensuite faire tourner un processus de mise à jour interne (que nous détaillerons plus tard)
pour choisir la route la plus préférable et la propager.
Si l’attribut NEXT_HOP d’une route BGP décrit une adresse pour laquelle le système local n’a pas de route dans sa base
Loc-RIB, la route BGP devra être exclu de la phase 2 du processus de décision.
Pour chaque ensemble de destinations pour lesquelles une route praticable existe dans la base Adj-RIB In, le système
BGP local doit identifier la route qui a :
1) Le plus haut degré de préférence de la route qui mène à la même destination
2) Ou qui est la seule route pour cette destination.
3) Ou qui est le résultat des règles du Breaking Ties de la phase 2.(voir après)
Le système local doit ensuite placer cette route dans la base Loc-RIB, remplaçant ainsi la route vers cette destination
qui était jusqu’alors utilisée.
Le système local doit déterminer le prochain saut décrit dans l’attribut NEXT_HOP de la route sélectionnée en regardant
dans la base des routes existantes du protocole de passerelle intérieur (IGP) du système autonome.
Ce prochain saut doit être utilisé lors de l’installation de la route dans la base Loc-RIB.
Breaking Ties : dans sa base Adj-RIB In, un système BGP peut avoir plusieurs routes possibles pour la même
destination, qui ont le même degré de préférence. Le système local ne peut pourtant utiliser qu’une seule route pour
l’inclure dans sa base Loc-RIB.
La procédure de Tie-Breaking suivante admet que pour chaque route candidate, tous les systèmes BGP à l’intérieur du
système autonome peuvent s’assurer du coût du chemin pour la destination indiquée dans NEXT_HOP. Les liens (ties)
devront être cassés (breaking) selon l’algorithme suivant :
- Si le système local est configuré pour prendre en compte le MULTI_EXIT_DISC, et que les routes candidates
diffèrent dans leur attribut MULTI_EXIT_DISC, la route choisie sera celle avec l’attribut MULTI_EXIT_DISC le plus
faible.
- Autrement, il choisira la route qui représente le moindre coût en terme de distance interne. Si plusieurs routes
représente le même coût de distance le tie-breaking sera opérer de la façon suivante :
WWW.RESEAUMAROC.COM
· Si au moins une des routes candidates a été connue grâce à un système BGP situé dans un système autonome
voisin, la route choisie sera celle qui a été connue grâce au système BGP qui a le BGP Identifier le plus faible parmi
tous les systèmes BGP des systèmes autonomes voisins.
· Autrement (si la route qui a été connue ne vient pas d’un système autonome voisin), la route choisie sera la
route qui a été apprise grâce au système BGP dont le BGP Identifier a la valeur la plus faible.
Phase 3 :Propagation de la route
La phase 3 intervient en complément de la phase 2, ou lorsque les événements suivants se passent :
- Quand les routes dans la base Loc-RIB ont changé
- Quand les routes générées localement apprises par un moyen étranger à BGP ont changé.
- Quand un nouveau système BGP, ou quand une nouvelle connexion BGP ont été établis.
Toutes les routes incluses dans la base Loc-RIB doivent être traitées dans une entrée correspondante de la base Adj-
RIB Out.
Routes redondantes :
Un système BGP peut transmettre des routes avec des informations d’accessibilité du réseau redondantes (NLRI
redondante). Ceci peut se produire lorsqu’on retrouve un ensemble de destinations qui sont identifiées comme Routes
Multiples non concordantes (non-matching). Pour palier à cela, un système BGP a plusieurs choix :
- Installer les deux routes (la plus spécifique et la moins spécifique).
- Installer la partie non redondante de la route la moins spécifique.
- Agréger les deux routes et installer la route agrégée.
- Installer la route la moins spécifique seulement
- N’installer aucune route.
Si le système BGP choisit d’installer la route la moins spécifique, il devra ajouter l’attribut ATOMIC_AGGREGATE à la
route.
b) Processus d’envoi du message UPDATE.
Le processus d’envoi du message UPDATE distribue les routes retenues lors du processus de décision aux autres
systèmes BGP situés dans le système autonome local et/ou les systèmes autonomes voisins.
Mises à jour internes :
Les mises à jour internes concernent les distributions d’informations de routage dans le même système autonome.
Quand un système BGP reçoit un message UPDATE d’un système local situé dans le même système autonome, il ne
doit pas propager ce message aux autres paires du système autonomes (le système BGP créateur de ce message l’aura
déjà envoyé à toutes les autres paires du système autonome).
Quand un système BGP reçoit un message UPDATE d’un système BGP situé dans un système autonome voisin, il devra
propager cette route à tous les autres systèmes BGP de son système autonome à l’aide d’un message UPDATE si les
conditions suivantes apparaissent :
WWW.RESEAUMAROC.COM
- le degré de préférence de la nouvelle route reçue par le système BGP local est plus haut que le degré de
préférence que ce système avait assigné aux autres routes (vers la même destination) qu’ils avait apprise de systèmes
BGP situés dans des systèmes autonomes voisins.
- Ou s’il n’y avait pas déjà d’autres routes apprises grâce à des systèmes BGP situés dans des systèmes autonomes
voisins.
- Ou si la nouvelle route reçue est le résultat de la technique Breaking-tie.
Quand un système BGP reçoit un message UPDATE avec des informations dans le champ WITHDRAWN ROUTES, il
devra retirer ces routes de sa base Adj-RIB In, puis il devra accomplir les étapes suivantes :
- Si la route correspondante praticable (celle qui devrait être dans la base Adj-RIB In) n’existe pas, il n’y a rien
d’autre à faire.
- Si la route praticable correspondante existe dans la base du système BGP local :
o Si une nouvelle route est sélectionnée pour être propagée et qu’elle a la même NLRI (destination) que la route
devenue impraticable (celle identifiée dans le champ WITHDRAWN ROUTES), le système BGP local devra propager une
route de remplacement.
o Si la route de remplacement n’est pas valable, le système BGP local devra inclure le destinations des routes
impraticables (sous forme de préfixe IP) dans le champ WITHDRAWN ROUTES d’un message UPDATE, et devra envoyer
ce message à toutes les paires BGP à qui il avait indiquer auparavant cette route comme route valide.
Si un système BGP local a plusieurs connexions avec des systèmes BGP situés dans des systèmes autonomes voisins, il
aura plusieurs bases Adj-RIB In et ces bases pourraient contenir des routes différentes pour la même destination. On
retrouve alors la technique du Breaking Ties pour palier à ce problème.
Mises à jour externes :
Les mises à jour externes permettent de propager les informations de routage aux systèmes BGP situés dans les
systèmes autonomes voisins.
Du fait de la phase trois du processus de décision, le système BGP a mis à jour sa base Adj-RIB Out. Toutes les
nouvelles routes installées et toutes les routes devenues impraticables sans remplacement possible seront propagées
aux systèmes BGP des systèmes autonomes voisins grâce au message UPDATE.
Toutes les routes impraticables seront éliminées de la base Loc-RIB un fois le message UPDATE envoyé.
Les changements sur les routes praticables qui mènent à des destinations à l’intérieur même du système autonome
doivent aussi être propagés dans un message UPDATE.
XII- Contrôle de la congestion du réseau
Le protocole BGP contraint la quantité de trafic généré par les informations de routage (plus particulièrement la
quantité de transit des messages UPDATE) dans le but de limiter le besoin en bande passante et la puissance de
traitement nécessaire au processus de décision.
C’est pourquoi BGP offre un paramètre appelé MinRouteAdvertisementInterval qui définit le temps minimum qu’il doit y
avoir entre deux messages UPDATE d’un même système BGP. Ceci n’est précisément possible que s’il existe un
compteur pour chaque ensemble de destinations.
Cette procédure ne s’appliquent pas pour les routes devenues impraticables (elles doivent aussitôt être retirées des
bases de tous les systèmes BGP).
Cette procédure ne limite pas le nombre de route à faire connaître mais seulement la fréquence de propagation.
WWW.RESEAUMAROC.COM
En contre partie, un autre paramètre permet d’assurer tout de même l’envoi de message UPDATE dans des intervalles
maximum pour des changements concernant le système autonome lui même : c’est le MinASOriginatingInterval.

Les Pro Toc Oles BGP 25

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Les Pro Toc Oles BGP 25

Încărcat de

Drepturi de autor:

Formate disponibile

WWW.RESEAUMAROC.

Protocole de passerelle frontière permettant l'interconnexion des domaines de routage

 La sécurité: votre connexion internet n'est jamais interrompue

BGP utilise le port TCP 179 pour établir ses communications.

Quelle route emprunter pour faire communiquer l’ordinateur A avec le B ?

I- Généralités sur BGP.

II- Routes : échange et stockage.

ü Loc-RIB : pour les informations utilisées par le périphérique BGP local.

ü La connexion BGP est fermée, ce qui ferme toutes les routes.

III- Format du message d’en-tête.

Autrement la valeur de ce champs est calculée suivant le mécanisme d’authentification utilisé.

Type : ce champ de 1 octet définit le type de message envoyé :

IV- Format du message OPEN.

En plus de l’en-tête BGP, le message OPEN contient les champs suivants :

Le champ « parameter Type» identifie de manière unique chaque paramètre optionnel.

Le champ « Parameter Length » indique la taille en octet du champ Parameter Value.

Authentication Data est le champ qui contient les informations d’authentification.

La taille minimale d’un message OPEN est de 29 octets (en-tête incluse).

V- Format du message UPDATE.

Voyons en détail l’octet Attribute Flags :

Les quatre bits suivants (bits de poids faibles) sont inutilisés.

L’octet Attribute Type Code contient le code type de l’attribut.

Code 1 : ORIGIN (origine du chemin de l’information).

Valeur 2 : INCOMPLETE àla NLRI a été apprise d’une autre manière.

Le Path segment Value contient un ou plusieurs numéros de systèmes autonomes.

Les éléments de cette liste peuvent être AS_SETs ou AS_SEQUENCEs.

La valeur de cet attribut est un nombre de 4 octets appelé Metric.(métrique en français).

Le champ NLRI est composé de deux informations :

VI- Format du message KeepAlive.

VII- Format du message NOTIFICATION.

En plus de l’en-tête BGP, le message de notification contient les champs suivants :

Chaque Error Code peut avoir une ou plusieurs Error Subcode.

Voici la liste exhaustive des sous codes d’erreur :

Pour les erreurs concernant l’en-tête (Error Code = 1)

Pour les erreurs concernant les messages OPEN (Error Code = 2)

Pour les erreurs concernant les messages UPDATE (Error Code = 3)

La taille minimale d’un message NOTIFICATION est de 21 octets en incluant l’en-tête.

VIII- Prise en charge des erreurs.

a) Erreur concernant l’en-tête.

b) Erreur concernant les messages OPEN.

Le code pour ce type d’erreur est le code 2 (Open Message Error)

c) Erreurs concernant les messages UPDATE.

d) Erreurs concernant les messages de notification.

e) Erreur concernant le Hold Timer.

f) Erreur concernant la Machine à l’état fini.

Voici les différents états finis de la machine :

Dans l’état Idle, seul le Start Event est pris en compte.

Un événement Start Event est ignoré dans l’état OpenSent.

XI- Prise en charge du message UPDATE.

Le processus de décision prend place en trois étapes :

Phase 1 :Calcul du degré de préférence

Phase 2 :Sélection de la route

1) Le plus haut degré de préférence de la route qui mène à la même destination

2) Ou qui est la seule route pour cette destination.

Phase 3 :Propagation de la route

La phase 3 intervient en complément de la phase 2, ou lorsque les événements suivants se passent :

- Quand les routes dans la base Loc-RIB ont changé

- Installer les deux routes (la plus spécifique et la moins spécifique).

- Installer la partie non redondante de la route la moins spécifique.

- Agréger les deux routes et installer la route agrégée.

- Installer la route la moins spécifique seulement

- N’installer aucune route.

b) Processus d’envoi du message UPDATE.

Mises à jour internes :