vRouter: 10.20Rel-VHDX für Hyper-V?

[Maurice]

Moin,

Mittlerweile gibt es den vRouter ja auch für Hyper-V. Die 10.20-Release-VHDX finde ich jedoch nirgends. Auf dem FTP-Server liegt nur eine RC2. Ist die Release noch nicht fertig oder gibt's die nur auf Anfrage? Kann ich alternativ die RC2-VHDX verwenden und dann mit der Release-UPX updaten?

(vRouter als Produktivsystem ist bei uns zwar vorläufig kein Thema, zum Testen neuer Konfigurationen wäre das aber ideal. Hyper-V habe ich ohnehin auf dem Rechner und mit VMware verträgt sich das nicht.)

Grüße

Maurice

[MoinMoin]

Moin, moin!

Der vRouter ist mit der 10.20 Rel noch nicht freigegeben. Der kommt mit einem späteren RU.

Ciao, Georg

[LoUiS]

Wo ich das hier gerade lese. Das steht auch in den Release Notes zur 10.20 Rel drin:

"Wenn Sie eine vRouter-Instanz erstmalig mit LCOS 10.20 RC1 oder LCOS 10.20 RC2 installiert haben, ist
es notwendig, den vRouter mit LCOS 10.20 Rel neu zu installieren.
Die generelle Verfügbarkeit des LANCOM vRouter für Microsoft Hyper-V folgt mit einem zukünftigen
LCOS Release Update."

[Maurice]

Hm OK, das hatte ich nicht gesehen. Da ist das Marketing mal wieder der Realität voraus.

Dann teste ich vorerst mit der RC2.

Grüße

Maurice

[Maurice]

Beim Testen mit der RC2 bin ich direkt auf ein eher spezielles, aber gravierendes Problem gestoßen:
Alle UDP-over-IPv6-Pakete, die der vRouter erzeugt (DHCPv6-Solicits, DNS-Queries, ...) haben eine ungültige Prüfsumme (0x0000), werden daher wohl von der Gegenstelle verworfen und in Folge kann der Router keine "richtige" Internet-Verbindung aufbauen.

Ist da was bekannt? Riecht irgendwie nach kaputtem Checksum-Offload oder so.

Grüße

Maurice

[alf29]

Moin,

nein, ist nicht bekannt, und es würde mich wundern, wenn das allgemein so wäre. Du wirst vermutlich nicht umhin kommen, Deine Umgebung genauer zu beschreiben. Ich habe mich eine Weile mit dem Hyper-V herumgeschlagen (Gottseidank jetzt nicht mehr...) und die Erfahrung bezüglich Checksum-Offloading ist, daß Fehler zum Teil sogar davon abhängen, was für eine Ethernet-Karte Host-seitig in der Kiste steckt, weil der Hypervisor das Offloading an die echte Hardware weiterreicht.

Viele Grüße

Alfred

[Koppelfeld]

Hihi, kann ich bestätigen.

Subtil unterschiedliche Fehlfunktionen beim Wechsel zwischen qlogic / emulex / broadcom / intel.

Kriegst Du nur stabil, wenn Du beim Gast "ältere Netzwerkkarte" einstellst.

SR-IOV unter MS habe ich noch nie probiert.

[alf29]

Moin,

Kriegst Du nur stabil, wenn Du beim Gast "ältere Netzwerkkarte" einstellst.

Die Performance dieser Tulip-Emulation ist aber je nach Rechner gruselig. Ich habe nie herausgefunden, warum man auf einem Rechner als Host 120 und auf dem nächsten wieder nur 20 Mbps Durchsatz bekommt. In allen Fällen hatte ich dann 100% CPU-Last im Gastsystem. Die Emulation irgendwelcher Hardware (egal ob Ethernet ode IDE) scheint im Hyper-V nur ein absoluter Notnagel zu sein, andere Hypervisoren kriegen die Emulation z.B. einer Intel e1000 um Größenordnungen besser hin.

Viele Grüße

Alfred

[Maurice]

Moin Alfred,

Da ich den vRouter vorläufig nur zum Testen einsetzen möchte läuft er auf einem Laptop. Windows 10 1809, Intel 82579LM-Ethernet (konfiguriert als Hyper-V External Switch). Ethernet-Treiber ist aktuell (12.15.31.4 / PROSet 23.2), die Offloading-Options im Geräte-Manager sind alle "Rx & Tx Enabled" (default). Über diesen Ethernet-Port hängt das Laptop im LAN-1 eines 1781VA.
Der vRouter hat zwei virtuelle Ethernet-Ports. ETH 1 (LAN-1) hängt in Hyper-V an einem Internal Switch, ETH 2 (DSL-1, DHCPOE) an besagtem External Switch.

