Comprendre l'importance de l'attribut de chemin de poids BGP

Introduction

Ce document décrit l'importance de l'attribut Weight Path du protocole BGP (Border Gateway Protocol) dans les scénarios de basculement réseau. 

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Protocole BGP (Border Gateway Protocol)
• Redistribution des protocoles de routage
• Routeur Cisco qui exécute Cisco IOS^®

Composants utilisés

Les informations contenues dans ce document sont basées sur un routeur Cisco avec Cisco IOS® version 15.6(2)

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.

Informations générales

Le protocole BGP est généralement utilisé pour annoncer les préfixes réseau au réseau étendu (WAN) une fois qu'ils ont été reçus via un protocole IGP (Interior Gateway Protocol) du réseau local (LAN) et vice versa. Sans la configuration correcte en place, BGP peut échouer à restaurer le chemin de routage d'origine sur le WAN après la récupération du réseau après une défaillance de liaison.

Les routes des routeurs déployés dans des scénarios de basculement peuvent être bloquées, ce qui peut entraîner une redirection du trafic sur le chemin de sauvegarde après une panne et un événement réseau de récupération. Cela peut se produire en raison de la nature de l'attribut de chemin de pondération BGP.

Après une panne réseau (généralement avec la liaison WAN), le réseau peut converger et utiliser le chemin de secours disponible reçu via l'IGP.

Cependant, lors de la récupération du chemin principal, le routeur peut toujours utiliser le chemin de sauvegarde et ne pas restaurer la route d'origine sur la liaison WAN.

Des conséquences telles que des chemins de routage asymétriques et sous-optimaux sont visibles.

Dans les scénarios de redondance avec deux routeurs WAN, ceux-ci peuvent exécuter BGP pour échanger des préfixes réseau avec le WAN. Un protocole IGP comme EIGRP (Enhanced Interior Gateway Routing Protocol) peut être utilisé pour échanger des préfixes réseau avec les périphériques réseau LAN. La redistribution mutuelle entre ces protocoles est généralement nécessaire pour réaliser une connectivité réseau complète. 

Remarque : ce document utilise les termes préfixe et route de manière interchangeable.

La conception de haut niveau de cette topologie est illustrée dans la topologie suivante :

Jeu d'attributs de chemin de pondération BGP dans les routes locales

Le scénario suivant décrit le comportement de l'attribut BGP Weight Path dans les cas de basculement.

Étape 1. La route est reçue via BGP.

Comme l'illustre l'image, le routeur WAN RTR reçoit le réseau 192.168.1.0/24 via BGP.

Avec une distance administrative (AD) de 20, la route est installée dans la table de routage.

Table BGP :

WAN_RTR#show ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.2.2                 0             0 2 i

La table de routage indique la route installée par BGP :

WAN_RTR#show ip route
<snip>
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:42

Étape 2. La route est reçue via EIGRP.

La session BGP s'arrête en raison d'une défaillance de liaison. Par convergence de réseau, la même route 192.168.1.0/24 est désormais reçue via EIGRP.

