Hyper-V und DHCP

[kengel 0]

Hallo zusammen,

 

ich habe ein doch recht merkwürdiges Problem mit einem DHCP Server.

 

Wir haben 2 neue HyperV Server aufgesetzt. Auf den Servern sollen die DC und DHCP Server laufen.

 

Die Kopfschmerzen bereitet der DHCP Server, der auf den HyperV Servern läuft. Er verteilt IP Adressen an aller Workstations die sich anmelden. Des weiteren gibt es noch Polycom IP Telefone. Die Telefone sollten auch IP's über den DHCP Server erhalten. das Funktioniert auch bei 2/3 der Telefone. Aber bei dem letzten 1/3 werden die DHCP Pakete von dem virtuellen Switch des HyperV Servers blockiert. 

Ich habe den Netzwerktraffic analysiert und gesehen das die Pakete auf dem physikalischen Adapter noch ankommen aber auf dem virtuellen Adapter nicht mehr aufgelistet werden.

 

Der DHCP Guard bei der VM ist abgeschaltet. (Aber soweit kommen die Pakete schon nicht mehr.)

Auf dem physikalischen Adapter sind auch die

Einstellungen für

IPsec Offload

IPV4 Checksum Offload

Large Send Checksum Offload V2

TCP Checksum Offload

UDP Checksum Offload

 

deaktiviert- für IP4 und IP6. (Sie waren schon mal aktiviert aber ich habe in einem Beitrag gelesen das das das Problem sein könnte. Hat aber leider keine Wirkung gezeigt.)

 

Hat irgend jemand noch eine Idee woran es liegen könnte?

 

Gruß

 

Klaus

 

 

 

 

 

[Doso 77]

Wir setzen nun seit ~5 Jahren DHCP Server auf Hyper-V ein, 2008R2 und nun auf 2012R2, mehrere VLANs ~1000 Geräte. Die beschriebenen Effekt konnten wir nicht beobachten.

[Daniel -MSFT- 129]

Hi Klaus,

 

mach einen Supportcall bei uns auf. Da wird Dir am schnellsten geholfen. Das Abschalten der Offloadingfunktionen ist ein Admin-Mythos: http://m.windowsitpro.com/networking/give-microsoft-s-scalable-networking-pack-another-look

 

Den würde ich wieder rückgängig machen. Damit versaust Du Dir nur die Performance. Wichtiger sind aktuelle Netzwerkkartentreiber.

bearbeitet 1. August 2014 von Daniel -MSFT-

[zahni 521]

Mythos? ich weis ja nicht. Unter 2003 jagte ein Update für SNP das Nächste.

Richtig funktioniert hat das erste unter 2008 (R2?), was durchaus auch an Treibern gelegen haben kann.

Ja, wir  hatten damals Probleme damit ;).

 

Kleines Beispiel: http://support.microsoft.com/kb/950224/en-us

http://www.intel.com/support/network/sb/CS-030646.htm

 

usw.

[h-d.neuenfeldt 21]

ich würde mal die Netzwerkmasken auf dem Hyper-V kontrollieren.

 

Idee dahinter : der DHCP liefert IPs aus dem Range z.B.: 172.20.x.x aber auf dem Server ist die Maske 255.255.255.0 gesetzt

[NeMiX 76]

Wieviele NICs hat die VM oder arbeitest du mit dhcp relay auf dem Router (was imho der saubere Weg ist)

[Daniel -MSFT- 129]

Hi zahni,

 

lies doch bitte mal den Link, den ich gepostet habe, vor dem Antworten. Da sind doch genau die von Dir aufgeführten Punkte drin. Das war 2003 und nicht 2012 R2, was der OP wohl einsetzt. Weiterhin ging es um RSS Offloading, was damals mehrprozessorfähig gemacht wurde. Dagegen waren die Funktionen, die der OP abschaltet, gar nicht vom SNP betroffen.

 

Ich zitier hier mal, damit Du Dir den Klick sparen kannst:

 

Back in 2007, Windows Server 2003 SP2 introduced a set of networking performance features—collectively known as the Scalable Networking Pack (SNP)—that utilized hardware acceleration to process network packets and achieve higher throughput.

 

...

 

Because of issues in the components and issues in network card drivers, customers who deployed Server 2003 SP2 on hardware that could use the features often had problems. Many customers resolved problems by disabling the features on Server 2003, and Microsoft released an update in the article “An update to turn off default SNP features is available for Windows Server 2003-based and Small Business Server 2003-based computers” that would disable the three features. A later update, “A Scalable Networking Pack (SNP) hotfix rollup package is available for Windows Server 2003,” allowed customers to enable the features if needed, but Microsoft’s recommendation is to leave the features disabled unless there’s a business need to enable them for higher network performance. In general, customers needing higher networking performance should utilize Windows Server 2008 or Server 2008 R2, due the included next-generation TCP/IP stack.

