IP : Protocolo de puerta de enlace fronteriza (BGP)

Utilice la característica del “par lento” BGP para resolver los problemas lentos del par

18 Junio 2016 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (21 Abril 2016) | Comentarios

Introducción

Este documento describe cómo resolver un problema lento del par con el uso de la característica lenta del par del Border Gateway Protocol (BGP), que identifica a un par lento en un grupo de la actualización de BGP y puede mover el grupo lento de la actualización de los del par permanentemente o temporalmente.

Contribuido por Lucas De Ghein, ingeniero de Cisco TAC.

Antecedentes

Esta sección proporciona una descripción de la característica lenta del par y el uso de los grupos de la actualización.

Grupos de la actualización

La característica lenta del par se utiliza en los grupos de la actualización. Un grupo de la actualización es un método dinámico que se utiliza para agrupar a los peeres BGP con la misma política de salida. La ventaja de los grupos de la actualización es que la directiva del grupo está utilizada para formatar los mensajes una vez, y después los replican y se transmiten a los otros miembros del grupo. Este método es más eficiente que la necesidad de formatar las actualizaciones de BGP para cada par por separado.

Cuando se implementa este método, si los cambios de políticas de salida, los grupos de peer cambian por el grupo de la actualización. Los grupos de la actualización se forman por la familia del direccionamiento (AF).

Aquí está un ejemplo de dos peeres BGP en diversos grupos de la actualización para el unicast del IPv4 AF, pero con el mismo grupo de la actualización para el VPNv4 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 la actualización llega a ser más eficiente como los peeres BGP del número que se incluyen en los aumentos del grupo de la actualización. Típicamente, los pares del Internal BGP (iBGP) tienen la misma política de salida. Para el iBGP, un reflector de ruta (RR) puede tener muchos pares del iBGP; así, tendrá grupos grandes de la actualización. El Routers del borde del proveedor (PE) puede tener muchos pares del BGP externo (eBGP) hacia el Routers de la frontera del cliente (CE) en uno virtual/la expedición de la encaminamiento (VRF). El Routers PE puede tener grupos grandes de la actualización también para los peeringes con el Routers CE en las interfaces VRF.

Problema

Un par lento es un par que no puede continuar con la tarifa en la cual el router genera los mensajes de la actualización de BGP durante un período de tiempo prolongado (en la orden de los minutos) en un grupo de la actualización. La razón de esto puede ser problemas de red persistentes. Las razones de la red podrían ser pérdida del paquete y/o links cargados, o la producción publica con las sesiones de BGP. También, un peer BGP pudo ser cargado pesadamente en términos de CPU y no puede mantener la conexión TCP en la velocidad requerida.

Los pares lentos afectan a la convergencia BGP del grupo completo de la actualización. Si un peer BGP es lento, hace el grupo entero de la actualización retrasar. El resultado es que los otros miembros del grupo de la actualización tendrán convergencia más lenta también. Por este motivo, el problema debe ser resuelto.

Usted puede identificar al par lento y moverlo grupo de la actualización de los. Para completar esta tarea, usted puede cambiar la política de salida para ese peer BGP; sin embargo, esto es una tarea manual. Usted debe primero identificar al par que es lento, y en seguida moverlo grupo de la actualización de los. La característica lenta del par puede hacer esto automáticamente, para no requerir ninguna intervención del usuario.

Solución

Hay tres porciones a la característica lenta del par:

  • Detección del par lento

  • Movimiento del par lento en un grupo lento de la actualización

  • Recuperación del par lento (que mueve al par recuperado de nuevo a su grupo original de la actualización)

Estos procesos se describen en el detalle adicional en las secciones que siguen.

Detección

La característica lenta del par detecta a los pares lentos en un grupo de la actualización. Cada grupo de la actualización tiene una cola de almacenamiento en memoria inmediata, donde las actualizaciones de BGP formatadas se salvan temporalmente antes de la transmisión.

Aquí está un ejemplo de tal caché del grupo de la 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 del caché se calcula y depende dinámicamente encendido:

  • El número de pares en el grupo de la actualización

  • Memoria del sistema instalada

  • El tipo de pares en el grupo de la actualización

  • El tipo de AF

