Lidando com mallocfail e utilização elevada de CPU, resultante do worm "código vermelho”

Introdução

Este documento descreve o worm “Code Red” e os problemas que ele pode causar em um ambiente de roteamento Cisco. Este documento também descreve técnicas para evitar a infestação do worm e fornece links para avisos relacionados que descrevem soluções para problemas relacionados ao worm.

O worm "Code Red" explora uma vulnerabilidade no Index Service do Microsoft Internet Information Server (IIS) versão 5.0. Quando o worm "Code Red" infecta um host, ele faz com que o host investigue e infecte uma série aleatória de endereços IP, o que causa um aumento acentuado no tráfego de rede. Isso é especialmente problemático se houver links redundantes na rede e/ou se o Cisco Express Forwarding (CEF) não for usado para comutar pacotes.

Pré-requisitos

Requisitos

Não existem requisitos específicos para 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 sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Como o worm "Código Vermelho" infecta outros sistemas

O worm "Código Vermelho" tenta se conectar a endereços IP gerados aleatoriamente. Cada servidor IIS infectado pode tentar infectar o mesmo conjunto de dispositivos. Você pode rastrear o endereço IP de origem e a porta TCP do worm, pois ele não é falsificado. O Unicast Reverse Path Forwarding (URPF) não pode suprimir um ataque de worm porque o endereço de origem é válido.

Consultivos que discutem o worm "Código Vermelho"

Estes avisos descrevem o worm "Code Red" e explicam como corrigir o software afetado pelo worm:

• Consultoria de segurança da Cisco: worm "Código vermelho" - Impacto para o cliente

• Excesso de buffer do Index Server ISAPI Extension de IIS remoto

• Worm .ida "código vermelho"

• CERT? Consultoria CA-2001-19 Worm "Código Vermelho" Explorando Estouro de Buffer na DLL do Serviço de Indexação do IIS

Sintomas

Estes são alguns sintomas que indicam que um roteador Cisco é afetado pelo worm "Código Vermelho":

• Grande número de fluxos em tabelas NAT ou PAT (se você usar NAT ou PAT).

• Grande número de solicitações ARP ou tempestades ARP na rede (causadas pela verificação de endereço IP).

• Uso excessivo de memória por processos de Entrada de IP, Entrada de ARP, Agente de Cache de IP e CEF.

• Alta utilização da CPU em ARP, entrada de IP, CEF e IPC.

• Alta utilização da CPU em nível de interrupção em baixas taxas de tráfego ou alta utilização da CPU em nível de processo na entrada de IP, se você usar NAT.

Uma condição de memória baixa ou alta utilização sustentada da CPU (100 por cento) no nível de interrupção pode fazer com que um roteador Cisco IOS^® seja recarregado. O recarregamento é causado por um processo que se comporta mal devido às condições de estresse.

Se você não suspeitar que os dispositivos no seu site estão infectados pelo worm "Código Vermelho" ou são alvo dele, consulte a seção Informações Relacionadas para obter URLs adicionais sobre como solucionar quaisquer problemas encontrados.

Identifique o dispositivo infectado

Use a comutação de fluxo para identificar o endereço IP origem do dispositivo afetado. Configure ip route-cache flow em todas as interfaces para registrar todos os fluxos comutados pelo roteador.

Depois de alguns minutos, emita o comando show ip cache flow para ver as entradas gravadas. Durante a fase inicial da infecção pelo worm "Código Vermelho", o worm tenta se replicar. A replicação ocorre quando o worm envia solicitações de HT para endereços IP aleatórios. Portanto, você deve procurar entradas de fluxo de cache com a porta de destino 80 (HT., 0050 em hexadecimal).

O comando show ip cache flow | include 0050 exibe todas as entradas de cache com uma porta TCP 80 (0050 em hex):

Router#show ip cache flow | include 0050 
... 

