• Français
Accueil
12-10-2008
 
 
Le Laboratoire
forum
Menu principal
Accueil
News
Tips
Articles
Letterman Subscribe




Le protocole BGP
Écrit par Guillemot Erwan   
26-06-2007
Index de l'article
Le protocole BGP
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21

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).



Dernière mise à jour : ( 31-12-2003 )
 
< Précédent   Suivant >
CLTE - Moteur de tests en ligne
Le CLTE est le moteur de tests en ligne du Laboratoire SUPINFO des Technologies Cisco.
Connectez-vous ! Création d'un compte gratuit
 
Top! Top!