Troubleshooting de CPU Elevada Gerados pelo Processo de BGP Scanner ou BGP Router

Introduction

Este documento descreve situações em que um roteador Cisco IOS^® pode experimentar alta utilização da CPU devido ao processo do roteador BGP (Border Gateway Protocol) ou ao processo de scanner BGP, como mostrado na saída do comando show process cpu. A duração da condição elevada de CPU varia conforme o número de condições, particularmente o tamanho da tabela de roteamento à Internet e o número de rotas que um determinado roteador mantém em seu roteamento e tabelas de BGP.

O comando show process cpu mostra a média de utilização da CPU durante os últimos cinco segundos, o último minuto e os últimos cinco minutos. Os números de utilização da CPU não oferecem uma indicação linear real da utilização no que diz respeito à carga oferecida. Estes são alguns dos principais motivos:

• Numa rede do mundo real, a CPU tem de gerenciar várias funções de manutenção do sistema, por exemplo, o gerenciamento de rede.

• O CPU tem que processar atualizações de roteamento periódico e acionados por eventos.

• Existem outras operações internas de carga adicional do sistema, como eleição da disponibilidade de recursos, que não são proporcionais à carga do tráfego.

Você também pode usar o comando show processes cpu para obter alguma indicação da atividade da CPU.

Depois de ler este documento, você deve entender a função de cada processo BGP e quando cada processo é executado. Além disso, você deve entender a convergência e as técnicas do BGP para otimizar o tempo de convergência.

Antes de Começar

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Prerequisites

Este documento requer uma compreensão de como interpretar o comando show process cpu. Consulte Troubleshooting de Alta Utilização da CPU em Cisco Routers como material de referência.

Componentes Utilizados

As informações neste documento se baseiam na Versão 12.0 do Software Cisco IOS.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Entendendo os processos de BGP

Um processo do Cisco IOS, em geral, consiste em segmentos individuais e dados associados que executam tarefas, como manutenção do sistema, pacotes de comutação e implementação de protocolos de roteamento. Vários processos do Cisco IOS executados no roteador permitem a execução do BGP. Usar a cpu show process | inclua o comando BGP para ver a quantidade de utilização da CPU devido aos processos BGP.

Esta tabela lista a função dos processos de BGP e mostra que cada processo é executado em momentos diferentes, dependendo das tarefas que ele manipula. Como o scanner BGP e os processos do roteador BGP são responsáveis por uma grande quantidade de cálculos, você pode ver uma alta CPU devido a um desses processos. As seções a seguir discutem esses processos com mais detalhes.

Nome do processo	Descrição	Intervalo
BGP aberto	Realiza o estabelecimento de peer de BGP.	Na inicialização, ao estabelecer uma conexão TCP com um peer BGP.
BGP I/O	Controla o enfileiramento e o processamento de pacotes BGP, como ATUALIZAÇÕES e KEEPALIVES.	À medida que pacotes de controle BGP são recebidos.
Scanner BGP	Passa pela tabela de BGP e confirma a alcançabilidade dos próximos saltos. O verificador BGP também verifica anúncio condicional para determinar se o BGP deve ou não anunciar prefixos de condição e executar retardar da rota. Em um ambiente VPN MPLS, o scanner BGP importa e exporta rotas para uma determinada instância de roteamento e encaminhamento de VPN (VRF).	Após um minuto.
Roteador BGP	Calcula o melhor caminho BGP e processa qualquer "agitação" da rota. Ele também envia e recebe rotas, estabelece peers e interage com o Routing Information Base (RIB).	Uma vez por segundo e ao adicionar, remover ou reconfigurar o software de um peer de BGP.

CPU elevada devido ao scanner de BGP

