O adaptador de rede do Windows Server 2008 R2 para de funcionar e requer reinicialização completa

Versão TL; DR: Acontece que este foi um erro profundo na rede Broadcom no Windows Server 2008 R2. A substituição pelo hardware Intel o corrigiu. Não usamos mais o hardware Broadcom. Sempre.

Temos usado o HAProxy junto com a pulsação do projeto Linux-HA. Estamos usando duas instâncias linux para fornecer um failover. Cada servidor possui seu próprio IP público e um único IP, que é compartilhado entre os dois usando uma interface virtual (eth1: 1) no IP: 69.59.196.211

A interface virtual (eth1: 1) IP 69.59.196.211 é configurada como o gateway para os servidores Windows por trás deles e usamos ip_forwarding para rotear o tráfego.

Estamos enfrentando uma interrupção ocasional da rede em um de nossos servidores Windows atrás de nossos gateways Linux. O HAProxy detectará que o servidor está offline, o que podemos verificar remotamente ao servidor com falha e tentando executar ping no gateway:

Ping 69.59.196.211 com 32 bytes de dados:
Resposta de 69.59.196.220: Host de destino inacessível.

A execução arp -aneste servidor com falha mostra que não há entrada para o endereço do gateway (69.59.196.211):

Interface: 69.59.196.220 --- 0xa
Tipo de endereço físico do endereço da Internet
69.59.196.161 00-26-88-63-c7-80 dynamic
69.59.196.210 00-15-5d-0a-3e-0e dinâmico
69.59.196.212 00-21-5e-4d-45-c9 dinâmico
69.59.196.213 00-15-5d-00-b2-0d dinâmico
69.59.196.215 00-21-5e-4d-61-1a dinâmico
69.59.196.217 00-21-5e-4d-2c-e8 dynamic
69.59.196.219 00-21-5e-4d-38-e5 dynamic
69.59.196.221 00-15-5d-00-b2-0d dynamic
69.59.196.222 00-15-5d-0a-3e-09 dynamic
69.59.196.223 estática ff-ff-ff-ff-ff-ff estática
224.0.0.22 01-00-5e-00-00-16 static
224.0.0.252 01-00-5e-00-00-fc static
225.0.0.1 01-00-5e-00-00-01 estático

Em nossas instâncias de gateway linux, arp -amostra:

peak-colo-196-220.peak.org (69.59.196.220) em <incomplete> on eth1
stackoverflow.com (69.59.196.212) às 00: 21: 5e: 4d: 45: c9 [éter] no eth1
peak-colo-196-215.peak.org (69.59.196.215) às 00: 21: 5e: 4d: 61: 1a [éter] em eth1
peak-colo-196-219.peak.org (69.59.196.219) às 00: 21: 5e: 4d: 38: e5 [éter] em eth1
peak-colo-196-222.peak.org (69.59.196.222) às 00: 15: 5d: 0a: 3e: 09 [éter] em eth1
peak-colo-196-209.peak.org (69.59.196.209) às 00: 26: 88: 63: c7: 80 [éter] em eth1
peak-colo-196-217.peak.org (69.59.196.217) às 00: 21: 5e: 4d: 2c: e8 [éter] em eth1

Por que o arp definiria ocasionalmente a entrada para esse servidor com falha como <incompleto>? Deveríamos estar definindo nossas entradas arp estaticamente? Eu sempre deixei o arp sozinho, pois funciona 99% do tempo, mas neste caso parece estar falhando. Existem etapas adicionais para solução de problemas que podemos seguir para resolver esse problema?

Coisas que tentamos

Eu adicionei uma entrada arp estática para teste em um dos gateways linux que ainda não ajudou.

root@haproxy2:~# arp -a
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org (69.59.196.221) at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org (69.59.196.219) at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org (69.59.196.209) at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org (69.59.196.217) at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org (69.59.196.220) at 00:21:5e:4d:30:8d [ether] PERM on eth1

root@haproxy2:~# arp -i eth1 -s 69.59.196.220 00:21:5e:4d:30:8d
root@haproxy2:~# ping 69.59.196.220
PING 69.59.196.220 (69.59.196.220) 56(84) bytes of data.
--- 69.59.196.220 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms

A reinicialização do servidor web Windows resolve esse problema temporariamente, sem outras alterações na rede, mas nossa experiência mostra que esse problema voltará.

Troca de placas de rede e switches

Percebi que a luz do link na porta do comutador para o servidor Windows com falha estava sendo executada a 100 Mb em vez de 1 Gb na interface com falha. Mudei o cabo para várias outras portas abertas e o link indicou 100Mb para cada porta que tentei. Também troquei o cabo com o mesmo resultado. Tentei alterar as propriedades da placa de rede no Windows e o servidor travou e exigiu uma redefinição após clicar em aplicar. Este servidor Windows possui duas interfaces de rede físicas, então troquei os cabos e as configurações de rede nas duas interfaces para verificar se o problema segue a interface. Se a interface pública cair novamente, saberemos que não há problema com a placa de rede.

(Também tentamos outra opção que temos à mão, sem alterações)

Alterando as versões do driver de hardware de rede

Tivemos o mesmo problema com o driver Broadcom mais recente, bem como o driver interno fornecido no Windows Server 2008 R2.

Substituindo cabos de rede

Como último esforço, lembramos que outra mudança ocorreu foi a substituição de todos os cabos de conexão entre nossos servidores / comutadores. Nós compramos dois conjuntos, um verde de 1 a 3 pés para as interfaces privadas e outro conjunto de cabos vermelhos para as interfaces públicas. Trocamos todos os cabos de patch da interface pública por uma marca diferente e executamos nossos servidores sem problemas por uma semana inteira ... aaaaaa e então o problema se repetiu.

Desabilitar o descarregamento da soma de verificação, remover o TProxy

Também tentamos desativar a descarga da soma de verificação TCP / IP no driver, sem alterações. Agora estamos retirando o TProxy e mudando para um x-forwarded-forarranjo de rede mais tradicional sem precisar reescrever os endereços IP. Vamos ver se isso ajuda.

Alternar entre provedores de virtualização

Na hipótese de isso estar relacionado ao Hyper-V de alguma forma (nós hospedamos VMs Linux nele), mudamos para o VMWare Server. Nenhuma mudança.

Alternar modelo de host

Chegamos ao final da nossa solução de problemas e agora estamos envolvendo formalmente o suporte da Microsoft. Eles recomendaram alterar o modelo do host:

• http://en.wikipedia.org/wiki/Host_model
• http://technet.microsoft.com/en-us/magazine/2007.09.cableguy.aspx

Fizemos isso e também recebemos alguns hotfixes de kernel não publicados que provavelmente foram lançados no 2008 R2 SP1. Sem reparo.

Substituindo o hardware da placa de rede

Por fim, a substituição do hardware de rede Broadcom pelo hardware de rede Intel corrigiu esse problema para nós. Portanto, estou inclinado a pensar que os drivers do Broadcom Windows Server 2008 R2 estão com defeito!

http://blog.serverfault.com/post/broadcom-die-mutha/

Em http://linux-ip.net/html/ether-arp.html :

Se nenhuma entrada de cache ARP existir para um IP de destino solicitado, o kernel gerará solicitações ARP mcast_solicit até receber uma resposta. Durante esse período de descoberta, a entrada de cache do ARP será listada em um estado incompleto. Se a pesquisa não for bem-sucedida após o número especificado de solicitações de ARP, a entrada de cache do ARP será listada em um estado com falha. Se a pesquisa for bem-sucedida, o kernel digitará a resposta no cache do ARP e redefinirá os cronômetros de confirmação e atualização.

Parece que sua caixa de gateway não está respondendo (ou está respondendo muito lentamente) às solicitações de ARP da caixa de gateway. Isso <incomplete>finalmente muda para <failed>? Qual hardware de rede você tem entre o servidor e o gateway? É possível que as solicitações de transmissão ARP estejam sendo filtradas ou bloqueadas em algum lugar entre os dois hosts?