El número de actualizaciones de BGP formatadas que aguarden la transmisión puede construir en un grupo de la actualización cuando un par (el lento) no reconoce los mensajes BGP tan rápidamente como los otros miembros. Cuando se alcanza el límite del caché, el grupo no tiene más cuota para hacer cola los nuevos mensajes. Ningunos nuevos mensajes pueden ser formatados hasta que se reduzca el caché (hasta que algunos mensajes son reconocidos por los pares lentos). Esto prohíbe al peer BGP y no permite que envíe los nuevos mensajes (las actualizaciones o se retiran) a los miembros más rápidos del grupo. Por lo tanto, esto retrasa la convergencia de todos los pares en el grupo de la actualización.

Para que la característica lenta del par identifique a un par lento, refiere a los parámetros TCP de los grupos fecha/hora y del par de la actualización de BGP.

La detección lenta del par se inhabilita por abandono. Para habilitar la detección lenta del par, utilice uno de estos métodos:

  • Habilite la característica para el proceso BGP (puede ser configurado de AF/VRF):
    bgp slow-peer detection [threshold <seconds>]

    [no] bgp slow-peer detection

    Nota: El valor de umbral puede extenderse entre 120 y 3,600 segundos, y el valor predeterminado es 300 segundos.

  • Habilite la característica por el par:
    neighbor {<nbr-addr>/<peer-grp-name>} slow-peer detection [threshold < seconds >]

    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer detection
  • Habilite la característica vía la plantilla de política del par:
    slow-peer detection [threshold < seconds >]

    [no] slow-peer detection

Cuando detectan a un par lento, un mensaje de Syslog similar a esto se imprime:

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

Usted puede ingresar estos comandos show para ver a los pares lentos:

  • muestre el resumen BGP del IP lento

  • muestre a los vecinos BGP del IP lentos

  • muestre el resumen del actualización-grupo BGP del IP lento

Aquí está una salida del comando show del ejemplo cuando se utiliza la palabra clave lenta:

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

Tal y como se muestra en de la salida, el par 10.1.6.7 es un par lento para el unicast del IPv4 AF. Los otros AF no muestran a ninguna pares lenta.

Para verificar si de la detección del temporizador los funcionamientos actualmente y su valor, ingresen 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       

Tal y como se muestra en de la salida de ejemplo, el temporizador de la detección ha comenzado. El temporizador de la detección comienza cuando el caché del grupo de la actualización es lleno.

En este ejemplo, usted puede ver que detectan a un par lento, pero mueve solamente el grupo de la actualización de los después de que expire el temporizador lento de la detección del par:

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 lenta del par

Si la característica lenta de la detección del par no se habilita, después usted debe identificar al par lento manualmente. Primero, marque la versión de tabla y la cola de salida de los pares en el grupo de la 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 pares alcance nunca la versión principal de la tabla BGP o si está siempre detrás. En segundo lugar, comprobación para uno o más pares con los valores de la cola muy de alto rendimiento. Es probable que éstos sean los pares lentos.

Cuando usted ve al peer BGP lento sospechoso, considere estas preguntas (a ambos lados de la sesión de BGP):

  • ¿Cuánto tiempo hace era el último escribe realizado?

  • ¿Está el Keepalives en la válvula reguladora?

  • ¿Es la cola de salida alta?

  • ¿Es el SRTT/RTTO alto?

  • ¿Hace el número de retransmite aumentaron?

  • ¿Hay cualquier hecho cola retransmite los paquetes?

  • ¿Es el TCP envía la ventana muy bajo o la pone a 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&colon; 65, total data bytes: 1261
Sent: 1463 (retransmit: 29 fastretransmit: 1),with data&colon; 1391, total
data bytes: 1245129

Movimiento

Esta sección describe el proceso del movimiento con respecto a la característica lenta del par en los diversos escenarios.

Movimiento sin la característica lenta del par

Un par lento puede ser trasladado manualmente a un nuevo grupo de la actualización sin la característica lenta del par.