A alta CPU devido ao processo de scanner BGP pode ser esperada para durações curtas em um roteador que transporta uma grande tabela de roteamento da Internet. Uma vez a cada minuto, o scanner BGP passa pela tabela RIB do BGP e executa importantes tarefas de manutenção. Essas tarefas incluem a verificação do próximo salto mencionado na tabela BGP do roteador, assim como a verificação quanto à possibilidade de os dispositivos do próximo salto serem alcançados. Portanto, uma ampla tabela de BGP demora um bom tempo para ser examinada e validada.

Como o processo de scanner de BGP é executado em toda a tabela de BGP, a duração da condição de CPU alta varia com o número de vizinhos e o número de rotas aprendidas por vizinho. Use os comando show ip bgp summary e show ip route summary para capturar essas informações.

O processo de scanner BGP caminha pela tabela BGP para atualizar qualquer estrutura de dados e caminha pela tabela de roteamento para fins de redistribuição de rota. (Neste contexto, a tabela de roteamento é conhecida também como o Routing Information Base (RIB), para a qual o roteador sai ao executar o comando show ip route). As duas tabelas são armazenadas separadamente na memória do roteador e podem ser muito grandes, consumindo assim ciclos de CPU.

O seguinte exemplo de saída do comando debug ip bgp updates captura uma execução do scanner de BGP, que inicia a exploração no prefixo de numeração inferior ou 0.0.0.0.

router# 
2d17h: BGP: scanning routing tables 
2d17h: BGP: 3.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 3.0.0.0 update run completed, ran for 0ms, neighbor
     version 8, start version 9, throttled to 9, check point net 0.0.0.0 
2d17h: BGP: 4.0.0.0 computing updates, neighbor version 8, 
     table version 9, starting at 0.0.0.0 
2d17h: BGP: 4.0.0.0 update run completed, ran for 4ms, neighbor
     version 8, start version 9, throttled to 9, check point net 0.0.0.0 
router#

Enquanto o scanner BGP é executado, os processo de baixa prioridade devem esperar por mais tempo para acessar a CPU. Um processo de baixa prioridade controla os pacotes ICMP (protocolo de mensagem de controle da Internet), como pings. Os pacotes destinados ou com origem no roteador podem experimentar uma latência mais elevada do que o esperado, uma vez que o processo de ICMP deve aguardar atrás de um scanner BGP. O ciclo é que o scanner BGP é executado por algum tempo e se suspende, e então o ICMP é executado. Em contraste, os pings enviados através de um roteador devem ser comutados através do CEF e não devem experimentar nenhuma latência adicional. Ao Troubleshoot picos periódicos de latência, compare os tempos de encaminhamento de pacotes encaminhados através de um roteador com os pacotes processados diretamente pela CPU no roteador.

Observação: os comandos ping que especificam opções de IP, como rota de registro, também exigem processamento direto pela CPU e podem sofrer atrasos de encaminhamento mais longos.

Usar o processo show | include bgp scanner command para ver a prioridade da CPU. O valor do "Lsi" na saída de exemplo a seguir utiliza "L" para se referir a um processo de baixa prioridade.

6513# show processes | include BGP Scanner
 172 Lsi 407A1BFC       29144     29130    1000 8384/9000  0 BGP Scanner

CPU alta devido ao processo do roteador BGP

O processo do roteador BGP é executado aproximadamente uma vez por segundo para verificar se há trabalho. A convergência de BGP define a duração entre o tempo em que o primeiro peer de BGP é estabelecido e o ponto em que o BGP é convergido. Para garantir os tempos de convergência mais curtos possíveis, o roteador BGP consome todos os ciclos de CPU livres. Entretanto, após a sua inicialização, ele abre mão da CPU (ou suspende) imediatamente.

O tempo de convergência é uma medição direta do tempo gasto pelo roteador BGP na CPU, não o tempo total. Este procedimento mostra uma condição de CPU alta durante a convergência de BGP e troca prefixos de BGP com dois peers BGP externos (eBGP).

