Troubleshooting de CPU Elevada Gerados pelo Processo de BGP Scanner ou BGP Router
Índice
Introdução
Este documento descreve as situações em que um roteador do ® do Cisco IOS pôde experimentar a utilização elevada da CPU devido ao processo do roteador (BGP) de protocolo de gateway de borda ou ao processo do scanner de BGP, segundo as indicações da 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 algumas das razões principal:
-
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ê pode igualmente usar o comando show processes cpu a fim obter alguma indicação de atividade do CPU.
Uma vez que você lê este documento, você deve compreender o papel de cada processo BGP e quando cada processo for executado. Além, você deve compreender a convergência de BGP e as técnicas para aperfeiçoar o tempo de convergência.
Antes de Começar
Convenções
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Pré-requisitos
Este documento exige uma compreensão de como interpretar o comando show process cpu. Refira pesquisando defeitos a utilização elevada da CPU em roteadores Cisco como o material de referência.
Componentes Utilizados
A informação neste documento é baseada no Cisco IOS Software Release 12.0.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Entendendo os processos de BGP
Um processo do Cisco IOS, geralmente, consiste nas linhas individuais e nos dados associados que executam tarefas, tais como a manutenção de sistema, pacotes de switching, e em executar protocolos de roteamento. Diversos processos do Cisco IOS executados no roteador permitem o BGP de ser executado. Use o processador central do processo da mostra | inclua o comando BGP para ver a quantidade de utilização de CPU devido a processos de BGP.
Esta tabela alista a função dos processos BGP e mostra que cada processo é executado em horas diferentes, segundo as tarefas que segura. Porque o scanner de BGP e os processos de roteador BGP são responsáveis para uma grande quantidade de cálculos, você pode ver a alta utilização da CPU devido a qualquer um um destes processos. As seguintes seções discutem estes processos em maiores detalhes.
| Nome do processo | Descrição | Intervalo |
|---|---|---|
| BGP aberto | Realiza o estabelecimento de peer de BGP. | Na iniciação, ao estabelecer uma conexão de TCP com um bgp peer. |
| 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 do MPLS VPN, o scanner de BGP importa e as rotas das exportações em um VPN Routing and Forwarding particular citam como exemplo (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 utilização da CPU devido ao processo do scanner de BGP pode ser para breve durações previstas em um roteador que leva 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.
Porque o processo do scanner de BGP é executado através da tabela de BGP inteira, a duração da condição elevada de CPU varia com o número de vizinho e o número de rotas aprendidas pelo vizinho. Use os comando show ip bgp summary e show ip route summary para capturar essas informações.
O processo do scanner de BGP anda a tabela de BGP para atualizar todas as estruturas de dados e anda a tabela de roteamento para finalidades da 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). Ambas as tabelas são armazenadas separadamente na memória do roteador e podem ser ciclos de CPU muito grandes, assim consumindo.
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 de BGP é executado por algum tempo e se suspende, e então corrida ICMP. 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 pesquisar defeitos pontos periódicos na latência, compare o tempo de encaminhamento para os pacotes enviados através de um roteador em comparação com pacotes processado diretamente pelo CPU no roteador.
Nota: Os comandos Ping que especificam opções IP, tais como a rota do registro, também exigem o processamento direto pelo CPU e podem experimentar uns atrasos mais longos da transmissão.
Use o processo da mostra | inclua o comando de scanner de BGP ver a prioridade do 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 de roteador BGP é executado aproximadamente uma vez por segundo para verificar para ver se há o trabalho. A convergência de BGP define a duração entre o tempo em que o primeiro bgp peer é estabelecido e o ponto em que o BGP está convirgido. A fim assegurar o tempo de convergência possível o mais curto, o BGP Router 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 medida direta de quanto tempo o BGP Router gasta no CPU, não o tempo total. Este procedimento mostra uma condição elevada de CPU durante a convergência de BGP e troca prefixos BGP com os dois external bgp (ebgp) peer.
-
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%
-
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
-
Monitore o roteador capturando saídas múltiplas do sumário e de comandos show process cpu BGP da mostra IP 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
-
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%
-
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.
Nota: A alta utilização da CPU no dispositivo podia igualmente ser devido à instabilidade da tabela de BGP. Se o roteador está recebendo duas cópias da tabela de roteamento, uma do peering eBGP com o ISP e a outro do ibgp peering na rede. A causa de raiz para esta é a quantidade de memória no dispositivo. Cisco recomenda um mínimo de 1 atuação de RAM para uma cópia única da tabela de roteamento do Internet. Para contornar esta instabilidade, aumente RAM no dispositivo ou filtre os prefixos de modo que a tabela de BGP e a memória ocupadas por ele sejam aliviadas.
Melhorias no desempenho
Enquanto o número de rotas na tabela de roteamento da Internet cresce, faz tão demasiado o tempo onde toma para que o BGP convirja. 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 de tabela para todos os pares iguala a versão de tabela da tabela de BGP.
-
O InQ e o OutQ para todos os pares são zero.
Esta seção descreve as melhorias de desempenho alguns IO para reduzir o tempo da convergência de BGP, que conduzem a uma redução de uma condição elevada de CPU devido a um processo 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
Quando ajudarem a simplificar a configuração de BGP, os grupos de BGP peer igualmente podem aumentar 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 replicates as atualizações para agrupar os membros com que é sincronizado. Sem peer-group, o BGP deve andar a tabela para cada par, filtrar prefixos com as políticas de saída, e gerar as atualizações que são enviadas somente ao um par.
MTU de caminho e o comando ip tcp path-mtu-discovery
Todas as sessões de TCP são limitadas por um limite no número de bytes que pode ser transportado em um pacote único. 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. Use os vizinhos de BGP da mostra IP | inclua o comando de dados máximo indicar o MSS dos bgp peer:
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 ao Transport Overhead. Desde que o BGP constrói uma conexão de TCP a todos os pares, vezes 536 de uma convergência de BGP das influências do byte MSS.
A solução é ativar o recurso PMTU (MTU de caminho) usando o comando ip tcp path-mtu-discovery. Você pode usar esta característica para determinar dinamicamente como grande o valor MSS pode ser sem criar os pacotes que precisam de ser fragmentados. O PMTU permite que o TCP determine o tamanho do MTU o menor entre todos os links em uma sessão de TCP. O TCP usa então este valor MTU, espaço inferior para o IP e cabeçalhos de 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 a 1460 ou 4430 bytes reduz as despesas gerais TCP/IP, que ajudam o BGP a convirgir mais rapidamente.
Após ter permitido o PMTU, use outra vez os vizinhos de BGP da mostra IP | inclua o comando de dados máximo ver o valor MSS pelo par:
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 bgp peer recebem estes pacotes e enviam reconhecimentos de TCP ao auto-falante de BGP da propaganda, que faz com que o auto-falante de BGP receba uma inundação de TCP ACK em um período de tempo curto. 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#
Aumentando a profundidade da fila de entrada de interface (que usa a posse-fila <1-4096> no comando) as ajudas reduzem o número de TCP deixado cair ACK, que reduz a quantidade de trabalho BGP deve fazer para convirgir. Normalmente, um valor de 1000 problemas das resoluções causados por quedas de fila de entrada.
Nota: O Cisco 12000 Series usa agora um valor do SPD headroom do padrão de 1000. Retém o tamanho da fila de entrada do padrão 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 que nós discutamos estas melhorias, deixe-nos olhar com maiores detalhes a embalagem e a replicação da atualização.
Uma atualização BGP consistem em uma combinação de atributos (como MED = 50 pés e LOCAL_PREF = 120) e os prefixos de uma informação de alcançabilidade da camada da lista de rede (NLRI) que compartilhem dessa combinação de atributos. Mais prefixos NLRI O BGP pode alistar em uma única atualização, mais rapidamente o BGP pode convirgir desde despesas gerais (tais como o IP, o TCP, e os cabeçalhos BGP) estão reduzidos. Da “a embalagem atualização” refere a embalagem do NLRI em atualizações BGP. Por exemplo, se uma tabela de BGP guarda 100,000 rotas com 15,000 combinações do atributo exclusivo, o BGP precisa de enviar somente 15,000 atualizações se o NLRI é embalado com 100 por cento de eficiência.
Nota: O por cento zero da eficiência da embalagem significa que o BGP precisaria de 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 melhoras de replicação, compare o número de mensagens replicated ao 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)). Também, a tabela de BGP que foi usada teve 36,250 combinações de atributo.
O seguinte exemplo de saída do peer-group BGP da mostra IP | inclua o comando replicado em um roteador que executa IO que 12.0(18)S indica a informação seguinte:
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.
A fim calcular a taxa de replicação para cada peer-group, divida o número de atualizações replicated pelo número de atualizações formatadas:
1668500/836500 = 1.99 1455000/1050000 = 1.38 1844500/660500 = 2.79 1849000/656000 = 2.81 2003750/501250 = 3.99 12114785/2476715 = 4.89
Se o BGP replicated perfeitamente, então os grupos de peer EBGP cada um teria uma taxa de replicação de 19 porque há 20 pares no peer-group. A atualização deve ser formatada para o líder de peer group e então ser replicated a outros 19 pares, fornecendo uma taxa de replicação ótima de 19. A taxa de replicação ideal para o ibgp peer group seria 99 desde que há 100 pares.
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 que executa IO 12.0(19)S, o peer-group BGP da mostra IP | inclua o comando replicado fornece esta informação:
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
Nota: O empacotamento de atualização está ótimo. 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
Nota: A replicação de atualização também é perfeita.
Troubleshooting
Use estes procedimentos a fim pesquisar defeitos a alta utilização da CPU devido ao scanner de BGP ou ao BGP Router:
-
Recolha a informação em sua topologia 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 alta utilização da CPU acontecer. 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 que compreende os comandos ping and traceroute explica este com maiores detalhes. Assegure que o encaminhamento regular não seja afetado.
-
Assegure-se de que os pacotes possam seguir um trajeto de encaminhamento rápido verificando se o interruptor rápido e/ou o CEF estão permitidos no de entrada e nas interfaces externas. Assegure-se de que você não ver o comando no ip route-cache cef na relação ou o comando no ip cef na configuração global. A fim permitir o CEF no modo de configuração global, use o comando ip cef.
-
Obtenha a saída destes comandos:
Comando Descrição Mostre o sumário do cef dos mls Indica o número de rotas na tabela do switching da camada 3 do hardware do switching multicamada (MLS) para todos os protocolos. mostre máximo-rotas do cef dos mls Indica a configuração de sistema máxima atual da rota. mostre o <status da exceção do cef dos mls > Indica a informação sobre o estado da exceção do Cisco Express Forwarding. -
Verifique o DRAM no roteador. Conforme a recomendação, deve haver um mínimo de 512 MB do espaço de DRAM pelo bgp peer que envia a tabela de roteamento de Internet completo. Se o roteador tem dois pares EBGP que executam a tabela de roteamento de Internet completo, a seguir um mínimo 1 GB do espaço de DRAM é recomendado. O espaço de DRAM mencionado aqui é apenas a memória exigida para o BGP. Os outros recursos que são executado no roteador exigirão o espaço de DRAM adicional.
Feedback