scram        scrappers    dative      DstIPaddress   Pr SrcP  DstP  Pkts 
Vl1       193.23.45.35      Vl3        2.34.56.12    06 0F9F  0050     2 
Vl1    211.101.189.208     Null     158.36.179.59    06 0457  0050     1 
Vl1       193.23.45.35      Vl3     34.56.233.233    06 3000  0050     1 
Vl1     61.146.138.212     Null     158.36.175.45    06 B301  0050     1 
Vl1       193.23.45.35      Vl3     98.64.167.174    06 0EED  0050     1 
Vl1     202.96.242.110     Null     158.36.171.82    06 0E71  0050     1 
Vl1       193.23.45.35      Vl3     123.231.23.45    06 121F  0050     1 
Vl1       193.23.45.35      Vl3       9.54.33.121    06 1000  0050     1 
Vl1       193.23.45.35      Vl3      78.124.65.32    06 09B6  0050     1 
Vl1      24.180.26.253     Null    158.36.179.166    06 1132  0050     1

Se você encontrar um número anormalmente alto de entradas com o mesmo endereço IP de origem, endereço IP de destino aleatório¹, DstP = 0050 (HTTP) e Pr = 06 (TCP), provavelmente terá localizado um dispositivo infectado. Neste exemplo de saída, o endereço IP origem é 193.23.45.35 e vem de VLAN1.

¹Outra versão do worm "Code Red", chamada "Code Red II", não escolhe um endereço IP de destino totalmente aleatório. Em vez disso, o "Code Red II" mantém a parte da rede do endereço IP e escolhe uma parte aleatória do host do endereço IP para propagar. Isso permite que o worm se espalhe mais rapidamente dentro da mesma rede.

O "Code Red II " usa estas redes e máscaras:

Mask        Probability of Infection 
0.0.0.0       12.5% (random) 
255.0.0.0     50.0% (same class A) 
255.255.0.0   37.5% (same class B)

Os endereços IP de destino excluídos são 127.X.X.X e 224.X.X.X, e nenhum octeto pode ser 0 ou 255. Além disso, o host não tenta infectar-se novamente.

Para obter mais informações, consulte Código Vermelho (II).

Às vezes, não é possível executar o netflow para detectar uma tentativa de infestação por "Código Vermelho". Isso pode ocorrer porque você executa uma versão de código que não suporta o netflow ou porque o roteador tem memória insuficiente ou excessivamente fragmentada para ativar o netflow. A Cisco recomenda que você não ative o netflow quando houver várias interfaces de entrada e apenas uma interface de saída no roteador, pois a contabilidade do netflow é executada no caminho de entrada. Nesse caso, é melhor ativar a contabilidade IP na interface de saída exclusiva.

Observação: o comando ip accounting desabilita o DCEF. Não ative a contabilidade IP em nenhuma plataforma onde você deseje usar a comutação DCEF.

Router(config)#interface vlan 1000 
Router(config-if)#ip accounting
  
Router#show ip accounting 
  Source           Destination           Packets               Bytes 
20.1.145.49    75.246.253.88                 2                  96 
20.1.145.43    17.152.178.57                 1                  48 
20.1.145.49    20.1.49.132                   1                  48 
20.1.104.194   169.187.190.170               2                  96 
20.1.196.207   20.1.1.11                     3                 213 
20.1.145.43    43.129.220.118                1                  48 
20.1.25.73     43.209.226.231                1                  48 
20.1.104.194   169.45.103.230                2                  96 
20.1.25.73     223.179.8.154                 2                  96 
20.1.104.194   169.85.92.164                 2                  96 
20.1.81.88     20.1.1.11                     3                 204 
20.1.104.194   169.252.106.60                2                  96 
20.1.145.43    126.60.86.19                  2                  96 
20.1.145.49    43.134.116.199                2                  96 
20.1.104.194   169.234.36.102                2                  96 
20.1.145.49    15.159.146.29                 2                  96 

