Rede de inundação de transmissão ARP e alto uso da CPU

Esperando que alguém aqui possa ter uma idéia do problema que estamos enfrentando. Atualmente, temos o Cisco TAC analisando o caso, mas eles estão lutando para encontrar a causa raiz.

Embora o título mencione a transmissão ARP e o alto uso da CPU, não temos certeza se eles estão relacionados ou não nesse estágio.

A edição original foi publicada na comunidade online do INE

Reduzimos a rede para um único link sem configuração de redundância; pense nela como uma topologia em estrela.

Fatos:

• Usamos switches 3750x, 4 em uma pilha. Versão 15.0 (1) SE3. O Cisco TAC não confirma problemas conhecidos para erros de CPU ou ARP altos para esta versão específica.
• Não há hubs / switches não gerenciados conectados
• Pilha de núcleo recarregada
• Não temos uma rota padrão "Ip route 0.0.0.0 0.0.0.0 f1 / 0". Usando o OSPF para roteamento.
• Vemos grandes pacotes de transmissão da VLAN 1, VLAN 1 usados ​​para dispositivos de desktop. Usamos 192.168.0.0/20
• O Cisco TAC disse que eles não veem nada de errado em usar / 20; caso contrário, teríamos um domínio de broadcast grande, mas ainda assim funcionaríamos.
• Wifi, gerenciamento, impressoras etc estão todos em diferentes VLAN
• A extensão da árvore foi verificada por indivíduos qualificados pelo Cisco TAC e CCNP / CCIE. Encerramos todos os links redundantes.
• A configuração no núcleo foi verificada Cisco TAC.
• Temos o tempo limite padrão do ARP na maioria dos comutadores.
• Não implementamos perguntas e respostas.
• Nenhuma nova opção foi adicionada (pelo menos nenhuma que conhecemos)
• Não é possível usar a inspeção arp dinâmica nos comutadores de borda, pois esses são 2950
• Usamos show interfaces | inc line | broadcast para descobrir de onde vem o grande número de broadcast, no entanto, o Cisco TAC e 2 outros engenheiros (CCNP e CCIE) confirmaram que esse é um comportamento normal devido ao que está acontecendo na rede (como no grande número de retalhos de mac) causando a transmissão maior). Verificamos que o STP estava funcionando corretamente nos comutadores de borda.

Sintomas na rede e switches:

• Grande número de retalhos MAC
• Alto uso da CPU para o processo de entrada ARP
• Grande número de pacotes ARP, aumentando rapidamente e visível
• Wiresharks mostra que centenas de computadores estão inundando a rede com o ARP Broadcast
• Para fins de teste, colocamos aproximadamente 80 máquinas de desktop com vlan diferente, no entanto, testamos isso e não fizemos nenhuma diferença visível na entrada de cpu ou arp alta
• Executaram antivírus / malware / spyware diferentes, mas nenhum vírus visível na rede.
• A contagem da tabela de endereços sh mac mostra-nos aproximadamente 750 endereços mac diferentes, conforme o esperado na vlan 1.

#sh processes cpu sorted | exc 0.00%
CPU utilization for five seconds: 99%/12%; one minute: 99%; five minutes: 99%

 PID Runtime(ms)     Invoked      uSecs   5Sec   1Min   5Min TTY Process
  12   111438973    18587995       5995 44.47% 43.88% 43.96%   0 ARP Input
 174    59541847     5198737      11453 22.39% 23.47% 23.62%   0 Hulc LED Process
 221     7253246     6147816       1179  4.95%  4.25%  4.10%   0 IP Input
  86     5459437     1100349       4961  1.59%  1.47%  1.54%   0 RedEarth Tx Mana
  85     3448684     1453278       2373  1.27%  1.04%  1.07%   0 RedEarth I2C dri

• Ran mostrou a tabela de endereços mac em diferentes switches e o próprio núcleo (no núcleo, por exemplo, conectado diretamente pela área de trabalho, minha área de trabalho), e podemos ver os vários endereços de hardware MAC sendo registrados na interface, mesmo que essa interface tenha sido apenas um computador conectado a isso:

 Vlan    Mac Address       Type        Ports
 ----    -----------       --------    -----
    1    001c.c06c.d620    DYNAMIC     Gi1/1/3
    1    001c.c06c.d694    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6ac    DYNAMIC     Gi1/1/3
    1    001c.c06c.d6e3    DYNAMIC     Gi1/1/3
    1    001c.c06c.d78c    DYNAMIC     Gi1/1/3
    1    001c.c06c.d7fc    DYNAMIC     Gi1/1/3

