La carte réseau Windows Server 2008 R2 ne fonctionne plus et nécessite un redémarrage matériel
TL; version DR: Il s'avère que c'était un bogue réseau Broadcom profond dans Windows Server 2008 R2. Le remplacement par du matériel Intel l'a corrigé. Nous n'utilisons plus de matériel Broadcom. Jamais.
Nous utilisons HAProxy avec heartbeat du projet Linux-HA. Nous utilisons deux instances Linux pour fournir un basculement. Chaque serveur possède sa propre IP publique et une seule IP qui est partagée entre les deux à l'aide d'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 passerelle pour les serveurs Windows 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 se 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.
Fonctionnement arp -a sur ce serveur défaillant 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 Type d'adresse physique de l'adresse Internet 69.59.196.161 00-26-88-63-c7-80 dynamique 69.59 .196.210 00-15-5d-0a-3e-0e dynamique 69.59.196.212 00-21-5e-4d-45-c9 dynamique 69.59.196.213 00-15-5d-00- b2-0d dynamique 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 dynamique 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 -a montre:
peak-colo-196-220.peak.org (69.59.196.220) à <incomplete> sur eth1 stackoverflow.com (69.59.196.212) à 00: 21: 5e: 4d: 45 : c9 [éther] sur eth1 peak-colo-196-215.peak.org (69.59.196.215) à 00: 21: 5e: 4d: 61: 1a [éther] sur eth1 peak-colo-196-219.peak.org (69.59.196.219) à 00: 21: 5e: 4d: 38: e5 [éther] sur eth1 peak-colo-196-222.peak.org ( 69.59.196.222) à 00: 15: 5d: 0a: 3e: 09 [éther] sur eth1 Peak-colo-196-209.peak.org (69.59.196.209) à 00: 26: 88: 63 : c7: 80 [éther] sur eth1 peak-colo-196-217.peak.org (69.59.196.217) à 00: 21: 5e: 4d: 2c: e8 [éther] sur eth1
Pourquoi arp définirait-il occasionnellement l'entrée pour ce serveur défaillant comme <incomplete>? Devrions-nous définir nos entrées arp statiquement? J'ai toujours laissé Arp seul car il fonctionne 99% du temps, mais dans ce cas, il semble échouer. Existe-t-il des étapes de dépannage supplémentaires que nous pouvons prendre pour résoudre ce problème?
CHOSES WE ONT ESSAYÉ
J'ai ajouté une entrée d'arp statique pour 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 temporairement ce problème sans aucune autre modification du 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 pour le 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 verrouillé et j'ai eu besoin d'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 sur les deux interfaces pour voir si le problème suit l'interface. Si l'interface publique tombe à nouveau en panne, nous saurons que ce n'est pas un problème avec la 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 eu le même problème avec le dernier pilote Broadcom, ainsi qu'avec le pilote intégré livré avec Windows Server 2008 R2.
Remplacement des câbles réseau
Comme 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/commutateurs. Nous avions acheté deux jeux, un vert de longueurs 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 raccordement d'interface publique avec une marque différente et avons fait fonctionner nos serveurs sans problème pendant une semaine entière ... aaaaaet 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 retirons maintenant TProxy et passons à un _ plus traditionnel x-forwarded-for arrangement réseau sans aucune réécriture d'adresse IP sophistiquée. Nous verrons si cela aide.
Changer de fournisseur de virtualisation
Au cas où cela était lié à Hyper-V d'une manière ou d'une autre (nous hébergeons des machines virtuelles Linux dessus), 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 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 dans 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 du matériel réseau Intel a résolu ce problème pour nous. J'ai donc tendance à penser que les pilotes Broadcom Windows Server 2008 R2 sont en faute!
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'à réception d'une réponse. Pendant cette période de découverte, l'entrée de 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 réussit, le noyau entre la réponse dans le cache ARP et réinitialise les temporisations de confirmation et de mise à jour.
Il semble que votre boîtier de passerelle ne répond pas (ou ne répond pas trop lentement) aux demandes ARP de votre boîtier de passerelle. Est-ce que <incomplete> éventuellement passer à <failed>? Quel matériel réseau avez-vous entre le serveur et la passerelle? Est-il possible que les requêtes 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 répondu de la machine en question. Lorsque nous voyons cela, c'est le plus souvent en raison d'un masque de sous-réseau mal défini - ou dans le cas d'IP liées à une interface de bouclage qui ont été accidentellement liées à l'interface eth à la place.
Qu'est-ce que 196.220? Quelle est sa relation avec 196.211? Je suppose que .220 est l'un des hôtes proxy HA. Lorsque vous exécutez ifconfig -a et arp -a dessus, qu'est-ce que cela montre?
Comme le dit Max Clark, le <incomplete> 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. (Dans Windows-land, vous verrez cela comme un mappage ARP vers "00-00-00-00-00-00" ... Il me semble étrange, BTW, que vous ne voyez pas un tel mappage ARP sur 69.59.196.220 pour 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 reniflerais l'interface Ethernet appropriée sur la machine Windows "défaillante" (69.59.196.220) pour l'observer en ARP pour 69.59.196.211, et pour observer comment/si elle répond aux requêtes ARP de 69.59. 196.211. J'envisagerais également de renifler la machine passerelle pour ARP uniquement (tcpdump -i interface-name arp) pour voir à quoi ressemble le trafic ARP du côté de la machine Linux.
Je sais, d'après le blog , que vous avez un réseau principal et un réseau frontal. Lors de ces pannes, le serveur Windows "défaillant" (69.59.196.220) a-t-il des problèmes de communication avec les autres machines du réseau frontal, ou a-t-il simplement des problèmes de communication avec sa passerelle? Je suis curieux de savoir si vous arrivez à la machine défaillante via le réseau frontal ou principal lorsque vous l'attrapez dans la loi.
Que faites-vous pour "résoudre" le problème lorsqu'il se produit?
Éditer:
Je constate à partir de votre mise à jour que vous redémarrez la machine Windows "défaillante" pour résoudre le problème. Avant de faire cela la prochaine fois, pouvez-vous vérifier que la machine Windows est en mesure de "parler" sur son interface frontale? Prenez également une copie de la table de routage de la machine Windows (route print) lors d'un échec également. (J'essaie de vérifier si le NIC/driver va bonkers sur la machine Windows, essentiellement.)
Ce document montre les différents états (tableau 2.1). Incomplet signifierait qu'il a envoyé une première demande ARP (vraisemblablement après un périmé, un retard, une sonde) mais 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 peut toujours pas comprendre comment revenir à la passerelle.
L'ARP statique sur le serveur Web interrompt la possibilité pour vos serveurs Web de changer de passerelle lorsque l'un des nœuds haproxy a échoué - je suppose que l'interface virtuelle partage la même adresse MAC que eth1 du nœud haproxy, vous devrez donc code à l'une des deux passerelles dans chaque serveur Web.
Avez-vous installé un type de logiciel de sécurité sur le serveur Web défaillant? J'ai passé une longue nuit avec un serveur Windows 2008 sur lequel Symantec Endpoint Security était installé - il installe du code de filtrage dans la pile réseau qui l'empêche 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, la suppression de la carte réseau entière du gestionnaire de périphériques et la réinstallation ont semblé aider.
Puisque vous avez défini statiquement votre entrée arp, vos serveurs savoir 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 mauvais (ou confus) commutateur entre votre HAproxy et vos serveurs Web. Redémarrez-le.
Soit cela, soit vos serveurs HAproxy ne s'entendent pas sur celui qui est en contrôle, et les deux répondent aux recherches d'arp pour .211.
Dans le même ordre d'idées, si votre commutateur est surchargé, vos serveurs proxy peuvent être incapables de communiquer les uns avec les autres assez rapidement et basculent.
La prochaine fois que ce problème se produira, je suggérerais d'exécuter des captures de paquets sur les deux hôtes en question, afin de déterminer le trafic ARP que chacun d'eux observe.
Votre machine HAproxy aura très probablement une certaine saveur de tcpdump installé. Pour la machine Windows, vous aurez besoin d'une application WinPCAP , comme Wireshark , ou Microsoft Network Monitor .
En fait, en y réfléchissant, comme le problème semble être lié à ARP spécifiquement, vous pourriez potentiellement simplement enregistrer en continu tout le trafic ARP sur la machine HAproxy et la machine Windows en question, avec un fichier de capture roulant de (pour le bien de l'argument) 10 Mo. Cela devrait être suffisamment grand 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'expérimenter en exécutant la capture pendant environ une heure, pour voir la quantité de données qu'elle génère).
Exemple de syntaxe de capture pour Linux tcpdump (remarque, je n'ai pas de boîte Linux à portée de main pour tester ceci; 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
J'espère que cela devrait vous donner une indication de ce qui échoue précisément. Lorsqu'une entrée ARP expire (et selon cet article , les nouvelles versions de Windows semblent vieillir les entrées "inactives" de manière très agressive), je m'attends à ce que ce qui suit se produise:
- L'hôte source enverra une demande ARP à l'hôte cible. Les requêtes ARP sont généralement diffusées, mais dans le cas où un hôte actualise une entrée existante, l'ARP peut être envoyé en monodiffusion.
- L'hôte cible répondra par une réponse ARP. 99% du temps, ce sera unicast, mais le RFC autorise les réponses diffusées. (Voir également le RFC concernant Détection de collision d'adresses IPv4 pour plus de détails).
Aussi simple que cela puisse paraître, il y a un tas 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 ARP gratuit pour faire échouer une adresse IP entre les nœuds?
- Un grand nombre des adresses MAC dans les tableaux ARP ci-dessus commencent par 00-15-5D, qui est apparemment enregistré auprès de Microsoft. Utilisez-vous une forme de clustering ou une autre HA 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 un "ipconfig/all" sur le serveur Windows?
Choses à vérifier si/quand cela se reproduit:
- Regardez les captures de paquets du trafic ARP; une partie de la conversation n'a-t-elle manifestement pas eu lieu?
- Vérifiez les tables de pontage/CAM 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 IP cible sur plusieurs machines sources différentes sont-elles résolues à la même adresse MAC? c'est-à-dire, connectez-vous à quelques autres hôtes sur le sous-réseau et vérifiez que 196.211 résout la même adresse MAC sur les deux.
J'ai eu le même problème avec le LAN de la carte mère Asus. Il a été corrigé en installant un dernier pilote depuis le site Web realtek
Nous avons eu un problème similaire avec l'un de nos serveurs de terminaux 2008 R2 où tout le trafic sur le NIC s'arrêterait mais resterait connecté, et les NIC LEDs afficheraient les communications) C'était un problème récurrent qui n'arrêtait pas d'apparaître 2-3 fois par semaine, mais seulement après environ 12-13 heures de disponibilité (le serveur est redémarré tous les soirs).
J'ai trouvé que Seriousbit Netbalancer était la cause, après avoir essayé (par curiosité) de mettre fin au service NetbalancerService. Le trafic a alors commencé à traverser l'interface. J'ai depuis désinstallé Netbalancer.