Bonjour,
Le réseau d'un client tombe périodiquement (à priori toutes les semaines).
Ils ont un serveur AD Windows Server 2019 sur Hyper-V.
Ils arrêtent tous les postes et redémarre le serveur et ça repart.
Je n'ai pas plus d'informations pour le moment car je ne suis pas sur place au moment où le problème intervient.
 
Je commence à fortement suspecter le DNS.
 
Le rôle DNS n'avait pas de recherche inversée, c'est chose faite.
Est-ce possible que l'absence de recherche inversée provoque ce genre de problème ?
 
Merci d'avance pour vos réponses...

non aucun rapport

faut regarde les logs l'event viewer du serveur
le problème se produit a la meme heure au meme moment tout le temps ?
coté switch as tu des logs ?
problème de carte reseau ? gestion du teaming peut etre ?
quand le probleme se produit faut effectuer des tests de ping vers ta passerelle et ton DC.
spanning tree ? un équipement fait conflit d'ip peut etre
quelles sont les symptômes sur les postes ?

as tu 2 DC  ? et par hazard un windows 2019 Essentials ?

C'est la VM AD qui tombe ou l'hote Hyper-V ?

lease DHCP qui expirent et pas renouvelés ?

Désolé de ne pas avoir répondu à vos questions, je n'ai pas reçu les alertes email pour me prévenir pourtant j'avais coché l'option...
Bref, non il n'y a rien dans les logs. Oui c'est également fort possible que cela vienne de la carte réseau et il y a un NIC Team dessus. C'est celle intégrée à la CM.
Je viens de mettre à jour les drivers, j'ai désactivé VMQ car j'ai vu que ça pouvait aussi faire ce genre de pb sur des puces non Broadcom.
Pas de conflit IP, j'ai tout vérifié.
Sinon j'ai pas pu faire de tests de ping, je n'ai pas de log sur les routeurs qui ne sont pas manageables.
On va voir si ça tient et je me ferais des tests sur place la prochaine fois...

 
Sauf que, son sentiment est peut être le bon.
 
J'ai vu les dernières années régulièrement des problèmes avec IPv6, dans le cas ou une étendue DHCP sans paramètres de DNS adaptés sont fournis par un équipement tiers que le serveur.
 
Dans ces conditions (un set IPv4 valide et un set IPv6 foireux au niveau des clients), malgré le forcing dans le registre d'utiliser IPv4 en priorité, la communication avec le DC ne fonctionnait *PAS*.
 
C'était presque devenu un récurrent à un moment.

 
Le teaming de NIC c'est toujours un peu chercher les emmerdes par contre. Faudrait désactiver au moins temporairement pour avancer dans le diag. Si possible.

Encore une fois aucun rapport avec la recherche inversée dns...

+1000

 
Notes qu'il n'a pas confirmé que ça a réglé le problème...

En j'ai fait des analyses BPA et il y avait des problèmes sur le DNS et DHCP.
Sur DNS en plus de la zone inversée il manquait aussi la zone principale _msdcs, sur DHCP il manquait les informations d'identification pour les mises à jour dynamique.
J'ai mis à jour les drivers LAN avec ceux du fabriquant de la CM.
Le réseau n'est plus tombé depuis le 08/11, je croise les doigts.
 

Le serveur est injoignable à nouveau :-(
Cette fois j'ai enlevé le NIC Team comme vous m'avez conseillé.
J'ai mis la NIC 1 dédié pour l'hôte Hyper-V
J'ai monté un commutateur virtuel External sur la NIC 2 en décochant le partage avec l'OS et je me sers de celle-ci sur les VM.
A priori c'est la recommandation MS si j'ai bien compris.
 
Je veux que l'hôte soit accessible sur le réseau et je me demandais s'il fallait mettre en IP statistique ou dynamique avec le DHCP. Comme le DHCP est lui-même sur une VM ça me semblait plus prudent de mettre en IP statique en renseignant manuellement.
 
On va voir comme ça...

tu peux regarder si y a pas des sauvegardes encours ou snapshots qui tourne
ou taches planifiées

quand le reseau tombe l'ad reponds au ping ?
ton serveur hote reponds au ping ?
rien dans console open manage ou idrac(dell) ou console hp ?

J'ai des backups mais c'est à 5h du matin avec Synology Active Backup (sur toutes les VM).
 
La coupure arrive systématiquement vers 13h, c'est à ce moment qu'il y a Synology Active Backup pour les postes cette fois. Mais j'ai limité à 2 PC en même temps et j'ai plafonné la bande passante à 70mo/s pour ne pas surchargé le réseau. Et ça ne passe pas du tout pas le serveur Hyper-V, directement du NAS vers les PC.
 
Cette fois j'ai vu qu'il y a avait un conflit de MAC address sur l'hôte (lié au NIC Team) mais comme la NIC Team a disparu j'attends le prochain crash pour vous mettre bien les logs.
J'ai un seul DC pas de Windows 2019 Essentials (c'est le standard).
 
