La Métrique De BGP

Maintenant que vous maitrisez le protocole BGP de manière basique, voyons comment fonctionne la métrique.

Nous allons voir que celle-ci est relativement complexe.

Nous verrons dans un premier temps les attributs utilisés par BGP pour calculer la métrique.

Ensuite nous ferons une mise en pratique, dans laquelle nous manipulerons la métrique.

 

1)     Présentation de la métrique

 

Comme dit précédemment, la métrique BGP est relativement complexe.

Là ou OSPF n’utilise qu’un attribut, BGP en utilise plus de 10 !

 

La métrique est en fait une série de Tags appliquées à la route.

Quand un routeur reçoit une route, il regarde tous ces tags (attributs), et en déduit la meilleure route.

 

Certains de ces attributs sont dits « Well-Known ». C’est-à-dire que tous les constructeurs les supportent.

Les autres sont dits « Optional ».

En bref, chaque constructeur utilise sa propre liste d’attributs. Le routeur qui reçoit la MAJ garde ceux qu’il connait.

 

Ensuite, certains attributs sont dits « Mandatory ». C’est-à-dire qu’ils doivent être inclus dans les MAJ.

Les autres sont dits « Discretionary ». Ils ne sont pas forcément envoyés dans les MAJ. Nous verrons des exemples plus tard.

 

Enfin, certains attributs sont dits « Transitive ». Cela veut dire qu’ils peuvent passer d’AS en AS.

Les « Non-Transitive » sont des attributs, qui quand ils sont annoncés, ne sortent pas de l’AS.

 

Ces déférentes catégories peuvent ensuite se cumuler :

• Well-known mandatory
• Well-known discretionary
• Optional transitive
• Etc …

 

Plutôt qu’un long discours, voici la liste de ces attributs.

Quand BGP reçoit deux routes pour la même destination, il utilise cette liste pour comparer les routes.

La liste est parcourus comme une ACL, de haut en bas jusqu’à qu’un attribut permette de différencier les deux routes.

Cette liste est celle utilisée par les routeurs Cisco. Chez d’autres constructeurs, la liste sera différente.

Les attributs les plus importants sont les 7 premiers (jusqu’à MED).

En général, le choix se fait au numéro 4 : AS Path

Comme il n’est pas évident de bien appréhender tous ces attributs, nous allons faire une mise en pratique.

 

2)     La topologie

 

Voici la topologie que nous allons utiliser.

L’AS 100 représente notre entreprise. Nous sommes connectés à deux FAI.

Le but est donc d’exploiter ces deux FAI, de manière à favoriser celui qui offre le meilleur chemin vers la destination.

Pour ce qui est de la configuration basique, voici ce qu’il faut configurer :

• IP des interfaces (ainsi que les Loopback)
• OSPF dans l’AS 100 (entre R1, R2 et R3)
• Relation BGP

Si vous voulez établir les relations BGP sur les IP de Loopback, ne pas oublier de :

• Inclure les Loopback dans OSPF
• Configurer des routes statiques (vers les IP de Loopback) entres les voisins eBGP. Ex : R2 = ip route 4.4.4.4 255.255.255.255 serial 0/2

 

Voici le résumé des configurations (en utilisant les IP de Loopback pour les relations BGP) :

Pour BGP :

R1(config)#do show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback0
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback0
no auto-summary

R2(config)#do show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
neighbor 3.3.3.3 remote-as 100
neighbor 3.3.3.3 update-source Loopback0
neighbor 4.4.4.4 remote-as 400
neighbor 4.4.4.4 ebgp-multihop 2
neighbor 4.4.4.4 update-source Loopback0
no auto-summary

R3(config)#do show run | s bgp
router bgp 100
no synchronization
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 100
neighbor 1.1.1.1 update-source Loopback0
neighbor 1.1.1.1 next-hop-self
neighbor 2.2.2.2 remote-as 100
neighbor 2.2.2.2 update-source Loopback0
neighbor 5.5.5.5 remote-as 500
neighbor 5.5.5.5 ebgp-multihop 2
neighbor 5.5.5.5 update-source Loopback0
no auto-summary

Etc …

 

Pour OSPF :

R1(config)#do show run | s ospf
router ospf 1
router-id 1.1.1.1
log-adjacency-changes
network 1.1.1.1 0.0.0.0 area 0
network 10.1.12.1 0.0.0.0 area 0
network 10.1.13.1 0.0.0.0 area 0

Etc …

 

Pour les routes statiques :

R4(config)#do show run | s ip route
ip route 2.2.2.2 255.255.255.255 Serial0/0
ip route 6.6.6.6 255.255.255.255 Serial0/1

