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

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

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 10.5.0.1/16 R4 R1 10.4.0.1/16 R3 ccnp_cch

Exemple Dans ce scénario l'AS 65502 est un client de l'opérateur qui a l'AS 65501. 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 , 10.4.0.0/16 et 10.5.0.0/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 10.4.0.1 255.255.0.0 interface Loopback11 ip address 10.5.0.1 255.255.0.0 interface Serial0/0 ip address 192.168.20.4 255.255.255.0 interface Serial1/0 ip address 192.168.30.4 255.255.255.0 router bgp 65502 no synchronization bgp log−neighbor−changes network 10.4.0.0 mask 255.255.0.0 network 10.5.0.0 mask 255.255.0.0 neighbor 192.168.20.2 remote−as 65501 neighbor 192.168.30.3 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

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

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 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 7 Paths: (2 available, best #1, table Default−IP−Routing−Table) Advertised to non peer−group peers: 1.1.1.1 3.3.3.3 65502 192.168.20.4 from 192.168.20.4 (4.4.4.4) Origin IGP, metric 0, localpref 100, valid, external, best 192.168.30.4 (metric 74) from 3.3.3.3 (3.3.3.3) Origin IGP, metric 0, localpref 100, valid, internal r2# show ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 6 Paths: (2 available, best #2, table Default−IP−Routing−Table) r3# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 8 1.1.1.1 2.2.2.2 192.168.20.4 (metric 74) from 2.2.2.2 (2.2.2.2) 192.168.30.4 from 192.168.30.4 (4.4.4.4) ccnp_cch

r3# show ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 10 Paths: (2 available, best #1, table Default−IP−Routing−Table) Advertised to non peer−group peers: 1.1.1.1 2.2.2.2 65502 192.168.30.4 from 192.168.30.4 (4.4.4.4) Origin IGP, metric 0, localpref 100, valid, external, best 192.168.20.4 (metric 74) from 2.2.2.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal r1# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 11 Not advertised to any peer 192.168.20.4 (metric 128) from 2.2.2.2 (2.2.2.2) Origin IGP, metric 0, localpref 100, valid, internal, best 192.168.30.4 (metric 128) from 3.3.3.3 (3.3.3.3) r1# show ip bgp 10.5.0.1 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 2.2.2.2 et celui de R3 est 3.3.3.3, R2 est préféré. Dans cette configuration de base, tout le trafic vers les deux réseaux dans l'AS 65502 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 65501. 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

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

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 !--- 10.4.0.0/16 et une valeur MED de 100 au réseau 10.5.0.0/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 !--- 10.4.0.0/16 et une valeur MED de 200 au réseau 10.5.0.0/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 10.4.0.0 /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 à 10.5.0.0/16. r1# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 14 Paths: (1 available, best #1, table Default−IP−Routing−Table) Flag: 0x800 Not advertised to any peer 65502 192.168.20.4 (metric 128) from 2.2.2.2 (2.2.2.2) Origin IGP, metric 100, localpref 100, valid, internal, best r1#sh ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 13 192.168.30.4 (metric 128) from 3.3.3.3 (3.3.3.3) ccnp_cch

ccnp_cch Regardons l'affichage pour R2: r2# show ip bgp 10.4.0.1 BGP routing table entry for 10.4.0.0/16, version 10 Paths: (1 available, best #1, table Default−IP−Routing−Table) Advertised to non peer−group peers: 1.1.1.1 3.3.3.3 65502 192.168.20.4 from 192.168.20.4 (4.4.4.4) Origin IGP, metric 100, localpref 100, valid, external, best r2# show ip bgp 10.5.0.1 BGP routing table entry for 10.5.0.0/16, version 11 Paths: (2 available, best #1, table Default−IP−Routing−Table) 192.168.20.4 192.168.30.4 (metric 74) from 3.3.3.3 (3.3.3.3) 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 10.4.0.0/16 c'est parce que R3 retire (transmet une mise à jour avec une métrique inaccessible) la mise à jour pour 10.4.0.0/16 lorsqu'il note que R3 utilise R2 pour accéder à 10.4.0.0/16 (après avoir exécuté l'algorithme de sélection du meilleur chemin sur tous les chemins dis- ponibles. r3# show ip bgp 10.4.0.0 BGP routing table entry for 10.4.0.0/16, version 20 192.168.30.4 192.168.20.4 (metric 74) from 2.2.2.2 (2.2.2.2) 192.168.30.4 from 192.168.30.4 (4.4.4.4) 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 10.4.0.0/16. Cette mise à jour indiquerait à R3 de transmettre une mise à jour avec la route R3 pour 10.4.0.0/ 16 via R4 vers R2. R2 pourrait commencer à router vers R3. ccnp_cch

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

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