Beiträge von Kunde

    Hallo,


    auch meine (Windows-)Server wurden gestern nachmittag hart ausgeschaltet, ohne ein ACPI-Shutdown-Signal. Nach ca. 25 Minuten liefen sie dann wieder.


    Bei Windows Server ab 2012 ist es in diesem Fall wichtig, dass man in der Systemsteuerung bei den Energieoptionen bei "Turn off the display:" ("Bildschirm ausschalten:") unbedingt "Never" ("Niemals") auswählt (am besten für alle drei Power-Profile, nicht nur für das aktuell ausgewählte), denn sonst wenn der Bildschirm gerade aus ist, fährt der Server beim ersten ACPI-Shutdown-Signal nicht herunter, sondern schaltet nur den Bildschirm wieder ein (ähnlich wie wenn man eine Taste drückt oder die Maus bewegt), und erst beim zweiten Shutdown-Signal kurz danach fährt er herunter. Nur wenn die Einstellung auf "Never" ist, kann man sicher sein, dass er auch beim ersten Signal herunterfährt.


    Diese Einstellung habe ich jedoch bei allen Servern gemacht, und es funktioniert auch wenn ich im Server-Controlpanel "Herunterfahren (ACPI)" wähle; bei dem Reboot gestern wurde das Signal aber anscheinend nicht gesendet.

    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!

    Hallo,

    RDP ist nicht dazu gedacht durchs offene Internet zu laufen.

    Darf ich fragen, warum du das so siehst?


    RDP nutzt ja TLS zur Verschlüsselung und Authentifizierung des Servers, sodass bei der Verwendung eines eigenen Zertifikats (also entweder ein selbstsigniertes (wobei man das Zertifikat ohne den Private Key auf dem Client-Rechner importiert, oder bei der Verbindungsherstellung den Fingerabdruck vergleicht und eine Ausnahme hinzufügt), oder ein von einer öffentlichen CA signiertes Zertifikat) die Verbindung zum Server sicher ist.


    Wenn man nicht gerade die "Authentifizierung auf Netzwerkebene" (NLA, Network Level Authentication) deaktiviert hat (was nur notwendig wäre wenn man XP-Clients zum Verbinden über RDP verwendet), hat man auch nicht das Problem der RDP-Versionen vor 6.0, wo der Server vor der Authentifizierung bereits eine Session für das Login erstellen musste, was viel Resourcen beanspruchte und eine DoS-Angriffsfläche bot.


    Ich verwende auch bei meinen Windows-Servern RDP übers Internet und kann mir nicht vorstellen, warum RDP nicht über das offene Internet laufen sollte; außer wenn man beispielsweise die Windows-Authentifizierung zu unsicher findet (seit RDP 8.1 reicht ja anscheinend ein Passwort-Hash, wenn dieser immer 16 Byte lang ist, gibt es nur 2^(8*16) (ca. 3,4 * 10^38 ) Möglichkeiten; bei einem 25-stelligen Passwort aus Groß- und Kleinbuchstaben und Zahlen hingegen hätte man schon 62^25 (ca. 6,5 * 10^44) Möglichkeiten).

    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!