Este documento explica como solucionar problemas de alta utilização da CPU devido ao processo de entrada de IP.
Observação: este documento não fornece estratégias para evitar diferentes tipos de ataques.
A Cisco recomenda 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. All of the devices used in this document started with a cleared (default) configuration. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.
Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.
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 está fazendo a switching de processo de muito tráfego IP. Verifique estes problemas:
A comutação de interrupções é desativada em uma interface (ou interfaces) que tem (tem) muito tráfego
A comutação de interrupção refere-se ao uso de algoritmos de comutação diferentes da comutação de processos. Exemplos incluem comutação rápida, comutação otimizada, comutação 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 verificar o comando show ip interface para ver quais métodos de comutação são usados em cada interface. Reative a switching de interrupção em tal interface. Lembre-se que a switching rápida regular é configurada nas interfaces de saída: se a comutação rápida estiver configurada em uma interface, os pacotes que saem dessa interface serão comutados rapidamente. O switching do Cisco Express Forwarding é configurado 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 da interface e destinado a um endereço nessa mesma interface, todos esses pacotes serão comutados por processo. Nessa situação, você deve habilitar a 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 roteamento de política está desabilitada
Se um mapa de rota tiver sido configurado em uma interface, e muito do tráfego for tratado pelo mapa de rota, o roteador processa-comuta esse tráfego. Nesta situação, você deve habilitar a política de cache de rota IP na interface. Verifique as restrições mencionadas na seção "Habilitando o roteamento baseado em políticas comutadas rapidamente" de Configuração do roteamento baseado em políticas.
O tráfego que não pode ser comutado por interrupções chega
Esse 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) seja configurada, um pacote para o qual não há correspondência no cache de switching rápida ou FIB e tabelas de adjacência é processado. Uma entrada é então criada no cache ou na tabela apropriada, e todos os pacotes subsequentes que correspondem aos mesmos critérios são rápidos, ótimos ou comutados por CEF. 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 os dispositivos alcançáveis através do roteador, e 2) use endereços IP de origem ou destino diferentes, não há correspondência para esses pacotes no cache ou na tabela de switching, portanto, eles são processados pelo processo de entrada 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 do 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 o Cisco Express Forwarding para obter mais informações sobre as 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 enorme quantidade 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. Entretanto, você pode começar a verificar a saída do comando show ip route summary periodicamente. Os valores que mudam rapidamente são um sinal de uma rede instável. Alterações frequentes na tabela de roteamento significam um 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 de TCP/IP do Guia de Troubleshooting de Internetwork.
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 de 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 dos comandos show interfaces e show interfaces switching para verificar em que interface os pacotes estão entrando. Depois de identificar a interface de recebimento, ative a contabilização de ip na interface de saída e veja se há um padrão. Se houver um ataque, o endereço de origem é quase sempre diferente, mas o endereço de destino é 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 interromper o ataque.
Tráfego de broadcast
Verifique o número de pacotes de broadcast na saída do comando show interfaces. Se você comparar a quantidade de broadcasts com a quantidade total de pacotes que foram 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 (compatível com o switching Cisco Express Forwarding)
Tráfego compactado
Se não houver um Adaptador de Serviço de Compressão (CSA - Compression Service Adapter) no roteador, os pacotes compactados devem ser comutados por processo.
Tráfego criptografado
Se não houver um ESA (Encryption Service Adapter, adaptador de serviço de criptografia) no roteador, os pacotes criptografados devem 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 de 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 ARP (Address Resolution Protocol). Isso não deve acontecer 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 de spoof.
Muito tráfego multicast passa pelo roteador. Infelizmente, não há maneira fácil de examinar a quantidade de tráfego multicast. O comando show ip traffic mostra apenas informações resumidas. No entanto, se você tiver configurado o roteamento multicast no roteador, poderá habilitar a comutação rápida de pacotes multicast com o comando de configuração da interface ip mroute-cache (a comutação rápida de pacotes multicast está desativada por padrão).
O roteador está com excesso de assinaturas. Se o roteador for superutilizado e não puder lidar com essa quantidade de tráfego, tente distribuir a carga entre outros roteadores ou comprar um roteador high-end.
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 de origem ou de destino 53 (DNS) são sempre pontuados para o nível de processo pelo NAT.
Há outros tipos de pacotes que são direcionados para o processamento.
Há fragmentação de 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.
Qualquer que seja a razão para a alta utilização da CPU no processo de entrada de IP, a origem do problema pode ser rastreada se você depurar os pacotes IP. Como a utilização da CPU já é alta, o processo de depuração deve ser executado com extremo cuidado. O processo de depuração produz muitas mensagens, portanto, somente o registro em buffer deve ser configurado.
O registro em um console gera interrupções desnecessárias na CPU e aumenta a utilização da CPU. Fazer login em um host (ou monitorar registro) gera tráfego adicional nas interfaces.
O processo de depuração pode ser iniciado com o comando exec debug ip packet detail. 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 um exemplo de sessão de depuração IP é fornecida na seção Sample IP Packet Debugging Session deste documento. Quando o dispositivo de origem de pacotes IP indesejados é encontrado, esse dispositivo pode ser desconectado da rede ou uma lista de acesso pode ser criada no roteador para descartar pacotes desse destino.
Os destinos de registro configurados devem ser verificados primeiro com o comando show logging:
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, datetime e milissegundos timestamps devem ser ativados:
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 agora pode ser iniciada:
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 exec undebug all:
router#undebug all All possible debugging has been turned off
Os resultados podem ser verificados com o comando exec show logging:
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=144.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=144.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=144.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=144.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
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
11-Feb-2019 |
Versão inicial |