Serveur d'impression

Mise en réseau: la carte réseau Windows Server 2008 R2 cesse de fonctionner et nécessite un redémarrage forcé – Serveur d’impression

Le 3 mai 2019 - 6 minutes de lecture

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.

Fonctionnement arp -a sur ce serveur en panne montre que il n'y a pas d'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 -a spectacles:



peak-colo-196-220.peak.org (69.59.196.220) à  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 de ce serveur défaillant comme ? 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 d'arp statique à tester sur l'une des passerelles linux qui n'a toujours pas aidé.

root @ haproxy2: ~ # arp -a
pic-colo-196-215.peak.org (69.59.196.215) à 00: 21: 5e: 4d: 61: 1a [ether] sur eth1
pic-colo-196-221.peak.org (69.59.196.221) à 00: 15: 5d: 00: b2: 0d [ether] sur eth1
stackoverflow.com (69.59.196.212) à 00: 21: 5e: 4d: 45: c9 [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-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
pic-colo-196-220.peak.org (69.59.196.220) à 00: 21: 5e: 4d: 30: 8d [ether] PERM sur 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) octets de données.
--- 69.59.196.220 statistiques de ping ---
7 paquets transmis, 0 reçus, 100% de pertes de paquets, temps 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 sortons maintenant TProxy et passons à une solution plus traditionnelle x-transféré-pour arrangement de réseau sans 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 hôte:

Nous l'avons fait et nous avons également obtenu des correctifs non publiés du noyau 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/

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.