Antes de que la característica lenta del par estuviera disponible, le requirieron identificar al par lento y después moverlo grupo de la actualización de los manualmente. Esto se completa con un cambio a la política de salida de ese peer BGP. Esta política de salida debe ser diferente que cualquier otra se utilice que, como usted debe asegurarse de que el par lento no se traslade a otro grupo de la actualización que exista actualmente (y mueva el problema a ese grupo de la actualización). El mejor cambio que usted puede aplicar es uno que no afecta a la directiva real. Por ejemplo, usted podría cambiar el intervalo mínimo del anuncio de ruteo (MRAI) del par (bajo el AF específico).

Aquí está un ejemplo que muestra el movimiento manual de un par lento cuando la característica lenta del par 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 lento estático del par

Para trasladarse a un par desde un grupo de la actualización a un nuevo grupo de la actualización, usted puede configurarlo como par lento estático. Si hay pares lentos múltiples, después colocan a los pares lentos estáticos con la misma política de salida en el mismo grupo lento de la actualización.

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

  • Habilite el movimiento del peer estático por el vecino o por el grupo de peers:
    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group static
  • Habilite el movimiento del peer estático vía una plantilla de política del par:
    [no] slow-peer split-update-group static

Movimiento lento dinámico del par

El movimiento lento del par se inhabilita por abandono. Para habilitar el movimiento lento del par, usted puede configurarlo vía uno de estos métodos:

  • Movimiento lento del par del permiso 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 de la opinión de la direccionamiento-familia/topology/VRF.

  • Movimiento lento del par del permiso por el par:
    neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group dynamic [permanent]

    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group dynamic
  • Habilite el movimiento lento del par vía una plantilla de política del par:
    slow-peer split-update-group dynamic [permanent]

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

Nota: La palabra clave permanente indica que el par lento no se recuperará automáticamente. En este caso, usted puede mover al par lento recuperado de nuevo a su grupo original de la actualización vía uno de los comandos clear.

Los pares lentos estáticos y los pares lentos dinámicos están en el mismo grupo lento de la actualización del par. En este ejemplo usted puede ver a un par lento en un grupo lento de la actualización:

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 par lento puede ser reagrupado bajo su grupo original de la actualización (ese hace juego la política de salida) una vez que se confirma que es no más un par lento (alcanza). El temporizador de recuperación comienza cuando ha convergido el grupo lento de la actualización del par. Cuando expira el temporizador de recuperación, mueven al par lento de nuevo al grupo de la actualización normal.

Nota: Para ver el comportamiento que se relaciona con la detección/el temporizador de recuperación, ingrese el comando de los eventos del debug ip bgp updates.

Cuando mueven a un par lento de nuevo al grupo original de la actualización (éste significa una recuperación), un mensaje de Syslog similar a esto se imprime:

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

Para verificar si del temporizador de recuperación los funcionamientos actualmente y el valor, ingresen 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 par posiblemente lento pudo moverse de nuevo a su grupo original de la actualización en 16 segundos.

En este ejemplo, usted puede ver a un par 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

Borre el estado de peer lento

El estado de peer lento puede ser borrado manualmente con estos comandos:

  • clear ip bgp * lento

  • borre BGP AF {unicast del IP|number> del Multicast} <AS lento

  • borre BGP AF {unicast del IP|grupo de peers del Multicast} <group-name> lento

  • borre el <neighbor-address> BGP del IP lento

  • borre BGP AF {unicast|Multicast} * redúzcase

  • borre BGP AF {unicast|number> del Multicast} <AS lento

  • borre BGP AF {unicast|grupo de peers del Multicast} <group-name> lento

  • borre BGP AF {unicast|<neighbor-address> del Multicast} lento

Nota: Cuando usted utiliza estos comandos, substituya el AF por la familia de la dirección real.

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

Ingrese el comando internal BGP del IP de la demostración para ver las configuraciones lentas de la detección y del movimiento del par:

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 par lento BGP es una característica que detecta a un par lento en un grupo de la actualización de BGP y permite una convergencia BGP más rápida con el movimiento del grupo lento de la actualización de los del par.


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Document ID: 119000