Possível loop de rede com WiFi e Ethernet quando acoplado

Question

Eu tenho visto um problema estranho que não posso reproduzir sob demanda e suspeito da causa raiz.

O problema: de forma intermitente, toda a rede fica inativa até que eu ando por aí e desplugue qualquer computador que esteja causando a inundação da árvore de abrangência.

Topologia: Eu tenho dois switches gigabit não gerenciados da Cisco conectados via gigabit gbic. Ambos os switches têm a porta correspondente ao lado da porta gigabit gbic desocupada, de modo que o up-link funcione conforme projetado. Os dois switches são Cisco e a mesma família (SG100 e SG102), portanto, não é uma questão de incompatibilidade.

Eu peguei uma captura wireshark diretamente conectada à máquina culpada, assim como conectei através do switch e BOTH produzi a mesma inundação Tree que faz com que o quadro MAC PAUSE reduza a velocidade das coisas, o que mata a rede.

Probable culprit but unable to replicate issue "YET" is that this seems to usually occur AFTER the following occurs:
1. User undocks their laptop from their docking station and connects to WiFi
2. User is done with need for laptop away from desk and re-docks
3. User's laptop re-connects via Ethernet on the docking station
4. Sometimes crashes entire network.

Como fui incapaz de replicar o problema sob demanda, como eu poderia criar um filtro de algum tipo para o Wireshark capturar apenas os pacotes que se assemelhariam a um eco (NÃO ICMP ECHO) mais como tráfego duplicado causando a tempestade inicial? antes de enlouquecer com spanning tree?

Dessa forma, posso executar a captura por dias ou semanas até que ocorra novamente. Abaixo está o que estou vendo depois que a rede cai no wireshark.

Como esses switches não são gerenciados, eles nem sequer suportam o STP, por isso estou confuso sobre o motivo pelo qual ele sempre termina com o tráfego da árvore de abrangência. Além disso, o endereço MAC de origem não existe em uma configuração natural e eu só conheço a estação de trabalho afetada após o fato e ela também é sempre congelada ou ocasionalmente obtida uma BSOD. Já faz muito tempo desde que eu vi um BSOD quando isso acontece, mas o sistema congelado ocorre toda vez e não há minidespejo e sim está configurado.

Other things I've already eliminated:
Cabling or cabling loop(s)
event logs - just show time loss between frozen time and reboot
no dumps when frozen
updated to Dell's latest certified drivers and BIOS
rebooted everything (again intermittent but usually after a undock, connecft to WiFi, re-dock and auto connect to ethernet pattern)

    

Answer 1

Primeiro, só para esclarecer, este não é o protocolo Spanning Tree (IEEE 802.1D), este é o controle de fluxo de Ethernet (IEEE 802.3x, agora parte do IEEE 802.3-2012). Os quadros PAUSE de controle de fluxo Ethernet são endereçados a um dos mesmos endereços que o STP usa, portanto, os sniffers de pacotes geralmente relatam o endereço como um endereço STP, mesmo quando está sendo usado para controle de fluxo.

A era 802.3x do controle de fluxo Ethernet foi meio que um fracasso. Foi descoberto tarde demais que poderia causar problemas na rede, especialmente o bloqueio de "cabeça de linha". Imagine um servidor rápido servindo dados para um cliente normal e um cliente lento. O cliente lento fica sobrecarregado envia um quadro PAUSE para o switch, e agora o switch não pode entregar todos os quadros que está recebendo do servidor, então o switch envia um quadro PAUSE para o servidor. Isso impede que o servidor possa enviar quadros para o outro cliente (normal), mesmo que o servidor, o comutador e o cliente tenham a capacidade extra para ele. Este cliente lento (e um switch não muito brilhante e o protocolo de controle de fluxo Ethernet 802.3x não muito brilhante) estragou tudo para todos.

Por causa disso, alguns fornecedores de switch intencionalmente não suportam controle de fluxo no estilo 802.3x, ou se eles o suportam, eles só permitem que o switch honre quadros PAUSE de entrada, mas nunca os envie. Se seus switches forem gerenciáveis e tiverem configurações para o controle de fluxo, verifique se eles estão configurados para nunca enviar quadros PAUSE.

Na verdade, considerando que você está vendo um quadro de PAUSE inunda, sua rede provavelmente estaria melhor se você desativasse o controle de fluxo todos juntos. Configure seus switches e clientes para desabilitar o controle de fluxo.

Além disso, mantenha seus drivers Ethernet atualizados e considere limpar sua rede de qualquer modelo de NIC Ethernet que seja conhecido por spam na rede com quadros PAUSE quando o host falhar.