Solucionar problemas de CPU alta no roteador ASR1000 Series

Introduction

Este documento descreve como solucionar problemas de alta CPU em um roteador da série ASR1000.

Pré-requisito

Requirements

A Cisco recomenda que você compreenda a arquitetura ASR1000 para interpretar e utilizar este documento. 

Descrição

A CPU alta em um roteador Cisco pode ser definida como a condição em que a utilização da CPU no roteador está acima do uso normal. Em alguns cenários, o aumento no uso da CPU é esperado, enquanto em outros pode indicar um problema. A alta utilização transitória da CPU no roteador devido a alterações na rede ou na configuração pode ser ignorada e é esperado comportamento.

No entanto, um roteador que experimenta alta utilização da CPU por períodos prolongados sem nenhuma alteração na rede ou na configuração é incomum e precisa ser analisado. Portanto, quando usada em excesso, a CPU não consegue atender ativamente todos os outros processos, o que resulta em uma linha de comando lenta, latência do plano de controle, descartes de pacotes e falha de serviços.

As causas da alta CPU são:

1. A CPU do plano de controle recebe muito tráfego punt
2. Um processo que se comporta inesperadamente e resulta em excesso de utilização da CPU
3. O processador de plano de dados é superutilizado/com excesso de assinaturas
4. Demasiadas interrupções do processador

A CPU alta nem sempre é um problema do roteador da série ASR1000, pois a utilização da CPU do roteador é diretamente proporcional à carga no roteador.  Por exemplo, se houver uma alteração na rede, isso causará uma grande quantidade de tráfego do plano de controle à medida que a rede for convergindo novamente. Portanto, precisamos determinar a causa raiz da superutilização da CPU para determinar se é um comportamento esperado ou um problema.

Abaixo está um diagrama que detalha um processo passo a passo sobre como solucionar um problema de alta CPU:

Etapas de solução de problemas

Etapa 1 - Identificar o módulo com CPU alta

O ASR1000 tem várias CPUs diferentes em diferentes módulos. Portanto, precisamos ver qual módulo mostra um uso maior do que o normal. Isso pode ser visto através do valor de ociosidade, pois quanto menor o valor de ociosidade, maior a utilização da CPU desse módulo. Todas essas CPUs diferentes refletem o plano de controle dos módulos.

Determine qual módulo dentro do dispositivo está sendo observado para experimentar uma CPU alta. É RP, ESP ou SIP com o comando abaixo?

   show platform software status control-processor brief

Consulte a saída abaixo para ver a coluna destacada

Se o RP tiver um valor de ociosidade baixo, vá para a Etapa 2 Ponto 1

Se o ESP tiver um valor de ociosidade baixo, vá para a Etapa 3 Ponto 2 

Se o SIP tiver um valor de ociosidade baixo, vá para a Etapa 4 Ponto 3

   Router#show platform software status control-processor brief

   Média de carga
   Status do slot 1-Min 5-Min 15-Min
   RP0 Saudável 0,00 0,02 0,00
   ESP0 Saudável 0,01 0,02 0,00
   SIP0 Saudável 0,00 0,01 0,00

   Memória (kB)
   Status Do Slot Total Usado (Pct) Livre (Pct) Confirmado (Pct)
   RP0 Saudável 2009376 1879196 (94%) 130180 ( 6%) 1432748 (71%)
   ESP0 Saudável 2009400 692100 (34%) 1317300 (66%) 472536 (24%)
   SIP0 Saudável 471804 284424 (60%) 187380 (40%) 193148 (41%)

   Utilização da CPU
   Slot CPU Sistema de usuário Nice Idle Idle IRQ SIRQ IOwait
   RP0 0 2.59 2.49 0.00 94.80 0.00 0.09 0.00
   ESP0 0 2.30 17.90 0.00 79.80 0.00 0.00 0.00
   SIP0 0 1.29 4.19 0.00 94.41 0.09 0.00 0.00

