Solucionar problemas de alta utilização da CPU no roteador ASR1000 Series

Introdução

Este documento descreve como resolver problemas de alta utilização da CPU em um roteador da série ASR1000.

Pré-requisito

Requisitos

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

Descrição

A alta utilização da CPU 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, espera-se um aumento no uso da CPU, enquanto em outros pode indicar um problema. A utilização elevada e transitória da CPU no roteador devido à alteração da rede ou da configuração pode ser ignorada e é o comportamento esperado.

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

As causas da alta utilização da CPU são:

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

A alta utilização da CPU 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 de plano de controle, pois a rede voltará a convergir. Portanto, precisamos determinar a causa raiz da superutilização da CPU para determinar se é um comportamento ou um problema esperado.

Abaixo está um diagrama que detalha um processo passo a passo sobre como solucionar um problema de alta utilização da CPU:

Etapas de solução de problemas

Etapa 1 - Identificar o módulo com alta utilização da CPU

O ASR1000 tem várias CPUs diferentes em módulos diferentes. Portanto, precisamos ver qual módulo mostra um uso maior que o normal. Isso pode ser visto através do valor Idle, quanto menor o valor idle, 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 no dispositivo apresenta alta utilização da CPU. É o 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 ocioso baixo, continue na etapa 2, ponto 1

Se o ESP tiver um valor ocioso baixo, vá para o Passo 3 Ponto 2 

Se o SIP tiver um valor ocioso 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 Íntegro 0,00 0,02 0,00
   ESP0 Saudável 0,01 0,02 0,00
   SIP0 Íntegro 0,00 0,01 0,00

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

   Utilização da CPU
   Slot CPU User System Nice 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 todos os valores de Ocioso forem relativamente altos, talvez não seja um problema de plano de controle. Para solucionar problemas do plano de dados, o QFP do ESP precisa ser observado. Sintomas de "alta utilização da CPU" ainda podem ser observados devido a um QFP superutilizado, o que não resultará em alta utilização da CPU nos processadores do plano de controle. Vá para o Passo 6.

Etapa 2 - Analisar o módulo

• Processador de rota

Confirme dentro do RP qual processador tem 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 de CPU do IOS estiver alta (linux_iosd-image), então ela será o IOS do RP. Vá para o Passo 3

Se a porcentagem de CPU de outros processos for alta, é 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 tem alta utilização da CPU. É a FECP?

   show platform software process slot FP ative monitor

Se os processos estiverem altos, é o FECP e, em seguida, vá para a ETAPA 5

Se não for o FECP, não será um problema relacionado aos processos do plano de controle dentro do ESP. Se sintomas como latência de rede ou quedas de fila ainda forem observados, o plano de dados pode precisar ser analisado quanto à superutilização. Vá para o Passo 6

• Processador de interface SPA

Se o SIP tiver alta utilização da CPU, o IOCP terá alta utilização da CPU. Determinar quais processos no IOCP apresentam alta utilização da CPU.

Execute 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. Continue na ETAPA 7

Etapa 3 - Processos do IOS

Consulte a saída abaixo, o primeiro percentual é a utilização total da CPU e o segundo percentual é a utilização da CPU para interrupção, que é a quantidade de CPU usada para processar pacotes puntados.

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

Se o percentual de interrupção for baixo, mas o total de CPU for alto, haverá um ou mais processos que serão observados para utilizar a CPU por um longo período.

Confirme dentro do IOS quais processos são observados como tendo alta utilização da CPU com o comando abaixo.

   show processes cpu sorted

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

   Router#show processes cpu sorted

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

   Tempo de Execução de PID (ms) Chamado Segundos 5Seg 1Min 5Min TTY Processo

   Tempo de Execução de PID (ms) Chamado Segundos 5Seg 1Min 5Min TTY Processo

   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 do SBC

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

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

    63 3132 11143 281 0,07% 0,07% 0,07% 0 Tarefa IPC IOSD   

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

     6 19 12 1583 0,00% 0,00% 0,00% 0 RF Slave Principal Th

     8 0 1 0 0.00% 0.00% 0.00% 0 RO Temporizadores de notificação

     7 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN      

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

     9 5671 538 10540 0,00% 0,14% 0,12% 0 Cheque pilhas     

Etapa 4 - Processos Linux

Se for observado que o IOS superutilizou a CPU, será necessário observar a utilização da CPU para o processo individual do Linux. Esses processos são os outros listados no monitor ativo do RP do slot de processo do software da plataforma. Identifique que processo ou processos são observados para que haja alta utilização da CPU e, em seguida, vá para a ETAPA 7.

Etapa 5 - Processos FECP