Quand ça crache j'arrive quand même à me connecter sur l'hôte en étant dessus mais plus à distance. Il ne répond plus au ping depuis les machines (ni l'hôte ni les VM).
Par contre j'arrive à voir les VM localement sur le serveur et rien n'est surchargé.
 
Le problème c'est que quand ça arrive c'est la panique et il faut vite remettre en place et j'ai pas le temps de faire trop de tests... Je reboot le serveur et les postes et c'est ok.
 
J'ai testé nsloockup sur un poste vers le serveur de fichiers par exemple (qui est une VM) et c'était bien la bonne IP. Si je ping le nom d'hôte ou l'IP ça répond pas. Idem vers l'hôte depuis le poste.
 
A mon avis c'est soit la NIC qui part en live sur le serveur (peut-être à cause du NicTeam), soit un switch qui déconne.
 
On va voir sans le Nic Team pour voir.

regarde si ton service dns n'est pas arrete sur ton serveur quand cela arrrive
redemarre ce service et dit nous

tu peux aussi mettre a jour les pilotes de tes cartes reseaux et véirifier les logs du switch
probleme de MTU ?

J'ai déjà mis à jour les pilotes et les switchs sont non manageables malheureusement...

Mais les autres vm sont accessibles ou pas ?
Parce que je vois pas bien le rapport avec l'ad la en fait. C'est ton hote qui a l'air d'en chier non ?
On savait même pas que ça tournait sur une VM sur hyper v avant

Si tu regardes mon thread du début je dis "Ils ont un serveur AD Windows Server 2019 sur Hyper-V".
 
Donc pour résumer il y a un hôte Hyper-V avec dessus, un AD, un serveur de fichier, deux serveurs Web et un serveur applicatif.
 
Quand ça répond plus c'est comme si l'hôte et les VM n'étaient plus sur le réseau (plus de ping). Par contre j'arrive bien à me donner sur l'hôte Hyper-V en me mettant dessus directement sans passer par le réseau, l'hôte va bien et les VM aussi, le processeur est à 0% la RAM va bien, bref pas de soucis. C'est juste qu'ils sont plus sur le réseau.

Donc on est d'accord pour dire aucun rapport avec l'ad non ?

Ben dessus il y a a le serveur DNS et c'est pas exclut qu'il y ait un lien (mais je ne suis pas du tout sûr évidemment).

quel serveur est redémarré ? l'ad ou l'hyper v ?
 
je pense que dans le doute le client reboot l'hyper V ( plus simple a faire)

Le client reboot l'hôte entier.

ok
quand le probleme se produit
demander au client de pinger les vm et hote via son ip et son nom  
et pinger 8.8.8.8
et te remonter le resultat

Replantage aujourd'hui.
J'ai testé le ping depuis un poste vers les vm, l'hôte (par nom dns et IP) et 8.8.8.8 aucune réponse.
Je me suis connecté sur l'hôte et les VM et celle où il y a AD/DNS, pas de réponse au ping 8.8.8.8
Cette fois il a fallu éteindre le réseau en entier, même les switchs pour que ça reparte.
 
Par contre c'est toujours vers 13h30 au moment où il y a beaucoup de trafic sur les switches à cause des sauvegardes.
ça a forcément un rapport, un switch défaillant peut-être...
J'ai essayé de désactiver les sauvegardes entre midi et deux et là ça peut tenir une semaine mais ça finit par planter.
Par contre si j'active tout, ça plante tous les jours.
Les sauvegardes sont faites avec Synology Active Backup.
C'est uniquement les sauvegardes des PC entre midi et deux, pas des VM qui sont faites la nuit.
 
Au niveau des logs sur l'hôte, il y a la première :
La résolution du nom wpad a expiré lorsqu’aucun des serveurs DNS configurés n’a répondu.
Et après il y a pleins d'erreurs lié au redémarrage donc rien à voir avec le plantage.
 
Au niveau de l'AD/DNS erreur :
L’enregistrement ou la suppression de l’enregistrement dynamique d’un ou plusieurs enregistrements DNS a échoué avec l’erreur suivante :  
Aucun serveur DNS n’est configuré pour le système local.
 
Après au niveau du réseau physique, c'est assez compliqué.
Il y a 4 switchs non manageables sur 2 étages : 2 pour le LAN et 2 pour les téléphones IP (12 PC / 12 téléphones IP).
 
Pour le LAN : Swith 1 (étage 1) > Swith 2 (étage 2) > Port 1 de la Livebox (en 1Go)
Pour la téléphonie : Swith 3 (étage 1) > Swith 4 (étage 2) > Port 2 de la Livebox (en 100Mo)
C'est Orange qui a voulu faire comme ça.
 
Tout communique ensemble car les téléphones doivent avoir accès au DHCP.
 
Au moins de février ils vont repasser sur 1 seul étage et on va prendre un seul gros switch manageable.

Si même depuis un poste tu ping pas 8.8.8.8 (donc aucun traffic qui passe par le serveur) c'est que le serveur est hors cause et ton pb purement réseau.
Mais si ton réseau n'est pas monitoré/monitorable mis à part débrancher switch par switch tu peux pas faire gd chose. Peut être la livebox aussi (mais dans ce cas la communication entre les PC et le serveur sauf s'ils repassent par la livebox devrait pas être affecté).
Le pb là c'est que tu t'amuses à tout redémarrer à chaque fois donc impossible d'isoler un élément en particulier