Jetzt kommen die zwei Absätze, die ich meine:

 

Fear in the IT Community

Because of the problems with SNP in Server 2003 SP2, the IT community quickly adopted the common practice to proactively and reactively disable these features. For Server 2003, this makes sense. But for Server 2008 and Server 2008 R2, disabling these features can often result in lower network performance and lower server capacity. These features are very stable on Server 2008 R2 (with or without SP1), and Server 2008 can achieve the same stability using SP2 and additional hotfix updates. Unfortunately, disabling them as one of the first steps to resolve networking issues is still a very common troubleshooting practice, with many problems not being resolved due to disabling the features.

 

Many customers have also started to disable additional offload features that have been stable across many OS releases. These offloads are typically named TCP Checksum Offload, IP Checksum Offload, Large Send Offload, and UDP Checksum Offload. They are available to configure in network adapter advanced properties or configuration utilities. These features are not the same thing as the SNP features, but customers often confuse them because of the similar naming. Also, many other performance enhancements require these features.

Deswegen Mythos. Wer 2014 ohne vernünftigen Grund an den Funktionen rumschraubt, verschlimmbessert es meist nur. Beispiel Dauer des Reseeding einer Exchange-DB statt in fünf Tagen in 19h: http://blogs.technet.com/b/exchange/archive/2013/07/30/a-reminder-on-real-life-performance-impact-of-windows-snp-features.aspx

 

Schon bei 2003 war die bessere Entscheidung, die Hotfixes zu installieren und Treiber und Firmware der Netzwerkkarten aktuell zu halten, wenn man ein SNP oder Multicore-System einsetzte.

 

Friends don’t let friends run their modern OS-servers with old network drivers and SNP features turned off!

 

 

[zahni 521]

Mich hat der "Mythos" ein wenig gestört.

Nennen wir es historische Tatsachen, ok?

Wir waren froh, als die den Kram damals komplett abschalten konnten.

Bei 2008 R2 lasse ich das eigentlich an.

 

Das Problem ist, dass sich solche Sachen ewig im Netz und in den Köpfen der Admins festsetzen.

 

Wie verhält sich das eigentlich in virtuellen Umgebungen? Nach meinem Verständnis müssten bestimme Offloading-Funktionen vom Hypervisor erledigt werden und nicht von der VM.

Nur der hat direkten Zugriff auf die NIC.

[DocData 85]

Es gibt keinen Common Practice zum Abschalten von Funktionen. Funktionen werden aktiviert oder deaktiviert, aufgrund einer konkreten Anforderung und nicht "proaktiv". Ich erlebe das bei etlichen Kunden. Fürchterlich was bei manchen im Kopf so rumspukt.

[Daniel -MSFT- 129]

Ich sage nicht, dass es keine Probleme gab, sondern das das Abschalten der Funktionen nicht die beste Lösung ist. Bei 2003 mit einer 1 GB-Netzwerkkarte und 1-2 CPUs war das Bottleneck woanders. Da war Abschalten nicht so schlimm. Bei heutigen Servern mit 32 und mehr CPUs und möglicherweise mehrfachen 10 GB-Anbindungen verschenkst Du massiv Performance, wenn Du der urbanen Legende folgst.

 

Hier zum Einstieg in das Thema: http://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx

 

Ganz wichtig: As with all Best Practices, not every recommendation can – or should – be applied. Best Practices are general guidelines, not hard, fast rules that must be followed. As such, you should carefully review each item to determine if it makes sense in your environment. If implementing one (or more) of these Best Practices seems sensible, great; if it doesn't, simply ignore it. In other words, it's up to you to decide if you should apply these in your setting.

 

Du musst verstehen, welche Funktion wofür ist. Was welcher Schalter tut. Welche Fähigkeiten die Hardware und der Treiber unterstützen. RSS, TCP Chimney, dVMQ, etc. Bei Jumboframes gibt es z.B. Switches, die >12k unterstützen, andere dagegen nur knapp >9k. Du tauschst nichtsahnend den Switch und kaboom.

 

Deswegen gibt es auch keine einfache Empfehlung, sondern abhängig davon, was ein Interface kann und machen soll (Storage, HA, VM, etc.), müssen die Parameter angepasst werden.

 

TCP Chimney ging z.B. früher nicht mit Link Aggregation. Da

musst Du dann entscheiden, ob mehr Performance oder Ausfallsicherheit gefragt ist. Eventuell macht man das für das Interface an, auf dem die VMs verschoben werden und lässt es auf anderen aus, auf denen die Anwender zugreifen.

 