1. Capture uma linha de base para a utilização de CPU normal antes de iniciar o teste.

   router# show process cpu
     CPU utilization for five seconds: 0%/0%; one minute: 4%; five minutes: 5%

2. Quando o teste começa, o CPU atinge 100% de uso. O comando show process cpu indica que a condição de utilização elevada da CPU é causada pelo roteador BGP, representado por 139 (a identificação de processo IOS para o roteador BGP) na saída seguinte.

   router# show process cpu
     CPU utilization for five seconds: 100%/0%; one minute: 99%; five minutes: 81%
   
   !--- Output omitted.
   
   139     6795740   1020252       6660 88.34% 91.63% 74.01%   0 BGP Router

3. Monitore o roteador capturando várias saídas dos comandos show ip bgp summary e show process cpu durante o evento. O comando show ip bgp summary captura o estado dos vizinhos BGP.

   router# show ip bgp summary
     Neighbor    V    AS  MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down State/PfxRcd
     10.1.1.1    4  64512  309453  157389    19981    0  253 22:06:44 111633
     172.16.1.1  4  65101  188934    1047    40081   41    0 00:07:51 58430

4. Quando o roteador conclui a troca de prefixo com seus peers de BGP, as taxas de utilização de CPU devem retornar aos níveis normais. As médias computadas de um e cinco minutos também serão estabelecidas de voltao e poderão mostrar níveis mais altos que o normal por um período maior do que a taxa de cinco segundos.

   router# show process cpu
     CPU utilization for five seconds: 3%/0%; one minute: 82%; five minutes: 91%

5. Use a saída capturada dos comandos show acima para calcular o tempo de convergência de BGP. Use especificamente a coluna "Para cima/Para baixo" do comando show ip bgp summary e compare os tempos de início e término da condição de CPU alta. Normalmente, a convergência de BGP pode demorar vários minutos, durante a troca de uma grande tabela de roteamento de Internet.

Observação: a alta CPU no dispositivo também pode ser devido à instabilidade da tabela BGP. Se o roteador estiver recebendo duas cópias da tabela de roteamento, uma do peering do EBGP com o ISP e a outra do peering do IBGP na rede. A causa principal disso é a quantidade de memória no dispositivo. A Cisco recomenda um mínimo de 1 Gig de RAM para uma única cópia da tabela de roteamento da Internet. Para contornar essa instabilidade, aumente a RAM no dispositivo ou filtre os prefixos de modo que a tabela BGP e a memória ocupada por ela sejam removidas.

Melhorias no desempenho

À medida que o número de rotas na tabela de roteamento da Internet cresce, também cresce o tempo que o BGP leva para convergir. Em geral, convergência é definida como o processo de colocar todas as tabelas de rota em um estado de consistência. O BGP é considerado convergido quando as seguintes condições são verdadeiras:

• Todas as rotas foram aceitas.

• Todas as rotas foram instaladas na tabela de roteamento.

• A versão da tabela para todos os peers é igual à versão da tabela de BGP.

• O InQ e o OutQ para todos os peers é zero.

Esta seção descreve algumas melhorias no desempenho do IOS para reduzir o tempo de convergência de BGP, que resulta em uma redução de uma condição de CPU alta devido a um processo de BGP.

Enfileiramento para conexões de peer TCP

Em vez de enfileirar dados uma vez por segundo, BGP agora os enfileira agressivamente do OutQ de BGP para o soquete de TCP de cada correspondente até os OutQs estarem completamente drenados. Como o BGP faz envios em uma taxa mais rápida, o BGP converge mais rapidamente.

Grupos de paridade BGP