sur  ton reseau ta livebox est ta passerelle ? ou tu as un firewall ?
pour moi ton souci comme le dit je@nb est reseau.
 
ta téléphonie se trouve sur le meme plan d'adressage IP que tes postes/serveurs ? pas de vlan ?

Oui c'est la Livebox qui est la passerelle, pas de FW.
Et oui tout est en 192.168.1.x, même les téléphones
Quand ils vont être sur un seul étage avec le nouveau switch je fais faire des VLAN.

Sinon d'ici là je pourrais essayer de faire changer la Livebox, prendre un switch neuf identique aux autres et changer un à un tant que le pb persiste ?

faut regarder le range DHCP pour la partie poste et téléphonie et vérifier qu'il ne distribue pas la même plages (par securité)
change ta livebox et test pendant 1 semaine sans rien toucher
si le souci persiste , test avec un autre switch

quand le souci se produit
 
tu peux demande au client de faire un ping vers la livebox
il peut esssayer de se connecter en https  
de faire un tracert vers la livebox
 

des news ?

 
Salut,
Je viens juste de changer la livebox, c'était une pro 4, je suis passé sur la v6 (changement ce matin).
J'ai viré un switch sur les quatre et je compte remplacer les autres si ça tombe encore.
 
En tout cas merci d'avance pris le temps !

pas eu de nouveau plantage ?

Non pas de plantage pour le moment, je croise les doigts

Plantage à nouveau hier, cette fois j'ai pu faire des tests moi même.
 
Donc depuis un poste, voici les résultats des pings :
8.8.8.8 : OK
ip d'un autre poste : OK
ip de l'hôte : NO
ip des MV : NO
 
Sur l'hôte je vois juste cet événement juste avant la coupure :
source ixgbs
événement 27
Intel(R) Ethernet Controller X550
La liaison réseau a été déconnectée.
 
Et ensuite un tas d'erreur Time-Service, DNS Client Events 8019, etc.
Mais je pense que c'est en lien avec le média déconnecté.
 
C'est sûrement lié à des pbs de drivers de la carte réseau.
Mais moi j'ai mis à jour avec ceux du fabriquant de la CM (c'est une carte intégrée).
Du coup je vais prendre une carte dédiée INTEL I350-T2-V2 et désactiver celle intégrée, on va voir si ça passe comme ça.
 
Mais c'est bizarre parce qu'il n'y avait pas ces logs la fois d'avant.
Et le ping 8.8.8.8 ne répondait pas depuis un poste.
Ils m'ont également signalé des lenteurs la veille du plantage.
 
Je vais en profiter pour changer et mettre un Switch manageable 48 ports.
Cisco 220 Series SF220-48P
Je comptais faire juste 2 VLAN : 1VLAN pour les serveurs/PC 192.168.1.0/24, 1 VLAN pour la téléphone IP sur 192.168.2.0/24.
Sur la Livebox V6 faire une route 192.168.2.0/24 vers 192.168.1.1 (IP de la Livebox).
Rediriger le DHCP vers la machine virtuelle AD où il y a le rôle DHCP.
Est-ce que ça vous paraît ok ?

 
Je ne pense pas que ça va fonctionner. La livebox n'est pas capable de faire du routage entre différents LAN.
 
Ce qui devrait marcher :  
-Un routeur dédié ou une VM (perso, j'opterais pour un petit routeur dédié, histoire de pas tout centraliser sur hyper-V)
-DHCP sur celui-ci pour les téléphones
-Sur la Livebox, une route 192.168.2.0 vers le routeur en question