Isso significa que você efetuou ping no endereço, o IP possui um registro PTR (daí o nome), mas nada respondeu da máquina em questão. Quando vemos isso, é mais comum o fato de uma máscara de sub-rede ser configurada incorretamente - ou no caso de IPs vinculados a uma interface de loopback que foram acidentalmente vinculados à interface eth.

O que é 196.220? Qual é a relação com 196.211? Estou assumindo que .220 é um dos hosts do Proxy HA. Quando você executa o ifconfig -a & arp -a nele, o que mostra?

Como diz Max Clark, o <incompleto> significa apenas que 69.59.196.211 apresentou uma solicitação de ARP para 69.59.196.220 e ainda não recebeu uma resposta. (Na região do Windows, você verá isso como um mapeamento ARP para "00-00-00-00-00-00" ... Parece estranho para mim, BTW, que você não esteja vendo um mapeamento ARP em 69.59.196.220 para 69.59.196.211.)

Costumo não gostar de usar entradas estáticas do ARP porque, na minha experiência, o ARP geralmente faz seu trabalho o tempo todo.

Se fosse eu, cheiraria a interface Ethernet apropriada na máquina Windows "com falha" (69.59.196.220) para observá-la ARP em 69.59.196.211 e para observar como / se está respondendo às solicitações de ARP de 69.59. 196.211. Também consideraria cheirar a máquina de gateway apenas para ARP ( tcpdump -i interface-name arp) para ver como é o tráfego ARP na lateral da máquina Linux.

Eu sei, no blog , que você tem uma rede de back-end e uma rede de front-end. Durante essas interrupções, o servidor Windows "com falha" (69.59.196.220) tem problemas para se comunicar com outras máquinas na rede front-end ou está apenas com problemas para conversar com seu gateway? Estou curioso para saber se você está entrando na máquina com falha através da rede de front-end ou back-end quando está pegando em flagrante.

O que você está fazendo para "resolver" o problema quando ele ocorre?

Editar:

Vejo pela atualização que você está reiniciando a máquina Windows "com falha" para resolver o problema. Antes de fazer isso da próxima vez, você pode verificar se a máquina Windows é capaz de "falar" em sua interface front-end? Além disso, pegue uma cópia da tabela de roteamento na máquina Windows ( route print) durante uma falha também. (Estou tentando verificar se a NIC / driver está ficando louca na máquina Windows, basicamente.)

Este documento mostra os diferentes estados (tabela 2.1). Incompleto significa que ele enviou uma primeira solicitação de ARP (presumivelmente após uma tentativa de atraso, atraso, investigação), mas ainda não recebeu uma resposta.

A razão pela qual o ARP estático no nó haproxy não ajuda é que seu servidor da web ainda não consegue descobrir como voltar ao gateway.

O ARP estático no servidor da Web interrompe a capacidade de seus servidores de alternar gateways quando um dos nós haproxy falhou - eu acho que a interface virtual compartilha o mesmo endereço MAC que o eth1 do nó haproxy, então você precisa código para um dos dois gateways em cada servidor web.

Você tem algum tipo de software de segurança instalado no servidor da web com falha? Passei uma longa noite com um servidor Windows 2008 que continha o Symantec Endpoint Security - ele instala algum código de filtragem na pilha de rede que impedia a visualização dos pacotes ARP do gateway. A correção para isso (conforme fornecida pela Microsoft) era remover a entrada do registro que carregava a DLL.

Na outra vez em que esse problema ocorreu, remover o adaptador de rede inteiro do gerenciador de dispositivos e reinstalar parecia ajudar.

Como você definiu estaticamente sua entrada arp, seus servidores sabem onde encontrar o gateway. No entanto, se o seu switch não souber onde está o gateway, ele não encaminhará seus pacotes.

Parece que você tem uma troca ruim (ou confusa) entre o HAproxy e os servidores da web. Reinicie.

Ou isso, ou os servidores HAproxy discordam sobre qual deles está no controle, e os dois que estão respondendo às pesquisas do arp em .211.

Na mesma linha, se o seu switch estiver sobrecarregado, os HAproxies poderão não conseguir se comunicar com a rapidez suficiente e o failover.

