Utiliser le discriminateur multi-sortie pour sélectionner le meilleur chemin pour le routeur BGP

Options de téléchargement

PDF (294.1 KB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (102.2 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (111.8 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:26 janvier 2024

ID du document:13759

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Conventions

L'attribut MED

Topologie du réseau

Exemple

La commande bgp deterministic-med

Exemples

Un routeur BGP avec la commande bgp deterministic-med désactivée

Un routeur BGP avec la commande bgp deterministic-med activée

Informations connexes

Introduction

Ce document décrit bgp deterministic-med et explique comment elle affecte la sélection du chemin en fonction du discriminateur de sortie multiple (MED).

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

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 utilisées dans ce document, reportez-vous aux Conventions relatives aux conseils techniques Cisco.

L'attribut MED

MED est un attribut non transitif facultatif. MED est un conseil aux voisins externes au sujet du chemin préféré dans un Autonomous System (AS) qui a des points d'entrée multiples. Le MED est également connu comme le métrique externe d'une route. L'attribut MED ayant la valeur la plus basse est préférée à l'attribut MED ayant la valeur la plus élevée.

Cette section décrit un exemple d'utilisation du MED pour influencer la décision de routage prise par un AS voisin.

Topologie du réseau

Network Topology Topologie du réseau

Exemple

Dans ce scénario, le système autonome 65502 est un utilisateur du FAI qui dispose du système autonome 65501. R4 est connecté à deux routeurs différents côté 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 montrée dans cette section.

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 exec-timeout 0 0 login ! ! end

!
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
 exec-timeout 0 0
 login
!
!
end

R2
! version 12.3 ! 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

!
version 12.3
!
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 de R1 et de R3 sont semblables à R2. R3 a un eBGP homologue à R4 et un iBGP homologue à R1.

R1 a un iBGP homologue à R2 et un iBGP homologue à R3. Observez 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 comme meilleur chemin la route externe à partir de R4 qui est attendue sur la base de l'algorithme de sélection du meilleur chemin BGP. Reportez-vous à l'Algorithme de sélection du meilleur chemin BGP pour plus d'informations.

De même, R1 choisit R2 pour accéder aux 2 réseaux, ce qui est conforme à la règle du meilleur chemin BGP : sélectionnez le chemin avec l'ID de routeur le plus faible. Puisque l'ID du routeur R2 est 10.2.2.2 et l'ID du 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 maintenant que R4 souhaite équilibrer la charge du trafic qu’il reçoit du système autonome 65501. Pour ce faire, sans aucune modification du FAI R4, vous configurez R4 de sorte qu'il utilise MED pour forcer le trafic d'un réseau sur un chemin et le trafic de l'autre réseau sur l'autre chemin.

Voici la configuration de R4 après avoir appliqué la configuration nécessaire :

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.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 MED-R3 is applying a MED of 200 to the 10.4.0.0/16 !--- network and a MED of 100 to the 10.5.0.0/16 network. !--- The route-map is `being` applied outbound towards R3. ! route-map setMED-R2 permit 10 match ip address 1 set metric 100 ! route-map setMED-R2 permit 20 match ip address 2 set metric 200 !--- The route-map MED-R2 is applying a MED of 100 to the 10.4.0.0/16 !--- network and a MED of 200 to the 10.5.0.0/16 network. !--- The route-map is `being` applied outbound towards R2. ! ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 exec-timeout 0 0 login ! ! end

!
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
!
route-map setMED-R3 permit 20
 match ip address 2
 set metric 100

!--- The route-map MED-R3 is applying a MED of 200 to the 10.4.0.0/16 
!--- network and a MED of 100 to the 10.5.0.0/16 network. 
!--- The route-map is being applied outbound towards R3. ! route-map setMED-R2 permit 10 match ip address 1 set metric 100 ! route-map setMED-R2 permit 20 match ip address 2 set metric 200 !--- The route-map MED-R2 is applying a MED of 100 to the 10.4.0.0/16 
!--- network and a MED of 200 to the 10.5.0.0/16 network. 
!--- The route-map is being applied outbound towards R2.  ! ! ! line con 0 exec-timeout 0 0 line aux 0 line vty 0 4 exec-timeout 0 0 login ! ! end

Remarque : vous devez effacer la session BGP avec le clear ip bgp * soft out , par exemple, pour que ces configurations prennent des mesures.

R1 considère maintenant la route passant par R2 comme le meilleur chemin pour le réseau 10.4.0.0/16 parce que la mise à jour reçue de R2 a un MED de 100, contre un MED de 200 pour R3. De même, 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 10.2.2.2 (10.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
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

Observez l'écran de 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

La raison pour laquelle R2 n'affiche qu'un seul chemin pour 10.4.0.0/16 est que R3 retire (envoie une mise à jour avec une métrique inaccessible) la mise à jour pour 10.4.0.0/16 une fois qu'il remarque que R3 utilise R2 pour accéder à 10.4.0.0/16 (après avoir exécuté le meilleur chemin BGP sur tous les chemins disponibles) :

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

Ceci permet à R2 d'économiser de la mémoire puisqu'il ne doit 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 conduirait R3 à envoyer une mise à jour avec la route R3 pour 10.4.0.0/16 par l'intermédiaire de R4 à R2. R2 a pu commencer le routage par l'intermédiaire de R3.

La commande bgp deterministic-med

Si vous activez l' bgp deterministic-med , elle supprime toute dépendance temporelle des décisions de meilleur chemin basées sur MED. Il s'assure qu'une comparaison précise de MED est faite à travers toutes les routes reçues du même Autonomous System (QUE).

Si vous désactivez bgp deterministic-med , l'ordre dans lequel les routes sont reçues peut avoir un impact sur les décisions de meilleur chemin basées sur MED. Ceci peut se produire quand la même route est reçue depuis plusieurs AS ou depuis des sous-AS de confédération, avec exactement la même longueur de chemin mais différents MED.

Exemples

Par exemple, considérez 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 de réception des routes BGP est entry3, entry2 et entry1 (entry3 est l'entrée la plus ancienne dans la table BGP et entry1 est la plus récente).

Un routeur BGP avec la commande bgp deterministic-med désactivée

Un routeur BGP avec bgp deterministic-med disabled choisit entry2 plutôt que entry1, en raison d'une métrique IGP inférieure pour atteindre NEXT_HOP (MED n'a pas été utilisé dans cette décision car entry1 et entry2 proviennent de deux AS différents). Il préfère alors entry3 à entry2 car il est externe. Cependant, entry3 a un MED plus élevé qu'entry1. Pour plus d'informations sur les critères de sélection de chemin BGP, référez-vous à Algorithme de sélection de meilleur chemin BGP .

Un routeur BGP avec la commande bgp deterministic-med activée

Dans ce cas, les routes provenant du même AS sont groupées ensemble et les meilleures entrées de chaque groupe sont comparées. Dans l'exemple donné, il y a deux AS, AS 1 et AS 2.

Group 1:  entry1: ASPATH 1, MED 100, internal, IGP metric to NEXT_HOP 10
          entry3: ASPATH 1, MED 200, external
Group 2:  entry2: ASPATH 2, MED 150, internal, IGP metric to NEXT_HOP 5

Dans le groupe 1, le meilleur chemin est entry1 en raison du MED inférieur (le MED est utilisé dans cette décision puisque les chemins viennent des mêmes AS). Dans le groupe 2, il y a seulement une 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. Lorsque vous activez bgp always-compare-med elle modifie ce comportement par défaut). Maintenant, quand vous comparez entry1 (le gagnant du groupe 1) et entry2 (le gagnant du groupe 2), entry2 peut être le gagnant puisqu'il a la meilleure métrique IGP au saut suivant.

Si bgp always-compare-med a également été activé lorsque vous comparez entry1 (le gagnant du groupe 1) et entry 2 (le gagnant du groupe 2), entry 1 peut être le gagnant en raison d'un MED inférieur.

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 la bgp deterministic-med et la bgp always-compare-med , reportez-vous àComment la commande bgp deterministic-med diffère de la commande bgp always-compare-med.