9
Hyper-V 2012 R2: (http-)Pakete gehen nicht durch vSwitch, hoher Speicherverbrauch DNS-Server - Diagnoseschritte?
Hallo,
wir haben einen vier Monate alten Windows Server 2012 R2 als Hyper-V Host und AD DC, auf dem zwei Windows Server 2012 R2 VMs laufen.
Die Netzwerkanbindung ist über den virtuellen Switch hergestellt; nach draußen sind 2x Onboard LAN und eine 4-fach Broadcom-LAN-Karte darüber zusammengefasst.
Der Weg ins Internet führt über einen LANCOM DSL-Router, der als Gateway und DNS-Server eingetragen ist.
Darüber hinaus gibt es mehrere Client-PCs bei denen der Hyper-V-Host als DNS-Server eingetragen ist.
gibt es seit Mitte letzter Woche Störungen im Zugriff auf das Internet.
Zur Diagnose habe ich in den Netzwerkeinstellungen den alternativen DNS-Server entfernt, und dann lassen sich folgende Symptome lassen sich beobachten:
Das alles würde darauf hindeuten, dass der DNS-Dienst nicht richtig arbeitet. Also trage ich testweise den DSL-Router als DNS-Server auf einer VM ein (bei einem Client habe ich das getan, und alle Probleme verschwinden sofort). Hilft aber auch nicht:
Was mir nun fehlt, sind Diagnoseschritte, mit denen ich das Problem schrittweise eingrenzen kann. Da fehlen mir leider Grundlagen... hat jemand Vorschläge?
Ich vermute, dass irgendetwas mit dem Hyper-V "virtual Ethernet Switch" nicht stimmt...
wir haben einen vier Monate alten Windows Server 2012 R2 als Hyper-V Host und AD DC, auf dem zwei Windows Server 2012 R2 VMs laufen.
Die Netzwerkanbindung ist über den virtuellen Switch hergestellt; nach draußen sind 2x Onboard LAN und eine 4-fach Broadcom-LAN-Karte darüber zusammengefasst.
Der Weg ins Internet führt über einen LANCOM DSL-Router, der als Gateway und DNS-Server eingetragen ist.
Darüber hinaus gibt es mehrere Client-PCs bei denen der Hyper-V-Host als DNS-Server eingetragen ist.
gibt es seit Mitte letzter Woche Störungen im Zugriff auf das Internet.
Zur Diagnose habe ich in den Netzwerkeinstellungen den alternativen DNS-Server entfernt, und dann lassen sich folgende Symptome lassen sich beobachten:
- der DNS-Server benötigt 500-600 MB RAM - ich denke, das ist zu viel (hatte ich aber früher auch schon beobachtet)
- sowohl der Hyper-V Host wie auch die VMs können nicht auf Webseiten zugreifen (Timeouts; nach zig Sekunden wird manchmal beim zweiten Versuch eine Seite geladen)
- ping-Anfragen nach "draußen" werden mangels DNS-Auflösung nicht beantwortet
- die interne Namensauflösung (domaenenname.local) funktioniert anstandslos
Das alles würde darauf hindeuten, dass der DNS-Dienst nicht richtig arbeitet. Also trage ich testweise den DSL-Router als DNS-Server auf einer VM ein (bei einem Client habe ich das getan, und alle Probleme verschwinden sofort). Hilft aber auch nicht:
- ping-Anfragen auf externe Rechnernamen werden nicht beantwortet (keine DNS-Auflösung)
- ping-Anfragen auf IP-Adressen werden unverzüglich beantwortet
- http-Anfragen per Browser auf eine IP-Adresse werden mit Verzögerung von einer Minute oder so bearbeitet
Was mir nun fehlt, sind Diagnoseschritte, mit denen ich das Problem schrittweise eingrenzen kann. Da fehlen mir leider Grundlagen... hat jemand Vorschläge?
Ich vermute, dass irgendetwas mit dem Hyper-V "virtual Ethernet Switch" nicht stimmt...
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 293520
Url: https://administrator.de/contentid/293520
Printed on: April 24, 2024 at 10:04 o'clock
9 Comments
Latest comment
Hallo,
Das Blech darf NUR Hyper-V sein und nix anderes.
Aus Eigeninteresse Sollte der Hyper-V auch nur Hyper-V machen und nix anderes.
Ich vermute mal der LANCOM ist neu bei euch und vorher gab es einen anderen Router?
Du musst bei den IPv4/v6 Die Regeln erweitern damit mehr als zwei Ping nach draußen gehen. Und auch Ausnahemn für DNS und andere Dienste der Server die nach draußen sollen.
Sonst blockt der LANCOM auf einmal (wird auch nirgends angezeigt)
Also Reglen erstellen und den LANCOM neu starten.
Und die Umgebung Lizenkonform machen und den DC in einer VM betreiben (nicht mit Exchange zusammen auf der selben VM.
Gruß
Chonta
Windows Server 2012 R2 als Hyper-V Host und AD DC, auf dem zwei Windows Server 2012 R2 VMs laufen.
Das ist nicht Lizenzonform.Das Blech darf NUR Hyper-V sein und nix anderes.
Aus Eigeninteresse Sollte der Hyper-V auch nur Hyper-V machen und nix anderes.
Der Weg ins Internet führt über einen LANCOM DSL-Router, der als Gateway und DNS-Server eingetragen ist.
Der DC ist IMMER der DNS ALLER Rechner im Netzwerk und macht auch di Rekrsion bei den Rootservern.Der Weg ins Internet führt über einen LANCOM DSL-Router..
ping-Anfragen auf externe Rechnernamen werden nicht beantworte usw.
ping-Anfragen auf externe Rechnernamen werden nicht beantworte usw.
Ich vermute mal der LANCOM ist neu bei euch und vorher gab es einen anderen Router?
Du musst bei den IPv4/v6 Die Regeln erweitern damit mehr als zwei Ping nach draußen gehen. Und auch Ausnahemn für DNS und andere Dienste der Server die nach draußen sollen.
Sonst blockt der LANCOM auf einmal (wird auch nirgends angezeigt)
Also Reglen erstellen und den LANCOM neu starten.
Und die Umgebung Lizenkonform machen und den DC in einer VM betreiben (nicht mit Exchange zusammen auf der selben VM.
Gruß
Chonta
1
Die Lizensierung ist kein Problem, weil wir 2x Server Standard Edition haben... Ob es geschickt ist, auf dem Hyper-V noch AD zu verwalten, steht auf einem anderen Blatt (wir hatten beim Einrichten damals die Sorge, dass der DC in einer VM ja nach dem Host-OS hochfährt und es Probleme geben könnte, solange diese höchste Instanz noch nicht live ist...).
Aber im DNS-Dienst muss ich doch mindestens einen Forwarder angeben - da bietet sich doch der DSL-Router an (schließlich lässt seine DNS-Loopup-Server-IPs vom Provider aktuell halten), oder?
Nein, der ist seit mehreren Jahren im Einsatz und bediente das gleiche Netzwerk unter "Regierung" eines SBS 2003 R2 ohne Probleme.
Gibt es neue Erfordernisse durch die Umstellung von Win2K3 R2 auf W2K12 R2??
Der DC ist IMMER der DNS ALLER Rechner im Netzwerk und macht auch di Rekrsion bei den Rootservern.
Aber im DNS-Dienst muss ich doch mindestens einen Forwarder angeben - da bietet sich doch der DSL-Router an (schließlich lässt seine DNS-Loopup-Server-IPs vom Provider aktuell halten), oder?
Ich vermute mal der LANCOM ist neu bei euch und vorher gab es einen anderen Router?
Nein, der ist seit mehreren Jahren im Einsatz und bediente das gleiche Netzwerk unter "Regierung" eines SBS 2003 R2 ohne Probleme.
Gibt es neue Erfordernisse durch die Umstellung von Win2K3 R2 auf W2K12 R2??
Hallo,
Ist Verschwendung.
Und auch wenn es nach Lizenzen jetzt evtl hinhaut, eine gute Idee ist es nicht den Hyper-Visor was anderes machen zu lassen als Hyper-V weil der mit dem management der VM schon genug beschäftig ist.
Hatte ich auch aber ich habe auch nur noch Hyper-V und DC als VM auf demselben.
Wenn der Hyper-V neu gestartet werden muss wird der neu gestartet und alles startet normal.
Eine Desasterrecovery ohne laufenden DC ist auch machbar.
Hast Du die Stamserver nicht mitinstalliert oder wie?
Weiterleitungen brauchst Du nur für Domains die nicht über die Stammserver aufgelößwerden können.
Mit 2012R2 kommt ein Verfahren zusammen, das mit 2003 nicht klar kommt.
Wenn das Passwort neu gemacht werden muss vom Computerkonto und der landet beim 2012R2 klapt das nicht.
D wirst es sehen, wenn Du Dich nicht mehr anmelden kannst (betrifft jeh nachdem auch aufeinmal Exchange) Server neu starten und die Passörter werden richtig gesetzt.
Ist der 2003er endlich weg und alle haben ein neues 2012R2 konformes Passwort ist der Spuk vorbei.
Gruß
Chonta
Die Lizensierung ist kein Problem, weil wir 2x Server Standard Edition haben
Und die sind beide dem selben Blech zugewiesen nur damit der Hyper-V auch andere Rollen übernhemen kann?Ist Verschwendung.
Und auch wenn es nach Lizenzen jetzt evtl hinhaut, eine gute Idee ist es nicht den Hyper-Visor was anderes machen zu lassen als Hyper-V weil der mit dem management der VM schon genug beschäftig ist.
wir hatten beim Einrichten damals die Sorge, dass der DC in einer VM ja nach dem Host-OS hochfährt und es Probleme geben könnte, solange diese höchste Instanz noch nicht live ist
Hatte ich auch aber ich habe auch nur noch Hyper-V und DC als VM auf demselben.
Wenn der Hyper-V neu gestartet werden muss wird der neu gestartet und alles startet normal.
Eine Desasterrecovery ohne laufenden DC ist auch machbar.
Nein, der ist seit mehreren Jahren im Einsatz und bediente das gleiche Netzwerk unter "Regierung" eines SBS 2003 R2 ohne Probleme.
Schau trozdem in die Regeln rein, wenn da z.B. die Regeln so aufgesetzt sind, das nur der 2003er alles kann schaut der neue in die Röhre.Aber im DNS-Dienst muss ich doch mindestens einen Forwarder angeben
Hä?Hast Du die Stamserver nicht mitinstalliert oder wie?
Weiterleitungen brauchst Du nur für Domains die nicht über die Stammserver aufgelößwerden können.
Gibt es neue Erfordernisse durch die Umstellung von Win2K3 R2 auf W2K12 R2??
Zumindest in Bezug auf die Passwörter der Computerkonten.Mit 2012R2 kommt ein Verfahren zusammen, das mit 2003 nicht klar kommt.
Wenn das Passwort neu gemacht werden muss vom Computerkonto und der landet beim 2012R2 klapt das nicht.
D wirst es sehen, wenn Du Dich nicht mehr anmelden kannst (betrifft jeh nachdem auch aufeinmal Exchange) Server neu starten und die Passörter werden richtig gesetzt.
Ist der 2003er endlich weg und alle haben ein neues 2012R2 konformes Passwort ist der Spuk vorbei.
Gruß
Chonta
- DHCP: wir haben für unsere ca. zwei Dutzend Netzwerk-Clients (PCs, Drucker, ...) statische IPs, das ist soweit OK.
- DNS: Mit Hilfe der verlinkten Anleitung habe ich dem DNS-Server eine Reverse Lookup Zone hinzugefügt (hatte vorher keine), aber ich sehe keine Änderung
Hier habe ich mal ein Beispiel, dass durch "ausdauerndes Nachfragen" schließlich eine DNS-Anfrage beantwortet wird:
PS C:\Users\Administrator> ping www.peugeot.com
Ping request could not find host www.peugeot.com. Please check the name and try again.
PS C:\Users\Administrator> ping www.peugeot.com
Ping request could not find host www.peugeot.com. Please check the name and try again.
PS C:\Users\Administrator> ping www.peugeot.com
Pinging peugeot.vo.llnwd.net [178.79.243.0] with 32 bytes of data:
Reply from 178.79.243.0: bytes=32 time=16ms TTL=57
Reply from 178.79.243.0: bytes=32 time=29ms TTL=57
Reply from 178.79.243.0: bytes=32 time=13ms TTL=57
Ping statistics for 178.79.243.0:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 13ms, Maximum = 29ms, Average = 19ms
Control-C
PS C:\Users\Administrator>Mit den ersten beiden vergeblichen Anfragen sind ca. 20 Sekunden vergangen, und danach kommt endlich die DNS-Antwort...
Hat noch jemand Vorschläge, wie ich dem auf den Grund gehen kann?
Servus.
Wieso macht man denn sowas? Ok, soll nicht mein Problem sein.
Was soll dir der Lookup in die andere Richtung auch für einen Ping auf den DNS Namen bringen, das ist nur für Whois interessant.
Hast du noch einen anderen Forwarder drin und die Wartezeit auf 20 Sekunden hochgeschalten, wie in der Anleitung im vorherigen Link zu sehen?
Trag mal einen beliebigen Statischen Hostnamen für deinen Router ein und prüfe ob der beim Eintragen als Forwarder aufgelöst wird.
In den NIC Einstellungen aller Client Rechner Server und DCs sollte nur der Windows DNS drinstehen nicht der Router.
Und DC und DNS sollten auf den gleichen Server wenn die Replikation ordentlich funktionieren soll.
Es könnte auch an Problemen mit IPv6 liegen.
Dann zu Stichwort Broadcom:
https://support.microsoft.com/en-us/kb/2902166
Und nein, auf dem HyperV sollte niemals eine andere Rolle als HyperV laufen, da hier durch die Installation der HyperV Rolle die Betriebssystemarchitektur komplett verändert wird.
Und du brauchst eigentlich keinen Forwarder. Es ist zwar grundsätzlich nicht verkehrt wenn man feste Provider-DNS hat die auch zu nutzen weil die evtl. etwas schneller antworten aber der Router kann auch eine Fehlerquelle sein. Lieber erst mal Weiterleitungen rauswerfen und nur mit den Stammhinweisen probieren, siehe Screenshot.
Zitat von @TeeLittle:
- DHCP: wir haben für unsere ca. zwei Dutzend Netzwerk-Clients (PCs, Drucker, ...) statische IPs, das ist soweit OK.
Wieso macht man denn sowas? Ok, soll nicht mein Problem sein.
* DNS: Mit Hilfe der verlinkten Anleitung habe ich dem DNS-Server eine Reverse Lookup Zone hinzugefügt (hatte vorher keine), aber ich sehe keine Änderung
Was soll dir der Lookup in die andere Richtung auch für einen Ping auf den DNS Namen bringen, das ist nur für Whois interessant.
Mit den ersten beiden vergeblichen Anfragen sind ca. 20 Sekunden vergangen, und danach kommt endlich die DNS-Antwort...
Hast du noch einen anderen Forwarder drin und die Wartezeit auf 20 Sekunden hochgeschalten, wie in der Anleitung im vorherigen Link zu sehen?
Hat noch jemand Vorschläge, wie ich dem auf den Grund gehen kann?
Trag mal einen beliebigen Statischen Hostnamen für deinen Router ein und prüfe ob der beim Eintragen als Forwarder aufgelöst wird.
In den NIC Einstellungen aller Client Rechner Server und DCs sollte nur der Windows DNS drinstehen nicht der Router.
Und DC und DNS sollten auf den gleichen Server wenn die Replikation ordentlich funktionieren soll.
Es könnte auch an Problemen mit IPv6 liegen.
Dann zu Stichwort Broadcom:
https://support.microsoft.com/en-us/kb/2902166
Und nein, auf dem HyperV sollte niemals eine andere Rolle als HyperV laufen, da hier durch die Installation der HyperV Rolle die Betriebssystemarchitektur komplett verändert wird.
Und du brauchst eigentlich keinen Forwarder. Es ist zwar grundsätzlich nicht verkehrt wenn man feste Provider-DNS hat die auch zu nutzen weil die evtl. etwas schneller antworten aber der Router kann auch eine Fehlerquelle sein. Lieber erst mal Weiterleitungen rauswerfen und nur mit den Stammhinweisen probieren, siehe Screenshot.
1
So, vielen Dank für all die wertvollen Hinweise - die mich aber leider auch nicht zur Lösung gebracht haben.
Inzwischen habe ich fünf Stunden mit einem DELL-Techniker daran herumgebastelt, der mit unglaublicher Akribie und Geduld die Ursache herausgearbeitet hat (wichtigstes Hilfsmittel war wireshark!):
Hier nochmal die Randbedingungen:
Nebenbemerkung dazu: in unserem Fall vergibt Hyper-V fälschlicherweise für den Virtual Switch die gleiche MAC-Adresse wie für die erste physikalische Netzwerkkarte. Das führt zu Warnungen im "System"-Eventlog:
Vorgesehen ist, dass Hyper-V aus dem angegebenen MAC-Adresspool eine Zuweisung an den Virtual Switch vornimmt, was bei uns aber nicht funktioniert hat. Auch Löschen und Neuanlage des Switches führten erstmal nicht dazu, dass eine MAC aus dem Pool zugewiesen wurde (später, nach Änderungen an den Netzwerktreibern, funktionierte es dann doch wie erwartet...).
Abhilfe: In der jeweiligen VM haben wir in den Adaptereinstellungen des Hyper-V-Netzwerkadapters (Netzwerk-/Freigabecenter > Adaptereinstellungen) unter dem Button "Konfigurieren" im Tab "Erweitert" die Netzwerkadresse (MAC) manuell festgelegt... Damit ist die Warnung verschwunden.
Nachtrag: Durch ein versehentliches Entfernen der Broadcom Control Suite incl. Treibern und nachträglichem Installieren der aktuellesten QLogic (Nachfolgefirma von Broadcom) Control Suite incl. Treibern gingen Team und Hyper-V-VirtualSwitch verloren. Nach der Neuanlage werden die MAC-Adressen der Hyper-V-Netzwerkadapter in den VMs jetzt korrekt aus dem in Hyper-V definierten Adressbereich vergeben...
Das eigentliche Problem aber lag darin, dass unser LANCOM 1811 Wireless DSL (alte Firmware 7.58.0045 von 2008 oder so...) immer wieder verworfene TCP-Pakete und Retransmissions auf Serverseite provozierte, wenn er mit dem Traffic des Teams konfrontiert wurde: Als wir alle Netzwerkkabel des Teams bis auf ein einzelnes ausstöpselten, war das Problem gelöst. Es konnte durch Wiederherstellen aller physischen LAN-Verbindungen des Teams reproduzierbar wiederhergestellt werden. Der DELL-Techniker vermutete ein Problem im Flow-Control des Routers - dem konnten wir aber nicht mehr auf den Grund gehen.
Lösung:
Wir änderten in den erweiterten Eigenschaften des Team-Adapters den "Load Balancing Mode" von "Dynamic" auf "Hyper-V", wodurch der Traffic jeder VM über ein einzelnes physisches Interface läuft und nicht über mehrere verteilt wird (Erklärung des DELL-Technikers).
Mit dieser Änderung waren die Kommunikationsprobleme zwischen Hyper-V und dem LANCOM 1811 DSL-Router behoben - keine TCP-Retransmissions und keine verlorengegangenen Pakete mehr!
Es könnte natürlich sein, dass Aktualisieren der Router-Firmware (viele Jahre alt) Abhilfe schafft, oder ein Umkonfigurieren der Flow-Control - dazu habe ich aber erstmal keine Zeit
Inzwischen habe ich fünf Stunden mit einem DELL-Techniker daran herumgebastelt, der mit unglaublicher Akribie und Geduld die Ursache herausgearbeitet hat (wichtigstes Hilfsmittel war wireshark!):
Hier nochmal die Randbedingungen:
- unser Server hat sechs NICs, die über den Server Manager zu einem Team gebündelt sind (die MAC eines Teams stimmt mit der ersten physikalischen NIC des Teams überein. Das gehört scheinbar so)
- im Hyper-V Manager ist darüber hinaus ein Virtual Switch definiert, das über den Team-Adapter in einem "externen" Netzwerk hängt
Nebenbemerkung dazu: in unserem Fall vergibt Hyper-V fälschlicherweise für den Virtual Switch die gleiche MAC-Adresse wie für die erste physikalische Netzwerkkarte. Das führt zu Warnungen im "System"-Eventlog:
Event 16945, MsLbfoSysEvtProvider
MAC conflict: A port on the virtual switch has the same MAC as one of the underlying team members on Team Nic Microsoft Network Adapter Multiplexor DriverVorgesehen ist, dass Hyper-V aus dem angegebenen MAC-Adresspool eine Zuweisung an den Virtual Switch vornimmt, was bei uns aber nicht funktioniert hat. Auch Löschen und Neuanlage des Switches führten erstmal nicht dazu, dass eine MAC aus dem Pool zugewiesen wurde (später, nach Änderungen an den Netzwerktreibern, funktionierte es dann doch wie erwartet...).
Abhilfe: In der jeweiligen VM haben wir in den Adaptereinstellungen des Hyper-V-Netzwerkadapters (Netzwerk-/Freigabecenter > Adaptereinstellungen) unter dem Button "Konfigurieren" im Tab "Erweitert" die Netzwerkadresse (MAC) manuell festgelegt... Damit ist die Warnung verschwunden.
Nachtrag: Durch ein versehentliches Entfernen der Broadcom Control Suite incl. Treibern und nachträglichem Installieren der aktuellesten QLogic (Nachfolgefirma von Broadcom) Control Suite incl. Treibern gingen Team und Hyper-V-VirtualSwitch verloren. Nach der Neuanlage werden die MAC-Adressen der Hyper-V-Netzwerkadapter in den VMs jetzt korrekt aus dem in Hyper-V definierten Adressbereich vergeben...
Das eigentliche Problem aber lag darin, dass unser LANCOM 1811 Wireless DSL (alte Firmware 7.58.0045 von 2008 oder so...) immer wieder verworfene TCP-Pakete und Retransmissions auf Serverseite provozierte, wenn er mit dem Traffic des Teams konfrontiert wurde: Als wir alle Netzwerkkabel des Teams bis auf ein einzelnes ausstöpselten, war das Problem gelöst. Es konnte durch Wiederherstellen aller physischen LAN-Verbindungen des Teams reproduzierbar wiederhergestellt werden. Der DELL-Techniker vermutete ein Problem im Flow-Control des Routers - dem konnten wir aber nicht mehr auf den Grund gehen.
Lösung:
Wir änderten in den erweiterten Eigenschaften des Team-Adapters den "Load Balancing Mode" von "Dynamic" auf "Hyper-V", wodurch der Traffic jeder VM über ein einzelnes physisches Interface läuft und nicht über mehrere verteilt wird (Erklärung des DELL-Technikers).
Mit dieser Änderung waren die Kommunikationsprobleme zwischen Hyper-V und dem LANCOM 1811 DSL-Router behoben - keine TCP-Retransmissions und keine verlorengegangenen Pakete mehr!
Es könnte natürlich sein, dass Aktualisieren der Router-Firmware (viele Jahre alt) Abhilfe schafft, oder ein Umkonfigurieren der Flow-Control - dazu habe ich aber erstmal keine Zeit
Hallo rzlbrnft,
ich habe mir oben die Mühe gemacht, die tief liegende Ursache und die Lösung zu beschreiben, und habe den Thread auf "gelöst" gesetzt. Ich kann aber meinen eigenen Beitrag nicht selbst als "zur Lösung beigetragen" markieren... Könntest Du das für mich übernehmen? - Danke!
ich habe mir oben die Mühe gemacht, die tief liegende Ursache und die Lösung zu beschreiben, und habe den Thread auf "gelöst" gesetzt. Ich kann aber meinen eigenen Beitrag nicht selbst als "zur Lösung beigetragen" markieren... Könntest Du das für mich übernehmen? - Danke!
Zitat von @TeeLittle:
Ich kann aber meinen eigenen Beitrag nicht selbst als "zur Lösung beigetragen" markieren... Könntest Du das für mich übernehmen? - Danke!
Ich kann aber meinen eigenen Beitrag nicht selbst als "zur Lösung beigetragen" markieren... Könntest Du das für mich übernehmen? - Danke!
Geht nicht