Na próxima vez que esse problema ocorrer, sugiro executar algumas capturas de pacotes nos dois hosts em questão, para determinar qual tráfego ARP cada um deles está observando.

Sua máquina HAproxy provavelmente terá algum tipo de tcpdump instalado. Para a máquina Windows, você precisará de um aplicativo WinPCAP , como o Wireshark , ou o Microsoft Network Monitor .

De fato, pensando nisso, como o problema parece estar especificamente com o ARP, você pode potencialmente registrar continuamente todo o tráfego do ARP na máquina HAproxy e na máquina Windows em questão, com um arquivo de captura contínuo de 10MB (por uma questão de argumento). Isso deve ser grande o suficiente para que, quando você detectar uma falha, o arquivo de captura ainda contenha o tráfego ARP anterior à falha. (Vale a pena experimentar executando a captura por mais ou menos uma hora, para ver a quantidade de dados que ela gera).

Exemplo de sintaxe de captura para o Linux tcpdump (observe, não tenho uma caixa do Linux à mão para testar isso; teste o comportamento de -C e -W antes de usar na produção!):

tcpdump -C 10 -i eth1 -w /var/tmp/arp.cap -W 1 arp

Esperamos que isso lhe dê alguma indicação do que exatamente está falhando. Quando uma entrada ARP expira (e, de acordo com este artigo , as versões mais recentes do Windows parecem envelhecer muito agressivamente as entradas 'inativas'), eu esperaria o seguinte:

1. O host de origem enviará uma solicitação ARP ao host de destino. As solicitações de ARP geralmente são transmitidas, mas no caso em que um host está atualizando uma entrada existente, o ARP pode ser enviado unicast.
2. O host de destino responderá com uma resposta ARP. Em 99% do tempo, isso será unicast, mas o RFC permite respostas de transmissão. (Consulte também a RFC referente à detecção de colisão de endereços IPv4 para obter mais detalhes).

Por mais simples que pareça, existem várias outras coisas que podem interferir nesse processo:

• A solicitação original pode não estar chegando ao destino.
• A solicitação pode estar chegando ao destino, mas a resposta pode não estar chegando à fonte.
• Algum tipo de mecanismo de alta disponibilidade pode estar interferindo no comportamento 'normal' do ARP:
  • Como o failover entre os nós HAProxy funciona? Ele usa um endereço MAC compartilhado ou usa ARP gratuito para fazer failover de um endereço IP entre nós?
  • Muitos endereços MAC nas tabelas ARP acima começam com 00-15-5D, que aparentemente está registrado na Microsoft. Você está usando alguma forma de cluster ou outra HA na máquina Windows em questão? Esses endereços MAC 00-15-5D são os mesmos que você vê associados às NICs de hardware quando você faz um 'ipconfig / all' no servidor Windows?

Coisas para verificar se / quando isso acontecer novamente:

• Veja as capturas de pacotes do tráfego ARP; alguma parte da conversa obviamente não ocorreu?
• Verifique as tabelas de ponte / CAM do switch; todos os endereços MAC em questão são mapeados para as portas que você espera?
• Outros hosts na sub-rede possuem entradas ARP válidas para os endereços IP dos hosts Windows e HAProxy?
• As entradas ARP para o mesmo IP de destino em várias máquinas de origem diferentes são resolvidas para o mesmo endereço MAC? ou seja, faça logon em alguns outros hosts na sub-rede e verifique se o 196.211 resolve o mesmo endereço MAC em ambos.

Tivemos um problema semelhante com um de nossos servidores de terminal 2008 R2, em que todo o tráfego na NIC parava, mas permanecia conectado, e os LEDs da NIC mostravam vírgulas. Esse era um problema contínuo que continuava aparecendo de 2 a 3 vezes por semana, mas somente após 12 a 13 horas de funcionamento (o servidor é reiniciado todas as noites).

Descobri que o Seriousbit Netbalancer era a causa, depois que tentei (por curiosidade) encerrar o serviço NetbalancerService. O tráfego começou a se mover pela interface. Desde então, desinstalei o Netbalancer.

Eu tive um mesmo problema com o Asus Mainboard lan. Foi corrigido instalando um driver mais recente do site realtek