Viele Hintergründe zum Verständnis von Netzwerkeinstellungen in der Parent Partition vs. Guest OS:

 

Hyper-V Networking Optimizations Part 1 of 6 (TCP Chimney Offload)http://blogs.technet.com/b/cedward/archive/2011/04/08/hyper-v-networking-optimizations-part-1-of-6-tcp-chimney-offload.aspx

 

Hyper-V Networking Optimizations Part 2 of 6 (VMQ)

http://blogs.technet.com/b/cedward/archive/2011/04/13/hyper-v-networking-optimizations-part-2-of-6-vmq.aspx

 

Hyper-V Networking Optimizations Part 3 of 6 (RSS)

http://blogs.technet.com/b/cedward/archive/2011/04/20/hyper-v-networking-optimizations-part-3-of-6-rss.aspx

 

Hyper-V Networking Optimizations Part 4 of 6 (Jumbo Frames)

http://blogs.technet.com/b/cedward/archive/2011/05/05/hyper-v-networking-optimizations-part-4-of-6-jumbo-frames.aspx

 

Hyper-V Networking Optimizations Part 5 of 6 (Features compatibility matrix)

 

 

http://blogs.technet.com/b/cedward/archive/2011/05/31/hyper-v-networking-optimizations-part-5-of-6-features-compatibility-matrix.aspx?utm_source=twitterfeed&utm_medium=twitter

 

Hyper-V Networking Optimizations Part 6 of 6 (Monitoring Hyper-V Network consumption)

http://blogs.technet.com/b/cedward/archive/2011/07/19/hyper-v-networking-optimizations-part-6-of-6-monitoring-hyper-v-network-consumption.aspx

 

Mit neueren Hyper-V-Versionen kommen natürlich Weiterentwicklungen, deswegen ist es wichtig, wenn man sich in dem Bereich professionell bewegt, das Wissen auf dem aktuellsten Stand zu halten.

bearbeitet 2. August 2014 von Daniel -MSFT-

[Weingeist 157]

Nun, gan so altbacken ist das Problem auch wieder nicht. Unter virtuellen Systemen gab es teils auch in jüngster Vergangenheit massivste Probleme. Egal ob zertifzierte Hardware oder nicht.

 

Meist lief es so ab, dass erst alles tadellos eine Weile lang funktionierte und dann urplötzlich und ohne jede Vorwarnung die Performance komplett zusammen brach und sich nicht mehr erholte. Es half dann nur ein Reboot. Ich kenne das vor allem unter VmWare. Glaube aber kaum, dass HyperV davon gänzlich verschont war, da sie ja im Endeffekt auf die gleichen Funktionen der Netzwerkkarten zugreifen. Nach langer Warterei gabs dann immer mal wieder nen Firmware und Treiber-Update welches teilweise Besserung versprach.

 

Bei abgedrehten Offload-Features im Gast konnte man das Problem in diesen Fällen oft aber nicht immer lösen. Performance aber tatsächlich immer etwas schlechter als wenn sie an waren. Dafür eben stabil.

 

Unter aktuellsten VmWare Builds, Firmware der Netzwerkkarten und Treiber bin ich von diesen Problemen mittlerweile (seit ca. nem halben oder sogar Jahr - die Zeit läuft schnell) verschont. Deshalb bei Netzwerkproblemen wenn die Konfiguration fehlerfrei zu sein scheint, erstmal Firmware und Treiber prüfen.

[zahni 521]

Bei "VMWare" sind  auch andere Problem denkbar, z.B. eine veralteter Patch-Stand. ESX verlagert auch bestimmte Funktionen auf die  NIC wenn der Treiber oder  die NIC das Supporten.

Hier sind bestimmte Broadcom-Chipsätze ein wenig schmerzhaft.

[kengel 0]

Die Treiber der Netzwerkkarte sind von 03.2013 und es stehen derzeit 5 Sicherheitsupdates an.

 

Ich werde diese mal installieren und danach noch mal den virtuellen Switch neu aufsetzen.

 

@Daniel: Stimmt wir setzen 2012 R2 sowohl in den VM's wie auch auf dem HyperV ein.

[kengel 0]

So will nun doch mal die Lösung meines Problems posten.

 

Ich habe dann den virtuellen Switch komplett deinstalliert und noch mal installiert.

Allerdings musste ich ihn auf einem der Beiden Server 2x De-/installieren bevor er alles gemacht hat was er sollte.

 

Die Installation hat keine Fehlermeldung angezeigt.

[Necron 71]

Danke für deine Rückmeldung! :)