Tenho quase certeza de que seu problema não é causado por apenas um fator, mas sim por uma combinação de fatores. O que esses fatores individuais são não é certo, mas provavelmente um fator é a interface de rede ou o driver e outro fator é encontrado no próprio switch. Por isso, é bem provável que o problema só possa ser reproduzido com essa marca específica de switch combinada com essa marca específica de interface de rede.
Você parece ser o gatilho para o problema é algo acontecendo em um servidor individual que, então, tem um kernel panic que tem efeitos que de alguma forma conseguem se propagar através do switch. Isso parece provável, mas eu diria que é quase provável que o gatilho esteja em outro lugar.
Pode ser que algo esteja acontecendo no switch ou na interface de rede, o que causa simultaneamente o problema de kernel panic e link no switch. Em outras palavras, mesmo que o kernel não tenha tido um kernel panic, o trigger pode muito bem ter derrubado a conectividade no switch.
Alguém tem que perguntar, o que poderia acontecer no servidor individual, o que poderia ter esse efeito nos outros servidores. Não deveria ser possível, então a explicação tem que envolver uma falha em algum lugar do sistema.
Se fosse apenas o link entre o servidor com falha e o comutador que ficou inativo ou ficou instável, isso não deverá afetar o estado do link para os outros servidores. Se isso acontecer, isso contaria como uma falha no switch. E no sentido horário, os outros servidores devem ver um tráfego um pouco menor quando o servidor com falha perder a conectividade, o que não pode explicar por que eles veem o problema que eles fazem.
Isso me leva a acreditar que uma falha de design no switch é provável.
No entanto, um problema de link não é a primeira explicação que alguém procuraria ao tentar explicar como um problema em um servidor poderia causar problemas a outros servidores no comutador. Uma tempestade de transmissão seria uma explicação mais óbvia. Mas poderia haver um link entre um servidor com um pânico no kernel e uma tempestade de transmissão?
O multicast e os pacotes destinados a endereços MAC desconhecidos são mais ou menos tratados da mesma forma que os broadcasts, portanto, uma tempestade desses pacotes também contaria. O servidor paniced poderia estar tentando enviar um crashdump pela rede para um endereço MAC não reconhecido pelo switch?
Se esse é o gatilho, então algo está errado nos outros servidores. Porque uma tempestade de pacotes não deve causar esse tipo de erro na interface de rede. Reset adapter unexpectedly não soa como uma tempestade de pacotes (que deve causar apenas uma queda no desempenho, mas nenhum erro como tal), e não soa como um problema de link (que deveria resultar em mensagens sobre links sendo desativados, mas não erro que você está vendo).
Portanto, é provável que exista alguma falha no hardware ou no driver da interface de rede, que é acionado pelo comutador.
Algumas sugestões que podem fornecer pistas adicionais:
- Você pode conectar algum outro equipamento ao switch e ver o tráfego que vê no switch quando o problema é exibido (eu prevejo que ele fica tranquilo ou você vê uma inundação).
- Seria possível substituir a interface de rede em um dos servidores com uma marca diferente usando um driver diferente para ver como o resultado é diferente?
- É possível substituir um dos switches por uma marca diferente? Espero que a substituição do comutador garanta que o problema não afeta mais vários servidores. O que é mais interessante saber é se isso também impede que o pânico do kernel aconteça.