Se os valores de ociosidade forem relativamente altos, isso pode não ser um problema do plano de controle. Para solucionar problemas no plano de dados, o QFP do ESP precisa ser observado. Os sintomas de "alta CPU" ainda podem ser observados devido a um QFP superutilizado, o que não resultará em alta CPU nos processadores do plano de controle. Vá para o Passo 6.

Etapa 2 - Analisar o módulo

• Processador de rota

Confirme no RP qual processador é observado com alta utilização da CPU com o comando abaixo. É o processo Linux ou o IOS?

   show platform software process slot RP ative monitor

Se a porcentagem da CPU do IOS é alta (linux_iosd-imag), então é o IOS do RP. Vá para o Passo 3

Se o percentual de CPU de outros processos for alto, é provável que seja o processo Linux. Vá para o Passo 4

• Processador de serviços integrados

Confirme dentro do ESP se o processador do plano de controle é observado com alta utilização da CPU. É a FECP?

   

   show platform software process slot FP ative monitor

Se os processos estiverem altos, então é o FECP e continue na ETAPA 5

Se não for a FECP, não é um problema relacionado ao plano de controle no ESP. Se sintomas como latência de rede ou quedas de fila ainda forem observados, o plano de dados pode precisar ser revisto para verificar se há sobreutilização. Vá para o Passo 6

• Processador de interface SPA

Se o SIP for observado como tendo alta utilização da CPU, o IOCP será observado como tendo alta CPU. Determine que processo ou processos dentro do IOCP são observados como tendo alta utilização da CPU.

Realize uma captura de pacote e identifique qual tráfego é maior do que o normal e quais processos estão associados a esse tipo de tráfego. Vá para o Passo 7

Etapa 3 - Processos do IOS

Consulte a saída abaixo, a primeira porcentagem é a utilização total da CPU e a segunda porcentagem é a utilização da CPU de interrupção, que é a quantidade de CPU usada para processar pacotes pontuados.

Se a porcentagem de interrupção for alta, isso significa que uma grande quantidade de tráfego é direcionada ao RP, (isso pode ser confirmado com o comando show platform software infrastructure punt)

Se a porcentagem de interrupção for baixa, mas a CPU total for alta, então haverá um processo ou processos que serão observados para utilizar a CPU por um período prolongado.

Confirme no IOS qual processo ou processos são observados para ter alta utilização da CPU com o comando abaixo.

   show processes cpu ordenado

Identifique qual porcentagem é alta (CPU total ou CPU de interrupção) e, se necessário, identifique o processo/processos individuais. Vá para o Passo 7

   Router#show processes cpu ordenada

   Utilização da CPU por cinco segundos: 0%/0%; um minuto: 1%; cinco minutos: 1%

   Tempo(s) de execução do PID Chamado em segundo 5 segundos Processo de 1 min. de 5 min. de TTY

   Tempo(s) de execução do PID Chamado em segundo 5 segundos Processo de 1 min. de 5 min. de TTY

   188 8143 434758 18 0,15% 0,18% 0,19% 0 Ethernet Msec Ti

   515 380 7050 53 0,07% 0,00% 0,00% 0 processo principal de SBC

     3 2154 215 10018 0,07% 0,00% 0,19% 0 Exec            

   380 1783 55002 32 0,07% 0,06% 0,06% 0 MMA DB TIMER    

    63 3132 11143 281 0,07% 0,07% 0,07% 0 tarefa do IOSD ipc   

     5 1 2 500 0,00% 0,00% 0,00% 0 IPC ISSU Dispatc

     6 19 12 1583 0,00% 0,00% 0,00% 0 RF Escravo Principal

     0 0.00% 0.00% 0.00% 0 RO Notificar Temporizadores

     7 0 1 0 0,00% 0,00% 0,00% 0 EDDRI_MAIN      

    10 6 75 80 0,00% 0,00% 0,00% 0 gerenciador de pool    

     9 5671 538 10540 0,00% 0,14% 0,12% 0 Verificar heaps     

