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

Version TL; DR: il s’est avéré qu’il s’agissait d’un grave problème de réseau Broadcom dans Windows Server 2008 R2. Le remplacement par du matériel Intel l'a corrigé. Nous n'utilisons plus le matériel Broadcom. Déjà.

Nous utilisons HAProxy avec les pulsations du projet Linux-HA. Nous utilisons deux instances Linux pour fournir un basculement. Chaque serveur a avec sa propre adresse IP publique et une seule adresse IP partagée entre les deux à l'aide d'une interface virtuelle (eth1: 1) à l'adresse IP: 69.59.196.211.

L’interface virtuelle (eth1: 1) IP 69.59.196.211 est configurée en tant que passerelle pour les serveurs Windows situés derrière eux et nous utilisons ip_forwarding pour acheminer le trafic.

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

Pinging 69.59.196.211 avec 32 octets de données:
Réponse de 69.59.196.220: hôte de destination inaccessible.

L'exécution arp -asur ce serveur défaillant indique qu'il n'y a aucune entrée pour l'adresse de passerelle (69.59.196.211):

Interface: 69.59.196.220 --- 0xa
Adresse Internet Type d'adresse physique
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 dynamique
69.59.196.217 00-21-5e-4d-2c-e8 dynamique
69.59.196.219 00-21-5e-4d-38-e5 dynamic
69.59.196.221 00-15-5d-00-b2-0d dynamique
69.59.196.222 00-15-5d-0a-3e-09 dynamique
69.59.196.223 ff-ff-ff-ff-ff-ff statique
224.0.0.22 01-00-5e-00-00-16 statique
224.0.0.252 01-00-5e-00-00-fc statique
225.0.0.1 01-00-5e-00-00-01 statique

Sur nos instances de passerelle linux arp -amontre:

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

Pourquoi arp définit-il parfois l'entrée pour ce serveur défaillant sur <incomplet>? Devrions-nous définir nos entrées arp statiquement? J'ai toujours laissé Arp seul, car cela fonctionne 99% du temps, mais dans ce cas, il semble échouer. Existe-t-il d'autres étapes de dépannage que nous pouvons entreprendre pour vous aider à résoudre ce problème?

Choses que nous avons essayées

J'ai ajouté une entrée arp statique à tester sur l'une des passerelles linux qui 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 ce problème temporairement sans autre changement sur le réseau, mais notre expérience montre que ce problème reviendra.

Échange de cartes réseau et de commutateurs

J'ai remarqué que le voyant de liaison sur le port du commutateur du serveur Windows défaillant fonctionnait à 100 Mo au lieu de 1 Go sur l'interface défaillante. J'ai déplacé le câble vers plusieurs autres ports ouverts et le lien indiquait 100 Mo pour chaque port que j'ai essayé. J'ai également échangé le câble avec le même résultat. J'ai essayé de changer les propriétés de la carte réseau dans Windows et le serveur s'est verrouillé et j'ai demandé une réinitialisation matérielle 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 des deux interfaces pour voir si le problème suit l'interface. Si l'interface publique tombe à nouveau en panne, nous saurons qu'il ne s'agit pas d'un problème avec la carte réseau.

(Nous avons également essayé un autre commutateur que nous avons sous la main, pas de changement)

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

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

Remplacement des câbles réseau

Comme dernier effort, nous nous sommes souvenus d’un autre changement intervenu: le remplacement de tous les cordons de brassage entre nos serveurs / commutateurs. Nous avions acheté deux ensembles, un vert de longueurs allant de 1 à 3 pieds pour les interfaces privées et un autre jeu de câbles rouges pour les interfaces publiques. Nous avons échangé tous les câbles de brassage d'interface publique avec une marque différente et avons utilisé nos serveurs sans problème pendant une semaine complète… 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 maintenant en train de sortir TProxy et de passer à un x-forwarded-forarrangement réseau plus traditionnel sans aucune réécriture d’adresse IP sophistiquée. Nous verrons si cela aide.

Changer de fournisseur de virtualisation

Si cela avait un lien avec Hyper-V (nous hébergeons des machines virtuelles Linux sur celui-ci), nous sommes passés à VMWare Server. Pas de changement.

Changer de modèle d'hôte

Nous avons atteint la fin de notre corde de dépannage et impliquons maintenant officiellement le support technique 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

Nous l'avons fait et nous avons également obtenu des correctifs de noyau non publiés qui ont probablement été intégrés à 2008 R2 SP1. Pas de solution.

Remplacement du matériel de la carte réseau

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

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

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

