Ethernet jamming [closed]

Question

Eu só tive uma experiência estranha na minha rede doméstica. Nossa ethernet caiu; pingar um host adjacente era impossível. Eu verifiquei o interruptor; todas as luzes estavam acesas e piscando, embora estivessem piscando em sincronia, o que era um pouco preocupante. Então notei que minha caixa do Linux havia caído (não respondia ao mouse e ao teclado). Eu apertei o botão de reset, e naquele momento a rede clareou.

Isso seria de interesse apenas acadêmico, exceto pelo fato de meu empregador estar em um negócio onde a continuidade do serviço é de grande importância. Dados críticos são enviados através de duas LANs Ethernet independentes. Nossos modelos de confiabilidade assumem que a única coisa que poderia derrubar uma LAN inteira é um switch com falha. Então a idéia de que um único host com defeito poderia fazer isso é ... preocupante.

Esta mensagem em um fórum da Cisco diz é impossível, então não se preocupe.

Este relatório sobre uma interrupção em a alfândega dos EUA é semelhante: um cartão Ethernet com defeito comprou sua rede. Essa era uma única rede e soa como uma falha de hardware, por isso não derrubaria nossas duas redes duplas. Mas eu estou querendo saber: um bug de driver de dispositivo poderia comprometer um cartão em um estado em que ele estava interferindo na rede? Se sim, então, se estivesse dirigindo dois canais ligados, ele poderia se dividir da mesma maneira.

Alguém sabe mais sobre os possíveis modos de falha da Ethernet?

Editar

O que estou tentando entender é: o que um nó poderia fazer no software (por exemplo, em um driver de dispositivo) que poderia derrubar toda a rede. Vamos supor que não é malware, bugs tão obscuros de switches específicos provavelmente não são um problema. O envio de quadros para um único host específico não faz isso. O envio de muitos quadros de broadcast (destino FF: FF: FF: FF: FF) tem esse efeito? E quanto ao jabber? Isso é uma coisa ainda?

    

Answer 1

Aqui estão algumas coisas que podem causar o comportamento que você presenciou:

1. Um loop de comutador.

2. Malware.

3. Uma placa de rede com defeito / defeituosa.

4. Um driver de NIC com bugs / mau comportamento.

5. Uma tempestade de transmissão (geralmente associada a um loop de comutador).

Para resolver sua edição: uma tempestade de transmissão ou uma inundação de comutador (que são duas coisas diferentes) podem causar esse problema. Observe que há dois endereços de broadcast funcionando aqui: FF-FF-FF-FF-FF (255.255.255.255), que é o endereço de broadcast da Camada 2, E o endereço de broadcast da sub-rede da Camada 3 (por exemplo, 192.168.1.255 é o endereço de broadcast da sub-rede da camada 3 para a sub-rede 192.168.1.0/24). Uma tempestade de transmissão na Camada 2 ou na Camada 3 pode causar esse problema.

    

Answer 2

Alterna o código de execução em seu firmware. Às vezes, esse código é buggy e a entrada inesperada pode travar o switch. Então, sim, um host mal-comportado pode travar um switch. Não é muito provável, mas pode acontecer.

Anos atrás (2003 talvez?) eu tinha switches Netgear não gerenciados que caíam de 2 a 4 vezes por semana, como se estivessem passando por uma tempestade - como sua descrição acima. A reinicialização da pilha foi a única correção. O suporte da Netgear disse que eles tinham um problema conhecido com a execução de IP e IPX neles e, como não eram gerenciados, não havia nada para solucionar. Eles tinham sido EoL sem mais atualizações de firmware, então eles os substituíram por novos switches gerenciados, sob garantia.

No que diz respeito a "listar todos os possíveis modos de falha da Ethernet" - não, esse é um pedido tolo. No entanto, para a sua própria educação, leia os loops de spanning tree, que é um modo comum de falha induzida pelo usuário.

    

Answer 3

Como a caixa do Linux parece ter duas interfaces de rede local: você pode descartar que ela não estava conectando temporariamente essas duas interfaces, criando um loop de ponte?

O uso de apenas dois switches não é de alta disponibilidade. Você deve ter indicadores nos interruptores sinalizando uma tempestade de transmissão e software de monitoramento apropriado. Para isso, configure uma VLAN de gerenciamento com uma prioridade mais alta para que não seja interrompida por uma tempestade de transmissão. Como alternativa, execute as funções de gerenciamento em links de rede fisicamente separados ou fora de banda.

PS para sua edição: Em uma rede comutada , as únicas coisas capazes de derrubar todas as portas são tempestades de transmissão ou congestionamento severo. Quadros superdimensionados (jabber), fragmentos ou anomalias semelhantes são simplesmente descartados por um switch. Uma tempestade de transmissão de uma porta de ingresso pode inundar a rede com a largura de banda dessa porta - uma porta de 100M não causa muito dano a uma rede 1G, mas uma porta 1G pode facilmente afogar todas as portas de saída de 100M. Da mesma forma, o envio de mais dados por meio de um uplink com o qual ele pode lidar derrubará a maior parte do tráfego nessa direção.

Tempestades de transmissão geralmente são causadas por loops de ponte. Spanning tree é um bom remédio para isso, permitindo também que você adicione links redundantes à sua rede. Outras tempestades podem ser manipuladas por limitação de transmissão em portas de borda.

O congestionamento é uma fera mais difícil. A abordagem de hardware é garantir que todas as portas de download / download sejam mais rápidas do que qualquer porta de borda. Em um switch gigabit com um uplink 10GE, você precisaria de pelo menos 10 portas de borda para saturar o uplink. Outra abordagem é limitar a largura de banda da porta de borda para que eles não possam superalimentar o uplink.