Na saída do comando show ip accounting, procure endereços de origem que tentam enviar pacotes para vários endereços de destino. Se o host infectado estiver na fase de varredura, ele tentará estabelecer conexões HTTP com outros roteadores. Assim, você verá tentativas de acessar vários endereços IP. A maioria dessas tentativas de conexão normalmente falha. Portanto, você vê apenas um pequeno número de pacotes transferidos, cada um com uma pequena contagem de bytes. Neste exemplo, é provável que 20.1.145.49 e 20.1.104.194 estejam infectados.

Ao executar o MLS (Multi-Layer Switching) no Catalyst 5000 Series e no Catalyst 6000 Series, você deve executar etapas diferentes para ativar a contabilidade de fluxo de rede e rastrear a infestação. Em um switch Cat6000 equipado com Supervisor 1 Multilayer Switch Feature Card (MSFC1) ou SUP I/MSFC2, o MLS baseado em netflow é habilitado por padrão, mas o modo de fluxo é somente de destino. Portanto, o endereço IP de origem não é armazenado em cache. Você pode ativar o modo "full-flow" para rastrear hosts infectados com a ajuda do comando set mls flow full no supervisor.

Para o modo Híbrido, use o comando set mls flow full:

6500-sup(enable)set mls flow full
Configured IP flowmask is set to full flow. 
Warning: Configuring more specific flow mask may dramatically
increase the number of MLS entries.

Para o modo Native IOS, use o comando mls flow ip full:

Router(config)#mls flow ip full

Quando você ativa o modo "fluxo completo", um aviso é exibido para indicar um aumento significativo nas entradas de MLS. O impacto do aumento das entradas de MLS pode ser justificado por um curto período se a sua rede já estiver infestada com o worm "Code Red". O worm faz com que as entradas de MLS sejam excessivas e estejam aumentando.

Para exibir as informações coletadas, use estes comandos:

Para o modo Híbrido, use o comando set mls flow full:

6500-sup(enable)set mls flow full
Configured IP flowmask is set to full flow. 
Warning: Configuring more specific flow mask may dramatically
increase the number of MLS entries.

Para o modo Native IOS, use o comando mls flow ip full:

Router(config)#mls flow ip full

Quando você ativa o modo "fluxo completo", um aviso é exibido para indicar um aumento significativo nas entradas de MLS. O impacto do aumento das entradas de MLS pode ser justificado por um curto período se a sua rede já estiver infestada com o worm "Code Red". O worm faz com que as entradas de MLS sejam excessivas e estejam aumentando.

Para exibir as informações coletadas, use estes comandos:

Para o modo Híbrido, use o comando show mls ent:

6500-sup(enable)show mls ent
Destination-IP  Source-IP     Prot  DstPrt SrcPrt Destination-Mac   Vlan EDst 
ESrc DPort     SPort     Stat-Pkts  Stat-Bytes  Uptime   Age 
-------------- --------------- ----- ------ ------ ----------------- ---- ---- 
---- --------- --------- ---------- ----------- -------- -------- 

Observação: todos esses campos são preenchidos quando estão no modo de "fluxo total".

Para o modo Native IOS, use o comando show mls ip:

Router#show mls ip 
DstIP           SrcIP           Prot:SrcPort:DstPort  Dst i/f:DstMAC 
-------------------------------------------------------------------- 
Pkts         Bytes       SrcDstPorts    SrcDstEncap Age   LastSeen 
-------------------------------------------------------------------- 

Ao determinar o endereço IP origem e a porta destino envolvidos no ataque, você pode definir o MLS de volta para o modo "somente destino".

Para o modo Híbrido, use o comando set mls flow destination:

6500-sup(enable) set mls flow destination 
Usage: set mls flow <destination|destination-source|full> 

Para o modo Native IOS, use o comando mls flow ip destination:

Router(config)#mls flow ip destination

A combinação Supervisor (SUP) II/MSFC2 está protegida contra ataques porque a switching CEF é executada no hardware e as estatísticas de netflow são mantidas. Assim, mesmo durante um ataque de "Código Vermelho", se você ativar o modo de fluxo completo, o roteador não será inundado, devido ao mecanismo de switching mais rápido. Os comandos para ativar o modo de fluxo completo e exibir as estatísticas são os mesmos no SUP I/MFSC1 e no SUP II/MSFC2.