Si aucune entrée de cache ARP n'existe pour une adresse IP de destination demandée, le noyau générera des requêtes ARP mcast_solicit jusqu'à ce qu'il reçoive une réponse. Au cours de cette période de découverte, l'entrée du cache ARP sera répertoriée dans un état incomplet. Si la recherche échoue après le nombre spécifié de demandes ARP, l'entrée de cache ARP sera répertoriée dans un état d'échec. Si la recherche aboutit, le noyau entre la réponse dans le cache ARP et réinitialise les minuteries de confirmation et de mise à jour.

Il semble que votre boîtier de passerelle ne répond pas (ou répond trop lentement) aux demandes ARP provenant de votre boîtier de passerelle. Est-ce que cela <incomplete>finit par basculer <failed>? Quel matériel réseau avez-vous entre le serveur et la passerelle? Est-il possible que des demandes ARP de diffusion soient filtrées ou bloquées quelque part entre les deux hôtes?

Cela signifie que vous avez envoyé une requête ping à l'adresse, l'IP a un enregistrement PTR (d'où le nom) mais rien n'a été répondu de la machine en question. Lorsque nous voyons cela, cela est généralement dû à un masque de sous-réseau mal défini - ou à des adresses IP liées à une interface de bouclage qui ont été liées accidentellement à l'interface eth.

Qu'est-ce que 196.220? Quelle est sa relation avec 196.211? Je suppose que .220 est l’un des hôtes du proxy HA. Lorsque vous exécutez ifconfig -a & arp -a, que montre-t-il?

Comme le dit Max Clark, <incomplet> signifie simplement que 69.59.196.211 a émis une demande ARP pour 69.59.196.220 et n'a pas encore reçu de réponse. (Sous Windows, vous verrez cela comme un mappage ARP en "00-00-00-00-00-00" ... Il m'est étrange, BTW, de ne pas voir un tel mappage ARP sur 69.59.196.220 à 69.59.196.211.)

J'ai tendance à ne pas aimer utiliser les entrées ARP statiques car, selon mon expérience, ARP a généralement fait son travail tout le temps.

Si c’était moi, je détecterais l’interface Ethernet appropriée sur la machine Windows "en échec" (69.59.196.220) pour l’observer avec ARP pour 69.59.196.211 et pour voir comment / s’il répond aux demandes ARP de 69.59. 196.211. J'envisagerais également de renifler sur la machine passerelle uniquement pour ARP ( tcpdump -i interface-name arp) pour voir à quoi ressemble le trafic ARP du côté de la machine Linux.

Sur le blog , je sais que vous avez un réseau back-end et un réseau front-end. Au cours de ces pannes, le serveur Windows "défaillant" (69.59.196.220) a-t-il des problèmes de communication avec d'autres machines du réseau frontal, ou a-t-il simplement du mal à communiquer avec sa passerelle? Je suis curieux de savoir si vous arrivez à la machine défaillante via le réseau frontal ou principal lorsque vous vous en prenez à la loi.

Que faites-vous pour "résoudre" le problème quand il se produit?

Modifier:

Je vois dans votre mise à jour que vous redémarrez la machine Windows "en échec" pour résoudre le problème. Avant de faire cela la prochaine fois, pouvez-vous vérifier que la machine Windows est capable de "parler" sur son interface frontale? En outre, récupérez une copie de la table de routage à partir de la machine Windows ( route print) en cas d’échec. (J'essaie de vérifier si la carte réseau / le pilote se comporte comme un dingue sur la machine Windows, en gros.)

Ce document présente les différents états (tableau 2.1). Incomplet signifierait qu'il a envoyé une première demande ARP (probablement après une vérification périmée, un délai, une analyse) mais qu'il n'a pas encore reçu de réponse.

La raison pour laquelle l'ARP statique sur le nœud haproxy n'aide pas, c'est que votre serveur Web ne sait toujours pas comment revenir à la passerelle.

L'ARP statique sur le serveur Web empêche les serveurs Web de changer de passerelle en cas de défaillance d'un des nœuds haproxy. Je suppose que l'interface virtuelle partage la même adresse MAC que le nœud eth1 du nœud haproxy. code à l’une des deux passerelles de chaque serveur Web.

Un logiciel de sécurité est-il installé sur le serveur Web défaillant? J'ai passé une longue nuit avec un serveur Windows 2008 sur lequel Symantec Endpoint Security était installé. Ce dernier installait du code de filtrage dans la pile réseau, ce qui l'empêchait de voir les paquets ARP de la passerelle. Le correctif (fourni par Microsoft) consistait à supprimer l'entrée de registre qui chargeait la DLL.

L'autre fois que ce problème s'est produit, supprimer la carte réseau entière du gestionnaire de périphériques et la réinstallation semblaient aider.

Puisque vous avez défini de manière statique votre entrée arp, vos serveurs savent où trouver la passerelle. Cependant, si votre commutateur ne sait pas où se trouve la passerelle, il ne transmettra pas vos paquets.

On dirait que vous avez un commutateur mauvais (ou confus) entre votre serveur HAproxy et vos serveurs Web. Redémarrez-le.

Soit cela, soit vos serveurs HAproxy sont en désaccord sur celui qui contrôle, et les deux qui répondent aux recherches arp pour .211.

Dans le même ordre d'idées, si votre commutateur est surchargé, vos HAproxies risquent de ne pas pouvoir communiquer entre eux assez rapidement et basculent.

La prochaine fois que ce problème se produit, je suggérerais d'exécuter des captures de paquets sur les deux hôtes en question, afin de déterminer le trafic ARP observé par chacun d'eux.

Votre machine HAproxy aura probablement une certaine saveur de tcpdump installée. Pour la machine Windows, vous aurez besoin d'une application WinPCAP , telle que Wireshark ou de Microsoft Network Monitor .

En fait, étant donné que le problème semble concerner ARP en particulier, vous pourriez éventuellement simplement enregistrer en continu tout le trafic ARP sur la machine HAproxy et la machine Windows en question, avec un fichier de capture défilant de (pour des raisons d’argument) 10MB. Cela devrait être suffisamment important pour qu'au moment où vous avez détecté une panne, le fichier de capture contienne toujours le trafic ARP d'avant la panne. (Cela vaut la peine d'essayer en exécutant la capture pendant environ une heure pour voir combien de données elle génère).

Exemple de syntaxe de capture pour Linux tcpdump (remarque, je ne dispose pas d'une machine Linux pour le tester; veuillez tester le comportement de -C et -W avant de l'utiliser en production!):

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

Cela devrait, espérons-le, vous donner une indication de ce qui échoue précisément. Quand une entrée ARP arrive à expiration (et selon cet article , les versions les plus récentes de Windows semblent disparaître de manière très agressive des entrées "inactives"), je suppose que les événements suivants se produiraient:

1. L'hôte source enverra une demande ARP à l'hôte cible. Les demandes ARP sont généralement diffusées, mais dans le cas où un hôte actualise une entrée existante, le message ARP peut être envoyé en monodiffusion.
2. L'hôte cible répondra avec une réponse ARP. 99% du temps, ce sera unicast, mais le RFC autorise les réponses de diffusion. (Voir également la RFC concernant la détection de collision d'adresses IPv4 pour plus de détails).

Aussi simple que cela paraisse, il y a beaucoup d'autres choses qui peuvent interférer avec ce processus:

• La demande d'origine peut ne pas arriver à la cible.
• La demande peut arriver à la cible, mais la réponse peut ne pas atteindre la source.
• Une sorte de mécanisme de haute disponibilité peut interférer avec le comportement «normal» de l'ARP:
  • Comment fonctionne le basculement entre les nœuds HAProxy? Utilise-t-il une adresse MAC partagée ou utilise-t-il gratuitement ARP pour faire échouer une adresse IP entre des nœuds?
  • Un grand nombre des adresses MAC dans les tables ARP ci-dessus commencent par 00-15-5D, qui est apparemment enregistré auprès de Microsoft. Utilisez-vous une forme quelconque de clustering ou autre haute disponibilité sur la machine Windows en question? Ces adresses MAC 00-15-5D sont-elles les mêmes que celles que vous voyez associées aux cartes réseau matérielles lorsque vous effectuez une opération 'ipconfig / all' sur le serveur Windows?

Points à vérifier si / quand cela se reproduira:

• Regardez les captures de paquets du trafic ARP; Est-ce qu'une partie de la conversation n'a évidemment pas eu lieu?
• Vérifiez les tables de pontage / FAO du commutateur. toutes les adresses MAC en question correspondent-elles aux ports auxquels vous vous attendez?
• Les autres hôtes du sous-réseau ont-ils des entrées ARP valides pour les adresses IP des hôtes Windows et HAProxy?
• Les entrées ARP pour la même adresse IP cible sur plusieurs machines sources différentes sont-elles résolues en une même adresse MAC? C'est-à-dire, connectez-vous à deux autres hôtes du sous-réseau et vérifiez que 196.211 a la même adresse MAC que les deux.

Nous avons eu un problème similaire avec l’un de nos serveurs de terminal R2 2008: tout le trafic de la carte réseau s’arrêtait, mais restait connecté, et les voyants de la carte réseau indiquaient des communications. Il s’agissait d’un problème récurrent qui persistait 2 à 3 fois par semaine, mais après environ 12 à 13 heures de disponibilité (le serveur est redémarré tous les soirs).

J'ai trouvé Seriousbit Netbalancer comme cause, après avoir essayé (par curiosité) de mettre fin au service NetbalancerService. Le trafic a ensuite commencé à se déplacer à travers l'interface. J'ai depuis désinstallé Netbalancer.

J'ai eu un même problème avec Asus Mainboard lan. Il a été corrigé en installant un dernier pilote du site Web de realtek .