Utilice la Función BGP "Peer Lento" para Resolver Problemas de Peer Lento

Introducción

Este documento describe cómo resolver un problema de peer lento con el uso de la función de peer lento BGP (Border Gateway Protocol), que identifica un peer lento en un grupo de actualización BGP y puede mover al peer lento fuera del grupo de actualización de forma permanente o temporal.

Antecedentes

Esta sección proporciona una descripción general de la función de peer lento y el uso de grupos de actualización.

Actualizar grupos

La función de peer lento se utiliza en los grupos de actualización. Un grupo de actualización es un método dinámico que se utiliza para agrupar peers BGP con la misma política de salida. La ventaja de los grupos de actualización es que la política de grupo se utiliza para dar formato a los mensajes una vez, y luego se replican y se transmiten a los otros miembros del grupo. Este método es más eficiente que la necesidad de dar formato a las actualizaciones de BGP para cada peer por separado.

Cuando se implementa este método, si cambia la política saliente, los grupos de peers cambian por grupo de actualizaciones. Los grupos de actualización se forman por familia de direcciones (AF).

Aquí hay un ejemplo de dos peers BGP en diferentes grupos de actualización para la unidifusión IPv4 de AF, pero con el mismo grupo de actualización para la VPNv4 de AF:

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

El grupo de actualización se vuelve más eficiente a medida que aumenta el número de peers BGP que se incluyen en el grupo de actualización. Normalmente, los peers BGP internos (iBGP) tienen la misma política de salida. Para iBGP, un Route Reflector (RR) puede tener muchos peers iBGP; por lo tanto, tendrá grandes grupos de actualización. Los routers de borde del proveedor (PE) pueden tener muchos peers BGP (eBGP) externos hacia los routers de borde del cliente (CE) en un reenvío de routing/virtual (VRF). Los routers PE pueden tener grandes grupos de actualización también para los pares con routers CE en las interfaces VRF.

Problema

Un peer lento es un peer que no puede mantener la velocidad a la que el router genera mensajes de actualización BGP durante un período prolongado de tiempo (en el orden de los minutos) en un grupo de actualización. El motivo de esto pueden ser problemas persistentes de red. Las razones de la red podrían ser la pérdida de paquetes y/o links cargados, o problemas de rendimiento con las sesiones BGP. Además, un peer BGP puede estar fuertemente cargado en términos de CPU y no puede prestar servicio a la conexión TCP a la velocidad requerida.

Los peers lentos afectan la convergencia BGP del grupo de actualización completo. Si un peer BGP es lento, hace que todo el grupo de actualización se ralentice. El resultado es que los otros miembros del grupo de actualización también tendrán una convergencia más lenta. Por esta razón, la cuestión debe resolverse.

Puede identificar el par lento y moverlo fuera del grupo de actualización. Para completar esta tarea, puede cambiar la política saliente para ese peer BGP; sin embargo, se trata de una tarea manual. Primero debe identificar el par que está lento y después moverlo fuera del grupo de actualización. La función de par lento puede hacerlo automáticamente, de modo que no se requiera ninguna intervención del usuario.

Solución

Hay tres partes en la función de peer lento:

• Detección del par lento
  
  
• Movimiento del peer lento a un grupo de actualización lenta
  
  
• Recuperación del peer lento (que devuelve el peer recuperado a su grupo de actualización original)

Estos procesos se describen con más detalle en las siguientes secciones.

Detección

La función de peer lento detecta peers lentos en un grupo de actualización. Cada grupo de actualización tiene una cola de almacenamiento en caché, donde las actualizaciones de BGP formateadas se almacenan temporalmente antes de la transmisión.

A continuación se muestra un ejemplo de tal caché de grupo de actualización:

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

El tamaño de la memoria caché se calcula dinámicamente y depende de:

• El número de pares en el grupo de actualización
  
  
• La memoria del sistema instalada
  
  
• El tipo de pares en el grupo de actualización
  
  
• El tipo de AF