Técnicas de prevenção

Use as técnicas listadas nesta seção para minimizar o impacto do worm "Code Red" no roteador.

Bloquear tráfego para a porta 80

Se for possível em sua rede, a maneira mais fácil de evitar o ataque de "Código Vermelho" é bloquear todo o tráfego para a porta 80, que é a porta conhecida para WWW. Crie uma lista de acesso para negar pacotes IP destinados à porta 80 e aplique-a na interface que enfrenta a origem da infecção.

Reduza o uso da memória de entrada ARP

A entrada ARP usa uma grande quantidade de memória quando uma rota estática aponta para uma interface de broadcast, como esta:

ip route 0.0.0.0 0.0.0.0 Vlan3

Cada pacote da rota padrão é enviado à VLAN3. No entanto, não há endereço IP do próximo salto especificado e, portanto, o roteador envia uma solicitação ARP para o endereço IP destino. O roteador do próximo salto para esse destino responde com seu próprio endereço MAC, a menos que o Proxy ARP esteja desativado. A resposta do roteador cria uma entrada adicional na tabela ARP onde o endereço IP destino do pacote é mapeado para o endereço MAC do próximo salto. O worm "Code Red" envia pacotes para endereços IP aleatórios, o que adiciona uma nova entrada ARP para cada endereço destino aleatório. Cada nova entrada ARP consome cada vez mais memória sob o processo de Entrada ARP.

Não crie uma rota estática padrão para uma interface, especialmente se a interface for broadcast (Ethernet/Fast Ethernet/GE/SMDS) ou multiponto (Frame Relay/ATM). Qualquer rota padrão estática deve apontar para o endereço IP do roteador do próximo salto. Depois de alterar a rota padrão para apontar para o endereço IP do próximo salto, use o comando clear arp-cache para limpar todas as entradas ARP. Esse comando corrige o problema de utilização de memória.

Use a switching Cisco Express Forwarding (CEF)

Para reduzir a utilização da CPU em um roteador IOS, mude de switching Fast/Optimum/Netflow para switching CEF. Há algumas advertências para ativar o CEF. A próxima seção discute a diferença entre o CEF e a switching rápida e explica as implicações ao ativar o CEF.

Cisco Express Forwarding versus Fast Switching

Ative o CEF para aliviar a carga de tráfego aumentada causada pelo worm "Code Red". O Cisco IOS® Software Releases 11.1( )CC, 12.0 e posteriores oferecem suporte ao CEF nas plataformas Cisco 7200/7500/GSR. O suporte para CEF em outras plataformas está disponível no Cisco IOS Software Release 12.0 ou posterior. Você pode investigar mais com a ferramenta Software Advisor.

Às vezes, você não pode ativar o CEF em todos os roteadores devido a um destes motivos:

• Memória insuficiente

• Arquiteturas de plataforma não suportadas

• Encapsulamentos de interface não suportados

Comportamento e implicações do Fast Switching

Estas são as implicações ao usar a switching rápida:

• Cache acionado pelo tráfego—O cache fica vazio até que o roteador comute pacotes e preencha o cache.

• O primeiro pacote é comutado por processo—O primeiro pacote é comutado por processo, porque o cache está inicialmente vazio.

• Cache granular—O cache é construído com uma granularidade da entrada RIB (Routing Information Base) mais específica de uma rede principal. Se o RIB tiver /24s para a rede principal 131.108.0.0, o cache será criado com /24s para essa rede principal.

• O cache /32 é usado—/32 é usado para equilibrar a carga para cada destino. Quando o cache equilibra a carga, o cache é construído com /32s para essa rede principal.

  Observação: esses dois últimos problemas podem causar um cache enorme que consumiria toda a memória.