Etapa 4 - Processos Linux

Se se observar que o IOS tem superutilizado a CPU, então precisamos observar a utilização da CPU para o processo de linux individual. Esses processos são os outros processos listados no show platform software process slot RP ative monitor. Identifique qual processo ou processos são observados para ter uma CPU alta e, em seguida, continue com a ETAPA 7.

Etapa 5 - Processos FECP

Se um processo ou processos forem altos, é provável que esses sejam os processos dentro da FECP responsáveis pela alta utilização da CPU, continue com a ETAPA 7

Etapa 6 - Utilização do QFP

O Quantum Flow Processor é o ASIC de encaminhamento. Para determinar a carga no mecanismo de encaminhamento, o QFP pode ser monitorado. O comando abaixo lista os pacotes de entrada e saída (prioridade e não prioridade) em pacotes por segundo e bits por segundo. A linha final exibe a quantidade total de carga da CPU devido ao encaminhamento de pacotes em uma porcentagem.

   show platform hardware qfp ative datapath usage

Identifique se a entrada ou a saída estão altas, visualize a carga do processo e continue na ETAPA 7

   Router#show platform hardware qfp ative datapath usage

     CPP 0: Subdev 0 5 seg 1 min 5 min 60 min

    Entrada:  Prioridade (pps) 0 0 0

                     (bps) 208 176 176 176

        Não Prioridade (pps) 0 2 2 2

                     (bps) 64 784 784 784

               Total (pps) 0 2 2 2

                     (bps) 272 960 960 960

    Saída: Prioridade (pps) 0 0 0

                     (bps) 192 160 160 160

        Não prioridade (pps) 0 1 1 1

                     (bps) 0 6488 6496 6488

              Total (pps) 0 1 1 1

                     (bps) 192 6648 6656 6648

    Processamento: Carregar (pct) 0 0 0

Etapa 7 - Determinar a causa raiz e identificar a correção

Com o(s) processo(s) observado(s) ter(em) superutilizado(s) a CPU identificada(s), há uma imagem mais clara do motivo pelo qual a alta utilização da CPU ocorreu. Para continuar, pesquise as funções executadas pelo processo identificado. Isso ajudará a determinar um plano de ação sobre como abordar o problema. Por exemplo - Se o processo for responsável por um protocolo específico, talvez você queira examinar a configuração relacionada a esse protocolo.

Se você ainda tiver problemas relacionados à CPU, é recomendável entrar em contato com o TAC para permitir que um engenheiro o ajude a solucionar os problemas. As etapas acima para solucionar o problema ajudarão o engenheiro a isolar o problema com mais eficiência.

Exemplo de solução de problemas

Neste exemplo, executaremos o processo de solução de problemas e tentaremos identificar melhor uma possível causa raiz para a alta CPU do roteador. Para começar, determine qual módulo é observado para experimentar a CPU alta, temos a saída abaixo:  

   Router#show platform software status control-processor brief
   Média de carga
   Status do slot 1-Min 5-Min 15-Min
   RP0 Saudável 0,66 0,15 0,05
   ESP0 Saudável 0,00 0,00 0,00
   SIP0 Saudável 0,00 0,00 0,00

   Memória (kB)
   Status Do Slot Total Usado (Pct) Livre (Pct) Confirmado (Pct)
   RP0 Saudável 2009376 1879196 (94%) 130180 ( 6%) 1432756 (71%)
   ESP0 Saudável 2009400 692472 (34%) 1316928 (66%) 472668 (24%)
   SIP0 Saudável 471804 284556 (60%) 187248 (40%) 193148 (41%)

   Utilização da CPU
   Slot CPU Sistema de usuário Nice Idle IRQ SIRQ IOwait
   RP0 0 57.11 14.42 0.00 0.00 28.25 0.19 0.00
   ESP0 0 2.10 17.91 0.00 79.97 0.00 0.00 0.00
   SIP0 0 1.20 6.00 0.00 92.80 0.00 0.00 0.00

