Rede inundada com pacotes aparentemente vazios

2

Deixe-me começar com o fato de que sou apenas um desenvolvedor da Web na minha empresa com pouco conhecimento de rede.

Hoje, havia um departamento que perdeu todas as suas conexões de rede, então eu abri o Wireshark e observei o fluxo de pacotes para a minha máquina.

Houve tráfego normal (solicitações ARP, etc.) chegando a ~ 50 pacotes a cada segundo. Então, de repente, o registro foi inundado com pacotes chegando a ~ 5000 por segundo. Parece que todos eles contêm os mesmos dados, apenas uma sequência em loop.

Temos alguém aqui olhando para ele, mas pensei em perguntar se alguém já tinha visto algo assim antes.

Aqui está uma seleção de uma das capturas no Wireshark (clique na imagem para abrir a captura Cloudshark):

    
por Adam Particka 09.11.2012 / 20:30

2 respostas

10

Primeiro, nem o número de quadros nem a quantidade de dados devem impactar significativamente as conexões de rede, mesmo com apenas Fast Ethernet no lugar - 5.000 quadros de 500 bytes equivalem a pouco menos de 2,5 MB / segundo de dados. Eles podem desencadear mecanismos de detecção de tempestades de broadcast em seus swithes, levando a broadcasts de tráfego legítimo - especialmente solicitações ARP - que poderiam afetar adversamente a conectividade IP (embora normalmente não a interrompam completamente, é provável que você veja perdas de pacotes devido a ARP inoportuna resolução).

Os quadros da LLC na sua captura enviada parecem estranhos. Nem o endereço de origem nem o endereço de destino multicast parecem endereços válidos do mundo real. Além disso, o formato de quadro LLC viola o padrão - os endereços NULL são usados em conjunto com um tipo de quadro de interface do usuário - o que nunca deveria acontecer:

The null address is only valid for use in the address fields of XID and TEST PDUs. The use of the null address (DSAP and SSAP) is specified in ISO/IEC 8802-2.

(Fonte: tutorial do IEEE LLC )

Eu suspeito que algum dispositivo (presumivelmente não uma Xerox, embora o endereço de origem resolva o espaço de endereço MAC da Xerox - eu esperaria que eles soubessem e respeitassem as regras básicas) está violando o protocolo. Tente procurá-lo consultando as tabelas de endereço / FDB dos switches gerenciados: inicie em um switch gerenciável arbitrário, localize o endereço 00:00:03:20:00:00 na tabela que presumivelmente estaria associado a uma porta upstream para outro switch, siga para o próximo switch repetindo o procedimento, a menos que você encontre o endereço associado a uma porta de borda (ou seja, uma porta com um único host conectado).

    
por 09.11.2012 / 22:35
1

Quando olho para o hexdump, noto que é a mesma sequência de quatro bytes repetidos várias vezes. Essa sequência de quatro bytes não é válida, e tentar decodificá-la não produzirá nenhuma informação útil.

Essa seqüência repetitiva abrange tanto o endereço MAC de origem quanto o de destino, bem como o tipo Ether. Isso significa que nem o endereço MAC de origem nem de destino significa nada, eles foram corrompidos. Este também não é um quadro LLC, acontece que esta sequência de bytes foi decodificada como LLC.

Se você vir algo parecido novamente, eu tentarei capturar o tráfego usando mais de uma marca de adaptador Ethernet para ter certeza de que esses quadros corrompidos estão sendo realmente enviados, e não apenas um artefato introduzido a máquina fazendo a captura.

Se você estabeleceu que esse tráfego está realmente sendo enviado pela rede, terá que começar a procurar o dispositivo que está produzindo. Isso parece um problema de baixo nível na camada física abaixo da camada MAC. Você não terá endereços MAC, então a única opção para encontrar a fonte pode ser ver o status do link piscando e desconectar os fios até encontrar o que está produzindo os pacotes.

Não é improvável que a causa raiz seja hardware defeituoso.

    
por 17.05.2014 / 23:41