Comment les routeurs BGP utilisent l'attribut Multi-Exit-Discriminator

Présentation au sujet: "Comment les routeurs BGP utilisent l'attribut Multi-Exit-Discriminator"— Transcription de la présentation:

1 Comment les routeurs BGP utilisent l'attribut Multi-Exit-Discriminator
pour la sélection du meilleur chemin ccnp_cch

2 Sommaire • Introduction • Prérequis - Composants utilisés
• L'attribut MED Exemple • La commande bgp deterministic-med Exemple ccnp_cch

3 Introduction Ce document illustre l'utilisation de la commande bgp dterministic-med et explique comment elle affecte la sélection du meilleur chemin basée sur l'attribut MED (Multi- Exit-Discriminator). Prérequis Il n'y a pas de prérequis spécifiques pour ce document. Composants utilisés Ce document n'est pas restreint à des versions logicielles ou matérielles spécifiques. L'attribut MED MED est un attribut optionnel non transitif. MED est une indication pour les voisins externes au sujet du chemin préféré dans un système autonome (AS) qui a de multi- ples points d'entrée. MED est également connu comme la métrique externe d'une route. Une faible valeur de MED est toujours préférée à une valeur supérieure. Cette section décrit un exemple qui montre comment utiliser MED pour influencer la décision de routage prise par un AS avoisinant. Topologie: AS 65501 AS 65502 R2 /16 R4 R1 /16 R3 ccnp_cch

4 Exemple Dans ce scénario l'AS est un client de l'opérateur qui a l'AS R4 est con- necté à deux routeurs différents du côté ISP pour des raisons de redondance et annon- ce deux réseaux à l'opérateur , /16 et /16. Une partie de la configu- ration est montrée ci-après. R4 ! version 12.3 hostname r4 ip cef interface Loopback10 ip address interface Loopback11 ip address interface Serial0/0 ip address interface Serial1/0 ip address router bgp 65502 no synchronization bgp log−neighbor−changes network mask network mask neighbor remote−as 65501 neighbor remote−as 65501 no auto−summary ip classless line con 0 exec−timeout 0 0 line aux 0 line vty 0 4 login end ccnp_cch

5 ccnp_cch R2 ! version 12.3 hostname r2 ip cef interface Loopback0
ip address interface Ethernet0/0 ip address interface Serial1/0 ip address serial restart−delay 0 interface Serial2/0 ip address router ospf 1 log−adjacency−changes redistribute connected passive−interface Serial2/0 network area 0 network area 0 network area 0 network area 0 router bgp 65501 no synchronization bgp log−neighbor−changes neighbor remote−as 65501 neighbor update−source Loopback0 neighbor remote−as 65501 neighbor update−source Loopback0 neighbor remote−as 65502 no auto−summary ip classless line con 0 exec−timeout 0 0 transport preferred all transport output all ccnp_cch

6 line aux 0 transport preferred all transport output al line vty 0 4 exec−timeout 0 0 login transport input all transport output all ! end Les configurations de R1 et R3 sont similaires à celle de R2. R3 utilise eBGP pour voi- siner avec R4 et iBGP pour voisiner avec R1. R1 utilise iBGP qui voisine avec R2 et R3. Regardons ce que contiennent les tables BGP de R1, R2 et R3 pour les deux réseaux annoncés par R4. r2# show ip bgp BGP routing table entry for /16, version 7 Paths: (2 available, best #1, table Default−IP−Routing−Table) Advertised to non peer−group peers: 65502 from ( ) Origin IGP, metric 0, localpref 100, valid, external, best (metric 74) from ( ) Origin IGP, metric 0, localpref 100, valid, internal r2# show ip bgp BGP routing table entry for /16, version 6 Paths: (2 available, best #2, table Default−IP−Routing−Table) r3# show ip bgp BGP routing table entry for /16, version 8 (metric 74) from ( ) from ( ) ccnp_cch

