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

Question

TL;DR version: Turns out this was a deep Broadcom networking bug in Windows Server 2008 R2. Replacing with Intel hardware fixed it. We don't use Broadcom hardware any more. Ever.

Estamos usando HAProxy junto com heartbeat do projeto Linux-HA. Estamos usando duas instâncias do Linux para fornecer um failover. Cada servidor tem seu próprio IP público e um único IP que é compartilhado entre os dois usando uma interface virtual (eth1: 1) no endereço 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 de rede ocasional em um dos nossos servidores Windows atrás de nossos gateways Linux. HAProxy detectará que o servidor está off-line, o que podemos verificar remotando para o servidor com falha e tentando executar o ping no gateway:

Pinging 69.59.196.211 with 32 bytes of data:
Reply from 69.59.196.220: Destination host unreachable.

A execução de arp -a neste 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
Internet Address      Physical Address      Type
69.59.196.161         00-26-88-63-c7-80     dynamic
69.59.196.210         00-15-5d-0a-3e-0e     dynamic
69.59.196.212         00-21-5e-4d-45-c9     dynamic
69.59.196.213         00-15-5d-00-b2-0d     dynamic
69.59.196.215         00-21-5e-4d-61-1a     dynamic
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         ff-ff-ff-ff-ff-ff     static
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     static

Em nossas instâncias de gateway do Linux, arp -a mostra:

peak-colo-196-220.peak.org (69.59.196.220) at <incomplete> on eth1
stackoverflow.com (69.59.196.212) at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-215.peak.org (69.59.196.215) at 00:21:5e:4d:61:1a [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-222.peak.org (69.59.196.222) at 00:15:5d:0a:3e:09 [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

Por que arp ocasionalmente definiria a entrada para esse servidor com falha como < incompleto >? Devemos definir nossas entradas arp estaticamente? Eu sempre deixei o arp sozinho, já que ele funciona 99% do tempo, mas neste caso, parece estar falhando. Há outras etapas de solução de problemas que podemos ajudar a resolver esse problema?

COISAS QUE TENHAMOS

Eu adicionei uma entrada de arp estática para testar em um dos gateways do 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 da web do windows soluciona esse problema temporariamente sem outras alterações na rede, mas nossa experiência mostra que esse problema retornará.

Troca de cartões de rede e comutadores

Notei que a luz de link na porta do switch do servidor com falha do Windows estava em execução 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 eu tentei. Eu 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 reinicialização a frio após clicar em aplicar. Esse servidor Windows possui duas interfaces de rede físicas, por isso troquei os cabos e as configurações de rede nas duas interfaces para ver se o problema segue a interface. Se a interface pública cair novamente, saberemos que não é um problema com a placa de rede.

(Também tentamos outro interruptor que temos à mão, sem alteração)

Alterando as versões do driver de hardware de rede

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

Substituição de cabos de rede

Como último esforço, lembramos que outra mudança que ocorreu foi a substituição de todos os patch cords entre nossos servidores / switch. Nós tínhamos comprado dois conjuntos, um verde de comprimentos de 1ft - 3ft para as interfaces privadas e outro conjunto de cabos vermelhos para as interfaces públicas. Nós trocamos todos os cabos de patch de interface pública por uma marca diferente e rodamos nossos servidores sem problemas por uma semana inteira ... aaaaae então o problema ocorreu novamente.

Desative o descarregamento da soma de verificação, remova o TProxy

Também tentamos desabilitar o descarregamento da soma de verificação TCP / IP no driver, sem alteração. Estamos agora retirando o TProxy e mudando para um arranjo de rede x-forwarded-for mais tradicional, sem qualquer reescrita de endereços IP sofisticados. Vamos ver se isso ajuda.

Alternar provedores de virtualização

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

Alternar modelo de host

Chegamos ao final da nossa corda de solução de problemas e agora envolvemos formalmente o suporte da Microsoft. Eles recomendaram a alteração do modelo de host:

• link
• link

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

Substituindo o hardware da placa de rede

Por fim, substituir o hardware de rede da Broadcom pelo hardware de rede da 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!

link

    

Answer 1

De link :

If no ARP cache entry exists for a requested destination IP, the kernel will generate mcast_solicit ARP requests until receiving an answer. During this discovery period, the ARP cache entry will be listed in an incomplete state. If the lookup does not succeed after the specified number of ARP requests, the ARP cache entry will be listed in a failed state. If the lookup does succeed, the kernel enters the response into the ARP cache and resets the confirmation and update timers.

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

    

Answer 2

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

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

    

Answer 3

Como Max Clark diz, o < incompleto > significa apenas que 69.59.196.211 emitiu uma solicitação ARP para 69.59.196.220 e ainda não recebeu uma resposta. (No Windows-terra 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 69.59.196.220 para 69.59.196.211.)

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

Se fosse eu, eu cheiraria a interface Ethernet apropriada na máquina Windows "com falha" (69.59.196.220) para observar o ARP para 69.59.196.211 e para observar como / se ele está respondendo a solicitações ARP de 69.59.196.211. Eu também consideraria farejar a máquina de gateway somente para ARP ( tcpdump -i interface-name arp ) para ver como é o tráfego ARP do lado da máquina Linux.

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

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

Editar:

Vejo na sua atualização que você está reinicializando 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 consegue "falar" em sua interface front-end? Além disso, pegue uma cópia da tabela de roteamento da máquina Windows ( route print ) durante uma falha também. (Eu estou tentando verificar se o NIC / driver está indo mal na máquina Windows, basicamente.)

    

Answer 4

Este documento mostra os diferentes estados (tabela 2.1). Incompleta significaria que enviou uma primeira solicitação ARP (presumivelmente após uma sonda obsoleta, atrasada), mas ainda não recebeu uma resposta.

    

Answer 5

O motivo pelo 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 da Web alternarem os gateways quando um dos nós haproxy falhou - Acredito que a interface virtual compartilha o mesmo endereço MAC que a eth1 do nó haproxy. tem que codificar 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 do Windows 2008 que tinha o Symantec Endpoint Security - ele instala algum código de filtragem na pilha de rede que impedia que ele visse os pacotes ARP do gateway. A correção para isso (conforme fornecido pela Microsoft) foi remover a entrada do registro que carregou a DLL.

Na outra vez em que esse problema ocorreu, a remoção de todo o adaptador de rede do gerenciador de dispositivos e a reinstalação pareciam ajudar.

    

Answer 6

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

Parece que você tem uma mudança ruim (ou confusa) entre o seu servidor HAproxy e seu servidor web. Reinicie.

Ou isso, ou seus servidores HAproxy discordam sobre qual deles está no controle e ambos respondendo a pesquisas de arp para .211.

Na mesma linha, se o seu comutador estiver sobrecarregado, suas HAproxies poderão não conseguir se comunicar com uma velocidade suficiente e falharão.

    

Answer 7

Na próxima vez que esse problema ocorrer, sugiro executar algumas capturas de pacote 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 Wireshark ou Microsoft Network Monitor .

Na verdade, pensando nisso, como o problema parece ser especificamente com o ARP, você poderia apenas gravar continuamente todo o tráfego ARP na máquina HAproxy e na máquina Windows em questão, com um arquivo de captura rolante de (para o argumento ) 10MB. Isso deve ser grande o suficiente para que, no momento em que você detectar uma falha, o arquivo de captura ainda contenha o tráfego ARP antes da falha. (Vale a pena experimentar rodando a captura por uma hora ou mais, para ver quantos dados ela gera).

Exemplo de sintaxe de captura para o Linux tcpdump (note que não tenho uma caixa do Linux à mão para testar isso; por favor, 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

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

1. O host de origem enviará uma solicitação ARP ao host de destino. As solicitações ARP geralmente são transmitidas, mas no caso de um host estar atualizando uma entrada existente, o ARP pode ser enviado unicast.
2. O host de destino responderá com uma resposta ARP. 99% das vezes será unicast, mas a RFC permite a transmissão de respostas. (Veja também o RFC sobre Detecção de colisão de endereços IPv4 para mais detalhes).

Por mais simples que pareça, há muitas 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 à origem.
• 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 o ARP gratuito para reprovar um endereço IP entre nós?
  • Muitos dos 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 outro 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 acontece 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 comutador; todos os endereços MAC em questão mapeiam para as portas que você espera?
• Os outros hosts da 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 o logon em alguns outros hosts na sub-rede e verifique se o 196.211 resolve o mesmo endereço MAC em ambos.

Answer 8

Tivemos um problema semelhante com um dos nossos servidores de terminal 2008 R2, onde todo o tráfego na NIC parava, mas permanecia conectado, e os LEDs da NIC mostravam comunicação. Este foi um problema contínuo que continuou surgindo 2-3 vezes por semana, mas somente após cerca de 12-13 horas de atividade (o servidor é reinicializado todas as noites).

Eu encontrei o Seriousbit Netbalancer foi a causa, depois que eu tentei (por curiosidade) terminar o serviço NetbalancerService. O tráfego começou a se mover pela interface. Eu já instalei o Netbalancer.

    

Answer 9

Eu tive o mesmo problema com o lan da Asus Mainboard. Foi corrigido com a instalação de um driver mais recente de realtek