Utilisation de la fonction BGP « Lent Peer » pour résoudre les problèmes de Lent Peer

Introduction

Ce document décrit comment résoudre un problème d'homologue lent avec l'utilisation de la fonctionnalité d'homologue lent BGP (Border Gateway Protocol), qui identifie un homologue lent dans un groupe de mise à jour BGP et peut déplacer l'homologue lent hors du groupe de mise à jour de manière permanente ou temporaire.

Informations générales

Cette section fournit une vue d'ensemble de la fonctionnalité homologue lente et de l'utilisation des groupes de mise à jour.

Mettre à jour les groupes

La fonction de pair lent est utilisée dans les groupes de mise à jour. Un groupe de mises à jour est une méthode dynamique utilisée pour regrouper des homologues BGP avec la même stratégie de sortie. L'avantage des groupes de mise à jour est que la stratégie de groupe est utilisée pour formater les messages une fois, puis ils sont répliqués et transmis aux autres membres du groupe. Cette méthode est plus efficace que la nécessité de formater les mises à jour BGP pour chaque homologue séparément.

Lorsque cette méthode est implémentée, si la stratégie sortante change, les groupes d'homologues changent par groupe de mise à jour. Les groupes de mise à jour sont formés par famille d'adresses (AF).

Voici un exemple de deux homologues BGP dans différents groupes de mise à jour pour la monodiffusion AF IPv4, mais avec le même groupe de mise à jour pour AF VPNv4 :

R2#show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
  Has 1 member (* indicates the members currently being sent updates):
   10.1.3.4
 
BGP version 4 update-group 2, external, Address Family: IPv4 Unicast
  Has 1 member (* indicates the members currently being sent updates):
   10.1.2.3
 
R2#show ip bgp vpnv4 all update-group
BGP version 4 update-group 1, external, Address Family: VPNv4 Unicast
  Has 2 members (* indicates the members currently being sent updates):
   10.1.2.3         10.1.3.4

Le groupe de mises à jour devient plus efficace à mesure que le nombre d'homologues BGP inclus dans le groupe de mises à jour augmente. En règle générale, les homologues BGP internes (iBGP) ont la même stratégie de sortie. Pour iBGP, un réflecteur de route (RR) peut avoir plusieurs homologues iBGP ; il y aura donc de grands groupes de mise à jour. Les routeurs de périphérie du fournisseur (PE) peuvent avoir de nombreux homologues BGP externes vers les routeurs de périphérie du client (CE) dans un VRF (Virtual/Routing Forwarding). Les routeurs PE peuvent également avoir de grands groupes de mise à jour pour les homologues avec des routeurs CE sur les interfaces VRF.

Problème

Un homologue lent est un homologue qui ne peut pas suivre le rythme auquel le routeur génère des messages de mise à jour BGP sur une période prolongée (en ordre de minutes) dans un groupe de mise à jour. Cela peut être dû à des problèmes de réseau persistants. Les raisons du réseau peuvent être la perte de paquets et/ou les liaisons chargées, ou des problèmes de débit avec les sessions BGP. En outre, un homologue BGP peut être lourdement chargé en termes de CPU et ne peut pas traiter la connexion TCP à la vitesse requise.

Les homologues lents affectent la convergence BGP du groupe de mise à jour complet. Si un homologue BGP est lent, cela entraîne le ralentissement de l'ensemble du groupe de mises à jour. En conséquence, les autres membres du groupe de mise à jour auront également une convergence plus lente. Pour cette raison, la question doit être résolue.

Vous pouvez identifier l'homologue lent et le déplacer hors du groupe de mise à jour. Afin d'effectuer cette tâche, vous pouvez modifier la stratégie de sortie pour cet homologue BGP ; cependant, c'est une tâche manuelle. Vous devez d'abord identifier l'homologue qui est lent, puis le déplacer hors du groupe de mise à jour. La fonction homologue lente peut le faire automatiquement, de sorte qu'aucune intervention de l'utilisateur n'est requise.

Solution

La fonction de l'homologue lent comporte trois parties :

• Détection de l'homologue lent
  
  
• Déplacement de l'homologue lent dans un groupe de mise à jour lente
  
  
• Récupération de l'homologue lent (qui redirige l'homologue restauré vers son groupe de mises à jour d'origine)

