Este documento descreve como solucionar problemas de alta utilização de CPU causados por diferentes processos.
Recomendamos que você leia Troubleshooting de Alta Utilização da CPU em Cisco Routers antes de continuar com este documento.
Este documento não se restringe a versões de software e hardware específicas.
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 você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.
A alta utilização da CPU no processo de entrada Address Resolution Protocol (ARP) ocorre se o roteador tiver que originar um número excessivo de solicitações ARP. O roteador usa ARP para todos os hosts, não apenas para aqueles na sub-rede local, e as solicitações ARP são enviadas como broadcasts, o que causa mais utilização da CPU em cada host na rede. As solicitações ARP para o mesmo endereço IP têm taxa limitada para uma solicitação a cada dois segundos, portanto, um número excessivo de solicitações ARP teria que se originar para endereços IP diferentes. Isso pode acontecer se uma rota IP foi configurada apontando para uma interface de transmissão. Um exemplo mais óbvio é uma rota padrão como:
ip route 0.0.0.0 0.0.0.0 Fastethernet0/0
Nesse caso, o roteador gera uma solicitação ARP para cada endereço IP que não pode ser acessado por meio de rotas mais específicas, o que praticamente significa que o roteador gera uma solicitação ARP para quase todos os endereços na Internet. Para obter mais informações sobre como configurar o endereço do próximo salto para o roteamento estático, consulte Especificando um endereço IP do próximo salto para rotas estáticas.
Como alternativa, uma quantidade excessiva de solicitações ARP pode ser causada por um fluxo de tráfego mal-intencionado que verifica através de sub-redes localmente conectadas. Uma indicação de tal fluxo seria a presença de um número muito alto de entradas ARP incompletas na tabela ARP. Como os pacotes IP de entrada que disparariam solicitações ARP teriam que ser processados, a identificação e solução de problemas desse problema seria essencialmente a mesma solução de problemas de alta utilização da CPU no processo de entrada de IP.
O processo de Entrada IPX é semelhante ao processo de Entrada IP no sentido de que toma conta da comutação de processos, exceto que o processo de Entrada IPX comuta pacotes IPX. Quase todos os pacotes IPX estão no nível de processo analisado pela Entrada IPX antes de serem enfileirados para outros processos IPX, como IPX SAP In, IPX RIP In e assim por diante. Diferentemente do IP, o IPX suporta apenas um modo de switching de interrupção, que é a switching rápida IPX, que é ativada por padrão. A comutação rápida IPX é ativada com o uso do comando de interface ipx route-cache .
Se você observar alta utilização da CPU durante o processo de entrada IPX, verifique o seguinte:
A comutação rápida IPX está desativada. Use o comando show ipx interface se a comutação rápida IPX estiver desativada.
Não é possível comutar rapidamente o IPX de parte do tráfego IPX.
Broadcasts IPX - Verifique se o roteador está sobrecarregado com broadcasts IPX usando o comando show ipx traffic.
Atualizações de roteamento IPX - Se houver muitas instabilidades na rede, o processamento de atualização de roteamento aumentará.
Observação: em vez do IPX RIP, use o IPX EIGRP (incremental) para reduzir a quantidade de atualizações, especialmente em links seriais de baixa velocidade (consulte Roteamento de Novell IPX em linhas seriais lentas e Gerenciamento SAP para obter detalhes).
Observação: mais documentos relacionados ao IPX podem ser encontrados na página de suporte da tecnologia Novell IPX.
Quando o processo de cronômetro de TCP (Transmission Control Protocol) usa muitos recursos da CPU, isso indica que há muitos pontos finais de conexão TCP. Isso pode acontecer em ambientes de switching de enlace de dados (DLSw) com muitos peers ou em outros ambientes onde muitas sessões TCP são abertas simultaneamente no roteador.
O temporizador de controle FIB inicializa e inicia o temporizador de coleta de estatísticas FIB para estatísticas por VLAN e estatísticas globais; inicializa e inicia o temporizador de solicitação/exceção FIB/ADJ; mantém as funções de registro relacionadas a FIB; e inicializa o temporizador de contabilidade BGP. Esses processos são iniciados quando o EARL é inicializado.
O processo TTY Background é um processo genérico usado por todas as linhas de terminal (console, aux, assíncrona etc.). Normalmente, não deve haver nenhum impacto no desempenho do roteador, pois esse processo tem uma prioridade mais baixa em comparação com os outros processos que precisam ser programados pelo software Cisco IOS.
Se esse processo usar muito a CPU, verifique se o "logging synchronous" está configurado em "line con 0". A causa possível poderia ser o bug da Cisco ID CSCed16920 (somente clientes registrados) Cisco ID ou CSCdy01705 (somente clientes registrados) .
A utilização da CPU vista para o processo "TAG Stats Background" é esperada e não afeta o encaminhamento de tráfego.
O plano de fundo de estatísticas de TAG é um processo de baixa prioridade. Esse processo coleta estatísticas para marcas e as encaminha para o RP. Não é uma função da quantidade de tráfego, mas da quantidade de trabalho que o plano de controle MPLS/LDP faz. Esse é um comportamento esperado e não afeta o encaminhamento de tráfego. Esse problema está documentado no bug CSCdz32988 (somente clientes registrados) .
Um modelo virtual (vtemplate) deve ser clonado para cada nova interface de acesso virtual sempre que um novo usuário for conectado ao roteador ou ao servidor de acesso. A utilização da CPU no processo Vtemplate Backgr poderá ficar extremamente alta, caso o número de usuários seja grande. Evite isto, configurando uma pré-clonagem do modelo virtual. Para obter mais informações, consulte Aprimoramentos de escalabilidade de sessão.
O processo Plano de Fundo Líquido é executado sempre que um buffer é necessário, mas não está disponível para o processo ou interface. Ele cria os buffers desejados a partir do pool principal com base na solicitação. O plano de fundo da rede também gerencia a memória usada por cada processo e limpa a memória liberada. Esse processo está principalmente associado às interfaces e pode consumir recursos significativos da CPU. Os sintomas de alta utilização da CPU são o aumento de aceleradores, ignorações, saturações e reinicializações em uma interface.
O processo em segundo plano de IP envolve estes procedimentos: o envelhecimento periódico do cache de redirecionamento ICMP a cada minuto; uma alteração do tipo de encapsulamento de uma interface; a movimentação de uma interface para um novo estado, UP e/ou DOWN; uma alteração no endereço IP da interface; a expiração de um novo mapa dxi; e a expiração dos temporizadores do discador.
O processo IP Background modifica a tabela de roteamento de acordo com o status das interfaces, enquanto o processo IP Background assume que há uma alteração de link-state quando recebe mensagens de alteração de link-state. Em seguida, notifica todos os protocolos de roteamento para verificar a interface afetada. Se mais interfaces executam protocolos de roteamento, uma utilização maior da CPU é causada pelo processo IP Background.
Os processos em segundo plano ARP lidam com vários trabalhos e podem consumir alta utilização da CPU.
Esta lista fornece alguns exemplos de trabalhos:
Liberação de ARP devido a eventos up/down de interface
Limpando a tabela ARP através do comando clear arp
Pacotes de entrada ARP
ager ARP
Se qualquer outro processo estiver consumindo muitos recursos da CPU e não houver indicação de nenhum problema nas mensagens registradas, o problema poderá ser causado por um bug no software Cisco IOS®. Utilizando um Bug Toolkit (somente clientes registrados), execute uma pesquisa do processo especificado para verificar se foram relatados alguns bugs.
Se você ainda precisar de assistência após seguir as etapas de solução de problemas acima e quiser criar uma solicitação de serviço com o Cisco TAC, certifique-se de incluir as seguintes informações: |
---|
|
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
29-Sep-2008 |
Versão inicial |