7 r3# show ip bgp BGP routing table entry for /16, version 10 Paths: (2 available, best #1, table Default−IP−Routing−Table) Advertised to non peer−group peers: 65502 from ( ) Origin IGP, metric 0, localpref 100, valid, external, best (metric 74) from ( ) Origin IGP, metric 0, localpref 100, valid, internal r1# show ip bgp BGP routing table entry for /16, version 11 Not advertised to any peer (metric 128) from ( ) Origin IGP, metric 0, localpref 100, valid, internal, best (metric 128) from ( ) r1# show ip bgp Paths: (2 available, best #2, table Default−IP−Routing−Table) r1# Comme nous pouvons le voir R2 et R3 prennent comme meilleur chemin la route exter- ne de R4 laquelle est prévisible d'après l'algorithme de sélection du meilleur chemin. De manière similaire, R1 choisit R2 pour accéder aux réseaux, ce qui est en concor- dance avec la règle de sélection du meilleur chemin avec le plus petit routeur ID, tous les autres attributs étant identiques. Comme le routeur ID de R2 est et celui de R3 est , R2 est préféré. Dans cette configuration de base, tout le trafic vers les deux réseaux dans l'AS passe de R1 vers R2 puis vers R4 par défaut. Maintenant supposons que R4 veuille faire de l'équilibrage sur le trafic qu'il reçoit de l'AS Pour faire cela sans demander à l'opérateur de faire un changement de configuration, vous pouvez configurer R4 pour utiliser MED et forcer le trafic pour un réseau vers un chemin et le trafic pour l'autre réseau vers l'autre chemin. ccnp_cch

8 Voici la configuration de R4 après l'application des modifications de configuration.
! version 12.3 hostname r4 ip cef interface Loopback10 ip address interface Loopback11 ip address interface Serial0/0 ip address interface Serial1/0 ip address router bgp 65502 no synchronization bgp log−neighbor−changes network mask network mask neighbor remote−as 65501 neighbor route−map setMED−R2 out neighbor remote−as 65501 neighbor route−map setMED−R3 out no auto−summary ip classless no ip http server access−list 1 permit access−list 2 permit route−map setMED−R3 permit 10 match ip address 1 set metric 200 ccnp_cch

9 route−map setMED−R3 permit 20
match ip address 2 set metric 100 !−−− La route−map MED−R3 applique une valeur MED de 200 au réseau ! /16 et une valeur MED de 100 au réseau /16. !−−− La route−map est appliquée en sortie vers R3. ! route−map setMED−R2 permit 10 match ip address 1 route−map setMED−R2 permit 20 set metric 200 !−−− La route−map MED−R2 applique une valeur MED de 100 au réseau ! /16 et une valeur MED de 200 au réseau /16. !−−− La route−map est appliquée en sortie vers R2. line con 0 exec−timeout 0 0 line aux 0 line vty 0 4 login end Note: Vous devez réinitialiser la session BGP avec la commande clear ip bgp * soft out pour que les modifications de configuration soient prises en compte. R1 voit maintenant la route par R2 comme le meilleur chemin pour le réseau /16 car la mise à jour reçue de R2 a une valeur MED égale à 100 contre une valeur MED égale à 200 annoncée par R3. De manière similaire, R1 utilise R3 et la liaison R3-R4 pour accéder à /16. r1# show ip bgp BGP routing table entry for /16, version 14 Paths: (1 available, best #1, table Default−IP−Routing−Table) Flag: 0x800 Not advertised to any peer 65502 (metric 128) from ( ) Origin IGP, metric 100, localpref 100, valid, internal, best r1#sh ip bgp BGP routing table entry for /16, version 13 (metric 128) from ( ) ccnp_cch