Etc …

3)     Annonce des routes

 

Pour R6 nous allons annoncer les routes grâce à BGP. Pour R7, nous allons redistribuer les routes dans BGP.

 

R6 :

R6(config)#router bgp 600
R6(config-router)#network 6.0.0.0 mask 255.255.255.0
R6(config-router)#network 6.0.1.0 mask 255.255.255.0
R6(config-router)#network 6.0.2.0 mask 255.255.255.0

 

R7 :

R7(config)#router bgp 700
R7(config-router)#redistribute connected

 

Il est important que R3 et R2 annoncent les routes internes :

R1(config-router)#network 10.1.12.0 mask 255.255.255.0
R1(config-router)#network 10.1.13.0 mask 255.255.255.0

 

R2(config-router)#network 10.1.23.0 mask 255.255.255.0

 

Bien entendu, dans la réalité nous n’annoncerons pas les IP privées.

 

Normalement, R1 devrait être capable de joindre R7 :

 

Bien. Nous avons un réseau fonctionnel. BGP assure le routage (basique) entre les réseaux, et nous sommes capables de joindre les deux destinations, à savoir 6.0.0.0 /22 et 7.0.0.0 /22.

De plus, nous sommes joignables.

Nous pourrions nous arrêter ici. Mais le but est de manipuler la métrique BGP.

Nous allons donc revenir sur certains attributs, et voir comment influencer BGP dans son choix de route.

 

4)     Manipulation de la métrique

 

Weight

Le poids est le premier dans la liste des attributs BGP.

Il est propriétaire Cisco.

Le but du poids est de mettre une préférence sur un voisin ou un autre (le plus haut poids gagne).

Par exemple, nous pouvons forcer R1 à préférer R2 comme voisin BGP.

La configuration se fera sur R1. Le poids n’est jamais annoncé, il ne quitte pas le routeur.

 

Un exemple sera plus parlant :

Voici la table BGP de R1. Elle indique toutes les routes apprises par BGP.

Actuellement, R1 préfère passer par R2 pour joindre 6.0.0.0 /24

Et si nous voulons qu’il préfère passer par R3 ?

Voici comment faire :

R1(config)#router bgp 100
R1(config-router)#neighbor 3.3.3.3 weight 50
R1#clear ip bgp *

(Attendre quelques secondes)

A présent, R1 préfère passer par R3.

Bon, l’inconvénient c’est qu’il en sera de même pour toutes les routes.

L’idéal serait de pouvoir favoriser R3 seulement pour certaines routes.

Cela se fait avec une route-map. Nous verrons un exemple plus tard.

 

Avant de passer à la suite, annulez les changements (et remettez à zéro le processus BGP).

Nous voulons juste voir comment modifier les attributs. Libre à vous de cumuler les modifications par après.

 

Local Preference

La Local Preference est un peu comme le poids.

Elle permet de choisir un routeur favori, et de l’annoncer dans l’AS.

Par exemple, nous pouvons favoriser R3 dans l’AS 100.

R1 et R2 préférerons passer par R3.

Par contre, la Local Preference n’est pas annoncée hors de l’AS.

 

Voici l’exemple pour favoriser R3 :

R3(config)#router bgp 100
R3(config-router)#bgp default local-preference 200

 

La Local Preference de base est 100.

Comme prévu, c’est R3 qui est favorisé .

Pourquoi ?

BGP a parcourus la liste des attributs, afin de différencier les routes de R2 et R3.

1 : quelle route a le meilleur poids ? Aucune des deux.

2 : quelle route a la meilleure Local Preference ? Celle venant de R3.

-> R3 sera choisi comme Next Hop.

Encore une fois, cela s’applique à toutes les routes annoncées par R3.

Pour ne favoriser que certaines d’entre-elles, il faudra utiliser une route-map.

 

Annulez les changements avant de passer à la suite

 

Self Originated

Comme vous avez pu le voir dans le tableau, si arrivé à ce point le routeur n’a pas encore pu déterminer quelle route est la meilleure, il va favoriser les routes qu’il a lui-même annoncé (via la commande Network, Aggregate ou Redistribute).

Bien entendu, s’il n’a pas lui-même annoncé de route vers la destination voulue, il passe à l’attribut suivant (le AS-Path).

 

AS-Path

Si arrivé à ce point, BGP a toujours le choix entre deux routes (ou plus), il va favoriser celle passant pas le moins d’AS.

C’est en général ici que ce fait le choix.

Si vous avez bien annulé les modifications, vous devriez pouvoir constater cela sur R1.