• Cache nos principais limites da rede—Com a rota padrão, o cache é executado nos limites da rede principal.

• Cache Ager—O cache ager é executado a cada minuto e verifica 1/20 (5 por cento) do cache para entradas não utilizadas sob condições normais de memória e 1/4 (25 por cento) do cache em uma condição de memória baixa (200k).

Para alterar os valores acima, use o comando ip cache-ager-interval X Y Z, onde:

• X é <0-2147483> número de segundos entre execuções de ager. Padrão = 60 segundos.

• Y é <2-50> 1/(Y+1) de cache para envelhecimento por execução (memória insuficiente). Padrão = 4.

• Z é <3-100> 1/(Z+1) de cache para envelhecimento por execução (normal). Padrão = 20.

Aqui está um exemplo de configuração que usa ip cache-ager 60 5 25.

Router#show ip cache
IP routing cache 2 entries, 332 bytes
   27 adds, 25 invalidates, 0 refcounts
Cache aged by 1/25 every 60 seconds (1/5 when memory is low).
Minimum invalidation interval 2 seconds, maximum interval 5 seconds, 
quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Last full cache invalidation occurred 03:55:12 ago

Prefix/Length          Age    Interface     Next Hop
4.4.4.1/32        03:44:53    Serial1       4.4.4.1
192.168.9.0/24    00:03:15    Ethernet1    20.4.4.1

Router#show ip cache verbose
IP routing cache 2 entries, 332 bytes
   27 adds, 25 invalidates, 0 refcounts
Cache aged by 1/25 every 60 seconds (1/5 when memory is low).
Minimum invalidation interval 2 seconds, maximum interval 5 seconds,
   quiet interval 3 seconds, threshold 0 requests
Invalidation rate 0 in last second, 0 in last 3 seconds
Last full cache invalidation occurred 03:57:31 ago
Prefix/Length       Age       Interface       Next Hop
4.4.4.1/32-24           03:47:13  Serial1         4.4.4.1
                   4   0F000800
192.168.9.0/24-0        00:05:35  Ethernet1       20.4.4.1
                   14  00000C34A7FC00000C13DBA90800

Com base na configuração do seu cache ager, algumas porcentagens das entradas do cache ficam obsoletas na tabela de cache rápido. Quando as entradas envelhecem rapidamente, uma porcentagem maior da tabela de cache rápido envelhece e a tabela de cache se torna menor. Como resultado, o consumo de memória no roteador é reduzido. Uma desvantagem é que o tráfego continua a fluir para as entradas que foram excluídas da tabela de cache. Os pacotes iniciais são comutados por processo, o que causa um pequeno pico no consumo da CPU na Entrada de IP até que uma nova entrada de cache seja criada para o fluxo.

A partir das versões 10.3(8), 11.0(3) e posteriores do software Cisco IOS, o IP cache ager é tratado de forma diferente, conforme explicado aqui:

• Os comandos ip cache-ager-interval e ip cache-invalidate-delay estão disponíveis apenas se o comando service internal estiver definido na configuração.

• Se o período entre execuções de invalidação de ager for definido como 0, o processo de ager será totalmente desativado.

• O tempo é expresso em segundos.

Observação: quando você executa esses comandos, a utilização da CPU do roteador aumenta. Use esses comandos somente quando absolutamente necessário.

Router#clear ip cache ? 
A.B.C.D Address prefix 
<CR>--> will clear the entire cache and free the memory used by it! 

Router#debug ip cache 
IP cache debugging is on

Vantagens do CEF

• A tabela Forwarding Information Base (FIB) é criada com base na tabela de roteamento. Portanto, as informações de encaminhamento existem antes de o primeiro pacote ser encaminhado. O FIB também contém /32 entradas para hosts de LAN conectados diretamente.

• A tabela Adjacency (ADJ) contém as informações de regravação da Camada 2 para os próximos saltos e hosts conectados diretamente (uma entrada ARP cria uma adjacência CEF).