El número de actualizaciones de BGP formateadas que están a la espera de la transmisión se puede generar en un grupo de actualización cuando un par (el lento) no reconoce los mensajes de BGP tan rápido como los otros miembros. Cuando se alcanza el límite de caché, el grupo no tiene más cuota para poner en cola los mensajes nuevos. No se puede formatear ningún mensaje nuevo hasta que se reduzca la caché (hasta que algunos mensajes sean reconocidos por los pares lentos). Esto prohíbe al peer BGP y no le permite enviar nuevos mensajes (actualizaciones o retiros) a los miembros más rápidos del grupo. Por lo tanto, esto ralentiza la convergencia de todos los pares en el grupo de actualización.

Para que la función de peer lento identifique un peer lento, hace referencia a los sellos de tiempo de actualización BGP y a los parámetros TCP de peer.

La detección lenta del par se inhabilita de forma predeterminada. Para habilitar la detección de peer lento, utilice uno de estos métodos:

• Habilite la función para el proceso BGP (se puede configurar desde AF/VRF):
  

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

  Nota: El valor del umbral puede oscilar entre 120 y 3.600 segundos y el valor predeterminado es 300 segundos.

• Habilite la función por par:
  

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

• Habilite la función a través de la plantilla de política de peer:
  

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

Cuando se detecta un peer lento, se imprime un mensaje syslog similar a esto:

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

Puede ingresar estos comandos show para ver los pares lentos:

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

A continuación se muestra un ejemplo de salida del comando show cuando se utiliza la palabra clave slow:

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

Como se muestra en el resultado, el peer 10.1.6.7 es un peer lento para la unidifusión IPv4 AF. Los otros AFs no muestran peers lentos.

Para verificar si el temporizador de detección se ejecuta actualmente y su valor, ingrese este comando:

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       

Como se muestra en el ejemplo de salida, se ha iniciado el temporizador de detección. El temporizador de detección se inicia cuando la memoria caché del grupo de actualización está llena.

En este ejemplo, puede ver que se detecta un peer lento, pero sólo se desplaza del grupo de actualización después de que caduque el temporizador de detección de peer lento:

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

Identificación de Peer Lento

Si la función de detección de peer lento no está habilitada, debe identificar el peer lento manualmente. Primero, verifique la versión de la tabla y la cola de salida de los pares en el grupo de actualización:

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

En este ejemplo, verifique si la versión de tabla (TblVer) de los peers alguna vez se encuentra al día con la versión de tabla BGP principal o si siempre está detrás. Segundo, verifique si hay uno o más peers con valores de cola de salida muy altos. Es probable que estos sean los pares lentos.

Cuando vea el par BGP lento sospechoso, tenga en cuenta estas preguntas (en ambos lados de la sesión BGP):

• ¿Hace cuánto se realizó la última escritura?
  
  
• ¿Están las señales de mantenimiento en el acelerador?
  
  
• ¿La cola de salida es alta?
  
  
• ¿Está el SRTT/RTTO alto?
  
  
• ¿Aumenta el número de retransmisiones?
  
  
• ¿Hay paquetes de retransmisión en cola?
  
  
• ¿Es la ventana de envío TCP muy baja o cero?

Aquí tiene un ejemplo:

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

Movimiento

En esta sección se describe el proceso de movimiento con respecto a la función de peer lento en varios escenarios.

Movimiento sin función de par lento

Un peer lento se puede mover manualmente a un nuevo grupo de actualización sin la función de peer lento.

Antes de que la función de peer lento estuviera disponible, era necesario identificar el peer lento y, a continuación, sacarlo del grupo de actualización manualmente. Esto se completa con un cambio en la política saliente de ese par BGP. Esta política saliente debe ser diferente a cualquier otra que se utilice, ya que debe asegurarse de que el par lento no se desplace a otro grupo de actualización que existe actualmente (y mover el problema a ese grupo de actualización). El mejor cambio que puede aplicar es uno que no afecta a la política real. Por ejemplo, podría cambiar el Intervalo de anuncio de ruta mínima (MRAI) del par (en el AF específico).