Den Packet-Capture habe ich gestern direkt übers Webinterface des vRouters gemacht (am DSL-1). Das war wohl nicht so sinnvoll. Dort sind die Prüfsummen bei ausgehenden UDPv6-Paketen alle 0x0000. Was nachvollziehbar ist, wenn die durch das Offloading erst später berechnet werden.
Dennoch sind wir wohl auf der richtigen Spur. Mache ich den Packet-Capure nämlich übers Webinterface des 1781VA (am LAN-1), dann haben alle UDPv6-Pakete vom vRouter zwar Prüfsummen, die sind laut Wireshark aber falsch:

Checksum: 0x442a incorrect, should be 0xca85 (maybe caused by "UDP checksum offload"?)

Ich habe ~10 VMs auf diesem Laptop (Windows, Linux, BSD) und kann mich an kein vergleichbares Problem erinnern.

Grüße

Maurice

[alf29]

Moin,

ja, korrekt, das Packet-Capturing auf dem Gerät greift (notwendigerweise) die Pakete ab, bevor sie in die "Hardware" gehen.

0x0000 ist aber auch nicht so gut, denn da sollte zu dem Zeitpunkt eigentlich schon die Teil-Prüfsumme des IP-Headers drinstehen. Die API vom Synthetic NIC ist wohl so definiert, daß die "Hardware" auf diese Teilsumme nur noch die Prüfsumme der TCP/UDP-Playload draufrechnet (das ist natürlich der Löwenanteil). Kommt wohl aus dem Linux-Umfeld, wo das generell so ist.

So einen Fehler hatte ich anfangs bei IPv4, daß in das Prüfsummenfeld nicht die Summe des Pseudo-Headers eingetragen war. Das fiese an der Sache: Der Hyper-V gibt das Offloading einfach an den Treiber der Ethernet-Hardware auf dem Host-System weiter, und da gibt es Chipsätze, die dieses "Angebot" ignorieren und die Prüfsumme einfach immer komplett berechnen. Da fällt so ein Fehler dann nicht auf...und in meinem System hatte ich eine Realtek-Karte, die das eben so handhabt. Ist erst beim Kollegen aufgefallen, der hatte einen Broadcom-Chipsatz. Deshalb meine Frage wegen Ethernet-Chipsatz im Host-System.

Ich schau mal morgen, ob es das sein kann. Wenn ich meinen Unwillen überwinden kann

Viele Grüße

Alfred

[alf29]

Moin,

wird heute mit dem Anschauen wohl nichts mehr. Das Windows macht gerade das, was es am liebsten tut...

[Maurice]

Moin Alfred,

Na dann viel Spaß beim Updaten und vielleicht klappt es ja morgen.

0x0000 ist aber auch nicht so gut, denn da sollte zu dem Zeitpunkt eigentlich schon die Teil-Prüfsumme des IP-Headers drinstehen.

Da steht zu diesem Zeitpunkt auch bei UDP über IPv4 noch nichts drin, das funktioniert aber.

Ein Packet-Capture direkt im vRouter an DSL-1 ergibt folgendes (nur bezogen auf TCP- und UDP-Pakete, die der vRouter selbst erzeugt):

• IPv4-Header-Prüfsumme ist 0xffff
• TCP-Prüfsumme ist vorhanden, aber inkorrekt (IPv4 und IPv6)
• UDP-Prüfsumme ist 0x0000 (IPv4 und IPv6)

Ein Packet-Capture "von außen" ergibt:

• IPv4-Header-Prüfsumme ist korrekt
• TCP-Prüfsumme ist bei IPv4 korrekt, bei IPv6 inkorrekt
• UDP-Prüfsumme ist vorhanden, bei IPv4 korrekt, bei IPv6 inkorrekt

Via IPv6 funktionieren daher weder TCP noch UDP (aber z. B. ICMP).


Noch etwas ganz anderes fiel mir auf: Der vRouter scheint davon auszugehen, dass die RTC in UTC läuft. Das ist auf Windows-Rechnern und damit auch in Hyper-V ja nicht der Fall. Die Uhrzeit im vRouter ist daher entsprechend verschoben. Als Workaround kann man im vRouter die Zeitzone auf UTC stellen und die Sommerzeit-Umstellung abschalten. Ist das so gedacht? Außerdem driften die Host-Zeit und vRouter-Zeit schnell auseinander. Der vRouter nutzt wohl den Zeitsynchronisations-Dienst von Hyper-V nicht?

Grüße

Maurice

[alf29]

Moin,

Na dann viel Spaß beim Updaten und vielleicht klappt es ja morgen.

Mal sehen. Das Windows-Update ist durch, und die Benutzerdaten sind noch da Am Update des VRouter-Images beiße ich mir aber noch die Zähne aus. Werden wohl die Kollegen mithelfen müssen. Egal, was ich mit diesem Hyper-V/VRouter-Gedöns mache, ich kriege braune Finger. Keine Ahnung, wieso das so ist.

Da steht zu diesem Zeitpunkt auch bei UDP über IPv4 noch nichts drin, das funktioniert aber.

