IP : Border Gateway Protocol (BGP)

Use “a característica do par lento” BGP para resolver edições lentas do par

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (21 Abril 2016) | Feedback

Introdução

Este documento descreve como resolver um problema lento do par com o uso da característica lenta do par do Border Gateway Protocol (BGP), que identifica um par lento em um grupo da atualização BGP e pode mover o par lento fora do grupo da atualização permanentemente ou temporariamente.

Contribuído por Luc De Ghein, engenheiro de TAC da Cisco.

Informações de Apoio

Esta seção fornece uma vista geral da característica lenta do par e o uso de grupos da atualização.

Grupos da atualização

A característica lenta do par é usada em grupos da atualização. Um grupo da atualização é um método dinâmico que seja usado a fim agrupar bgp peer com a mesma política de saída. O benefício de grupos da atualização é que a política do grupo está usada a fim formatar uma vez mensagens, e replicated e são transmitidos então aos outros membros do grupo. Este método é mais eficiente do que a necessidade de formatar separadamente atualizações BGP para cada par.

Quando este método estiver executado, se as alterações de política externa, os peer-group mudam pelo grupo da atualização. Os grupos da atualização são formados pela família do endereço (AF).

Está aqui um exemplo de dois bgp peer em grupos diferentes da atualização para o unicast do IPv4 AF, mas com o mesmo grupo da atualização para o 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

O grupo da atualização transforma-se mais eficiente como os bgp peer do número que são incluídos nos aumentos do grupo da atualização. Tipicamente, os pares do Internal BGP (iBGP) têm a mesma política de saída. Para o iBGP, um refletor de rota (RR) pode ter muitos pares do iBGP; assim, terá grandes grupos da atualização. O Roteadores da ponta de provedor (PE) pode ter muitos external bgp (ebgp) peer para o Roteadores do edge de cliente (CE) em um virtual/transmissão do roteamento (VRF). Os roteadores de PE podem ter grandes grupos da atualização também para os peerings com os CE Router nas relações VRF.

Problema

Um par lento é um par que não possa prosseguir com a taxa em que o roteador gerencie mensagens da atualização BGP durante um período de tempo prolongado (na ordem de minutos) em um grupo da atualização. A razão para esta pode ser questões de rede persistentes. As razões da rede poderiam ser perda de pacotes e/ou links carregados, ou a taxa de transferência emite com as sessões de BGP. Também, um bgp peer pôde pesadamente ser carregado em termos do CPU e não pode prestar serviços de manutenção à conexão de TCP na velocidade exigida.

Os pares lentos afetam a convergência de BGP do grupo completo da atualização. Se um bgp peer é lento, faz com que o grupo inteiro da atualização retarde. O resultado é que os outros membros do grupo da atualização terão uma convergência mais lenta também. Por este motivo, a edição deve ser resolved.

Você pode identificar o par lento e movê-lo fora do grupo da atualização. A fim terminar esta tarefa, você pode mudar a política de saída para esse bgp peer; contudo, esta é uma tarefa manual. Você deve primeiramente identificar o par que é lento, e então movê-lo fora do grupo da atualização. A característica lenta do par pode fazer esta automaticamente, de modo que nenhuma intervenção de usuário seja exigida.

Solução

Há três porções à característica lenta do par:

  • Detecção do par lento

  • Movimento do par lento em um grupo lento da atualização

  • Recuperação do par lento (que move o par recuperado de volta a seu grupo original da atualização)

Estes processos são descritos em um detalhe mais adicional nas seções que seguem.

Detecção

A característica lenta do par detecta pares lentos em um grupo da atualização. Cada grupo da atualização tem uma fila pondo em esconderijo, onde as atualizações BGP formatadas sejam armazenadas temporariamente antes da transmissão.

Está aqui um exemplo de tal esconderijo do grupo da atualização:

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

O tamanho do esconderijo dinamicamente é calculado e depende sobre:

  • O número de pares no grupo da atualização

  • A memória de sistema instalada

  • O tipo de pares no grupo da atualização

  • O tipo de AF