Se um processo ou processos forem altos, é provável que esses processos no FECP sejam responsáveis pela alta utilização da CPU, continue na 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, exiba a carga do processo e continue na ETAPA 7

   Router#show platform hardware qfp ative datapath usage

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

    Entrada:  Prioridade (pps) 0 0 0

                     (bps) 208 176 176 176

        Não Prioritário (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 Prioritário (pps) 0 1 1 1

                     (bps) 0 6488 6496 6488

              Total (pps) 0 1 1 1

                     (bps) 192 648 6656 6648

    Processamento: Carga (pct) 0 0 0

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

Com o processo ou processos que foram observados como tendo a CPU superutilizada identificada, há uma imagem mais clara do motivo pelo qual a CPU alta 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 outros problemas. As etapas acima para solucionar problemas ajudarão o engenheiro a isolar o problema com mais eficiência.

Exemplo de solução de problemas

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

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

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

   Utilização da CPU
   Slot CPU User System 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 de ociosidade no RP0 é muito baixa, isso sugere um problema alto de CPU dentro do processador de rotas. Portanto, para fazer troubleshooting adicional, identificaremos qual processador no RP apresenta alta utilização da CPU.

   Router#show processes cpu sorted
   Utilização da CPU por cinco segundos: 84%/36%; um minuto: 34%; cinco minutos: 9%
   Tempo de Execução de PID (ms) Chamado Segundos 5Seg 1Min 5Min TTY Processo
   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 IOSD ipc
   159 74792 2645991 28 0,15% 0,06% 0,06% 0 VRRS Thread principal
   116 53685 169683 316 0,15% 0,05% 0,01% 0 Empregos Por Segundo
     9 305547 26511 11525 0,15% 0,28% 0,16% 0 Check-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 Medidor de Carga
   446 416 33932 12 0,07% 0,00% 0,00% 0 processo VDC
   164 59945 5261819 11 0,07% 0,04% 0,02% 0 Tempo de Repetição do IP ARP
    43 1703 16969 100 0,07% 0,00% 0,00% 0 Keep Alive M de IPC  

A partir dessa saída, pode-se observar que o percentual total de CPU e o percentual de interrupção são maiores do que o esperado. O processo superior que utiliza a CPU é o "IOSXE-RP Punt Se", que é o processo que manipula o tráfego para a CPU RP, portanto, podemos examinar melhor esse tráfego que é lançado no 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 de rxdone = 90100722
   contagem de txdone = 100436
   Contagem de tipo de partícula no Rx = 0
   Tx sem contagem de tipo de partícula = 0
   Txbuf da contagem de sombras = 0
   Sem início de pacote = 0
   Sem fim de pacote = 0
   Estatísticas de queda de punt:
   Versão incorreta 0
   Tipo inválido 0
   Cabeçalho de recurso 0
   Cabeçalho de plataforma 0
   Cabeçalho do recurso ausente 0
   Incompatibilidade de cabeçalho comum 0
   Tamanho total inválido 0
   Comprimento de pacote inválido 0
   Deslocamento de rede inválido 0
   Cabeçalho não pontuado 0
   Tipo de link desconhecido 0
   Sem fenda 1
   Cabeçalho inválido do recurso ESS 0
   Sem recurso ESS 0
   Sem recurso SSLVPN 0
   Punt For Us tipo desconhecido 0
   Causa do punt fora do intervalo 0
   O pacote Punt IOSXE-RP causa:
       62210226 pacotes herdados e de controle da Camada 2
            147 pacotes de solicitação ou resposta ARP
       Pacotes de dados 27801234 For-us
          84426 pacotes de keepalive RP<->QFP
              6 pacotes de adjacência de Glean
           1647 pacotes de controle para uso

       Estatísticas do protocolo IPv4 de controle FOR_US:
              1.647 pacotes OSPF
   Histograma do pacote (500 bytes/bin), tamanho médio em 92, de 56:
    Pak-Size In-Count Out-Count
         + de 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 For-us" que indicam o tráfego direcionado para o roteador. Esse contador foi confirmado como tendo sido incrementado a partir da observação do comando várias vezes ao longo de vários minutos. Isso confirma que a CPU é superutilizada por uma grande quantidade de tráfego pontilhado, que geralmente controla o tráfego 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, podemos identificar a causa potencial da alta utilização da CPU e isso ajuda a identificar e 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 apontado para o RP, o que permitiria que a causa raiz fosse identificada e resolvida para evitar um problema semelhante no futuro.

Uma vez concluída a captura de um pacote, alguns exemplos de tráfego punted potencial são:

• ARP: Isso pode ocorrer devido a um número excessivo de solicitações ARP, que ocorreriam se vários endereços IP enviassem solicitações ARP através da configuração de uma rota IP para uma interface de broadcast. Isso também pode ocorrer devido a entradas liberadas da tabela ARP e terá que ser reaprendido com base nas entradas de endereço MAC que envelhecem ou nas interfaces que surgem/desaparecem.

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

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

• Atualizações de rota: Frequentemente, um influxo de atualizações de rotas será devido a uma reconvergência de rede, ou oscilações de link. Isso pode indicar rotas que ficam inoperantes dentro da rede ou dispositivos inteiros que ficam inoperantes, 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 utilização da CPU, quando se trata de um nível de processo individual. A partir daqui, 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 seguir está uma lista de outros comandos úteis adicionais a serem utilizados e são ordenados 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 a memória de processo individual e as alocações de CPU
• <show platform software infrastructure punt>
  • Fornece informações sobre todo o tráfego apontado para o RP
• <show platform software status control-processor brief>
  • Detalha a carga e a "integridade" da CPU, bem como detalha a memória e as estatísticas do módulo
• <show platform software process slot r0|monitor r1>
  • Detalha os diferentes processos e suas alocações de CPU e Memória no módulo selecionado
• <processo do software da plataforma do monitor 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 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>
  • Detalha os diferentes processos e suas alocações de CPU e Memória no módulo selecionado
• <processo f0|f1 do software da plataforma do monitor>
  • Fornece um feed ao vivo que atualiza os processos à medida que eles utilizam a CPU
  • Requer que o comando "terminal terminal-type" seja inserido no modo de configuração global para funcionar corretamente