Ja, das ist mir bei längerem Überlegen auch aufgegangen, wieso das so sein muß. Der VRouter verwendet den Ethernet-Mapper, wo man ein physisches Interface (ETH-x) auf LAN-x oder DSL-x abbilden kann. Das Paket-Capturing passiert am LAN-x, das Ausfüllen der Prüfsummen (inklusive Vorbelegen mit Pseudo-Header-Prüfsummen) erst im ETH-x. Beim Capturen kann da also noch gar nichts drinstehen. Da werde ich nicht ums Debuggig in der Firmware herumkommen - sobald ich denn mal einen aktuellen VRouter zum Laufen kriege. Das ist manchmal echt zum k***.

Noch etwas ganz anderes fiel mir auf: Der vRouter scheint davon auszugehen, dass die RTC in UTC läuft. Das ist auf Windows-Rechnern und damit auch in Hyper-V ja nicht der Fall. Die Uhrzeit im vRouter ist daher entsprechend verschoben.

Also LCOS geht m.W. grundsätzlich davon aus, daß eine Hardware-RTC in UTC läuft (was auch eigentlich die einzig sinnvolle Einstellung ist, aber das ist eine andere Sache...). Bei einem emulierten System sind die RTC des Host- und des Gastsystems eigentlich zwei verschiedene Dinge und eigentlich müßte man den Hypervisor so konfigurieren können, daß die emulierte RTC in UTC oder in Localtime läuft. Linux-Systeme bevorzugen inzwischen eigentlich auch eine RTC, die mit UTC läuft, was macht der Hyper-V denn da?

Viele Grüße

Alfred

[alf29]

Moin,

Der vRouter nutzt wohl den Zeitsynchronisations-Dienst von Hyper-V nicht?

Nein, meines Wissens nicht. Meine persönliche Dosis "Microsoft" für die nächsten paar Jahre war nach drei Monaten Synthetic NIC und Shutdown-Device erreicht, und ein Kollege hat dann wohl noch das Heartbeat-Device angebunden.

Viele Grüße

Alfred

[Maurice]

Moin Alfred,

Also LCOS geht m.W. grundsätzlich davon aus, daß eine Hardware-RTC in UTC läuft (was auch eigentlich die einzig sinnvolle Einstellung ist, aber das ist eine andere Sache...).

Da sind wir einer Meinung, aber auf Windows-Rechnern läuft die Hardware-RTC nun mal in lokaler Zeit.

Bei einem emulierten System sind die RTC des Host- und des Gastsystems eigentlich zwei verschiedene Dinge [...]

Grundsätzlich ja. Jeder Gast hat seine eigene emulierte RTC. Die wird von Hyper-V beim allerersten Start des Gastes auf die (lokale) Zeit des Hosts gesetzt und läuft dann unabhängig davon weiter (kann daher vom Gast-OS auch beliebig umgestellt werden). Die Gast-Zeit driftet aber relativ schnell weg, da dessen Zeitbasis prinzipbedingt ungenau ist. Das behebt der Hyper-V-Zeitsynchronisierungsdienst, über die der Gast sich kontinuierlich mit der (genaueren) Host-Zeit abgleicht. Zeitzonenunterschiede werden dabei berücksichtigt. Außerdem sorgt der Dienst dafür, dass eine pausierte VM nach dem Fortsetzen sofort wieder die aktuelle Zeit hat.

[...] und eigentlich müßte man den Hypervisor so konfigurieren können, daß die emulierte RTC in UTC oder in Localtime läuft.

Hyper-V ist es egal, in welcher Zeitzone die emulierte RTC läuft. Solange der Gast läuft ist er selbst dafür verantwortlich. Fährt man den Gast herunter, so merkt sich Hyper-V die Differenz zwischen Gast-RTC und Host-Zeit und stellt beim nächsten Start die emulierte Gast-RTC wieder entsprechend ein.

Linux-Systeme bevorzugen inzwischen eigentlich auch eine RTC, die mit UTC läuft, was macht der Hyper-V denn da?

Praktisch alle Linux- und BSD-Varianten nutzen die Hyper-V-Integrationsdienste. Bei Gast-Systemen ohne Integrationsdienste benötigt man zwingend eine andere Methode zur kontinuierlichen Zeitsynchronisierung.

Was der vRouter genau treibt ist mir nicht klar. Wie Du auch schreibst nutzt er den Zeitsynchronisierungsdienst offensichtlich nicht, wodurch die Zeit schnell wegdriftet (hier ca. eine Minute pro Stunde) und beim Pausieren der VM Zeit "verloren geht". Verstellt man im vRouter die Zeit manuell, so geht diese durch einen Neustart verloren. Es hat den Anschein, dass die emulierte RTC vom vRouter gar nicht gestellt wird. Vielleicht könnt ihr euch das nochmal anschauen?

Grüße

Maurice