bgp always-compare-med Différence entre bgp dterministic-med et bgp always-compare-med ccnp_cch

Sommaire • Introduction - Composants utilisés • Rappel • Exemples de commandes - Exemple 1: Les deux commandes sont dévalidées - Exemple 2 : bgp deterministic-med dévalidée, bgp always-compare-med validée - Exemple 3 : bgp deterministic-med validée, bgp always-compare-med dévalidée - Exemple 4 : Les deux commandes sont validées ccnp_cch

Introduction Il y a quelques fois confusion entre les commandes de configuration BGP (Border Ga- teway Protocol) bgp deterministic-med et bgp always-compare-med. Ce document explique les différences entre bgp deterministic-med et bgp always-compare-med qui affectent la sélection de chemin basée sur MED (Multi-Exit Discriminator) et com- ment chaque commande change le comportement de BGP lors du choix de la meilleure route. Composants utilisés Les informations présentes dans ce document sont basées sur la Release 12.2(10b) de l'IOS Cisco. Rappel Il y a deux commandes qui peuvent influencer la sélection de chemin basée sur MED. Ce sont les commandes bgp deterministic-med et bgp always-compare-med. Valider la commande bgp deterministic-med assure que la comparaison des valeurs de MED sera faite lors du choix des routes annoncées par différents voisins dans le même système autonome. Valider la commande bgp always-compare-med que la comparaison de MED pour des chemins issus de voisins dans différents systèmes au- tonomes sera faite. La commande bgp always-compare-med est utile quand de multi- ples fournisseurs d'accès ou entreprises s'accordent sur un même politique d'utilisa- tion de MED. Ainsi, pour le réseau X, si le fournisseur d'accès Internet A (FAI A) fixe MED à la valeur 10 et le FAI B fixe MED à la valeur 20, les deux FAIs admettent que le FAI A a le meilleur chemin vers le réseau X. Note: Les commandes bgp deterministic-med et bgp always-compare-med ne sont pas validées par défaut. Les deux commandes sont également indépendantes; valider l'une ne valide pas automatiquement l'autre. ccnp_cch

Exemples de commandes bgp always-compare-med validée ccnp_cch Les exemples dans cette section montrent comment les commandes bgp determinis- tic-med et bgp always-compare-med peuvent influencer la sélection de chemin basée sur MED. Note : Cisco Systems recommande la validation de bgp deterministic-med dans tous les déploiements de nouveaux réseaux. Pour les réseaux existants la commande doit être soit déployée sur tous les routeurs en même temps ou de manière incrémentale avec le soin d'éviter les boucles de routage iBGP( internal BGP). Par exemple, considérons les routes suivantes pour le réseau 10.0.0.0/8 entry1: AS(PATH) 500, med 150, external, rid 172.16.13.1 entry2: AS(PATH) 100, med 200, external, rid 1.1.1.1 entry3: AS(PATH) 500, med 100, internal, rid 172.16.8.4 L'ordre dans lequel Les routes BGP sont reçues est entry3, entry2, entry1. (Entry3 est l'entrée la plus ancienne dans la table BGP et Entry1 est la plus récente) Note : Quand BGP reçoit plusieurs routes pour un même destination, il les liste dans l'ordre inverse de leur réception, de la plus récente vers la plus ancienne. BGP ensuite compare les routes par paires, commençant par l'entrée la plus récente et allant vers la plus ancienne (débute au sommet de la liste et va vers le bas). Par exemple, entry1 et entry2 sont comparées. La meilleure des deux est comparée à entry3 et ainsi de suite. Exemple 1: Les deux commandes sont dévalidées Entry1 et Entry2 sont comparées en premier. Entry 2 est choisie comme la meilleure des deux car elle le Router ID le plus faible. MED n'est pas vérifié car les chemins sont issus de voisins dans des systèmes autonomes différents. Ensuite Enrty 2 est comparée à Entry3. Entry2 est choisie comme le meilleur chemin car c'est une route externe. Exemple 2: bgp deterministic-med dévalidée, bgp always-compare-med validée Entry1 est comparée à Entry2. Ces entrées sont issues de différents systèmes autono- mes voisins mais comme la commande bgp always-compare-med est validée, MED est utilisé dans la comparaison. De ces deux entrées Entry1 est la meilleure car la valeur de MED est plus faible. Ensuite Entry1 est comparée à Entry3. MED est de nouveau vérifié car ces entrées viennent du même système autonome. Entry3 est choisie comme le meilleur chemin. ccnp_cch

bgp always-compare-med dévalidée Exemple 3: bgp deterministic-med validée, bgp always-compare-med dévalidée Quand la commande bgp deterministic-med est validée, les routes issues du même système autonome sont groupées ensemble et les meilleures des entrées de chaque groupe sont comparées. La table BGP ressemble à cela: entry1: AS(PATH) 100, med 200, external, rid 1.1.1.1 entry2: AS(PATH) 500, med 100, internal, rid 172.16.8.4 entry3: AS(PATH) 500, med 150, external, rid 172.16.13.1 Il a un groupe pour l'AS 100 et un groupe pour l'AS 500. Les meilleures entrées de chaque groupe sont comparées. Entry1 est la meilleure de son groupe car c'est la seule route issue de l'AS 100. Entry2 est la meilleure pour l'AS 500 car elle a la va- leur MED la plus faible. Ensuite Entry1 est comparée avec Entry2. Comme les deux entrées sont issues de différents systèmes autonomes voisins, MED n'est pas pris en compte dans la comparaison. La route externe BGP prend le dessus sur la route iBGP faisant de Entry1 la meilleure route. Exemple 4: Les deux commandes sont validées La méthode de comparaison de cet exemple est la même que celle de l'exemple 3, sauf pour pour la dernière comparaison entre Entry2 et Entry1. MED est pris en compte pour la dernière comparaison car la commande bgp always-compare-med est validée. Entry2 est choisie comme meilleur chemin. ccnp_cch