• Não há conceito de envelhecimento de cache com CEF para aumentar a utilização de CPU. Uma entrada FIB será excluída se uma entrada da tabela de roteamento for excluída.

Cuidado: Novamente, uma rota padrão que aponta para uma interface de broadcast ou multiponto significa que o roteador envia solicitações ARP para cada novo destino. As solicitações ARP do roteador criam potencialmente uma tabela de adjacências enorme até que o roteador fique sem memória. Se o CEF falhar em alocar memória, o CEF/DCEF será desativado. Será necessário habilitar manualmente o CEF/DCEF novamente.

Exemplo de saída: CEF

Aqui está um exemplo de saída do comando show ip cef summary, que mostra o uso de memória. Esta saída é um snapshot de um servidor de rota Cisco 7200 com o Cisco IOS Software Release 12.0.

Router>show ip cef summary
IP CEF with switching (Table Version 2620746)
  109212 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 84625
  109212 leaves, 8000 nodes, 22299136 bytes, 2620745 inserts, 2511533
  invalidations
  17 load sharing elements, 5712 bytes, 109202 references
  universal per-destination load sharing algorithm, id 6886D006
  1 CEF resets, 1 revisions of existing leaves
  1 in-place/0 aborted modifications
  Resolution Timer: Exponential (currently 1s, peak 16s)
  refcounts:  2258679 leaf, 2048256 node

Adjacency Table has 16 adjacencies 


Router>show processes memory | include CEF
 PID TTY  Allocated      Freed    Holding    Getbufs    Retbufs Process
  73   0     147300       1700     146708          0          0 CEF process
  84   0        608          0       7404          0          0 CEF Scanner


Router>show processes memory | include BGP

   2   0    6891444    6891444       6864          0          0 BGP Open
  80   0       3444       2296       8028          0          0 BGP Open
  86   0     477568     476420       7944          0          0 BGP Open
  87   0 2969013892  102734200  338145696          0          0 BGP Router
  88   0   56693560 2517286276       7440     131160    4954624 BGP I/O
  89   0      69280   68633812      75308          0          0 BGP Scanner
  91   0    6564264    6564264       6876          0          0 BGP Open
 101   0    7635944    7633052       6796        780          0 BGP Open
 104   0    7591724    7591724       6796          0          0 BGP Open
 105   0    7269732    7266840       6796        780          0 BGP Open
 109   0    7600908    7600908       6796          0          0 BGP Open
 110   0    7268584    7265692       6796        780          0 BGP Open


Router>show memory summary | include FIB

Alloc PC        Size     Blocks      Bytes    What
0x60B8821C        448          7       3136    FIB: FIBIDB
0x60B88610      12000          1      12000    FIB: HWIDB MAP TABLE
0x60B88780        472          6       2832    FIB: FIBHWIDB
0x60B88780        508          1        508    FIB: FIBHWIDB
0x60B8CF9C       1904          1       1904    FIB 1 path chunk pool
0x60B8CF9C      65540          1      65540    FIB 1 path chunk pool
0x60BAC004       1904        252     479808    FIB 1 path chun
0x60BAC004      65540        252   16516080    FIB 1 path chun


Router>show memory summary | include CEF

0x60B8CD84       4884          1       4884    CEF traffic info
0x60B8CF7C         44          1         44    CEF process
0x60B9D12C      14084          1      14084    CEF arp throttle chunk
0x60B9D158        828          1        828    CEF loadinfo chunk
0x60B9D158      65540          1      65540    CEF loadinfo chunk
0x60B9D180        128          1        128    CEF walker chunk
0x60B9D180        368          1        368    CEF walker chunk
0x60BA139C         24          5        120    CEF process
0x60BA139C         40          1         40    CEF process
0x60BA13A8         24          4         96    CEF process
0x60BA13A8         40          1         40    CEF process
0x60BA13A8         72          1         72    CEF process
0x60BA245C         80          1         80    CEF process
0x60BA2468         60          1         60    CEF process
0x60BA65A8      65488          1      65488    CEF up event chunk