• mostre a utilização do tcam da plataforma

 CAM Utilization for ASIC# 0                      Max            Used
                                              Masks/Values    Masks/values

  Unicast mac addresses:                       6364/6364       1165/1165
  IPv4 IGMP groups + multicast routes:         1120/1120          1/1
  IPv4 unicast directly-connected routes:      6144/6144        524/524
  IPv4 unicast indirectly-connected routes:    2048/2048         77/77
  IPv4 policy based routing aces:               452/452          12/12
  IPv4 qos aces:                                512/512          21/21
  IPv4 security aces:                           964/964          45/45

Agora estamos em um estágio em que exigiremos uma quantidade enorme de tempo de inatividade para isolar cada área de cada vez, a menos que alguém tenha algumas idéias para identificar a origem ou a causa raiz desse problema estranho e bizarro.

Atualizar

Obrigado @ MikePennington e @ RickyBeam pela resposta detalhada. Vou tentar responder o que puder.

• Como mencionado, 192.168.0.0/20 é uma bagunça herdada. No entanto, pretendemos dividir isso no futuro, mas infelizmente esse problema ocorreu antes que pudéssemos fazer isso. Pessoalmente, também concordo com a maioria, segundo a qual o domínio de transmissão é muito grande.
• O uso do Arpwatch é definitivamente algo que podemos tentar, mas suspeito que várias portas de acesso estão registrando endereços MAC, mesmo que não pertençam a essa porta, a conclusão do arpwatch pode não ser útil.
• Concordo plenamente em não ter 100% de certeza de encontrar todos os links redundantes e comutadores desconhecidos na rede, mas como o melhor de nossa descoberta, esse é o caso até encontrarmos mais evidências.
• A segurança portuária foi analisada, infelizmente a gerência decidiu não usá-la por vários motivos. O motivo comum é que constantemente movemos os computadores (ambiente da faculdade).
• Usamos o spanning tree portfast juntamente com o spanning tree bpduguard por padrão em todas as portas de acesso (máquinas desktop).
• No momento, não usamos switchport não negociado na porta de acesso, mas não estamos recebendo nenhum ataque de salto de Vlan entre vários Vlans.
• Irá dar uma notificação à tabela de endereços mac e verificar se podemos encontrar algum padrão.

"Como você está recebendo um grande número de abas de MAC entre as portas de switch, é difícil encontrar onde estão os infratores (suponha que você encontre dois ou três endereços MAC que enviam muitos arps, mas os endereços Mac de origem continuam alternando entre as portas)."

• Começamos com isso, escolhemos qualquer um dos retalhos MAC e continuamos nosso caminho através de todo o switch central até a distribuição para acessar o switch, mas o que descobrimos foi mais uma vez, a interface da porta de acesso estava sobrecarregando vários endereços mac, portanto, mac flaps; Então, de volta à estaca zero.
• Controle de tempestade é algo que consideramos, mas tememos que alguns pacotes legítimos sejam descartados, causando mais problemas.
• Verificará três vezes a configuração do VMHost.
• @ytti, os endereços MAC inexplicáveis ​​estão atrás de muitas portas de acesso e não de um indivíduo. Não foram encontrados loops nessas interfaces. Os endereços MAC também existem em outras interfaces, o que explicaria grande número de abas MAC
• @ RickyBeam Concordo com o motivo pelo qual os hosts estão enviando tantas solicitações de ARP; esse é um dos problemas intrigantes. A ponte sem fio Rouge é interessante, e até onde sabemos, a conexão sem fio está em uma VLAN diferente; mas não autorizado, obviamente, significa que pode estar na VLAN1.
• @ RickyBeam, eu realmente não desejo desconectar tudo, pois isso causará uma quantidade enorme de tempo de inatividade. No entanto, é aqui que pode estar indo. Temos servidores Linux, mas não mais que 3.
• @ RickyBeam, você pode explicar a investigação "em uso" do servidor DHCP?

Nós (Cisco TAC, CCIEs, CCNP) concordamos globalmente que essa não é uma configuração de switch, mas um host / dispositivo está causando o problema.

Resolvido.

O problema está no SCCM 2012 SP1, um serviço chamado: ConfigMrg Wake-Up Proxy . O 'recurso' não existe no SCCM 2012 RTM.