Como a quantidade ociosa dentro do RP0 é muito baixa, isso sugere um problema de alta CPU dentro do Route Processor. Portanto, para solucionar mais problemas, identificaremos qual processador dentro do RP é observado para experimentar alta CPU.

   Router#show processes cpu ordenada
   Utilização da CPU por cinco segundos: 84%/36%; um minuto: 34%; cinco minutos: 9%
   Tempo(s) de execução do PID Chamado em segundo 5 segundos Processo de 1 min. de 5 min. de TTY
   107 303230 50749 5975 46,69% 18,12% 4,45% 0 IOSXE-RP Punt Se
    63 105617 540091 195 0,23% 0,10% 0,08% 0 tarefa de ipc do IOSD
   159 74792 2645991 28 0,15% 0,06% 0,06% 0 VRRS Fio principal
   116 53685 169683 316 0,15% 0,05% 0,01% 0 por segundo de emprego
     9 305547 26511 11525 0,15% 0,28% 0,16% 0 Verificar heaps
   188 362507 20979154 17 0,15% 0,15% 0,19% 0 Ethernet Msec Ti
     3 147 186 790 0,07% 0,08% 0,02% 0 Exec
     2 32126 33935 946 0,07% 0,03% 0,00% 0 Carga Meter
   446 416 33932 12 0,07% 0,00% 0,00% 0 processo VDC
   164 59945 5261819 11 0,07% 0,04% 0,02% 0 IP ARP Idade da repetição
    43 1703 16969 100 0,07% 0,00% 0,00% 0 IPC Keep Alive M  

A partir dessa saída, pode-se observar que a porcentagem total da CPU e a porcentagem de interrupção são maiores do que o esperado. O processo principal que utiliza a CPU é o "IOSXE-RP Punt Se", que é o processo que trata o tráfego para a CPU RP, portanto podemos examinar mais detalhadamente esse tráfego que é direcionado para o RP.

  

   Router#show platform software infrastructure punt
   Estatísticas internas da interface LSMPI:
   enabled=0, disabled=0, throttled=0, unthrottled=0, estado pronto
   Buffers de entrada = 90100722
   Buffers de saída = 100439
   contagem rxdone = 90100722
   contagem txdone = 100436
   Rx sem contagem de tipo de partição = 0
   Tx sem contagem de tipo de partição = 0
   Txbuf da contagem de sombra = 0
   Nenhum início de pacote = 0
   Sem fim de pacote = 0
   Estatísticas de queda:
   Versão incorreta 0
   Tipo 0 com problema
   Cabeçalho do recurso ocupado 0
   Tinha cabeçalho de plataforma 0
   Cabeçalho do recurso ausente 0
   Incompatibilidade de cabeçalho comum 0
   Comprimento total inválido 0
   Comprimento do pacote com problema 0
   Deslocamento de rede inválido 0
   Cabeçalho não punt 0
   Tipo de link desconhecido 0
   Sem swidb 1
   Cabeçalho de recurso ESS com problema 0
   Nenhum recurso ESS 0
   Nenhum recurso SSLVPN 0
   Tipo de busca para nós desconhecido 0
   Causa de busca fora do intervalo 0
   O pacote de busca IOSXE-RP causa:
       62210226 Camada 2 controle e pacotes herdados
            147 pacotes de solicitação ou resposta ARP
       27801234 Pacotes de dados para uso
          84426 RP<->pacotes de keepalive QFP
              6 pacotes de adjacência Glean
           1647 Pacotes de controle para uso

       Estatísticas do protocolo IPv4 de controle FOR_US:
              1647 pacotes OSPF
   Histograma de pacotes (500 bytes/bin), tamanho médio em 92, saída 56:
    Contagem de Saída de Pak-Size
         0+: 90097805 98790
       Mais de 500: 0 7