Router>show memory summary | include adj

0x60B9F6C0        280          1        280    NULL adjacency
0x60B9F734        280          1        280    PUNT adjacency
0x60B9F7A4        280          1        280    DROP adjacency
0x60B9F814        280          1        280    Glean adjacency
0x60B9F884        280          1        280    Discard adjacency
0x60B9F9F8      65488          1      65488    Protocol adjacency chunk

Pontos a serem considerados

Quando o número de fluxos é grande, o CEF normalmente consome menos memória do que a switching rápida. Se a memória já estiver consumida por um cache de switching rápida, você deverá limpar o cache ARP (através do comando clear ip arp) antes de habilitar o CEF.

Observação: quando você limpa o cache, um pico é causado na utilização da CPU do roteador.

Perguntas frequentes "Código vermelho" e suas respostas

P. Eu uso NAT e uso 100% da CPU na entrada de IP. Quando executo show proc cpu, minha utilização da CPU é alta no nível de interrupção - 100/99 ou 99/98. Isso pode estar relacionado ao "Código Vermelho"?

R. Recentemente, foi corrigido um bug da NAT Cisco (CSCdu63623 (somente clientes registrados) ) que envolve escalabilidade. Quando há dezenas de milhares de fluxos de NAT (com base no tipo de plataforma), o bug causa 100% de utilização da CPU no nível de processo ou interrupção.

Para determinar se esse erro é o motivo, execute o comando show align e verifique se o roteador enfrenta erros de alinhamento. Se você vir erros de alinhamento ou acessos artificiais à memória, execute o comando show align algumas vezes e veja se os erros estão aumentando. Se o número de erros estiver aumentando, os erros de alinhamento podem ser a causa da alta utilização da CPU no nível de interrupção, e não o bug Cisco CSCdu63623 (somente clientes registrados) . Para obter mais informações, consulte Troubleshooting de Acessos Artificiais e Erros de Alinhamento.

O comando show ip nat translation exibe o número de conversões ativas. O ponto de fusão para um processador da classe NPE-300 é de aproximadamente 20.000 a 40.000 conversões. Esse número varia de acordo com a plataforma.

Esse problema de sobrecarga foi observado anteriormente por alguns clientes, mas depois de "Code Red", mais clientes já passaram por esse problema. A única solução é executar o NAT (em vez do PAT), de modo que haja menos traduções ativas. Se você tiver um 7200, use um NSE-1 e reduza os valores de tempo limite de NAT.

P. Eu executo o IRB e encontro alta utilização da CPU no processo de entrada do HyBridge. Por que isso acontece? Tem alguma relação com "Código Vermelho"?

R. O processo de entrada HyBridge trata todos os pacotes que não podem ser comutados rapidamente pelo processo IRB. A incapacidade do processo IRB de comutar rapidamente um pacote pode ocorrer porque:

• O pacote é um pacote de broadcast.

• O pacote é um pacote multicast.

• O destino é desconhecido e o ARP precisa ser disparado.

• Há BPDUs de spanning tree.

A entrada HyBridge encontra problemas se houver milhares de interfaces ponto-a-ponto no mesmo grupo de pontes. A entrada do HypBridge também encontra problemas (mas em menor extensão) se houver milhares de VSs na mesma interface multiponto.

Quais são os motivos possíveis para problemas com IRB? Suponha que um dispositivo infectado com "Código vermelho" examine endereços IP.

• O roteador precisa enviar uma solicitação ARP para cada endereço IP destino. Uma inundação de solicitações ARP resulta em cada VC no grupo de pontes para cada endereço que é varrido. O processo ARP normal não causa um problema de CPU. No entanto, se houver uma entrada ARP sem uma entrada de bridge, o roteador inunda pacotes destinados a endereços para os quais já existem entradas ARP. Isso poderá causar uma alta utilização de CPU, pois o tráfego é comutado pelo processo. Para evitar o problema, aumente o tempo de envelhecimento da bridge (padrão de 300 segundos ou 5 minutos) para corresponder ou exceder o tempo limite do ARP (padrão de 4 horas) de modo que os dois temporizadores sejam sincronizados.