Dentro de quatro horas após desativá-lo na política, vimos quedas constantes no uso da CPU. Quando as 4 horas terminaram, o uso do ARP era apenas 1-2%!

Em resumo, este serviço faz falsificação de endereço MAC! Não posso acreditar o quanto isso causou estragos.

Abaixo está um texto completo do Microsoft Technet, pois considero importante entender como isso se relaciona ao problema postado.

Para quem estiver interessado, abaixo estão os detalhes técnicos.

O Gerenciador de Configurações suporta duas tecnologias de ativação na rede de área local (LAN) para ativar os computadores no modo de suspensão quando você deseja instalar o software necessário, como atualizações e aplicativos de software: pacotes de ativação tradicionais e comandos de inicialização da AMT.

A partir do Gerenciador de Configurações SP1, você pode suplementar o método tradicional de pacotes de ativação usando as configurações do cliente de proxy de ativação. O proxy de ativação usa um protocolo ponto a ponto e computadores eleitos para verificar se outros computadores na sub-rede estão ativos e para ativá-los, se necessário. Quando o site está configurado para Wake On LAN e os clientes estão configurados para proxy de ativação, o processo funciona da seguinte maneira:

1. Os computadores que possuem o cliente do Gerenciador de Configurações SP1 instalado e que não estão inativos na sub-rede verificam se outros computadores na sub-rede estão ativos. Eles fazem isso enviando um ao outro um comando ping TCP / IP a cada 5 segundos.

2. Se não houver resposta de outros computadores, eles serão adormecidos. Os computadores que estão ativados se tornam computadores gerenciadores da sub-rede.

3. Como é possível que um computador possa não responder por um motivo diferente do que está adormecido (por exemplo, ele está desligado, removido da rede ou a configuração do cliente de ativação por proxy não é mais aplicada), os computadores estão enviava um pacote de ativação todos os dias às 14:00, horário local. Os computadores que não responderem não serão mais considerados adormecidos e não serão acordados pelo proxy de ativação.

Para oferecer suporte ao proxy de ativação, pelo menos três computadores devem estar ativos para cada sub-rede. Para conseguir isso, três computadores são escolhidos de maneira não determinística como computadores guardiões da sub-rede. Isso significa que eles permanecem acordados, apesar de qualquer política de energia configurada para dormir ou hibernar após um período de inatividade. Os computadores Guardian respeitam os comandos de desligamento ou reinicialização, por exemplo, como resultado de tarefas de manutenção. Se isso acontecer, os computadores guardiões restantes ativam outro computador na sub-rede, para que a sub-rede continue a ter três computadores guardiões.

Os computadores gerenciadores solicitam ao comutador de rede que redirecione o tráfego de rede dos computadores inativos para si mesmos.

O redirecionamento é alcançado pelo computador gerenciador que transmite um quadro Ethernet que usa o endereço MAC do computador adormecido como endereço de origem. Isso faz com que o comutador de rede se comporte como se o computador em suspensão tivesse sido movido para a mesma porta em que o computador gerenciador está. O computador gerenciador também envia pacotes ARP para os computadores inativos para manter a entrada atualizada no cache do ARP. O computador gerenciador também responderá às solicitações de ARP em nome do computador adormecido e responderá com o endereço MAC do computador adormecido.

Durante esse processo, o mapeamento de IP para MAC do computador adormecido permanece o mesmo. O proxy de ativação funciona informando o comutador de rede que um adaptador de rede diferente está usando a porta que foi registrada por outro adaptador de rede. No entanto, esse comportamento é conhecido como retalho MAC e é incomum para a operação de rede padrão. Algumas ferramentas de monitoramento de rede procuram esse comportamento e podem assumir que algo está errado. Conseqüentemente, essas ferramentas de monitoramento podem gerar alertas ou desligar portas quando você usa o proxy de ativação. Não use o proxy de ativação se suas ferramentas e serviços de monitoramento de rede não permitirem retalhos de MAC.

4. Quando um computador gerenciador vê uma nova solicitação de conexão TCP para um computador adormecido e a solicitação é para uma porta na qual o computador adormecido estava escutando antes de adormecer, o computador gerenciador envia um pacote de ativação ao computador adormecido e, em seguida, pára de redirecionar o tráfego para este computador.

5. O computador adormecido recebe o pacote de ativação e acorda. O computador remetente tenta novamente a conexão automaticamente e, desta vez, o computador está ativado e pode responder.

Ref: http://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#BKMK_PlanToWakeClients

