Hyper-V Portmirror - Fehlende Pakete

sonny1895
Goto Top
Hallo zusammen,

ich habe eine Tracing (Wireshark bzw. dumpcap) Umgebung für unser Microsoft S2D Cluster erstellt.

Dafür habe ich auf jedem Knoten eine VM erstellt, welche keine HA Rolle hat. Nun nutze ich die Hyper-V Funktion "portmirroring" um den Traffic der Produktiven VM's auf die Trace VM zu bekommen und diese dann dort mittels Capture Filter zu trennen.

Das funktioniert auch soweit. Nun ist meinem Netzwerker aufgefallen, dass immer mal wieder Pakete (Die von der Produktiv VM gesendet werden) nicht auf der Trace VM auftauchen. Um das zu validieren haben wir zusätzlich eine dumpcap Instanz auf der Produktiv VM laufen lassen. Beim Vergleich der beiden dumpcap Dateien ist dieser Fehler gut sichtbar geworden.

Leider haben meine Google Suchen nicht viel ergeben. Deswegen wende ich mich an euch.

Habt ihr Ideen woran das liegen könnte?
Was braucht noch für Infos um eine Aussage treffen zu können?

Danke im voraus.

Viele Grüße
Patrick

Content-Key: 3135440186

Url: https://administrator.de/contentid/3135440186

Ausgedruckt am: 02.07.2022 um 16:07 Uhr

Mitglied: MysticFoxDE
MysticFoxDE 22.06.2022 um 14:44:58 Uhr
Goto Top
Moin Patrik,

ist das ein Hyper-V 2019?

Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.


Ist der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?

Verwendest du SR-IOV oder VMQ?

Geht es eventuell um IPv6 Verkehr?

Beste Grüsse aus BaWü

Alex
Mitglied: Sonny1895
Sonny1895 22.06.2022 um 15:34:45 Uhr
Goto Top
Moin Alex,

ich setze Hyper-V 2016 als auch 2019 ein. Natürlich sind die Versionen innerhalb eines Clusters identisch.


Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.

Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.

Melde mich sobald ich weitere Infos habe face-smile

Ist der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?

Ja und nein, wenn die geteamt sind dann so:

Hyper-V 2016: LBFO
Hyper-V 2019: SET

Aber ich hab auch NICs die nicht geteamt sind.

Verwendest du SR-IOV oder VMQ?

SR-IOV ist bei uns deaktiviert.
VMQ ist bei unseren Containern aktiviert.

Geht es eventuell um IPv6 Verkehr?

Nein es geht ausschließlich um IPv4 Verkehr.


Ich habe bei einer Trace VM in der vNIC -> Advanced Features -> Protected network deaktiviert. Dadurch wurde der Packet "lost" weniger.


Danke schon mal für die Ideen face-wink

Gruß
Patrick
Mitglied: MysticFoxDE
MysticFoxDE 22.06.2022 aktualisiert um 20:21:17 Uhr
Goto Top
Moin Patrick,

ich setze Hyper-V 2016 als auch 2019 ein. Natürlich sind die Versionen innerhalb eines Clusters identisch.

tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?

Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.

Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.

Melde mich sobald ich weitere Infos habe face-smile

soweit ich weis nicht, aber ich bin ehrlich gesagt auch kein S2D Experte.

Ist der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?

Ja und nein, wenn die geteamt sind dann so:

Hyper-V 2016: LBFO
Hyper-V 2019: SET

😬, Details siehe hier.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...

Aber ich hab auch NICs die nicht geteamt sind.

Hast du auf den Nodes des 2019er Cluster noch je eine Physikalische NIC zur freien Verwendung?


SR-IOV ist bei uns deaktiviert.
VMQ ist bei unseren Containern aktiviert.

Beides sollte das Problem eigentlich nicht verursachen, ich wollte es vorerst nur der Vollständigkeit halber wissen.

Geht es eventuell um IPv6 Verkehr?

Nein es geht ausschließlich um IPv4 Verkehr.

Sehr gut, dann läuft du schon mal nicht in den Prüfsummenabladungsbug.

Ich habe bei einer Trace VM in der vNIC -> Advanced Features -> Protected network deaktiviert. Dadurch wurde der Packet "lost" weniger.

Wie bitte, 😮 ... 😵.
Sehr interessant aber absolut schräg, da dieses Feature eigentlich nicht aktiv in den Datenverkehr eingreifen sollte.
Aber das SDN benötigt aufgrund der ständigen Überwachung der entsprechenden vNIC's dadurch auch etwas mehr Leistung. 🤔

Ich habe da eine Idee, benötige im Vorfeld aber noch ein paar Infos.

Kannst du mir bitte die Konfiguration des entsprechenden vSwitches posten, danke.


Und auch die Infos zu den betreffenden vNIC's.



Welche physikalischen NIC's (Hersteller/Typ) verwendest du eigentlich?

Beste Grüsse aus BaWü
Alex
Mitglied: Sonny1895
Sonny1895 24.06.2022 um 12:20:35 Uhr
Goto Top
Moin Alex,

entschuldige die späte Antwort, ich hatte Kundentermine und konnte deswegen noch nicht weiter Testen.

ich setze Hyper-V 2016 als auch 2019 ein. Natürlich sind die Versionen innerhalb eines Clusters identisch.

tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?

Das muss ich noch testen. Habe eben schon mal ein Trace gestartet. Also werde ich heute Nachmittag eine Info haben.

Wenn ja, hast du auf dem entsprechenden vSwitch noch RSC aktiviert?
Wenn ja, dann hau das mal raus, das zickt öfters mal rum.

Ja bei allen vSwitch ist RSC aktiv. Werde das mal abklären ob das RSC für S2D eine Rolle spielt.

Melde mich sobald ich weitere Infos habe face-smile