Este es un ejemplo que muestra el movimiento manual de un peer lento cuando la función de peer lento no está 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

Movimiento Estático Lento

Para mover un peer de un grupo de actualización a un nuevo grupo de actualización, puede configurarlo como un peer estático lento. Si hay varios pares lentos, los pares lentos estáticos con la misma política saliente se colocan en el mismo grupo de actualización lenta.

Para mover un peer lento estáticamente, puede configurarlo con el uso de estos comandos:

• Habilite el movimiento estático de peers por vecino o por grupo de peers:
  

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

• Habilite el movimiento estático de pares a través de una plantilla de política de peer:
  

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

Movimiento de par lento dinámico

El movimiento lento del par está desactivado de forma predeterminada. Para habilitar el movimiento lento del peer, puede configurarlo a través de uno de estos métodos:

• Habilite el movimiento lento del peer para el proceso BGP:
  

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

  Nota: Esto se puede configurar desde la vista address-family/topology/VRF.

• Habilite el movimiento lento de peers por peer:
  

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

• Habilite el movimiento lento de pares a través de una plantilla de política de peer:
  

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

Nota: La palabra clave permanente indica que el peer lento no se recuperará automáticamente. En este caso, puede mover el peer lento recuperado a su grupo de actualización original a través de uno de los comandos clear.

Los pares lentos estáticos y los pares lentos dinámicos se encuentran en el mismo grupo de actualización de peer lento. En este ejemplo puede ver un par lento en un grupo de actualización lenta:

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

Recuperación

Un peer lento se puede reagrupar bajo su grupo de actualización original (que coincide con la política saliente) una vez que se confirma que ya no es un peer lento (se pone al día). El temporizador de recuperación comienza cuando el grupo de actualización de peer lento ha convergido. Cuando caduca el temporizador de recuperación, el par lento se mueve de nuevo al grupo de actualización regular.

Nota: Para ver el comportamiento relacionado con el temporizador de detección/recuperación, ingrese el comando debug ip bgp updates events.

Cuando un peer lento se mueve de vuelta al grupo de actualización original (esto significa una recuperación), se imprime un mensaje syslog similar a esto:

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

Para verificar si el temporizador de recuperación se ejecuta actualmente y el valor, ingrese este comando:

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

En este ejemplo, el temporizador de recuperación, con un valor de 16 segundos, indica que un peer posiblemente lento podría volver a su grupo de actualización original en 16 segundos.

En este ejemplo, puede ver un peer que se ha recuperado del estado de peer lento:

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

Borrar el estado del par lento

El estado de peer lento se puede borrar manualmente con estos comandos:

• clear ip bgp * slow
  
  
• clear ip bgp AF {unicast|multicast} <AS number> slow
  
  
• clear ip bgp AF {unicast|multicast} peer-group <group-name> slow
  
  
• clear ip bgp <neighbor-address> slow
  
  
• clear bgp AF {unicast|multicast} * slow
  
  
• clear bgp AF {unicast|multicast} <AS number> slow
  
  
• clear bgp AF {unicast|multicast} peer-group <group-name> slow
  
  
• clear bgp AF {unicast|multicast} <neighbor-address> slow

Nota: Cuando utilice estos comandos, reemplace AF por la familia de direcciones real.

Con el uso de estos comandos, el par se mueve de nuevo al grupo de actualización original.

Ingrese el comando show ip bgp internal para ver la detección de peer lento y la configuración de movimiento:

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

Nota: En resumen, el peer lento BGP es una función que detecta un peer lento en un grupo de actualización BGP y permite una convergencia BGP más rápida con el movimiento del peer lento fuera del grupo de actualización.