Le point clé est que le protocole BGP peut annoncer ou redistribuer des routes EIGRP (à l'aide de la configuration suivante du routeur). Si tel est le cas, la route EIGRP est maintenant ajoutée à la table BGP. 

Remarque : l'attribut de chemin de pondération BGP est défini sur 32768 par défaut lorsque le routeur émet localement des préfixes réseau.

Configuration BGP :

WAN_RTR#show running-config | begin router bgp
<snip>
router bgp 1
 redistribute eigrp 1
 neighbor 10.1.2.2 remote-as 2
!

Remarque : la commande BGP network 192.168.1.0 mask 255.255.255.0 peut afficher les mêmes résultats.

Table BGP :

WAN_RTR#show ip bgp
<snip>

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.3.3            156160         32768 ?

La table de routage indique la route installée par le protocole EIGRP :

WAN_RTR#show ip route
<snip>

D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:00:02, FastEthernet0/1
WAN_RTR#

Étape 3. Route reçue à nouveau via BGP.

Avec la route EIGRP maintenant redistribuée dans BGP et après que la route d'origine est reçue via le BGP de nouveau, il y a maintenant 2 entrées pour le réseau 192.168.1.0/24 dans la table BGP.

Table BGP :

WAN_RTR#show ip bgp
<snip>

     Network          Next Hop            Metric LocPrf Weight Path
 *   192.168.1.0      10.1.2.2                 0             0 2 i
 *>                   10.1.3.3            156160         32768 ?

 Dans la table BGP :

 - L'entrée créée à l'étape 2 par la route EIGRP redistribuée dans BGP est toujours visible.

 - La route d'origine est rajoutée au moyen de la session BGP rétablie.

Du point de vue de la sélection du meilleur chemin BGP :

- La valeur de l'attribut de chemin de pondération de la route EIGRP redistribuée dans BGP est définie sur 32768 car elle provient localement du routeur du point de vue BGP.

- La valeur de l'attribut Weight path de la route d'origine reçue via la session BGP avec le WAN est 0.

- La première route a le poids le plus élevé et elle est donc élue comme la meilleure dans la table BGP.

- Cela empêche la table de routage de revenir à l'état d'origine et de conserver l'entrée de route EIGRP.

Remarque : l'attribut BGP Weight Path est le premier attribut de chemin que BGP vérifie lors de la sélection du meilleur chemin dans la table BGP sur les routeurs Cisco IOS. BGP préfère le chemin pour l'entrée avec le poids le plus élevé. Le poids est un paramètre propre à Cisco et n'est significatif que localement dans le routeur où il est configuré. Plus d'informations via l'algorithme BGP Best Path Selection.

Table de routage :

WAN_RTR#show ip route
<snip>
D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:08:55, FastEthernet0/1

Modifier l'attribut de chemin de poids BGP

La valeur par défaut de l'attribut de chemin de pondération BGP peut être modifiée dans l'homologue BGP configuré par l'utilisation de la commande weight ou d'une route-map.

Les commandes suivantes définissent l'attribut Weight path sur 40000 pour toutes les routes reçues de l'homologue BGP.

Exemple 1

router bgp 1
 neighbor 10.1.2.2 weight 40000

Exemple 2

route-map FROM-WAN permit 10
 set weight 40000
!
router bgp 1
 neighbor 10.1.2.2 route-map FROM-WAN in
!
clear ip bgp * soft in

Exemple 3

ip prefix-list NETWORKS permit 192.168.1.0/24
!
route-map FROM-WAN permit 10
 match ip address prefix NETWORKS
 set weight 40000
route-map FROM-WAN permit 100
!
router bgp 1
 neighbor 10.1.2.2 route-map FROM-WAN in
!
clear ip bgp * soft in

Avec la valeur de l'attribut de chemin de pondération augmentée, les routes d'origine reçues via BGP ont priorité comme vu dans le cas suivant :

Étape 1. La route est reçue via BGP.

La table BGP montre que les routes reçues via BGP ont maintenant une valeur de poids de 40000 au lieu de zéro.

Table BGP :

WAN_RTR#show ip bgp
<snip>

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.2.2                 0         40000 2 i

WAN_RTR#

 Table de routage :

WAN_RTR#show ip route
<snip>
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:09:53

Étape 2. La route est reçue via EIGRP.

Les routes d'origine locale ont toujours une valeur de 32768 dans la table BGP.

Table BGP :

WAN_RTR#show ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.3.3            156160         32768 ?

Table de routage :

WAN_RTR#show ip route
<snip>
D     192.168.1.0/24 [90/156160] via 10.1.3.3, 00:01:41, FastEthernet0/1

Étape 3. Route reçue à nouveau via BGP.

Avec Weight 40000, les routes reçues via BGP sont maintenant élues sur les routes d'origine locale. Cela permet au réseau de revenir correctement à son état d’origine.

Table BGP :

WAN_RTR#show ip bgp
<snip>
     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.168.1.0      10.1.2.2                 0         40000 2 i

Table de routage :

WAN_RTR#show ip route
<snip>
B     192.168.1.0/24 [20/0] via 10.1.2.2, 00:00:25

Scénario de cas réel

Prenons comme exemple le scénario suivant :

Étape 1. État d’origine du réseau.

Le commutateur de couche 3 CORE reçoit la route 192.168.1.0/24 via EIGRP à partir des RTR A et B WAN. Le chemin sur le WAN RTR A est sélectionné.

Le résultat suivant montre comment le commutateur CORE maintient une contiguïté EIGRP avec les deux routeurs WAN et que le routeur WAN RTR A est choisi pour atteindre le réseau 192.168.1.0/24.

CORE#show ip eigrp neighbors
EIGRP-IPv4 Neighbors for AS(1)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   10.1.2.2  (WAN_RTR_A)   Fa0/0                    10 00:05:15   79  1066  0  10
1   10.1.3.3  (WAN_RTR_B)   Fa0/1                    12 00:06:22   76   456  0  5


CORE#show ip route
<snip>
D EX  192.168.1.0/24 [170/28416] via 10.1.2.2, 00:00:32, FastEthernet0/0


CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
        via 10.1.2.2 (28416/2816), FastEthernet0/0
        via 10.1.3.3 (281856/2816), FastEthernet0/1

Étape 2. Échec de la liaison WAN principale.

En cas de défaillance d’une liaison, le commutateur CORE installe désormais la route via le deuxième meilleur chemin EIGRP, WAN RTR B.

CORE#show ip route
<snip>
D EX  192.168.1.0/24 [170/281856] via 10.1.3.3, 00:00:05, FastEthernet0/1


CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
        via 10.1.3.3 (281856/2816), FastEthernet0/1

Étape 3. Restauration de la liaison WAN principale.

La liaison WAN principale a été restaurée. Cependant, le commutateur CORE continue à router sur le chemin de sauvegarde comme indiqué dans le résultat suivant :

CORE#show ip route
<snip>
D EX  192.168.1.0/24 [170/281856] via 10.1.3.3, 00:06:09, FastEthernet0/1


CORE#show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(10.10.10.10)
<snip>
P 192.168.1.0/24, 1 successors, FD is 28416, tag is 4
        via 10.1.3.3 (281856/2816), FastEthernet0/1

La raison de ce comportement réside dans l'attribut de chemin de pondération BGP comme cela a été discuté.

Dans l'état actuel, le routeur WAN RTR A affiche la route dans la table de routage via le protocole EIGRP et dans la table BGP redistribuée à partir du protocole EIGRP en raison de la valeur la plus élevée de l'attribut de chemin de pondération qui l'emporte sur la valeur de pondération de la route reçue via le protocole BGP à partir de la liaison WAN rétablie.

WAN_RTR_A#show ip bgp
<snip>
    Network          Next Hop            Metric LocPrf Weight Path
*   192.168.1.0      10.2.4.4                 0             0 4 i
*>                   10.1.2.1            284416         32768 ?


WAN_RTR_A#show ip bgp summary
BGP router identifier 10.20.20.20, local AS number 2
<snip>
Neighbor        V           AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.2.4.4        4            4      12      12       16    0    0 00:03:54   (UP) 4


WAN_RTR_A#show ip route
<snip>
D EX  192.168.1.0/24 [170/284416] via 10.1.2.1, 00:08:22, FastEthernet0/0

Le comportement traité dans ce document a été largement vu sur le terrain. Les topologies de réseau et les symptômes initiaux peuvent différer de l'exemple traité. Cependant, la cause première peut être et est souvent telle que décrite dans ce document. Il est important de vérifier si les configurations et le scénario correspondent aux variables pour que cette condition se produise dans votre déploiement réseau.