Introdução
Este documento descreve como solucionar problemas de alta utilização da CPU devido ao processo de entrada de IP.
Pré-requisitos
Requisitos
A Cisco recomenda que você leia Troubleshooting de Alta Utilização da CPU em Cisco Routers antes de continuar com este documento.
Componentes Utilizados
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 a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Conventions
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
Observação: este documento não fornece estratégias para evitar diferentes tipos de ataques.
Entrada de IP
O processo do software Cisco IOS® chamado entrada IP cuida dos pacotes IP de switching de processo. Se o processo de entrada de IP usar recursos de CPU excepcionalmente altos, o roteador estará comutando o processo de grande parte do tráfego IP. Verifique estes problemas:
-
A comutação de interrupção é desativada em uma interface (ou interfaces) que tem (têm) muito tráfego
A comutação por interrupção refere-se ao uso de algoritmos de comutação diferentes da comutação por processo. Os exemplos incluem switching rápido, switching ideal, switching do Cisco Express Forwarding e assim por diante (consulte Conceitos básicos de ajuste de desempenho para obter detalhes). Examine a saída do comando show interfaces switching
para ver qual interface está sobrecarregada com tráfego. Você pode marcar a caixa show ip interface
para ver quais métodos de switching são usados em cada interface. Reative a switching de interrupção em tal interface. Lembre-se de que a comutação rápida regular é configurada em interfaces de saída: se a comutação rápida for configurada em uma interface, os pacotes que saem dessa interface serão comutados rapidamente. A comutação Cisco Express Forwarding é configurada nas interfaces de entrada. Para criar a base de informações de encaminhamento (FIB) e entradas de tabela de adjacência em uma interface específica, configure a switching do Cisco Express Forwarding em todas as interfaces que encaminham para essa interface.
-
A comutação rápida na mesma interface está desativada
Se uma interface tiver muitos endereços secundários ou subinterfaces e houver muito tráfego originado na interface e destinado a um endereço nessa mesma interface, todos esses pacotes serão comutados por processo. Nessa situação, você deve habilitar ip route-cache
same-interface
na interface. Quando a comutação Cisco Express Forwarding é usada, não é necessário habilitar a comutação Cisco Express Forwarding switching na mesma interface separadamente.
-
A comutação rápida em uma interface que fornece o roteamento de política está desativada
Se um mapa de rotas foi configurado em uma interface e muito tráfego é tratado pelo mapa de rotas, o processo do roteador comuta esse tráfego. Nessa situação, você deve habilitar ip route-cache policy
na interface. Verifique as restrições mencionadas na seção Habilitando o Roteamento Baseado em Políticas de Comutação Rápida de Configurando o Roteamento Baseado em Políticas.
-
O tráfego que não pode ser comutado por interrupção chega
Pode ser qualquer um dos tipos de tráfego listados. Clique nos itens vinculados para obter mais informações.
-
Pacotes para os quais ainda não há entrada no cache de switching
Mesmo que a switching rápida, ideal ou Cisco Express Forwarding (CEF) esteja configurada, um pacote para o qual não há correspondência no cache de switching rápida ou FIB e nas tabelas de adjacência é processado. Uma entrada é então criada no cache ou tabela apropriada e todos os pacotes subsequentes que correspondem aos mesmos critérios são comutados por CEF, rápidos ou ideais. Em circunstâncias normais, esses pacotes processados não causam alta utilização da CPU. No entanto, se houver um dispositivo na rede que 1) gere pacotes a uma taxa extremamente alta para dispositivos alcançáveis através do roteador e 2) use endereços IP de origem ou destino diferentes, não haverá uma correspondência para esses pacotes no cache de switching ou na tabela, então eles são processados pelo processo de entrada de IP (se a comutação NetFlow estiver configurada, as portas TCP de origem e destino são verificadas em relação às entradas no cache NetFlow também). Esse dispositivo de origem pode ser um dispositivo não funcional ou, mais provavelmente, um dispositivo tentando um ataque.
(*) Somente com adjacências glean. Consulte Compreender o Cisco Express Forwarding para obter mais informações sobre adjacências do Cisco Express Forwarding.
-
Pacotes destinados ao roteador
Estes são exemplos de pacotes destinados ao roteador:
-
Atualizações de roteamento que chegam a uma taxa extremamente alta. Se o roteador receber uma quantidade enorme de atualizações de roteamento que precisam ser processadas, essa tarefa poderá sobrecarregar a CPU. Normalmente, isso não pode acontecer em uma rede estável. A maneira pela qual você pode obter mais informações depende do Routing Protocol que você tem configurado. No entanto, você pode começar a verificar a saída do comando show ip route summary
periodicamente. Valores que mudam rapidamente são um sinal de uma rede instável. Mudanças frequentes na tabela de roteamento significam maior processamento do protocolo de roteamento, o que resulta em maior utilização da CPU. Para obter mais informações sobre como solucionar esse problema, consulte a seção Troubleshooting TCP/IP do Internetwork Troubleshooting Guide.
-
Qualquer outro tipo de tráfego destinado ao roteador. Verifique quem está conectado ao roteador e as ações do usuário. Se alguém estiver conectado e emitir comandos que produzam uma saída longa, a alta utilização da CPU pelo processo de "entrada IP" será seguida por uma utilização muito maior da CPU pelo processo Virtual Exec.
-
Ataque falso. Para identificar o problema, emita o comando show ip traffic
para verificar a quantidade de tráfego IP. Se houver um problema, o número de pacotes recebidos com um destino local é significativo. Em seguida, examine a saída do comando show interfaces
e show interfaces switching
para verificar em que interface os pacotes estão entrando. Depois de identificar a interface de recebimento, ative ip accounting
na interface de saída e veja se há um padrão. Se houver um ataque, o endereço de origem será quase sempre diferente, mas o endereço de destino será o mesmo. Uma lista de acesso pode ser configurada para resolver o problema temporariamente (preferencialmente no dispositivo mais próximo da origem dos pacotes), mas a solução real é rastrear o dispositivo de origem e parar o ataque.
-
Tráfego de broadcast
Verifique o número de pacotes de broadcast na show interfaces
Saída do comando. Se você comparar a quantidade de broadcasts com a quantidade total de pacotes recebidos na interface, poderá ter uma ideia se há uma sobrecarga de broadcasts. Se houver uma LAN com vários switches conectados ao roteador, isso pode indicar um problema com o Spanning Tree.
-
Pacotes IP sem opções
-
Pacotes que requerem conversão de protocolos
-
Multilink Point-to-Point Protocol (suportado na comutação Cisco Express Forwarding)
-
Tráfego compactado
Se não houver nenhum Adaptador de Serviço de Compactação (CSA) no roteador, os pacotes compactados deverão ser comutados por processo.
-
Tráfego criptografado
Se não houver nenhum Adaptador de Serviço de Criptografia (ESA) no roteador, os pacotes criptografados deverão ser comutados por processo.
-
Pacotes que passam pelas interfaces seriais com encapsulamento X.25
No conjunto de protocolos X.25, o controle de fluxo é implementado na segunda camada do Open System Interconnection (OSI).
-
Muitos pacotes, que chegam a uma taxa extremamente alta, para um destino em uma sub-rede diretamente conectada, para o qual não há entrada na tabela Address Resolution Protocol (ARP). Isso não é esperado com o tráfego TCP devido ao mecanismo de janelamento, mas pode acontecer com o tráfego UDP (User Datagram Protocol). Para identificar o problema, repita as ações sugeridas para rastrear um ataque falso.
-
Grande parte do tráfego multicast passa pelo roteador. Infelizmente, não há uma maneira fácil de examinar a quantidade de tráfego multicast. O show ip traffic
mostra apenas informações de resumo. No entanto, se tiver configurado o roteamento multicast no roteador, você poderá ativar a comutação rápida de pacotes multicast com o comando ip mroute-cache
comando de configuração de interface (a comutação rápida de pacotes multicast é desativada por padrão).
-
Excesso de assinaturas no roteador. Se o roteador estiver sobrecarregado e não puder lidar com essa quantidade de tráfego, tente distribuir a carga entre outros roteadores ou adquira um roteador de alto desempenho.
-
A Conversão de Endereço de Rede (NAT - Network Address Translation) IP está configurada no roteador e muitos pacotes do Sistema de Nome de Domínio (DNS - Domain Name System) passam pelo roteador. Os pacotes UDP ou TCP com a porta origem ou destino 53 (DNS) são sempre apontados para o nível de processo pelo NAT.
-
Há outros tipos de pacotes que são direcionados para o processamento.
-
Há fragmentação do datagrama IP. Há um pequeno aumento na sobrecarga da CPU e da memória devido ao fragmento de um datagrama IP. Consulte Resolver problemas de fragmentação de IP, MTU, MSS e PMTUD com GRE e IPSEC para obter mais informações sobre como solucionar esse problema.
Cuidado: qualquer que seja o motivo da alta utilização da CPU no processo de Entrada de IP, a origem do problema poderá ser rastreada se você depurar os pacotes IP. Como a utilização da CPU já está alta, o processo de depuração deve ser executado com extremo cuidado.
O processo de depuração produz muitas mensagens, portanto somente o registro colocado em buffer deve ser configurado.
Registrar-se em um console gera interrupções desnecessárias para a CPU e aumenta a utilização da CPU. O registro em um host (ou registro de monitor) gera tráfego adicional nas interfaces.
O processo de depuração pode ser iniciado com o comando debug ip packet detail exec
comando. Esta sessão não deve durar mais de três a cinco segundos. As mensagens de depuração são gravadas no buffer de registro. Uma captura de uma amostra de uma sessão de depuração IP é fornecida na seção Sessão de depuração de pacote IP de amostra deste documento. Quando o dispositivo de origem dos pacotes IP indesejados for encontrado, esse dispositivo poderá ser desconectado da rede ou uma lista de acesso poderá ser criada no roteador para descartar pacotes desse destino.
Exemplo de sessão de depuração de pacote IP
Os destinos de registro configurados devem ser verificados primeiro com o comando show logging
comando:
router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 52 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: level debugging, 148 messages logged
Trap logging: level informational, 64 message lines logged
Logging to 192.168.100.100, 3 message lines logged
Logging to 192.168.200.200, 3 message lines logged
--More--
Desative todos os destinos de registro, exceto o buffer de registro, e limpe o buffer de registro:
router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#no logging console
router(config)#no logging monitor
router(config)#no logging 192.168.100.100
router(config)#no logging 192.168.200.200
router(config)#^Z
router#clear logging
Clear logging buffer [confirm]
router#
Para melhor legibilidade da saída de depuração, os carimbos de data e hora e de milissegundo devem ser habilitados:
router#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
router(config)#service timestamps log datetime msec
router(config)#service timestamps debug datetime msec
router(config)#end
router#
Uma sessão de depuração pode ser iniciada agora:
router#debug ip packet detail
IP packet debugging is on (detailed)
A depuração não deve durar mais de três a cinco segundos. A sessão pode ser interrompida com o comando undebug all exec
comando:
router#undebug all
All possible debugging has been turned off
Os resultados podem ser verificados com o comando show logging exec
comando:
router#show logging
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: disabled
Monitor logging: disabled
Buffer logging: level debugging, 145 messages logged
Trap logging: level informational, 61 message lines logged
Log Buffer (64000 bytes):
*Mar 3 03:43:27.320: IP: s=192.168.40.53 (Ethernet0/1), d=10.254.2.204
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.324: ICMP type=8, code=0
*Mar 3 03:43:27.324: IP: s=192.168.40.53 (Ethernet0/1), d=10.254.2.205
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.324: ICMP type=8, code=0
*Mar 3 03:43:27.328: IP: s=192.168.40.53 (Ethernet0/1), d=10.254.2.206
(Ethernet0/0), g=10.200.40.1, len 100, forward
*Mar 3 03:43:27.328: ICMP type=8, code=0
...
O registro mostra que:
-
Um pacote foi recebido a cada quatro milissegundos
-
O endereço IP de origem é 192.168.40.53
-
Os pacotes chegaram na interface Ethernet0/1.
-
Os pacotes possuem diferentes endereços IP de destino
-
Os pacotes foram enviados na interface da Ethernet0/0
-
O Next-Hop IP Address é 10.200.40.1.
-
Os pacotes eram solicitações ICMP (tipo=8)
Neste exemplo, você pode ver que a alta utilização da CPU no processo de entrada de IP foi causada por uma inundação de ping do endereço IP 192.168.40.53.
Inundações de SYN podem ser facilmente detectadas desse modo porque a presença de flag SYN é indicada na saída de depuração:
*Mar 3 03:54:40.436: IP: s=192.168.40.53 (Ethernet0/1), d=10.254.2.204
(Ethernet0/0), g=10.200.40.1, len 44, forward
*Mar 3 03:54:40.440: TCP src=11004, dst=53,
seq=280872555, ack=0, win=4128 SYN
Informações Relacionadas