10 ccnp_cch Regardons l'affichage pour R2:
r2# show ip bgp BGP routing table entry for /16, version 10 Paths: (1 available, best #1, table Default−IP−Routing−Table) Advertised to non peer−group peers: 65502 from ( ) Origin IGP, metric 100, localpref 100, valid, external, best r2# show ip bgp BGP routing table entry for /16, version 11 Paths: (2 available, best #1, table Default−IP−Routing−Table) (metric 74) from ( ) Origin IGP, metric 100, localpref 100, valid, internal, best Origin IGP, metric 200, localpref 100, valid, external r2# La raison pour laquelle R2 montre un seul chemin pour /16 c'est parce que R3 retire (transmet une mise à jour avec une métrique inaccessible) la mise à jour pour /16 lorsqu'il note que R3 utilise R2 pour accéder à /16 (après avoir exécuté l'algorithme de sélection du meilleur chemin sur tous les chemins dis- ponibles. r3# show ip bgp BGP routing table entry for /16, version 20 (metric 74) from ( ) from ( ) r3# Ceci permet à R2 d'économiser de la mémoire car il ne doit sauvegarder d'informations inutiles. Dans le cas où la session BGP entre R2 et R4 devient inopérante, R2 trans- mettrait une mise à jour "inaccessible" vers R3 pour le réseau /16. Cette mise à jour indiquerait à R3 de transmettre une mise à jour avec la route R3 pour / 16 via R4 vers R2. R2 pourrait commencer à router vers R3. ccnp_cch

11 La commande bgp deterministic-med La validation de bgp deterministic-med retire toute dépendance temporelle des déci- sions de choix du meilleur chemin basées sur l'attribut MED. Cela assure qu'une com- paraison MED fiable est faite sur toutes les routes reçues du même système autonome (AS). Si vous dévalidez bgp deterministic-med, l'ordre dans lequel les routes sont reçues peut impacter les décisions de choix du meilleur chemin basées sur MED. Ceci peut se produire quand la même route est reçue de plusieurs AS ou confédérations Sub-AS avec exactement la même longueur de chemin mais avec des MEDs différents. Exemples: Par exemple, considérons les routes suivantes: entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10 entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5 entry3: ASPATH 1, MED 200, external L'ordre dans lequel les routes BGP ont été reçues est entry3, entry2 puis entry1 (entry 3 est la plus ancienne dans la table BGP et entry1 est la plus récente). Routeur BGP avec bgp deterministic-med dévalidé Un routeur BGP avec bgp deterministic-med dévalidé choisit entry 2 par rapport à entry 1 à cause de la métrique IGP plus faible pour atteindre le prochain saut ou NEXT_HOP. (MED n'a pas été utilisé pur cette décision car entry1 et entry2 sont issus de deux AS différents). Le routeur préfèrera ensuite entry3 par rapport à entry 2 à cause de la métrique externe. Cependant entry3 a une valeur de MED supérieure à celle de entry1. Routeur BGP avec bgp deterministic-med validé Dans ce cas les routes issues d'un même AS sont groupées séparément et les meilleu- res entrées de chaque groupe sont comparées. Dans cet exemple, il y a deux AS, AS 1 et AS 2. Group 1: entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10 Group 2: entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5 Dans Group1, le meilleur chemin est entry1 à cause de la valeur de MED plus faible (MED est utilisé dans la décision tant que les chemins sont issus du même AS). Dans Group2 il y a une seule entrée (entry2). Le meilleur chemin est ensuite déterminé en comparant le meilleur de chacun des groupes (par défaut Med n'est pas utilisé pour cette comparaison car les meilleurs de chaque groupe sont issus de différents AS. La validation de bgp always-med-compare change ce comportement par défaut). Maintenant, quand on compare entry1 (la meilleur du Group1) et entry2 (la meilleure du Group2), entry2 sera préférée car elle a une meilleure métrique IGP vers le prochain saut. ccnp_cch

12 Si la commande bgp always-med-compare a été validée, alors la comparaison de
entry1 entry1 (la meilleur du Group1) et entry2 (la meilleure du Group2), donnera entry1 car elle a une valeur MED plus faible. Cisco recommande la validation de bgp deterministic-med dans tout nouveau déploie- ment de réseau. De plus, si bgp always-compre-med est validé, les décisions BGP ba- sées sur MED seront toujours déterministes. ccnp_cch