Obrigado por todos que postaram aqui e ajudaram no processo de solução de problemas, muito apreciado.

Tempestade ARP / Broadcast

• Vemos grandes pacotes de transmissão da VLAN 1, VLAN 1 usados ​​para dispositivos de desktop. Usamos 192.168.0.0/20 ...
• O Wiresharks mostra que centenas de computadores estão inundando a rede com o ARP Broadcast ...

Seu processo de entrada de ARP é alto, o que significa que o switch está gastando muito tempo processando ARPs. Uma causa muito comum de inundação de ARP é um loop entre seus comutadores. Se você tiver um loop, também poderá obter as abas para mac mencionadas acima. Outras causas possíveis de inundações por ARP são:

• Configurações incorretas de endereço IP
• Um ataque da camada2, como a falsificação de arp

Primeiro elimine a possibilidade de configurações incorretas ou um ataque da camada2 mencionado acima. A maneira mais fácil de fazer isso é com o arpwatch em uma máquina Linux (mesmo que você precise usar um livecd em um laptop). Se você tiver um erro de configuração ou ataque da camada2, o arpwatch fornecerá mensagens como esta no syslog, que listam os endereços mac que estão lutando pelo mesmo endereço IP ...
Oct 20 10:31:13 tsunami arpwatch: flip flop 192.0.2.53 00:de:ad:85:85:ca (00:de:ad:3:d8:8e)

Quando você vê "chinelos", precisa rastrear a origem dos endereços mac e descobrir por que eles estão brigando pelo mesmo IP.

• Grande número de retalhos MAC
• A extensão da árvore foi verificada por indivíduos qualificados pelo Cisco TAC e CCNP / CCIE. Encerramos todos os links redundantes.

Falando como alguém que passou por isso mais vezes do que eu gostaria de lembrar, não assuma que você encontrou todos os links redundantes ... apenas faça seu switchports se comportar o tempo todo.

Como você está recebendo um grande número de abas de mac entre as portas de switch, é difícil encontrar onde estão os infratores (suponha que você encontre dois ou três endereços de mac que enviam muitos arps, mas os endereços de mac de origem continuam alternando entre portas). Se você não está aplicando um limite rígido em endereços MAC por porta de borda, é muito difícil rastrear esses problemas sem desconectar manualmente os cabos (que é o que você deseja evitar). Os loops de switch causam um caminho inesperado na rede e você pode acabar com centenas de macs aprendidos intermitentemente do que normalmente deve ser uma porta de switch de desktop.

A maneira mais fácil de desacelerar o mac-moves é com port-security. Em cada porta de switch de acesso na Vlan 1 conectada a um único PC (sem um switch downstream), configure os seguintes comandos no nível da interface em seus switches cisco ...

switchport mode access
switchport access vlan 1
!! switchport nonegotiate disables some Vlan-hopping attacks via Vlan1 -> another Vlan
switchport nonnegotiate
!! If no IP Phones are connected to your switches, then you could lower this
!!   Beware of people with VMWare / hubs under their desk, because 
!!   "maximum 3" could shutdown their ports if they have more than 3 macs
switchport port-security maximum 3
switchport port-security violation shutdown
switchport port-security aging time 5
switchport port-security aging type inactivity
switchport port-security
spanning-tree portfast
!! Ensure you don't have hidden STP loops because someone secretly cross-connected a 
!!   couple of desktop ports
spanning-tree bpduguard enable

Na maioria dos casos de inundação de mac / ARP, a aplicação dessa configuração a todas as suas portas de comutador de borda (especialmente todas com portfast) o levará de volta ao estado normal, porque a configuração encerrará qualquer porta que exceda três endereços de mac e desabilitará secretamente porta portfast em loop. Três macs por porta é um número que funciona bem no meu ambiente de desktop, mas você pode aumentá-lo para 10 e provavelmente está bem. Depois de fazer isso, todos os loops da camada 2 são quebrados, os retalhos rápidos do Mac cessam e facilita muito o diagnóstico.

Outro par de comandos globais que são úteis para rastrear portas associadas a uma tempestade de broadcast (mac-move) e flooding (threshold) ...

mac-address-table notification mac-move
mac address-table notification threshold limit 90 interval 900

Depois de terminar, opcionalmente, faça um clear mac address-tablepara acelerar a recuperação da tabela CAM potencialmente cheia.

