Broadcast storm - como identificar a fonte?

Question

Eu tive duas situações nesta semana em que meu provedor de uplink precisou desativar nosso link porque seu roteador identificou uma tempestade de transmissão. Infelizmente, eles não podem fornecer mais informações sobre a origem do problema.

Qual é a melhor maneira de identificar o que está causando esse problema?

Eu tenho um roteador Vyatta entre o provedor de uplink e minha rede. Está rodando "tcpdump broadcast" e registrando uma solução viável?

Dessa forma, talvez eu possa ter pelo menos um log e identificar os IPs com mais tráfego de broadcast se esse problema acontecer novamente.

    

Answer 1

Existe mais de um tipo de transmissão.

As transmissões de camada 2 (rede) (tráfego para o endereço MAC all-1) são usadas por protocolos como o ARP para coletar informações sobre como se conectar a um nó específico quando já conhece seu endereço de camada superior (geralmente IP).

Transmissões de camada 3 (IP) (tráfego para o endereço mais alto da sub-rede) servem funções totalmente diferentes.

Se o seu provedor de rede é afetado pelo tráfego de difusão da camada 2, eu realmente me pergunto sobre o nível de competência deles.

O seu provedor de rede normalmente se conecta através de um roteador IP (camada 3), que não passa o tráfego da camada 2.

As únicas transmissões de nota da camada 3 são as solicitações típicas de serviço de nomes do Windows (WINS e semelhantes)

Esse comportamento pode indicar um problema de hardware no roteador ou em qualquer outro ponto entre os nós finais (seu computador e o provedor de rede).

    

Answer 2

Eu não estou familiarizado com o Vyatta, mas é possível que haja algum arp gratuito acontecendo (geralmente em eventos de failover), causando o problema. Esse é um mecanismo muito comum para forçar atualizações de cache de ar durante o failover, mas pode causar problemas como esse, dependendo da agressividade das transmissões e da sensibilidade dos destinatários.

Vale a pena olhar para qualquer um dos lados.

    

Answer 3

Obrigado por todos que responderam!

Depois de investigar isso mais, parecia que o limite de cache do arp estava definido como um valor muito baixo e não estava mantendo todos os hosts em nossa rede.

Depois de definir isso para um valor maior, resolveu o problema.