Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Conventions

L'attribut MED

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

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 du côté de l'ISP pour des raisons de redondance et annonce deux réseaux à l'ISP : 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

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

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 AS 65502 passe de R1 par R2, puis à R4 par défaut. Supposez maintenant que R4 souhaite équilibrer la charge du trafic qu'il reçoit d'AS 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

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.

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 et téléchargements Cisco