Utiliser le discriminateur MultiExit pour influencer la sélection du meilleur chemin BGP
Introduction
Ce document décrit la commande bgp deterministic-med et comment elle affecte la sélection de chemin basée sur le discriminateur multisortie (MED).
Conditions préalables
Exigences
Cisco vous recommande de prendre connaissance des rubriques suivantes :
- Routage IP de base
- Protocole BGP (Border Gateway Protocol)
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Conventions
Pour plus d'informations sur les conventions de documentation Cisco, référez-vous à Conventions relatives aux conseils techniques Cisco.
L'attribut MED
MED est un attribut BGP facultatif non transitif qui fournit un indice aux voisins externes sur le chemin préféré vers un système autonome (AS) avec plusieurs points d'entrée. MED est également connu comme la métrique externe d'une route et une valeur MED inférieure est préférée à une valeur supérieure. Par défaut, BGP compare les valeurs MED uniquement parmi les chemins reçus du même AS voisin.
Remarque : Par défaut, BGP compare les valeurs MED seulement pour les chemins reçus du même AS voisin, à moins que bgp always-compare-med soit configuré. Référez-vous à Comment la commande bgp deterministic-med diffère de la commande bgp always-compare-med pour plus d'informations.
Topologie du réseau
Topologie du réseau
Exemple
Dans ce scénario, le système autonome 65502 est un utilisateur du FAI qui possède le système autonome 65501. R4 est connecté à deux routeurs différents du côté du FAI à des fins de redondance et annonce deux réseaux au FAI : 10.4.0.0/16 et 10.5.0.0/16. Une partie de la configuration appropriée est présentée dans cette section.
| R4 |
|---|
! 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 exec-timeout 0 0 login ! ! end |
| R2 |
|---|
! hostname r2 ! ip cef ! ! interface Loopback0 ip address 10.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 serial restart-delay 0 ! router ospf 1 log-adjacency-changes redistribute connected passive-interface Serial2/0 network 10.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 10.1.1.1 remote-as 65501 neighbor 10.1.1.1 update-source Loopback0 neighbor 10.3.3.3 remote-as 65501 neighbor 10.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 line aux 0 transport preferred all transport output all line vty 0 4 exec-timeout 0 0 login transport preferred all transport input all transport output all ! end |
Les configurations R1 et R3 pertinentes utilisent la même conception que R2. R1, R2 et R3 ont une accessibilité iBGP par le biais d'interfaces de bouclage et le protocole IGP fournit une accessibilité aux sauts suivants BGP. R3 a une session eBGP avec R4 et des sessions iBGP avec R1 et R2.
R1 a un iBGP qui est homologue à R2 et un à R3. Regardez ce que les tables BGP de R1, R2 et R3 affichent 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:
10.1.1.1 10.3.3.3
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.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)
Advertised to non peer-group peers:
10.1.1.1 10.3.3.3
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
r3#show ip bgp 10.4.0.1
BGP routing table entry for 10.4.0.0/16, version 8
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
10.1.1.1 10.2.2.2
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
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:
10.1.1.1 10.2.2.2
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 0, localpref 100, valid, external, best
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.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
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Not advertised to any peer
65502
192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 10
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not advertised to any peer
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 0, localpref 100, valid, internal
65502
192.168.20.4 (metric 128) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 0, localpref 100, valid, internal, best
R2 et R3 choisissent le meilleur chemin en tant que route externe à partir de R4, ce qui est attendu sur la base de l'algorithme de sélection du meilleur chemin BGP. Référez-vous à Algorithme de sélection du meilleur chemin BGP pour plus d'informations.
De même, R1 choisit R2 pour accéder aux deux réseaux parce que les attributs de meilleur chemin BGP antérieurs sont liés, et l'ID de routeur BGP le plus bas est utilisé comme séparateur de temps. R2 a l’ID de routeur 10.2.2.2 et R3 l’ID de routeur 10.3.3.3. Comme l’ID de routeur R2 est 10.2.2.2 et l’ID de routeur R3 est 10.3.3.3, R2 est choisi. Dans cette configuration de base, tout le trafic vers les deux réseaux dans le système autonome 65502 passe de R1 à R2, puis à R4 par défaut. Supposons à présent que R4 souhaite équilibrer la charge du trafic qu’il reçoit du système autonome 65501. Pour ce faire, sans aucune modification du fournisseur de services Internet R4, vous configurez R4 de manière à utiliser le protocole MED pour forcer le trafic d’un réseau sur un chemin et le trafic de l’autre réseau sur l’autre chemin.
Remarque : Notez que l'exemple de configuration MED décrit fournit une ingénierie de trafic par préfixe, et non un véritable équilibrage de charge à coût égal.
Voici la configuration de R4 après avoir appliqué la configuration nécessaire :
| R4 |
|---|
! 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 ! route-map setMED-R3 permit 20 match ip address 2 set metric 100 !--- The route-map setMED-R3 is applying a MED of 200 to the 10.4.0.0/16 |
Remarque : dans cet exemple, seuls 10.4.0.0/16 et 10.5.0.0/16 sont annoncés. Si des préfixes supplémentaires sont annoncés au même voisin, ajoutez-les à la liste d’accès ou à la séquence de route-map appropriée. Ajoutez une séquence d’autorisation finale si des préfixes sans correspondance doivent être annoncés sans être filtrés par la carte de routage sortante.
Après l’application de MED, R2 sélectionne le chemin/la liaison R2-à-R4 comme étant le meilleur pour 10.4.0.0/16, et R3 sélectionne le chemin/la liaison R3-à-R4 comme étant le meilleur pour 10.5.0.0/16. Dans l’état de convergence affiché, R1 reçoit la meilleure annonce iBGP éligible pour chaque préfixe et utilise R2 pour 10.4.0.0/16 et R3 pour 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 10.2.2.2 (10.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
r1#show ip bgp 10.5.0.1
BGP routing table entry for 10.5.0.0/16, version 13
Paths: (1 available, best #1, table Default-IP-Routing-Table)
Flag: 0x800
Not advertised to any peer
65502
192.168.30.4 (metric 128) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 100, localpref 100, valid, internal, best
Reportez-vous à l'exemple suivant pour l'écran 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:
10.1.1.1 10.3.3.3
65502
192.168.20.4 from 192.168.20.4 (10.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)
Advertised to non peer-group peers:
192.168.20.4
65502
192.168.30.4 (metric 74) from 10.3.3.3 (10.3.3.3)
Origin IGP, metric 100, localpref 100, valid, internal, best
65502
192.168.20.4 from 192.168.20.4 (10.4.4.4)
Origin IGP, metric 200, localpref 100, valid, external
R2 affiche un chemin pour 10.4.0.0/16, car R3 n'annonce plus son chemin appris par R4 après que R3 ait sélectionné le meilleur chemin appris par iBGP via R2. R3 retire la mise à jour (envoie un retrait de route BGP, cette mise à jour contient une mesure inaccessible) pour 10.4.0.0/16 une fois qu'il remarque que R3 utilise R2 pour accéder à 10.4.0.0/16. Les règles d'annonce iBGP standard empêchent R3 de signaler le chemin appris par iBGP à un autre homologue iBGP dans cette topologie :
r3#show ip bgp 10.4.0.0
BGP routing table entry for 10.4.0.0/16, version 20
Paths: (2 available, best #1, table Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.30.4
65502
192.168.20.4 (metric 74) from 10.2.2.2 (10.2.2.2)
Origin IGP, metric 100, localpref 100, valid, internal, best
65502
192.168.30.4 from 192.168.30.4 (10.4.4.4)
Origin IGP, metric 200, localpref 100, valid, external
Cela permet à R2 d’enregistrer une partie de la mémoire car il n’a pas à stocker ces informations inutiles. En cas d’échec de la session BGP entre R2 et R4, R2 enverrait une mise à jour inaccessible à R3 pour 10.4.0.0/16. Cette mise à jour déclencherait l’envoi par R3 d’une mise à jour avec la route R3 pour 10.4.0.0/16 via R4 vers R2. R2 peut commencer la route via R3.
La commande MED
Pour activer la comparaison MED déterministe, configurez la commande bgp deterministic-med sous le mode de configuration du routeur BGP. Quand elle est activée, bgp deterministic-med supprime la dépendance temporelle des décisions de meilleur chemin basées sur MED en regroupant les chemins du même AS avant la comparaison. Cela garantit une comparaison précise de MED sur toutes les routes reçues du même système autonome (AS).
Si vous désactivez bgp deterministic-med, l'ordre des routes reçues peut avoir un impact sur les meilleures décisions de chemin basées sur MED. Cela peut se produire lorsque la même route est reçue de plusieurs AS ou sous-AS de confédération, avec exactement la même longueur de chemin, mais des MED différents.
Exemples
Par exemple, considérez les routes suivantes :
| Entrée | Chemin AS | MÉDICAMENT | Préférence locale | Longueur du chemin AS | Origine |
|---|---|---|---|---|---|
| entrée 1 |
AS 65001 |
100 |
100 |
1 |
IGP |
| entrée 2 |
AS 65002 |
50 |
100 |
1 |
IGP |
| entrée 3 |
AS 65001 |
20 |
100 |
1 |
IGP |
Un routeur BGP avec MED désactivé
Exemple de commande d'arrivée 1
L'ordre dans lequel les routes BGP ont été reçues est (entry1 est l'entrée la plus ancienne de la table BGP et entry3 est la plus récente) :
- entrée 1
- entrée 2
- entrée 3
Initialement, une seule route existe, donc entry1 devient le meilleur chemin. Lorsque l'entrée 2 de l'AS65002 est comparée à l'entrée 1 de l'AS65001, MED est ignoré car les routes proviennent de différents AS voisins ; comme tous les attributs restants sont égaux, le routeur conserve le meilleur chemin actuel, entry1.
Lorsque l'entrée 3 de l'AS65001 avec MED 20 est comparée à l'entrée 1 de l'AS65001 avec MED 100, MED est évalué car les deux routes proviennent du même AS voisin. Puisque 20 est inférieur à 100, entry3 devient le meilleur chemin final.
Exemple de commande d'arrivée 2
Supposons maintenant que les mêmes routes arrivent dans un ordre différent :
- entrée 2
- entrée 3
- entrée 1
Initialement, entry2 est sélectionné comme meilleur chemin. Lorsque l'entrée 3 de l'AS65001 est comparée à l'entrée 2 de l'AS65002, MED n'est pas évalué parce que les routes proviennent de différents AS voisins ; comme tous les attributs restants sont égaux, le routeur conserve le meilleur chemin actuel, entry2.
Lorsque l'entrée 1 de l'AS65001 est comparée à l'entrée 2 de l'AS65002, MED est de nouveau ignoré car les routes proviennent de différents AS voisins. Par conséquent, le routeur conserve entry2 comme meilleur chemin final.
Lorsque MED est désactivé, l'ordre d'arrivée des routes influence la séquence de comparaison. Notez que le routeur reçu est exactement le même que les trois routes, mais qu'il a sélectionné différents meilleurs chemins car les routes sont arrivées dans un ordre différent. Il s'agit de la dépendance temporelle que bgp deterministic-med est conçu pour éliminer.
Remarque : Pour plus d'informations sur les critères de sélection de chemin BGP, référez-vous à Algorithme de sélection du meilleur chemin BGP.
Un routeur BGP avec MED activé
Lorsque MED est activé, le routeur commence par regrouper les routes par le système autonome voisin avant de prendre des décisions basées sur MED. Dans ce cas, les routes du même AS sont regroupées et les meilleures entrées de chaque groupe sont comparées. Dans l'exemple donné, il y a deux AS, AS 65001 et AS 65002.
| Groupe | Chemin AS | Entrée | Route sélectionnée | Motif |
|---|---|---|---|---|
| Groupe 1 |
AS 65001 |
entry1 (MED 100), entry3 (MED 20) |
entrée 3 |
MED inférieur (20 < 100) |
| Groupe 2 |
AS 65002 |
entry2 (MED 50) |
entrée 2 |
Seul candidat |
Dans le groupe 1, le meilleur chemin est entry3 en raison du MED inférieur (MED est utilisé dans cette décision car les chemins proviennent du même AS). Dans le groupe 2, il n'y a qu'une seule entrée (entry2). Le meilleur chemin est alors déterminé avec une comparaison des gagnants de chaque groupe, MED n'est pas utilisé dans cette comparaison par défaut parce que les gagnants de chaque groupe sont de différents AS.
À ce stade, MED n'est plus pris en compte, car les routes restantes proviennent de différents AS voisins. L'algorithme de meilleur chemin BGP continue avec les attributs suivants (tels que eBGP vs. iBGP, mesure IGP au saut suivant, chemin le plus ancien, ID de routeur, etc., en fonction des attributs qui diffèrent).
Le principal avantage est que ce processus est indépendant des routes qui ont été reçues. Indique si le routeur apprend les routes comme suit :
- entry1 → entry2 → entry3
- entry2 → entry3 → entry1
- entry3 → entry1 → entry2
Par conséquent, les ordres d'arrivée produisent le même résultat, car la décision est basée sur les attributs de route plutôt que sur l'ordre dans lequel les mises à jour ont été reçues.
Remarque : Si bgp always-compare-med a également été activé lorsque vous comparez entry3 (le gagnant du groupe 1) et entry 2 (le gagnant du groupe 2) ; entrée 3 est le gagnant en raison de MED inférieur.
Remarque : L'activation de la commande bgp deterministic-med assure la comparaison de la variable MED lors du choix des routes annoncées par différents homologues dans le même AS. L'activation de la commande bgp always-compare-med assure la comparaison du MED pour les chemins des voisins dans différents AS.
Cet exemple suppose que tous les attributs BGP de priorité plus élevée (tels que le poids, la préférence locale, la longueur du chemin AS, l'origine et d'autres) sont identiques. L'objectif est d'isoler l'effet de MED et d'illustrer pourquoi la désactivation de bgp deterministic-med peut garantir que la décision du meilleur chemin dépend de l'ordre d'arrivée de la route.
Cisco vous recommande d'activer bgp always-compare-med dans tous les nouveaux déploiements de réseau. En outre, si bgp always-compare-med est activé, les décisions BGP MED sont toujours déterministes.
Pour plus d'informations sur les commandes bgp deterministic-med et bgp always-compare-med, consultez Comment la commande bgp deterministic-med diffère de la commande bgp always-compare-med.
Informations connexes
- Exemple de configuration pour BGP avec deux fournisseurs de services différents (multihébergement)
- Prise en charge IP/BGP
- Études de cas BGP
- Assistance technique de Cisco et téléchargements
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
3.0 |
30-Jul-2026
|
Titre mis à jour, introduction, orthographe, grammaire, insérer des lignes horizontales pour séparer les sections/lisibilité. |
2.0 |
26-Jan-2024
|
Mise à jour SEO et formatage. |
1.0 |
10-Dec-2001
|
Première publication |
Commentaires