• O endereço que o host final tenta infectar é um endereço de broadcast. O roteador faz o equivalente a uma difusão de sub-rede que precisa ser replicada pelo processo HyBridge Input (Entrada de HyBridge). Isso não acontece se o comando no ip directed-broadcast estiver configurado. No Cisco IOS Software Release 12.0, o comando ip directed-broadcast é desabilitado por padrão, fazendo com que todos os broadcasts direcionados a IP sejam descartados.

• Aqui está uma nota lateral, não relacionada a "Code Red" e relacionada a arquiteturas IRB:

  Os pacotes multicast e broadcast da camada 2 precisam ser replicados. Portanto, um problema com os servidores IPX que são executados em um segmento de broadcast pode desativar o link. Você pode usar políticas de assinante para evitar o problema. Para obter mais informações, consulte x Digital Subscriber Line (xDSL) Bridge Support. Você também deve considerar listas de acesso de bridge, que limitam o tipo de tráfego permitido para passar pelo roteador.

• Para aliviar esse problema de IRB, você pode usar vários grupos de pontes e garantir que haja um mapeamento um para um para BVIs, subinterfaces e VCs.

• O RBE é superior ao IRB porque evita a pilha de Bridging. Você pode migrar do IRB para o RBE. Esses bugs da Cisco inspiram essa migração:

  • CSCdr1146 (somente clientes registrados)

  • CSCdp18572 (somente clientes registrados)

  • CSCds40806 (somente clientes registrados)

P. A utilização da CPU está alta no nível de interrupção e recebo liberações se eu tentar um show log. A taxa de tráfego também está um pouco superior ao normal. Qual é a razão para isso?

R. Aqui está um exemplo da saída do comando show logging:

Router#show logging
     Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
                                                  ^ 
                                                this value is non-zero
         Console logging: level debugging, 9 messages logged

Verifique se você efetua login no console. Em caso afirmativo, verifique se há solicitações HTTP de tráfego. Em seguida, verifique se há listas de acesso com palavras-chave de log ou depurações que observem determinados fluxos IP. Se as liberações estiverem aumentando, pode ser porque o console, geralmente um dispositivo de 9600 baud, não consegue lidar com a quantidade de informações recebidas. Neste cenário, o roteador desativa interrupções e não faz nada além de processar mensagens do console. A solução é desativar o registro do console ou remover qualquer tipo de registro que você executar.

P. Posso ver várias tentativas de conexão HTTP no meu roteador IOS que executa um ip http-server. Isso é devido ao exame de worm "Código vermelho"?

R. "Código Vermelho" pode ser a razão aqui. A Cisco recomenda que você desabilite o comando ip http server no roteador IOS para que ele não precise lidar com várias tentativas de conexão de hosts infectados.

Soluções

Há várias soluções que são discutidas na seção Recomendações que Discutem o Worm "Código Vermelho". Consulte as recomendações para as soluções alternativas.

Outro método para bloquear o worm "Code Red" nos pontos de ingresso da rede usa o Network-Based Application Recognition (NBAR) e as Access Control Lists (ACLs) dentro do software IOS nos roteadores Cisco. Use este método em conjunto com os patches recomendados para servidores IIS da Microsoft. Para obter mais informações sobre esse método, consulte Uso de NBAR e ACLs para bloquear o worm "Code Red" nos pontos de ingresso da rede.

Informações Relacionadas

• Troubleshooting Problemas de Memória
• Troubleshooting de Vazamentos de Buffer
• Troubleshooting de Alta Utilização de CPU em Cisco Routers
• Troubleshooting de Travamentos de Roteador
• Notas técnicas de solução de problemas - Roteadores
• Troubleshooting do Roteador
• Suporte Técnico e Documentação - Cisco Systems