Ces processus sont décrits plus en détail dans les sections qui suivent.

Détection

La fonctionnalité de pair lent détecte les homologues lents dans un groupe de mise à jour. Chaque groupe de mises à jour a une file d'attente de mise en cache, où les mises à jour BGP formatées sont temporairement stockées avant la transmission.

Voici un exemple de cache de groupe de mise à jour :

R2#show ip bgp replication

                                                                    Current    Next
Index  Members          Leader       MsgFmt    MsgRepl     Csize    Version Version
    1        1        10.1.1.1            0          0    0/100           6/0
    2        3        10.1.2.3            2          6    0/1000          6/0
    3        1        10.1.2.6            3          0    0/100           6/0

La taille du cache est calculée dynamiquement et dépend des éléments suivants :

• Nombre d'homologues dans le groupe de mises à jour
  
  
• La mémoire système installée
  
  
• Type d'homologues dans le groupe de mises à jour
  
  
• Type d'AF

Le nombre de mises à jour BGP formatées qui attendent la transmission peut être généré dans un groupe de mises à jour lorsqu'un homologue (le plus lent) ne reconnaît pas les messages BGP aussi rapidement que les autres membres. Lorsque la limite de cache est atteinte, le groupe n'a plus de quota pour mettre en file d'attente les nouveaux messages. Aucun nouveau message ne peut être formaté tant que le cache n'est pas réduit (jusqu'à ce que certains messages soient reconnus par les homologues lents). Ceci interdit l'homologue BGP et ne lui permet pas d'envoyer de nouveaux messages (mises à jour ou retraits) aux membres les plus rapides du groupe. Par conséquent, cela ralentit la convergence de tous les homologues dans le groupe de mise à jour.

Pour que la fonctionnalité homologue lent identifie un homologue lent, elle fait référence aux horodatages de mise à jour BGP et aux paramètres TCP homologues.

La détection lente des homologues est désactivée par défaut. Afin d'activer la détection lente des homologues, utilisez l'une des méthodes suivantes :

• Activez la fonctionnalité pour le processus BGP (peut être configuré à partir de AF/VRF) :
  

  bgp slow-peer detection [threshold 
         
         
           ] 
          
   
          
  [no] bgp slow-peer detection 
         

  Note: La valeur de seuil peut être comprise entre 120 et 3 600 secondes et la valeur par défaut est 300 secondes.

• Activez la fonctionnalité par homologue :
  

  neighbor {
         
         
           / 
          
            } slow-peer detection [threshold < seconds >] 
           
   
           
  [no] neighbor { 
           
             / 
            
              } slow-peer detection 
             
            
           
         

• Activez la fonctionnalité via le modèle de stratégie homologue :
  

  slow-peer detection [threshold < seconds >]
  
  [no] slow-peer detection

Lorsqu'un homologue lent est détecté, un message syslog similaire à celui-ci est imprimé :

%BGP-5-SLOWPEER_DETECT: Neighbor IPv4 Unicast 10.1.6.7 has been detected
 as a slow peer.

Vous pouvez entrer ces commandes show afin d'afficher les homologues lents :

• show ip bgp summary slow
  
  
• show ip bgp neighbors slow
  
  
• show ip bgp update-group summary slow

Voici un exemple de sortie de commande show lorsque le mot clé slow est utilisé :

R2#show ip bgp update-group summary slow
Summary for  Update-group 1, Address Family IPv4 Unicast
Summary for  Update-group 2, Address Family IPv4 Unicast
Summary for  Update-group 3, Address Family IPv4 Unicast
Summary for  Update-group 4, Address Family IPv4 Unicast
BGP router identifier 10.1.6.2, local AS number 2
BGP table version is 966013, main routing table version 966013
BGP main update table version 966013
50000 network entries using 6050000 bytes of memory
50000 path entries using 2600000 bytes of memory
5001/5000 BGP path/bestpath attribute entries using 700140 bytes of memory
5000 BGP AS-PATH entries using 183632 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 9533772 total bytes of memory
BGP activity 208847/158847 prefixes, 508006/458006 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.6.7        4     7     165   50309        0    0  100 00:10:35        0

Comme le montre le résultat, l'homologue 10.1.6.7 est un homologue lent pour la monodiffusion IPv4 AF. Les autres AF ne montrent aucun homologue lent.

Afin de vérifier si le compteur de détection s'exécute actuellement et sa valeur, entrez cette commande :

R2#show ip bgp update-group
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
  BGP Update version : 116013/0, messages 164 queue 164, not converged
  Private AS number removed from updates to this neighbor
  Update messages formatted 5948, replicated 11589
  Number of NLRIs in the update sent: max 249, min 1
  Minimum time between advertisement runs is 30 seconds
  Slow-peer detection timer (expires in 111 seconds)
  Has 3 members (* indicates the members currently being sent updates):
   10.1.4.5         10.1.5.6         10.1.6.7       

Comme le montre l'exemple de sortie, le compteur de détection a démarré. Le compteur de détection démarre lorsque le cache du groupe de mises à jour est plein.

Dans cet exemple, vous pouvez voir qu'un homologue lent est détecté, mais il ne sort du groupe de mise à jour qu'après l'expiration du compteur de détection d'homologue lent :

R2#show ip bgp update-group
…
BGP version 4 update-group 3, external, Address Family: IPv4 Unicast
  BGP Update version : 516013/566013, messages 357 queue 357, not converged
  Private AS number removed from updates to this neighbor
  Update messages formatted 27044, replicated 53645
  Number of NLRIs in the update sent: max 249, min 0
  Minimum time between advertisement runs is 30 seconds
  Slow-peer detection timer (expires in 20 seconds)
  Has 3 members (* indicates the members currently being sent updates)
   (1 dynamically detected as slow): 

  *10.1.4.5        *10.1.5.6         10.1.6.7

Identification des homologues lente

Si la fonction de détection de l'homologue lent n'est pas activée, vous devez identifier l'homologue lent manuellement. Tout d'abord, vérifiez la version de la table et la file d'attente de sortie des homologues dans le groupe de mises à jour :

R2#show ip bgp update-group 3 summary
Summary for  Update-group 3, Address Family IPv4 Unicast
BGP router identifier 10.1.6.2, local AS number 2
BGP table version is 552583, main routing table version 552583
BGP main update table version 552583
37870 network entries using 4582270 bytes of memory
37870 path entries using 1969240 bytes of memory
5002/3788 BGP path/bestpath attribute entries using 700280 bytes of memory
5001 BGP AS-PATH entries using 183656 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 7435446 total bytes of memory
BGP activity 158847/108847 prefixes, 295876/258006 paths, scan interval 60 secs
Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.1.4.5        4     5      77   26840   516013    0    0 01:07:12        0
10.1.5.6        4     6      69   26833   516013    0    0 01:00:30        0
10.1.6.7        4     7      79   26761   516013    0  194 00:45:42        0

Dans cet exemple, vérifiez si la version de table (TblVer) des homologues rattrape la version de table BGP principale ou si elle est toujours en retard. Ensuite, recherchez un ou plusieurs homologues avec des valeurs de file d'attente de sortie très élevées. Il est probable qu'il s'agit des homologues lents.

Lorsque vous affichez l'homologue BGP lent suspecté, tenez compte des questions suivantes (des deux côtés de la session BGP) :

• Depuis combien de temps la dernière écriture a-t-elle été effectuée ?
  
  
• Les keepalives sont-ils en action ?
  
  
• La file d'attente de sortie est-elle élevée ?
  
  
• Le SRTT/RTTO est-il élevé ?
  
  
• Le nombre de retransmissions augmente-t-il ?
  
  
• Existe-t-il des paquets de retransmission en file d’attente ?
  
  
• La fenêtre d'envoi TCP est-elle très basse ou nulle ?

Voici un exemple :

R2#show ip bgp neighbors 10.1.6.7
BGP neighbor is 10.1.6.7,  remote AS 7, external link
 Member of peer-group group3 for session parameters
  BGP version 4, remote router ID 10.1.6.7
  BGP state = Established, up for 00:56:09
  Last read 00:00:43, last write 00:00:17, hold time is 180, keepalive interval
   is 60 seconds
  Keepalives are temporarily in throttle due to closed TCP window
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast:
     advertised and received
  Message statistics
    InQ depth is 0
    OutQ depth is 0    Partial message pending
                         Sent       Rcvd
    Opens:                  5          4
    Notifications:          0          0
    Updates:            29004          0
    Keepalives:             0       1426
    Route Refresh:          0          0
    Total:              30336       1431
  Default minimum time between advertisement runs is 30 seconds
For address family: IPv4 Unicast
  BGP table version 250001, neighbor version 200001/250001
  Output queue size : 410
  Index 3, Offset 0, Mask 0x8
  3 update-group member
  group3 peer-group member
  Inbound soft reconfiguration allowed
  Private AS number removed from updates to this neighbor
  Inbound path policy configured
  Route map for incoming advertisements is eBGP-in
                                 Sent       Rcvd
  Prefix activity:               ----       ----
    Prefixes Current:            2596          0
    Prefixes Total:            102624          0
    Implicit Withdraw:             28          0
    Explicit Withdraw:         100000          0
    Used as bestpath:             n/a          0
    Used as multipath:            n/a          0
                                   Outbound    Inbound
  Local Policy Denied Prefixes:    --------    -------
    Total:                                0          0
  Maximum prefixes allowed 20000
  Threshold for warning message 80%, restart interval 300 min
  Number of NLRIs in the update sent: max 249, min 0
  Last detected as dynamic slow peer: never
 Dynamic slow peer recovered: never
  Oldest update message was formatted: 00:02:24
  Address tracking is enabled, the RIB does have a route to 10.1.6.7
  Connections established 4; dropped 3
  Last reset 00:57:39, due to User reset
  Transport(tcp) path-mtu-discovery is enabled
Connection state is ESTAB, I/O status: 1, unread input bytes: 0       
Connection is ECN Disabled
Mininum incoming TTL 0, Outgoing TTL 1
Local host: 10.1.6.2, Local port: 20298
Foreign host: 10.1.6.7, Foreign port: 179
Connection tableid (VRF): 0
 
Enqueued packets for retransmit: 15, input: 0  mis-ordered: 0 (0 bytes)
Event Timers (current time is 0x4A63D14):
Timer          Starts    Wakeups            Next
Retrans           697         29       0x4A6590C
TimeWait            0          0             0x0
AckHold            64         63             0x0
SendWnd             0          0             0x0
KeepAlive           0          0             0x0
GiveUp              0          0             0x0
PmtuAger          128        127       0x4A64CB7
DeadWait            0          0             0x0
Linger              0          0             0x0
 
iss:  130287252  snduna:  131516888  sndnxt:  131532233     sndwnd:  16384
irs: 1184181084  rcvnxt: 1184182346  rcvwnd:      15123  delrcvwnd:   1261
 
SRTT: 20122 ms, RTTO: 20440 ms, RTV: 318 ms, KRTT: 0 ms
minRTT: 20028 ms, maxRTT: 20796 ms, ACK hold: 200 ms
Status Flags: none
Option Flags: nagle, path mtu capable, higher precendence
 
Datagrams (max data segment is 1460 bytes):
Rcvd: 922 (out of order: 0), with data: 65, total data bytes: 1261
Sent: 1463 (retransmit: 29 fastretransmit: 1),with data: 1391, total
 data bytes: 1245129

Mouvement

Cette section décrit le processus de déplacement en ce qui concerne la fonctionnalité homologue lente dans différents scénarios.

Mouvement sans fonction d'homologue lente

Un homologue lent peut être déplacé manuellement dans un nouveau groupe de mise à jour sans la fonctionnalité homologue lent.

Avant que la fonctionnalité d'homologue lent ne soit disponible, vous deviez identifier l'homologue lent, puis le déplacer manuellement hors du groupe de mise à jour. Ceci est complété par une modification de la stratégie de sortie de cet homologue BGP. Cette stratégie de sortie doit être différente de toute autre stratégie utilisée, car vous devez vous assurer que l'homologue lent ne se déplace pas vers un autre groupe de mise à jour qui existe actuellement (et déplacer le problème vers ce groupe de mise à jour). Le meilleur changement que vous pouvez appliquer est celui qui n'affecte pas la stratégie réelle. Par exemple, vous pouvez modifier l'intervalle d'annonce de route minimum (MRAI) de l'homologue (sous la AF spécifique).

Voici un exemple qui montre le déplacement manuel d'un homologue lent lorsque la fonctionnalité homologue lent n'est pas disponible :

RR1#debug ip bgp groups 
BGP groups debugging is on

RR1(config)#router bgp 1                                    
RR1(config-router)#address-family vpnv4                           
RR1(config-router-af)#neighbor 10.100.1.3 advertisement-interval 3 
 
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
 mismatch
BGP(4): Scheduling withdraws and update-group membership change for 10.100.1.3
BGP(4): Resetting 10.100.1.3's version for its transition out of update-group 1
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
 mismatch
BGP-DYN(4): Removing 10.100.1.3 from update-group 1
BGP-DYN(4): 10.100.1.3 cannot join update-group 1 due to an advertisement-interval
 mismatch
BGP-DYN(4): Created update-group 0 from neighbor 10.100.1.3
BGP-DYN(4): Adding 10.100.1.3 to update-group 0

Mouvement d'homologue lent statique

Afin de déplacer un homologue d'un groupe de mise à jour vers un nouveau groupe de mise à jour, vous pouvez le configurer en tant qu'homologue statique lent. S'il y a plusieurs homologues lents, les homologues lents statiques avec la même stratégie de sortie sont placés dans le même groupe de mise à jour lente.

Afin de déplacer un homologue lent de manière statique, vous pouvez le configurer à l'aide des commandes suivantes :

• Activez le déplacement statique des homologues par voisin ou par groupe d'homologues :
  

  [no] neighbor {
         
         
           / 
          
            } slow-peer split-update-group static 
           
         

• Activer le déplacement statique des homologues via un modèle de stratégie d'homologue :
  

  [no] slow-peer split-update-group static

Mouvement d'homologue lent dynamique

Par défaut, le déplacement lent des homologues est désactivé. Afin d'activer le mouvement homologue lent, vous pouvez le configurer via l'une des méthodes suivantes :

• Activez le déplacement lent des homologues pour le processus BGP :
  

  bgp slow-peer split-update-group dynamic [permanent]
  
  [no] bgp slow-peer split-update-group dynamic

  Note: Ceci peut être configuré à partir de la vue famille d'adresses/topologie/VRF.

• Activer le déplacement lent des homologues par homologue :
  

  neighbor {
         
         
           / 
          
            } slow-peer split-update-group dynamic [permanent] 
           
   
           
  [no] neighbor { 
           
             / 
            
              } slow-peer split-update-group dynamic 
             
            
           
         

• Activer le déplacement lent des homologues via un modèle de stratégie d'homologue :
  

  slow-peer split-update-group dynamic [permanent]
  
  [no] slow-peer split-update-group dynamic

Note: Le mot clé permanent indique que l'homologue lent ne se rétablira pas automatiquement. Dans ce cas, vous pouvez déplacer le pair lent récupéré vers son groupe de mise à jour d'origine via l'une des commandes clear.

Les homologues statiques lents et les homologues dynamiques lents font partie du même groupe de mise à jour des homologues lents. Dans cet exemple, vous pouvez voir un homologue lent dans un groupe de mise à jour lente :

R2#show ip bgp update-group
…
BGP version 4 update-group 4, external, Address Family: IPv4 Unicast
  BGP Update version : 0/566013, messages 100 queue 100, not converged
  Slow update group
  Private AS number removed from updates to this neighbor
  Update messages formatted 2497, replicated 0
  Number of NLRIs in the update sent: max 10, min 1
  Minimum time between advertisement runs is 30 seconds
  Has 1 member (* indicates the members currently being sent updates)
   (1 dynamically detected as slow):
  *10.1.6.7

Récupération

Un homologue lent peut être regroupé dans son groupe de mise à jour d'origine (qui correspond à la stratégie sortante) une fois qu'il a été confirmé qu'il n'est plus un homologue lent (il rattrape). Le compteur de récupération commence lorsque le groupe de mise à jour des homologues lente a convergé. À l'expiration du compteur de récupération, le pair lent est redirigé vers le groupe de mises à jour régulières.

Note: Afin de voir le comportement associé au compteur de détection/récupération, entrez la commande debug ip bgp update events.

Lorsqu'un homologue lent est renvoyé au groupe de mise à jour d'origine (ce qui signifie une récupération), un message syslog similaire à celui-ci est imprimé :

%BGP-5-SLOWPEER_RECOVER: Slow peer IPv4 Unicast 10.1.6.7 has recovered.

Afin de vérifier si le compteur de récupération s'exécute actuellement et la valeur, entrez cette commande :

R2#show ip bgp update-group
BGP version 4 update-group 1, external, Address Family: IPv4 Unicast
  BGP Update version : 165973/0, messages 0 queue 0, converged
  Route map for outgoing advertisements is dummy
  Update messages formatted 0, replicated 0
  Number of NLRIs in the update sent: max 0, min 0
  Minimum time between advertisement runs is 30 seconds
  Slow-peer recovery timer (expires in 16 seconds)
  Has 1 member (* indicates the members currently being sent updates):
   10.1.1.1

Dans cet exemple, le compteur de récupération, avec une valeur de 16 secondes, indique qu'un homologue potentiellement lent peut revenir à son groupe de mises à jour d'origine en 16 secondes.

Dans cet exemple, vous pouvez voir un homologue qui s'est rétabli de l'état homologue lent :

R2#show ip bgp neighbor 10.1.6.7 

BGP neighbor is 10.1.6.7,  remote AS 7, external link
 Member of peer-group group3 for session parameters
  BGP version 4, remote router ID 10.1.6.7
…
 3 update-group member
  group3 peer-group member
…
 Number of NLRIs in the update sent: max 249, min 0
  Last detected as dynamic slow peer: 00:12:49
  Dynamic slow peer recovered: 00:01:57
  Oldest update message was formatted: 00:00:55

Effacer l'état de l'homologue lent

L'état de l'homologue lent peut être effacé manuellement à l'aide des commandes suivantes :

• clear ip bgp * slow
  
  
• clear ip bgp AF {unicast|multicast} <numéro AS> lent
  
  
• clear ip bgp AF {unicast|multicast} peer-group <nom-groupe> slow
  
  
• clear ip bgp <adresse-voisine> slow
  
  
• clear bgp AF {unicast|multicast} * slow
  
  
• clear bgp AF {unicast|multicast} <numéro AS> slow
  
  
• clear bgp AF {unicast|multicast} peer-group <nom-groupe> slow
  
  
• clear bgp AF {unicast|multicast} <neighbor-address> slow

Note: Lorsque vous utilisez ces commandes, remplacez AF par la famille d'adresses réelle.

Avec l'utilisation de ces commandes, l'homologue est redirigé vers le groupe de mise à jour d'origine.

Entrez la commande show ip bgp internal afin d'afficher les paramètres de détection et de déplacement des homologues lents :

R2#show ip bgp internal
Time left for bestpath timer: 593 secs
Address-family IPv4 Unicast, Mode : RW
    Table Versions : Current 622091, RIB 622091
    Start time : 00:00:01.168    Time elapsed 01:21:56.740
    First Peer up in : 00:00:07    Exited Read-Only in : 00:02:16
    Done with Install in : 00:02:26    Last Update-done in : never
    0 updates expanded
    Attribute list queue size: 0
    Slow-peer detection is enabled  Threshold is 300 seconds
    Slow-peer split-update-group dynamic is enabled
    BGP Nexthop scan:-
        penalty: 0, Time since last run: never,  Next due in: none
        Max runtime : 0 ms Latest runtime : 0 ms Scan count: 0
    BGP General Scan:-
        Max runtime : 14572 ms Latest runtime : 14572 ms Scan count: 78
    BGP future scanner version: 79
    BGP scanner version: 0

Note: En résumé, l'homologue lent BGP est une fonctionnalité qui détecte un homologue lent dans un groupe de mise à jour BGP et permet une convergence BGP plus rapide avec le déplacement de l'homologue lent hors du groupe de mise à jour.