L'adaptateur réseau de Windows Server 2008 R2 cesse de fonctionner et nécessite un redémarrage brutal.

Version TL;DR : Il s'est avéré qu'il s'agissait d'un bogue profond du réseau Broadcom dans Windows Server 2008 R2. Le remplacement par du matériel Intel a permis de le résoudre. Nous n'utilisons plus de matériel Broadcom. Jamais.

Nous avons utilisé HAProxy ainsi que battement de cœur du projet Linux-HA. Nous utilisons deux instances linux pour fournir un basculement. Chaque serveur a sa propre IP publique et une seule IP qui est partagée entre les deux en utilisant une interface virtuelle (eth1:1) à l'IP : 69.59.196.211.

L'interface virtuelle (eth1:1) IP 69.59.196.211 est configurée comme la passerelle pour les serveurs Windows derrière eux et nous utilisons ip_forwarding pour router le trafic.

Nous rencontrons une panne de réseau occasionnelle sur l'un de nos serveurs Windows derrière nos passerelles linux. HAProxy détecte que le serveur est hors ligne, ce que nous pouvons vérifier en nous connectant à distance au serveur défaillant et en tentant d'envoyer un ping à la passerelle :

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

Running arp -a sur ce serveur en panne montre que il n'y a pas d'entrée pour l'adresse de la passerelle (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

Sur nos instances de passerelle linux arp -a montre :

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

Pourquoi arp définit-il occasionnellement l'entrée de ce serveur défaillant comme <incomplete> ? Devrions-nous définir nos entrées arp de manière statique ? J'ai toujours laissé arp tranquille car il fonctionne 99% du temps, mais dans ce cas précis, il semble échouer. Y a-t-il d'autres mesures de dépannage que nous pouvons prendre pour résoudre ce problème ?

LES CHOSES QUE NOUS AVONS ESSAYÉES

J'ai ajouté une entrée arp statique pour le test sur l'une des passerelles linux, mais cela n'a toujours pas aidé.

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

Le redémarrage du serveur web Windows résout temporairement ce problème sans autre modification du réseau, mais notre expérience montre que ce problème reviendra.

Remplacement des cartes réseau et des commutateurs

J'ai remarqué que le voyant de liaison sur le port du commutateur pour le serveur Windows en panne fonctionnait à 100Mb au lieu de 1Gb sur l'interface en panne. J'ai déplacé le câble vers plusieurs autres ports ouverts et le lien indiquait 100Mb pour chaque port que j'ai essayé. J'ai également échangé le câble avec le même résultat. J'ai essayé de modifier les propriétés de la carte réseau dans Windows, mais le serveur s'est bloqué et a dû être réinitialisé après avoir cliqué sur Appliquer. Ce serveur Windows a deux interfaces réseau physiques, j'ai donc échangé les câbles et les paramètres réseau sur les deux interfaces pour voir si le problème suit l'interface. Si l'interface publique se bloque à nouveau, nous saurons qu'il ne s'agit pas d'un problème de carte réseau.

(Nous avons également essayé un autre interrupteur que nous avons sous la main, aucun changement).

Modification des versions des pilotes de matériel réseau

Nous avons rencontré le même problème avec le dernier pilote Broadcom, ainsi qu'avec le pilote intégré fourni avec Windows Server 2008 R2.

Remplacement des câbles réseau

Dans un dernier effort, nous nous sommes souvenus d'un autre changement qui s'est produit : le remplacement de tous les cordons de raccordement entre nos serveurs et nos commutateurs. Nous avions acheté deux jeux, un vert de longueurs 1ft - 3ft pour les interfaces privées et un autre jeu de câbles rouges pour les interfaces publiques. Nous avons remplacé tous les câbles de l'interface publique par des câbles de marque différente et nos serveurs ont fonctionné sans problème pendant une semaine entière... et puis le problème est réapparu.

Désactiver le déchargement de la somme de contrôle, supprimer TProxy

Nous avons également essayé de désactiver le déchargement de la somme de contrôle TCP/IP dans le pilote, sans changement. Nous sommes en train de retirer TProxy et de passer à un système plus traditionnel, le x-forwarded-for sans réécriture fantaisiste de l'adresse IP. Nous verrons si cela aide.

Prestataires de services de virtualisation des commutateurs

Dans l'éventualité où cela serait lié à Hyper-V d'une manière ou d'une autre (nous hébergeons des VM Linux sur ce système), nous sommes passés à VMWare Server. Aucun changement.

Modèle de commutateur hôte

Nous sommes arrivés au bout de notre rouleau de dépannage et nous faisons maintenant officiellement appel à l'assistance de Microsoft. Ils ont recommandé de changer le modèle d'hôte :

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

C'est ce que nous avons fait, et nous avons également obtenu quelques correctifs non publiés du noyau qui ont probablement été intégrés dans 2008 R2 SP1. Aucun correctif.

Remplacement du matériel de la carte réseau

Finalement, le remplacement du matériel réseau Broadcom par du matériel réseau Intel a permis de résoudre ce problème. Je suis donc enclin à penser que les pilotes Broadcom de Windows Server 2008 R2 sont en cause !

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