IPv6-Upstream unter Windows Server mit VirtIO langsam - Workaround: LSO/TSO deaktivieren

  • Guten Tag,


    (ich hatte das Problem bereits dem Netcup Support geschildert, möchte dies aber auch hier nochmal tun.)


    Ich habe seit kurzem einen vServer bei Netcup (Root-Server M). Dieser funktioniert auch soweit, jedoch gibt es ein Problem mit der Geschwindigkeit von IPv6.


    Auch dem Server habe ich die Testversion von Windows Server 2012 R2 installiert, jeweils mit den VirtIO-Treibern (virtio-win-0.1-81) für den SCSI-Controller und die Netzwerkkarte. Im VCP habe ich IPv6 aktiviert und im vServer die IPv4- und IPv6-Konfiguration eingetragen.


    Über IPv4 funktioniert alles einwandfrei, bei IPv6 jedoch ist die Upload-Geschwindigkeit vom Server sehr langsam - Daten werden nur mit ca. 160 KBit/s bzw. 20 KB/s übertragen. Die Download-Geschwindigkeit jedoch ist normal (je nach Speedtest zwischen 100 - 400 MBit/s).


    Ich bin dann auf diesen Bugreport von Red Hat gestoßen: Bug 648572 – virtio GSO makes IPv6 very slow
    Dort wird ein Geschwindigkeitsproblem mit IPv6 bei Verwendung des VirtIO-Netzwerkadapters beschrieben, und als Workaround das Deaktivieren von LSO ("large segment offload" bzw. "TCP segmentation offload" oder "generic segmentation offload").


    Daraufhin habe ich im vServer im Windows-Gerätemanager bei der VirtIO-Netzwerkkarte die Option "Large Send Offload V2 (IPv6)" deaktiviert. Nun ist die Upload-Geschwindigkeit bei IPv6 tatsächlich wieder sehr hoch, so wie bei IPv4.


    Zumindest geht nun mit dem Workaround auch IPv6 sehr schnell, aber ich bin mir nun nicht sicher, ob das Problem am VirtIO-Treiber für Windows liegt, oder am Hostsystem (der Bugreport bei Red Hat wurde ja eigentlich 2011 schon geschlossen). Ich habe testweise auch den "latest" VirtIO-Netzwerktreiber (virtio-win-0.1-94) installiert, dort tritt das Problem ebenfalls auf. Das Gleiche auch unter dem älteren Windows Server 2008 R2.


    Ich habe danach mal testweise ein Debian Wheezy mit Plesk-Panel installieren lassen, und dort auch die IPv6-Adresse eingerichtet. Hier trat das Problem jedoch nicht auf. Da ich mich mit Linux allerdings nicht auskenne, weiß ich nicht, ob hier LSO aktiviert war bzw. wie man dieses aktivieren oder deaktivieren kann.


    Ich habe dann mal mit Wireshark ein Capture des Netzwerkverkehrs erstellt (dort schickt ein Browser eine HTTP-Anfrage zum Herunterladen eines ca. 90 KB großen Bildes an den IIS-Webserver), jeweils einmal mit aktiviertem und einmal mit deaktiviertem IPv6-LSO. Ich bin kein Netzwerkexperte, deswegen kann ich nicht sagen, ob man hier die Ursache des Problems sehen kann (die MTU scheint in beiden Fällen gleich zu sein).
    Ich habe die Wireshark-Captures hier und hier mal hochgeladen, vielleicht möchte sie sich jemand ansehen und kann das Geschwindigkeitsproblem nachvollziehen.


    Ich hatte mal einen unter KVM laufenden virtuellen Server (mit Win Svr 2012R2) bei einem anderen Anbieter; dort traten, soweit ich mich erinnere, bei IPv6 keine Geschwindigkeitseinbußen auf (ich bin mir allerdings nicht mehr sicher, ob ich dort IPv6-Verbindungen wirklich ausreichend getestet hatte). Somit sollte dies kein generelles Problem von KVM bzw. den VirtIO-Treibern sein, ich würde die Ursache hier am KVM-Hostsystem bzw. am Netzwerk von Netcup vermuten. Vielleicht kennt sich hier aber jemand besser aus und kann die genaue Ursache feststellen.


    Evtl. könnte man auch im Wiki-Artikel zur Installation von Windows dieses Geschwindigkeitsproblem bei IPv6 und (standardmäßig) aktiviertem LSO sowie den Workaround beschreiben, falls andere dasselbe Problem haben.



    Danke!

  • Hallo,


    sorry, die obigen Links für die zwei Wireshark-Captures sind bei dem Filehoster nicht mehr erreichbar. Ich habe sie nochmal hier und hier hochgeladen.


    Könnte die Problematik mit dem langsamen IPv6 unter Windows, wenn LSO bei der VirtIO-Netzwerkkarte nicht deaktiviert wurde, ins Netcup-Wiki zum Thema Windows-Installation mit eingefügt werden?



    Im Hinblick auf den Wiki-Eintrag zur Windows-Installation ist mir noch etwas anderes eingefallen, was man auch mit reinschreiben könnte:
    Zumindest bei Windows Server 2012 (und R2) ist es eigenartigerweise so, wenn Windows den Bildschirm aufgrund von Inaktivität (standardmäßig nach 10 Minuten) ausgeschalten hat, dass ein Druck auf den ACPI-Ausschaltknopf nicht Windows herunterfährt, sondern nur den Bildschirm wieder einschaltet - erst bei einem erneuten Druck auf den Ausschaltknopf während der Bildschirm an ist, fährt Windows tatsächlich herunter.


    Dies könnte ein Problem werden, falls Netcup den Server z.B. wegen Wartungsarbeiten am Host herunterfahren muss und dafür den ACPI-Ausschaltknopf der VM nur 1x auslöst.
    Um dies zu beheben, müsste man in den Windows-Energiesparoptionen die Option "Bildschirm ausschalten" auf "Niemals" einstellen. Dann bleibt der VM-Bildschirm immer eingeschaltet, und beim Drücken des ACPI-Ausschaltknopfes fährt Windows sofort herunter.



    Danke!