• Ran mostrou a tabela de endereços mac em diferentes switches e o próprio núcleo (no núcleo, por exemplo, conectado diretamente pela área de trabalho, minha área de trabalho), e podemos ver os vários endereços de hardware MAC sendo registrados na interface, mesmo que essa interface tenha sido apenas um computador conectado a isso ...

Toda essa resposta assume que o 3750 não possui um bug que está causando o problema (mas você disse que o wireshark indicou computadores que estão inundando). O que você está mostrando para nós está obviamente errado quando há apenas um computador conectado ao Gi1 / 1/3, a menos que o PC tenha algo como o VMWare.

Pensamentos diversos

Com base em uma conversa de bate-papo que tivemos, provavelmente não preciso mencionar o óbvio, mas farei para futuros visitantes ...

• Colocar qualquer usuário no Vlan1 normalmente é uma má ideia (eu entendo que você pode ter herdado uma bagunça)
• Independentemente do que o TAC diz, 192.168.0.0/20 é muito grande para gerenciar em um único domínio comutado sem riscos de ataques da camada2. Quanto maior a sua máscara de sub-rede, maior a exposição a ataques de camada 2 como essa porque o ARP é um protocolo não autenticado e um roteador deve pelo menos ler um ARP válido dessa sub-rede.
• O controle de tempestades nas portas da camada 2 também costuma ser uma boa idéia; no entanto, ao ativar o controle de tempestades em uma situação como essa, o tráfego será bom com o tráfego ruim. Após a recuperação da rede, aplique algumas políticas de controle de tempestade nas portas de borda e nos uplinks.

A verdadeira questão é por que os hosts estão enviando tantos ARPs em primeiro lugar. Até que isso seja respondido, os comutadores continuarão tendo dificuldades para lidar com a tempestade arp. Incompatibilidade de máscara de rede? Temporizadores arp de host baixos? Um (ou mais) hosts com uma rota de "interface"? Uma ponte sem fio rouge em algum lugar? "arp gratuito" enlouqueceu? Sondagem "em uso" do servidor DHCP? Não parece um problema com os comutadores ou a camada 2; você tem hosts fazendo coisas ruins.

Meu processo de depuração desconectaria tudo e observaria atentamente como as coisas são reconectadas, uma porta por vez. (Eu sei que está a quilômetros do ideal, mas em algum momento você precisa reduzir suas perdas e tentar isolar fisicamente qualquer (s) fonte (s) possível). Então eu trabalhava para entender por que as portas selecionadas estão gerando muitos arps.

(Muitos desses hosts são sistemas linux? O Linux possui um sistema de gerenciamento de cache ARP estúpido e medíocre. O fato de "verificar novamente" uma entrada em poucos minutos está quebrado no meu livro. Tende a ser menos problemático em redes pequenas, mas um / 20 não é uma rede pequena.)

Isso pode ou não estar relacionado ao seu problema em questão, no entanto, achei que pode ser algo que vale a pena lançar pelo menos:

Atualmente, temos alguns 3750x empilhados em alguns de nossos sites remotos, principalmente executando o 15.0.2 (SE0 a 4, existem alguns erros de FRU com o SE0 dos quais estou migrando lentamente).

Durante uma atualização de rotina do IOS, passando de 15.0.2 para 15.2-1 (SE mais recente), notamos um aumento bastante significativo da CPU, de uma média de cerca de 30% a 60% e superior durante os horários fora de pico. Revisei configurações e logs de alteração do IOS e trabalhei com o TAC da Cisco. De acordo com o TAC, eles parecem estar no ponto em que acreditam que esse seja um bug do IOS 15.2-1.

Enquanto continuamos a investigar o aumento da CPU, começamos a ver grandes quantidades de tráfego ARP até o ponto em que nossas tabelas ARP se encheram completamente e causaram instabilidade na rede. A muleta temporária para isso foi fazer manualmente o retorno de nossos tempos limite de ARP do padrão (14400) para 300 em nossas vlans de voz e dados.

Após reduzir nossos tempos limite de ARP, permanecemos estáveis ​​por mais ou menos uma semana, quando retornamos ao IOS 15.0.2-SE4 e removemos nossos tempos limite de ARP não padrão. Nossa utilização da CPU está reduzida a ~ 30% e nossos problemas de tabela ARP são inexistentes.

Um simples fracassado, mas talvez esquecido; seus clientes têm um gateway padrão válido, não é você que faz muitos arps de proxy? Você poderia negar a função arp do proxy ip no seu 3750?