Pour joindre 6.0.0.0 /24, R1 préfère le chemin R2 -> R4 -> R6.

Pourquoi ? Car cela implique de passer par 2 AS.

Alors que le chemin R3 -> R5 -> R7 -> R5 implique de passer par 3 AS.

 

Origin

Si l’AS-Path est équivalent entre deux routes, BGP va favoriser les routes avec le type Origin le plus faible.

Voici les trois types :

• IGP : Survient quand la commande « Network » est utilisée
• EGP : La route est annoncée par eBGP
• Incomplete : survient quand la commande « Redistribute » est utilisée

Dans l’ordre, BGP préfère IGP puis EGP puis Incomplete

Le type Origin est visible après l’AS-Path dans la table BGP :

Ici nous pouvons voir la différence entre les routes vers 7.0.0.0 /22 et 6.0.0.0 /22.

En effet, pour annoncer 6.0.0.0 /22, nous avons utilisé la commande Network.

Pour 7.0.0.0 /22 nous avons utilisé la commande Redistribute.

 

MED

Finissons par voir le Multi-Exit-Discriminator, aussi appelé Metric.

Cet attribut permet d’influencer le choix du routeur pour entrer dans l’AS.

Pour cet exemple, nous allons devoir modifier la topologie.

Il faut ajouter un lien entre R4 et R3.

Ensuite, appliquer la configuration pour que ce lien soit fonctionnel.

• Adresse IP
• Route statique (vers 4.4.4.4 pour R3, et vers 3.3.3.3 pour R4)
• Relation BGP

 

Le MED permet de favoriser un routeur pour l’entrée dans l’AS.

Nous allons donc chercher à favoriser R3 pour entrer dans l’AS 100.

 

Actuellement, R4 préfère utiliser R2 (utiliser « show ip bgp » pour voir cela).

 

Par défaut la métrique est de 0.

La métrique la plus faible est la meilleure.

Nous allons donc augmenter celle de R2.

 

Pour cela, deux solutions :

• Utiliser la commande « default-metric »
• Utiliser une Route Map et appliquer une métrique (MED) sur certains réseaux (routes) annoncés

La première solution s’apparente à ce que nous avons vu jusqu’à présent. Appliquer l’attribut à toutes les routes annoncées.

Sauf que cette commande ne permet que de modifier la métrique par défaut. Or certaines routes sont annoncées avec une métrique (donc la métrique par défaut n’aura d’effet).

La métrique (ou MED) dépend de la façon d’annoncer les routes (commande Network, Redistribute, etc…)

 

Nous avions dit tout à l’heure que nous utiliserons une route Map de manière à influencer le routage seulement pour certaines routes.

Par exemple, configurer une Local Preference sur R3, seulement pour les routes vers 7.0.0.0 /22 (et non pas vers 6.0.0.0 /22).

Ou encore, configurer une métrique (MED) de manière à ce que R4 passe par R3 quand il veut joindre 10.1.13.0 /24.

De cette manière, R4 favorisera toujours R2 pour joindre 10.1.12.0 /24.

 

Nous allons donc voir comment mettre en place une Route Map permettant d’agir sur les attributs.

Nous verrons l’exemple pour la MED. Libre à vous de faire le test avec un autre attribut.

 

Première chose à faire, créer une Access List afin d’agir seulement sur le réseau voulu :

R2(config)#access-list 1 permit 10.1.13.0 0.0.0.255

 

Puis nous créons la Route-Map

 

R2(config)#route-map R2_MED
R2(config-route-map)#match ip address 1
R2(config-route-map)#set metric 200

 

Afin que la Route Map ne bloque pas l’annonce des autres réseaux, il faut ajouter une entrée vide.

R2(config)#route-map R2_MED permit 20
R2(config-route-map)#exit

 

Il ne reste plus qu’à appliquer la Route-Map

R2(config)#router bgp 100
R2(config-router)#neighbor 4.4.4.4 route-map R2_MED out

 

Après quelques instants, vous pourrez constater le résultat sur R4.

Plutôt que de choisir R2 comme Next-Hop pour 10.1.13.0 /24, il va choisir R3 :

 

Voici donc comment faire une route Map utile en BGP.

Libre à vous de faire les tests avec d’autres attributs.

Attention, selon le cas la Route Map est à appliquer en entrée ou en sortie.

Ex :

R2(config-router)#neighbor 4.4.4.4 route-map R2_MED out (exemple precedent)
R2(config-router)#neighbor 4.4.4.4 route-map R4_LocalPref IN (appliquer une Local Pref aux routes apprises par R4 qui sont annoncées dans l’AS 100).