Dans cet article, je souhaite vous parler de la fonctionnalité « BGP Best External » utilisée pour améliorer le temps de convergence BGP dans les architectures Actif/Passif

Pour démontrer l’utilité de cette fonctionnalité, on utilisera l’architecture ci-dessous :

Diagram

Description automatically generated

Supposant que vous êtes l’administrateur de l’AS BGP 1 et vous souhaitez utiliser le lien 10G connectant R1 à R4 pour rejoindre tous les services derrière l’AS BGP 2, en l’occurrence le subnet 10.10.10.20/30. En cas de panne sur ce lien, vous souhaiteriez basculer rapidement le trafic ver le lien 1G connectant R2 <==> R4.

Pour répondre à ce besoin, sachant que la valeur Local Pref de 100 est associée par défaut à tous les subnets en provenance de l’AS 2, vous avez opté pour la configuration d’un Local Pref de 200 au niveau du peering R1 <==>R4 comme illustré dans le schéma ci-dessous :

Diagram, schematic

Description automatically generated

La configuration Local Pref R1 :

Text

Description automatically generated

Après cette modification de la Local Pref, vous avez constaté dans la table de routage BGP de R3 qu’il n’y a qu’un seul chemin pour rejoindre le subnet 10.10.10.10/20, celui via R1.

Pourquoi R3 ne voit que le chemin via R1 ?

Par défaut, quand un routeur BGP reçoit plusieurs chemins pour la même destination, il n’envoi que la meilleure route vers ces Peers (Voisins).

Dans notre cas, R2 connait la destination 10.10.10.20/32 via deux chemins :

  • Via la session eBGP avec le routeur R4 ==> Local Pref 100
  • Via la session iBGP avec le routeur R1 ==> Local Pref 200

R2 préfère le chemin via R1 car la route est associée avec une Local Pref plus élevée comparée à celle associée à la route externe en provenance du R4.

Text

Description automatically generated

Par conséquent, R2 n’annonce pas la route vers R3

Text

Description automatically generated

Imaginons pour l’instant que le lien R1<==>R4 est coupé, la séquence suivante va se dérouler :

  1. R1 informe R3 par un message BGP Widthrawal qu’il n’a plus la route vers 10.10.10.20/30 ==> R3 supprime la route de sa table de routage,
  2. R1 informe R2 par un message BGP Widthrawal qu’il n’a plus la route vers 10.10.10.20/30,
  3. À la réception du message Widthrawal, R2 installe immédiatement la route externe via R4 dans sa table RIB,
  4. R2 informe R1 via une mise à jour BGP qu’il connait une route alternative pour rejoindre le 10.10.10.20/30 via sa session BGP avec R4,
  5. R1 R3 installe la route 10.10.10.20/30 via R2 dans sa table de routage,
  6. R2 informe R1 via une mise à jour BGP qu’il connait une route alternative pour rejoindre le 10.10.10.20/30 via sa session BGP avec R4,R1 installe la route 10.10.10.20/30 via R2 dans sa table de routage,
  7. R3 installe la route 10.10.10.20/30 via R2 dans sa table de routage.

Diagram

Description automatically generated

En configurant, le BGP Advertise-Best-External dans la session BGP R2 <==> R4, le routeur R2 annoncera la route BGP externe en provenance du R4 vers R1 et R3

Text

Description automatically generated

Par conséquent R1 et R3 installent cette route dans leurs tables de routage BGP comme route de Backup,

R1 :

R3 :

Maintenant quand le lien reliant R1<>R4 est coupé, la séquence suivante se déroulera :

  1. R1 utilise immédiatement la route de Backup 10.10.10.20 en provenance du R2,
  2. R1 informe R2 que la destination 10.10.10.20/30 n’est plus joignable par son biais par un message Widthrawal
  3. R2 utilise immédiatement la route de Backup 10.10.10.20 en provenance du R2,
  4. R1 informe R3 que la destination 10.10.10.20/30 n’est plus joignable par son biais par un message Widthrawal
  5. R3 utilise immédiatement la route de Backup 10.10.10.20 en provenance du R2.

Diagram

Description automatically generated

Comme vous pouvez le constater, la configuration du BGP Advertise Best-External, permet d’améliorer le temps de convergence BGP et réduire le nombre des messages échangés entre les Peers BGP.

Généralement, pour améliorer le temps de convergence du protocole BGP, il faut comprendre et adapter tous les paramètres qui entrent en jeu lors d’une défaillance du protocole, en l’occurrence :

  • La détection de la panne par le routeur BGP utilisant un protocole de type BFD
  • La propagation de l’information à tous les Peers ==> on a vu dans l’article précèdent comment le paramètre Minimum Time Route Advertisement (MRAI) pourrait accélérer la propagation de l’information vers tous les Peers BGP
  • Le calcul du nouveau chemin==> Le temps de calcul du nouveau chemin est lié à :
    • La taille de la table RIB
    • Le temps nécessaire par le routeur pour analyser la table RIB et calculer les meilleurs chemins ==> Ce process nécessite des ressources CPU mémoire. Un routeur avec des bonnes ressources (CPU/Mémoire) calculera plus rapidement ses meilleurs chemins qu’un routeur avec moins de ressources.
  • L’installation de la nouvelle route dans la table de routage

Si vous avez des questions ou vous avez besoin d’un complément d’informations ou une consultation spécifique à votre environement, n’hésitez pas à laisser un message en commentaire de la page ou nous contacter directement à l’adresse : contact@mhd-experts.com.

Author

Driss JABBAR Un Architect réseaux avec plus de 10 ans d'expérience dans la conception et l'implémentation des architectures complexes LAN/WAN/DC. Pendant son parcours professionnelle, Driss a travaillé chez des intégrateurs et aussi des opérateurs. Driss possède actuellement trois certifications d'expertise Cisco CCIE RS & SP et CCDE. En dehors du travail, Driss consacre plus de temps pour sa famille mais il réserve toujours un petit créneau pour apprendre des nouvelles technologies ou pour regarder un match de foot de son club préféré. Driss est contributeur du blog MHD et joignable à l’adresse : driss.jabbar@mhd-experts.com

2 Comments

  1. Pingback: BGP Shadow Route-Reflector - MHD Experts

  2. ROUIMI Mohamed Reply

    Merci beaucoup de partager cette information qui nous aide à améliorer l’architecture BGP.

Write A Comment