O número de atualizações BGP formatadas que esperam a transmissão pode construir em um grupo da atualização quando um par (lento) não reconhece os mensagens BGP tão rapidamente quanto os outros membros. Quando o limite do esconderijo é alcançado, o grupo não tem any more quota para enfileirar mensagens novas. Nenhuma mensagem nova pode ser formatada até que o esconderijo esteja reduzido (até que algumas mensagens estejam reconhecidas pelos pares lentos). Isto proibe o bgp peer e não permite que envie mensagens novas (as atualizações ou se retiram) aos membros mais rápidos do grupo. Daqui, isto retarda a convergência de todos os pares no grupo da atualização.

Para que a característica lenta do par identifique um par lento, refere os parâmetros TCP dos timestamps e do par da atualização BGP.

A detecção lenta do par é desabilitada à revelia. A fim permitir a detecção lenta do par, use um destes métodos:

  • Permita a característica para o processo BGP (pode ser configurado de AF/VRF):
    bgp slow-peer detection [threshold <seconds>]

    [no] bgp slow-peer detection

    Nota: O valor de limiar pode variar entre 120 e 3,600 segundos, e o valor padrão é 300 segundos.

  • Permita a característica pelo par:
    neighbor {<nbr-addr>/<peer-grp-name>} slow-peer detection [threshold < seconds >]

    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer detection
  • Permita a característica através do molde de política do par:
    slow-peer detection [threshold < seconds >]

    [no] slow-peer detection

Quando um par lento é detectado, um mensagem do syslog similar a este está imprimido:

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

Você pode inscrever estes comandos show a fim ver os pares lentos:

  • mostre o sumário BGP IP lento

  • mostre os vizinhos de BGP IP lentos

  • mostre o sumário do atualização-grupo BGP IP lento

Está aqui um show command output (resultado do comando show) do exemplo quando a palavra-chave lenta é usada:

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

Segundo as indicações da saída, o par 10.1.6.7 é um par lento para o unicast do IPv4 AF. Os outros AF não mostram nenhuns pares lentos.

A fim verificar se da detecção do temporizador as corridas atualmente e seu valor, incorporam 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       

Segundo as indicações das saídas de exemplo, o temporizador da detecção começou. O temporizador da detecção começa quando o esconderijo do grupo da atualização está completo.

Neste exemplo, você pode ver que um par lento está detectado, mas se move somente fora do grupo da atualização depois que o temporizador lento da detecção do par expira:

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

Identificação lenta do par

Se a característica lenta da detecção do par não é permitida, a seguir você deve identificar o par lento manualmente. Primeiramente, verifique a versão de tabela e a fila de saída dos pares no grupo da atualização:

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

Neste exemplo, verifique se a versão de tabela (TblVer) dos pares alcança nunca com a versão principal da tabela de BGP ou se é sempre atrás. Em segundo, verificação para uns ou vários pares com valores de fila muito a rendimento elevado. É provável que estes são os pares lentos.

Quando você vê o bgp peer lento suspeitado, considere estas perguntas (em ambos os lados da sessão de BGP):

  • Quanto tempo há era o último escreve executado?

  • Está o Keepalives no regulador de pressão?

  • É a fila de saída alta?

  • É o SRTT/RTTO alto?

  • Faz o o número de retransmite aumentam?

  • Há alguns enfileirados retransmite pacotes?

  • É o TCP envia o indicador muito baixo ou zera-o?

Aqui está um exemplo:

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

Movimento

Esta seção descreve o processo do movimento com respeito à característica lenta do par em várias encenações.

Movimento sem característica lenta do par

Um par lento pode ser movido manualmente em um grupo novo da atualização sem a característica lenta do par.

Antes que a característica lenta do par esteve disponível, você foi exigido identificar o par lento e movê-lo então manualmente fora do grupo da atualização. Isto é terminado com uma mudança à política de saída desse bgp peer. Esta política de saída deve ser diferente do que qualquer outro que for usada, como você deve se assegurar de que o par lento não se transporte a um outro grupo da atualização que exista atualmente (e mova o problema para esse grupo da atualização). A melhor mudança que você pode aplicar é uma que não afeta a política real. Por exemplo, você poderia mudar o intervalo mínimo do anúncio da rota (MRAI) do par (sob o AF específico).