Embora ajudem a simplificar a configuração do BGP, os grupos de peer do BGP também podem melhorar a escalabilidade. Todos os membros de grupo de peer devem compartilhar uma política de saída comum. Assim, os mesmos pacotes de atualização podem ser enviados para cada membro do grupo, reduzindo o número de ciclos de CPU que o BGP requer para anunciar rotas para peers. Em outras palavras, com grupos de peer, o BGP vai para a tabela BGP apenas no líder do grupo de peer, filtra os prefixos através das políticas de saída e gera atualizações que envia para o líder do grupo de peer. Por sua vez, o líder replica as atualizações para os membros do grupo com os quais está sincronizado. Sem grupos de peer, o BGP deve caminhar pela tabela para cada peer, filtrar prefixos por meio de políticas de saída e gerar atualizações que são enviadas somente para um peer.

MTU de caminho e o comando ip tcp path-mtu-discovery

Todas as sessões TCP são limitadas por um limite no número de bytes que podem ser transportados em um único pacote. Esse limite, conhecido como Tamanho máximo de segmento (MSS), é de 536 bytes por padrão. Em outras palavras, antes de encaminhar os pacotes para a camada IP inferior, o TCP quebra os pacotes na fila de transmissão, em blocos de 536 bytes. Usar o comando show ip bgp neighbors | inclua o comando max data para exibir o MSS dos peers BGP:

Router# show ip bgp neighbors | include max data 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 
Datagrams (max data segment is 536 bytes): 

A vantagem de um MSS de 536 bytes é a pouca probabilidade de que os pacotes sejam fragmentados em um dispositivo de IP ao longo do caminho para o destino já que a maioria dos links usa um MTU de, no mínimo, 1500 bytes. A desvantagem é que os pacotes menores aumentam a quantidade de largura de banda usada para transportar a sobrecarga. Como o BGP cria uma conexão TCP para todos os peers, um MSS de 536 bytes afeta os tempos de convergência do BGP.

A solução é ativar o recurso PMTU (MTU de caminho) usando o comando ip tcp path-mtu-discovery. Você pode usar esse recurso para determinar dinamicamente o tamanho do valor MSS sem criar pacotes que precisam ser fragmentados. PMTU permite que o TCP determine o menor tamanho de MTU entre todos os links em uma sessão TCP. O TCP usa esse valor de MTU, menos espaço para os cabeçalhos IP e TCP, como o MSS para a sessão. Se uma sessão de TCP atravessa somente segmentos de Ethernet, o MSS será de 1460 bytes. Se ele atravessar apenas segmentos POS (Packet over SONET), o MSS será de 4430 bytes. O aumento no MSS de 536 para 1.460 ou 4.430 bytes reduz a sobrecarga de TCP/IP, o que ajuda a convergência de BGP mais rápida.

Depois de habilitar o PMTU, use novamente o comando show ip bgp neighbors | inclua o comando max data para ver o valor MSS por peer:

Router# show ip bgp neighbors | include max data 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 
Datagrams (max data segment is 1460 bytes): 

Aumentar filas de entrada de interface

Se o BGP estiver anunciando milhares de rotas para muitos peers, o TCP deve transmitir milhares de pacotes em um curto período de tempo. Os peers BGP recebem esses pacotes e enviam confirmações TCP para o locutor BGP de anúncio, o que faz com que o locutor BGP receba uma inundação de ACKs TCP em um curto período de tempo. Se os ACKS chegarem a uma taxa que é muito alta para o processador de rota, os pacotes voltam para as filas de interface de entrada. Por padrão, as interfaces de roteador usam um tamanho de fila de entrada de 75 pacotes. Além disso, pacotes de controle especiais como ATUALIZAÇÕES DE BGP usam uma fila especial com SPD (Descarte seletivo de pacotes). Essa fila especial mantém 100 pacotes. Durante a convergência de BGP, ACKs de TCP podem preencher rapidamente os 175 locais de buffer de entrada e novos pacotes que chegarem posteriormente precisam ser descartados. Em roteadores com 15 ou mais peers BGP e intercâmbio da tabela completa de roteamento de Internet, podem ser vistas mais de 10 mil quedas por interface por minuto. Este é um exemplo da saída de um roteador 15 minutos depois da reinicialização:

Router# 
show interface pos 8/0 | include input queue 
Output queue 0/40, 0 drops; input queue 0/75, 278637 drops 
Router#

Aumentar a profundidade da fila de entrada da interface (usando o hold-queue <1-4096> no comando) ajuda a reduzir o número de ACKs TCP descartadas, o que reduz a quantidade de trabalho que o BGP deve fazer para convergir. Normalmente, um valor de 1000 resolve problemas causados por quedas de fila de entrada.

Observação: o Cisco 12000 Series agora usa um valor de espaço padrão SPD de 1000. Mantém o tamanho padrão da fila de entrada de 75. Use o comando show spd para exibir essas filas de entrada especiais.

Outras melhorias no IOS 12.0(19)S

O IOS 12.0(19)S inclui várias otimizações no código de grupo de peers BGP para melhorar o empacotamento e a replicação de atualizações. Antes de discutirmos esses aprimoramentos, vamos examinar a embalagem de atualizações e a replicação com mais detalhes.

Uma atualização de BGP consiste em uma combinação de atributos (como MED = 50 e LOCAL_PREF = 120) e uma lista de prefixos de Informações de Acessibilidade da Camada de Rede (NLRI - Network Layer Reachability Information) que compartilham essa combinação de atributos. Quanto mais prefixos NLRI o BGP pode listar em uma única atualização, mais rápido o BGP pode convergir desde que a sobrecarga (como cabeçalhos IP, TCP e BGP) é reduzida. "Pacote de atualização" refere-se ao empacotamento de NLRI em atualizações de BGP. Por exemplo, se uma tabela de BGP contém 100.000 rotas com 15.000 combinações de atributos exclusivos, o BGP precisa enviar apenas 15.000 atualizações se o NLRI estiver empacotado com eficiência de 100%.

Observação: zero por cento de eficiência de embalagem significa que o BGP precisaria enviar 100.000 atualizações neste ambiente.

Use o comando show ip bgp peer-group para exibir a eficiência das atualizações BGP.

Se um membro de grupo de correspondentes estiver "em sincronia", um roteador BGP selecionará uma mensagem de atualização formatada para o líder do grupo de correspondentes e a replicará para o membro. É muito mais eficiente reproduzir uma atualização para um membro de grupo de peer do que reformatar a atualização. Por exemplo, suponha que um grupo de correspondentes tenha 20 membros e todos eles precisem receber 100 mensagens BGP. A replicação de cem por cento significa que um roteador BGP formata as 100 mensagens para o líder do grupo de correspondentes e replica essas mensagens para os outros 19 membros do grupo de correspondentes. Para confirmar melhorias na replicação, compare o número de mensagens replicadas com o número de mensagens formatadas, como mostrado pelo comando show ip bgp peer-group. As melhorias fizeram uma grande diferença nos tempos de convergência e permitem que o BGP suporte muitos mais peers. Vamos ver um exemplo.

Utilize o comando ip bgp peer-group para verificar a eficiência do empacotamento de dados e replicação da atualização. A saída a seguir é de um teste de convergência com 6 grupos de peer com 20 peers em cada um dos 5 primeiros grupos (peers eBGP) e 100 peers no sexto grupo (peers de BGP internos (iBGP)). Além disso, a tabela BGP usada tinha 36.250 combinações de atributos.

O exemplo de saída a seguir do comando show ip bgp peer-group | incluir comando replicado em um roteador executando IOS 12.0(18)S exibe as seguintes informações:

Update messages formatted 836500, replicated 1668500 
Update messages formatted 1050000, replicated 1455000 
Update messages formatted 660500, replicated 1844500 
Update messages formatted 656000, replicated 1849000 
Update messages formatted 501250, replicated 2003750 

!-- The first five lines are for eBGP peer groups.
 
Update messages formatted 2476715, replicated 12114785 

!-- The last line is for an iBGP peer group.