soweit ich weis nicht, aber ich bin ehrlich gesagt auch kein S2D Experte.

Ich werde mich dazu noch einlesen und nochmal meine Consulting Dame Fragen face-smile


Ist der Uplink auf dem vSwitch geteamt?
Wenn ja welches, LBFO oder SET?

Ja und nein, wenn die geteamt sind dann so:

Hyper-V 2016: LBFO
Hyper-V 2019: SET

😬, Details siehe hier.
https://community.spiceworks.com/topic/2343311-the-windows-horror-story- ...

Den Artikel führe ich mir heute zu gemühte face-smile Danke schon mal face-smile


Aber ich hab auch NICs die nicht geteamt sind.

Hast du auf den Nodes des 2019er Cluster noch je eine Physikalische NIC zur freien Verwendung?

Auf dem 2019er Cluster leider nein. Aber auf den 2016er Cluster (Hier bleibt abzuwarten was mein Test ergibt)

Ich habe bei einer Trace VM in der vNIC -> Advanced Features -> Protected network deaktiviert. Dadurch wurde der Packet "lost" weniger.

Wie bitte, 😮 ... 😵.
Sehr interessant aber absolut schräg, da dieses Feature eigentlich nicht aktiv in den Datenverkehr eingreifen sollte.
Aber das SDN benötigt aufgrund der ständigen Überwachung der entsprechenden vNIC's dadurch auch etwas mehr Leistung. 🤔

Ich hatte am Anfang den verdacht das es auch ein Performancethema sein könnte. Da die Packets ca. 2 Sekunden später erst auf der Tracing VM eintreffen(Hatte ich initial leider nicht erwähnt).

Ich habe da eine Idee, benötige im Vorfeld aber noch ein paar Infos.

Kannst du mir bitte die Konfiguration des entsprechenden vSwitches posten, danke.



Und auch die Infos zu den betreffenden vNIC's.



Welche physikalischen NIC's (Hersteller/Typ) verwendest du eigentlich?

NIC's 2019er Cluster
Intel(R) Ethernet Server Adapter I350

NIC's 2016er Cluster
Intel(R) Ethernet Connection X722 for 1 GbE

Melde mich später nochmal

Grüße aus NRW
Patrick
Mitglied: Sonny1895
Sonny1895 24.06.2022 um 16:12:25 Uhr
Goto Top
Moin Alex,

tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?

Auf dem 2016 Cluster tritt das Problem nicht auf. Dort verwenden wir ein LBFO Teaming.

Gruß
Patrick
Mitglied: MysticFoxDE
MysticFoxDE 25.06.2022 um 07:27:09 Uhr
Goto Top
Moin Patrick,

tritt dieses Problem etwa auf beiden Clustern 2016/2019 gleich auf?

Auf dem 2016 Cluster tritt das Problem nicht auf. Dort verwenden wir ein LBFO Teaming.

ich sehe dein Problem schon an dem vorherigen Post. 😀
Geb mir noch etwas Zeit um wieder fit zu werden (habe gerade Corona 🤮),
dann schreibe ich dir ausführlich woran das liegt und was zu machen ist.

Beste Grüsse aus BaWü
Alex
Mitglied: MysticFoxDE
MysticFoxDE 25.06.2022 um 08:57:30 Uhr
Goto Top
Moin Patrick,

NIC's 2019er Cluster
Intel(R) Ethernet Server Adapter I350

NIC's 2016er Cluster
Intel(R) Ethernet Connection X722 for 1 GbE

sehr gut, Intel, meine Lieblinge. 😀


Ich werde mich dazu noch einlesen und nochmal meine Consulting Dame Fragen face-smile

Egal was die sagt, schalt das bescheuerte RSC aus, das bringt nur Probleme und wird von deinen NIC's eh nicht unterstützt, weil Intel den RSC Support bei den Treibern für Server 2019, schon vor über einem Jahr, vollständig entfernt hat.

Den Artikel führe ich mir heute zu gemühte face-smile Danke schon mal face-smile

Das ist eigentlich nur einer der kleinen Brüder von diesem hier. 🤪
https://community.spiceworks.com/topic/post/9486432

Und der Letzte Post in diesem, betrifft +- auch dich.

Mal abgesehen vom RSC ist RSS dein zweites Problem.
Die Lastverteilungstechnologie ist erst ab 10G NIC's wichtig und dann muss diese
bei allen NIC auch noch richtig konfiguriert werden. Mit den Standardeinstellungen der Hersteller kannst du diese meistens mehr als nur knicken.

Für dich ist das ganze aber eh egal, weil du nur 1G NIC's hast und somit auf RSS vollkommen pfeifen kannst, da ein modernen Kern alleine schon locker 5-10G wuppen kann.

Sprich, als erstes solltest du RSS (Empfangsseitige Skalierung) auf den physikalischen NIC's und auch auf den vNIC's innerhalb der VM's deaktivieren.




danach sollten diese beiden Werte des vSwitches eigentlich auf 1 gehen.

DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 8

DefaultQueueVmmqQueuePairs : 8
DefaultQueueVmmqQueuePairsRequested : 16

Wenn nicht, dann musst du von Hand etwas nachhelfen.


Und auch die Infos zu den betreffenden vNIC's.



Bei der vNIC sieht von aussen gar nicht so schlecht aus.

VrssMaxQueuePairs : 1

Das einzige was mir hier nicht gefällt ist der "VrssQueueSchedulingMode",
hier sollte eigentlich nicht "Dynamic" stehen, was die gleichzeitige Verwendung von RSS und VMQ ermöglicht sondern "StaticVrss".


Danach sollten deine Datenpakete wieder ohne Verlust durchflutschen.

Beste Grüsse aus BaWü

Alex