Está aqui um exemplo que mostre o movimento manual de um par lento quando a característica lenta do par não está disponível:

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

Movimento lento estático do par

A fim mover um par de um grupo da atualização em um grupo novo da atualização, você pode configurar-lo como um par lento estático. Se há pares lentos múltiplos, a seguir os pares lentos estáticos com a mesma política de saída estão colocados no mesmo grupo lento da atualização.

A fim mover estaticamente um par lento, você pode configurar-lo com o uso destes comandos:

  • Permita o movimento do peer estático pelo vizinho ou pelo peer-group:
    [no] neighbor {<nbr-addr>/<peer-grp-name>} slow-peer split-update-group static
  • Permita o movimento do peer estático através de um molde de política do par:
    [no] slow-peer split-update-group static

Movimento lento dinâmico do par

O movimento lento do par é desabilitado à revelia. A fim permitir o movimento lento do par, você pode configurar-lo através de um destes métodos:

  • Permita o movimento lento do par para o processo BGP:
    bgp slow-peer split-update-group dynamic [permanent]

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

    Nota: Isto pode ser configurado da opinião da endereço-família/topology/VRF.

  • Permita o movimento lento do par pelo 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
  • Permita o movimento lento do par através de um molde de política do par:
    slow-peer split-update-group dynamic [permanent]

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

Nota: A palavra-chave permanente indica que o par lento não recuperará automaticamente. Neste caso, você pode mover o par lento recuperado de volta a seu grupo original da atualização através de um dos comandos clear.

Os pares lentos estáticos e os pares lentos dinâmicos estão no mesmo grupo lento da atualização do par. Neste exemplo você pode ver um par lento em um grupo lento da atualização:

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

Recuperação

Um par lento pode ser reagrupado sob seu grupo original da atualização (esse combina a política de saída) uma vez que se confirma que é já não um par lento (alcança). O temporizador de recuperação começa quando o grupo lento da atualização do par convirgiu. Quando o temporizador de recuperação expira, o par lento está movido de volta ao grupo da atualização regular.

Nota: A fim ver o comportamento que é relacionado à detecção/temporizador de recuperação, incorpore o comando dos eventos do debug ip bgp updates.

Quando um par lento estiver movido de volta ao grupo original da atualização (este significa uma recuperação), um mensagem do syslog similar a este está imprimido:

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

A fim verificar se do temporizador de recuperação as corridas atualmente e o valor, incorporam 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

Neste exemplo, o temporizador de recuperação, com um valor de 16 segundos, indica que um par possivelmente lento pôde se mover de volta a seu grupo original da atualização em 16 segundos.

Neste exemplo, você pode ver um par que recupere do status 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

Cancele o status de peer lento

O status de peer lento pode ser cancelado manualmente com estes comandos:

  • clear ip bgp * lento

  • cancele BGP AF IP {unicast|number> do Multicast} <AS lento

  • cancele BGP AF IP {unicast|<group-name> do peer-group do Multicast} lento

  • cancele o <neighbor-address> BGP IP lento

  • cancele BGP AF {unicast|Multicast} * retarde

  • cancele BGP AF {unicast|number> do Multicast} <AS lento

  • cancele BGP AF {unicast|<group-name> do peer-group do Multicast} lento

  • cancele BGP AF {unicast|<neighbor-address> do Multicast} lento

Nota: Quando você usa estes comandos, substitua o AF com a família do endereço real.

Com o uso destes comandos, o par é movido de volta ao grupo original da atualização.

Inscreva o comando internal BGP da mostra IP a fim ver os ajustes lentos da detecção e do movimento do 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: Em resumo, o par lento BGP é uma característica que detecte um par lento em um grupo da atualização BGP e o permita uma convergência de BGP mais rápida com o movimento do par lento fora do grupo da atualização.



Document ID: 119000