Para calcular a taxa de replicação para cada grupo de pares, divida o número de atualizações replicadas pelo número de atualizações formatadas:

1668500/836500 = 1,99 1455000/1050000 = 1,38 1844500/660500 = 2,79 184 9000/656000 = 2,81 2003750/501250 = 3,99 12114785/2476715 = 4,89

Se o BGP replicasse perfeitamente, os grupos de peer do eBGP teriam uma taxa de replicação de 19, pois há 20 peers no grupo de peers. A atualização deve ser formatada para o líder do grupo de pares e depois replicada para os outros 19 pares, fornecendo uma taxa de replicação ideal de 19. A taxa de replicação ideal para o grupo de peer do iBGP seria 99, pois há 100 peers.

Se o BGP empacotou as atualizações corretamente, teremos apenas 36.250 atualizações formatadas. Seria necessário gerar apenas 36.250 atualizações para cada grupo de correspondentes, pois este é o número de combinações de atributos na tabela de BGP. O grupo de peers de iBGP por si só formata aproximadamente 2.500.000 atualizações, enquanto que cada um dos grupos de peers de eBGP gera cerca de 500.000 a 1.000.000 de atualizações.

Em um roteador executando IOS 12.0(19)S, o comando show ip bgp peer-group | include replicated command fornece estas informações:

Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 688750 
Update messages formatted 36250, replicated 3588750

Observação: a embalagem de atualização é ideal. Exatamente 36.250 atualizações são formatadas por cada grupo de componentes.

688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 688750/36250 = 19 3588750/36250 = 99

Observação: a replicação de atualizações também é perfeita.

Troubleshooting

Use estes procedimentos para solucionar problemas de CPU alta devido ao scanner BGP ou ao roteador BGP:

• Colete informações sobre a topologia do BGP. Determine o número de peers BGP e o número de rotas que estão sendo anunciadas por cada peer. A duração da condição de CPU alta é baseada de forma razoável em seu ambiente?

• Determine quando a CPU está alta. Isso coincide com uma movimentação programada regularmente da tabela BGP?

• Execute o comando show ip bgp flap-statistics. A CPU alta seguiu um flap de interface?

• Emita um ping através do roteador e, em seguida, a partir do roteador. Os ecos ICMP são tratados como um processo de baixa prioridade. O documento Understanding the Ping and Traceroute Commands explica isso com mais detalhes. Assegure que o encaminhamento regular não seja afetado.

• Certifique-se de que os pacotes possam seguir um caminho de encaminhamento rápido verificando se a comutação rápida e/ou CEF estão ativados nas interfaces de entrada e de saída. Certifique-se de não ver o comando no ip route-cache cef na interface ou o comando no ip cef na configuração global. Para ativar o CEF no modo de configuração global, use o comando ip cef.

• Obtenha saída destes comandos:

  Comando	Descrição
  Mostrar resumo do mls cef	Exibe o número de rotas na tabela de switching de Camada 3 de hardware de Comutação Multicamada (MLS - Multilayer Switching) para todos os protocolos.
  show mls cef maximum-routes	Exibe a configuração máxima atual do sistema de rotas.
  show mls cef exception <status>	Exibe informações sobre o status de exceção do Cisco Express Forwarding.

• Verifique a DRAM no roteador. De acordo com a recomendação, deve haver um mínimo de 512 MB de espaço DRAM por peer BGP que envia a tabela de roteamento de Internet completa. Se o roteador tiver dois peers EBGP que executam a tabela de roteamento de Internet completa, recomenda-se um mínimo de 1 GB de espaço DRAM. O espaço DRAM mencionado aqui é apenas a memória necessária para o BGP. Outros recursos executados no roteador exigirão espaço DRAM adicional.

Informações Relacionadas

• Página de suporte de BGP
• Página de Suporte do IP Routing
• Suporte Técnico - Cisco Systems

Histórico de revisões