A partir dessa saída, podemos ver que há uma grande quantidade de pacotes nos "Pacotes de dados para uso" que indicam o tráfego direcionado para o roteador. Confirmou-se que esse contador foi incrementado da observação do comando várias vezes em vários minutos. Isso confirma que a CPU é superutilizada por uma grande quantidade de tráfego punted, que geralmente controla o tráfego do plano. O tráfego do plano de controle pode incluir ARP, SSH, SNMP, atualizações de rota (BGP, EIGRP, OSPF) etc. A partir dessas informações, somos capazes de identificar a causa potencial da alta CPU e isso ajuda a solucionar problemas da causa raiz. Por exemplo, uma captura de pacote ou um monitor de tráfego diferente poderia ser implementado para ver o tráfego exato direcionado ao RP, o que permitiria que a causa raiz fosse identificada e resolvida para evitar um problema semelhante no futuro.

Quando uma captura de pacote é concluída, alguns exemplos de tráfego punido em potencial são:

• ARP: Isso pode ser devido a um número excessivo de solicitações ARP, que ocorreria se vários endereços IP enviassem solicitações ARP por meio da configuração de uma rota IP para uma interface de broadcast. Isso também pode ser devido a entradas descarregadas da tabela ARP e precisará ser aprendida novamente com base nas entradas de endereço MAC que expiram ou interfaces com a configuração ativa/inativa.

• SSH: Isso pode causar alta CPU devido a um grande comando show (show tech-support) ou quando muitos comandos debug estão ativados, o que força muita CLI a ser enviada pela sessão SSH.

• SNMP: Isso pode ser devido ao agente SNMP que leva um longo período de tempo para processar uma solicitação e, portanto, causa a alta CPU. Frequentemente, duas causas prováveis são MIBs que são pesquisadas, ou tabelas de rota e/ou ARP que são pesquisadas pelo NMS.

• Atualizações de rotas: Frequentemente, um influxo de atualizações de rota será devido a uma reconvergência de rede, ou flaps de link. Isso pode indicar rotas que ficam inoperantes na rede ou dispositivos inteiros que são desativados, o que força a rede a convergir e recalcular as melhores rotas, o que depende de qual protocolo de roteamento está em uso.

Isso destaca como a causa raiz pode ser isolada por meio da identificação da causa da alta CPU, quando se trata de um nível de processo individual. A partir daí, o processo ou protocolo individual pode ser analisado isoladamente para identificar se é um problema de configuração, de software, de projeto de rede ou de prática pretendida.

Comandos adicionais

A lista a seguir contém outros comandos úteis adicionais a serem usados e classificados por qual processador eles se relacionam:

Processador de rota

• <show process cpu history>
  • Fornece um gráfico do histórico da CPU nos últimos 60 segundos, minutos e 72 horas
• <show process process_ID>
  • Informações detalhadas sobre alocações de memória e CPU de processos individuais
• <show platform software infrastructure punt>
  • Fornece informações sobre todo o tráfego que é direcionado ao RP
• <show platform software status control-processor brief>
  • Detalha a carga e a "integridade" da CPU, bem como detalha as estatísticas da memória e do módulo
• <show platform software process slot r0|r1 monitor>
  • Detalhes dos diferentes processos e suas alocações de CPU e Memória no módulo selecionado
• <monitor platform software process r0|r1>
  • Fornece um feed ao vivo que atualiza os processos à medida que eles utilizam a CPU
  • Requer que o comando "terminal terminal-type" seja inserido primeiro no modo de configuração global para funcionar corretamente

Processador de serviços integrados

• <show platform software process list fp ative summary>
  • Detalha um resumo de todos os processos executados na CPU, bem como a carga média
• <show platform software process slot f0|f1 monitor>
  • Detalhes dos diferentes processos e suas alocações de CPU e Memória no módulo selecionado
• <processo de software da plataforma de monitor f0|f1>
  • Fornece um feed ativo que atualiza os processos à medida que utilizam a CPU
  • Requer que o comando "terminal terminal-type" seja inserido primeiro no modo de configuração global para funcionar corretamente