38
Inter-VLAN Routing - Router on a Stick - Windows Server 2022
Hallo zusammen,
ich bin seit Tagen auf Fehlersuche, diverse Einträge in diesem Forum und in anderen Foren als auch Beiträgen im Internet haben mir bisher leider nicht die Lösung verschafft.
Ich muss ein (bestehendes) Netzwerk aus einem Segment segmentieren. Dazu habe ich mir eine Testumgebung aufgebaut.
Bei den Systemen die im aktuellen Schritt zu segmentieren sind handelt es sich um virtuelle Maschinen mit Windows Server 2022 auf Hypervisoren mit Windows Server 2022 (Hyper-V).
Bei den Switchen handelt es sich um Switche von Juniper, Modell EX3400.
Bei der Firewall handelt es sich um Sophos XGS 3100.
Der Aufbau den ich bisher durchgeführt habe ist dieser Zeichnung zu entnehmen, ich denke das sagt mehr als tausend Worte:
Ich möchte nun den linken (neuen) Hypervisor in Dunkelblau (10.0.5.203/24) mit der Domäne joinen. Der Domänencontroller ist virtualisiert und befindet sich auf der VM oben rechts in Blaulila (10.0.10.216/24).
Das Hostbetriebssystem zu der VM liegt auf dem Hypervisor rechts in Blau (10.0.5.202/24).
Die Hypervisoren sind in dem Netzwerk 10.0.5.0/24 welches ich auf der Zeichnung CYAN markiert habe und in dem VLAN 5 liegen. Die VMs sind für die Testumgebung in dem Netzwerk 10.0.10.0/24 welches ich GELB markiert habe und in dem VLAN 10 liegen.
Zwischen den Hypervisoren und dem Switch (Juniper EX3400) ist ein VLAN Trunk konfiguriert, die Konfiguration sieht so aus:
Von dem Switch zur Sophos XGS Firewall geht es mit einem LCAP - VLAN Trunk. Auf dem Switch sind die Interfaces zu ae0 zusammengefasst:
Die Sophos XGS ist so konfiguriert:
Damit das die Firewall auch zwischen den beiden Netzen transportiert habe ich eine Testregel angelegt:
Details:
Ich möchte nun einen Ping zum Testen von 10.0.5.203 an die VM 10.0.10.216 senden. Damit der Hypervisor die Route dahin kennt habe ich diese auf dem Hypervisor (DUNKELBLAU) auf der Powershell mit
eine Route dahin gesetzt und in diesem Netzsegment die Sophos (10.0.5.254) angegeben. Achtung, hier ist es wichtig zu wissen das der Hypervisor noch ein zweites Netzwerkinterface hat an dem das Internet / DMZ anliegt. Auf diesem Netzwerkinterface ist auch das Default Gateway (= 172.27.77.1/24) gesetzt.
Der Vollständigkeit halber hier die Routingtabelle des Hypervisors 10.0.5.203:
Ich habe auf allen Systemen aktuell die Windows Firewall für alle Profile (Domäne, Private, Public) ausgestellt.
Sende ich nun von dem Hypervisor der noch nicht in der Domäne ist (DUNKELBLAU 10.0.5.203) einen Ping an die VM 10.0.10.216 kommt keine Antwort zurück. Auf der VM sehe ich allerdings mit Wireshark die eingehenden ICMP Requests:
Auf der Sophos Firewall sehe ich im Packet Capture auch nur diese Richtung:
Soweit also alles stimmig. Nur, warum kommt kein Reply zurück? RDP, Telnet etc. funktioniert ebenso nicht.
Von dem Hypervisor (10.0.5.203/24) kann ich aber die Sophos im anderen Netz auf der 10.0.10.254/24) mit ping erreichen und erhalte eine Antwort.
Ein Traceroute von dem Hypervisor auf die VM sieht so aus, hier abgebrochen da sich nichts mehr ändert:
Ich vermute ich habe nur eine ganze Kleinigkeit vergessen, habe mich nur derart in dem Thema verstrickt das ich es nicht erkenne.
Ich hoffe ihr könnt mir den hilfreichen Hinweis oder die Lösung sagen. Wenn noch andere Informationen etc. notwendig sind kann ich diese nachliefern.
Vielen Dank und beste Grüße!
ich bin seit Tagen auf Fehlersuche, diverse Einträge in diesem Forum und in anderen Foren als auch Beiträgen im Internet haben mir bisher leider nicht die Lösung verschafft.
Ich muss ein (bestehendes) Netzwerk aus einem Segment segmentieren. Dazu habe ich mir eine Testumgebung aufgebaut.
Bei den Systemen die im aktuellen Schritt zu segmentieren sind handelt es sich um virtuelle Maschinen mit Windows Server 2022 auf Hypervisoren mit Windows Server 2022 (Hyper-V).
Bei den Switchen handelt es sich um Switche von Juniper, Modell EX3400.
Bei der Firewall handelt es sich um Sophos XGS 3100.
Der Aufbau den ich bisher durchgeführt habe ist dieser Zeichnung zu entnehmen, ich denke das sagt mehr als tausend Worte:
Ich möchte nun den linken (neuen) Hypervisor in Dunkelblau (10.0.5.203/24) mit der Domäne joinen. Der Domänencontroller ist virtualisiert und befindet sich auf der VM oben rechts in Blaulila (10.0.10.216/24).
Das Hostbetriebssystem zu der VM liegt auf dem Hypervisor rechts in Blau (10.0.5.202/24).
Die Hypervisoren sind in dem Netzwerk 10.0.5.0/24 welches ich auf der Zeichnung CYAN markiert habe und in dem VLAN 5 liegen. Die VMs sind für die Testumgebung in dem Netzwerk 10.0.10.0/24 welches ich GELB markiert habe und in dem VLAN 10 liegen.
Zwischen den Hypervisoren und dem Switch (Juniper EX3400) ist ein VLAN Trunk konfiguriert, die Konfiguration sieht so aus:
show interfaces xe-0/2/0
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ 5 10 ];
}
storm-control default;
}
}show interfaces xe-1/2/0
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ 5 10 ];
}
storm-control default;
}
}show interfaces xe-0/2/2
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ 5 10 ];
}
storm-control default;
}
}Von dem Switch zur Sophos XGS Firewall geht es mit einem LCAP - VLAN Trunk. Auf dem Switch sind die Interfaces zu ae0 zusammengefasst:
show interfaces ae0
vlan-tagging;
aggregated-ether-options {
lacp {
active;
}
}
unit 0 {
family ethernet-switching {
interface-mode trunk;
vlan {
members [ 5 10 ];
}
}
}show interfaces ge-0/0/0
ether-options {
802.3ad ae0;
}show interfaces ge-0/0/1
ether-options {
802.3ad ae0;
}show interfaces ge-0/0/2
ether-options {
802.3ad ae0;
}show interfaces ge-0/0/3
ether-options {
802.3ad ae0;
}show interfaces ge-1/0/0
ether-options {
802.3ad ae0;
}show interfaces ge-1/0/1
ether-options {
802.3ad ae0;
}show interfaces ge-1/0/2
ether-options {
802.3ad ae0;
}show interfaces ge-1/0/3
ether-options {
802.3ad ae0;
}Die Sophos XGS ist so konfiguriert:
Damit das die Firewall auch zwischen den beiden Netzen transportiert habe ich eine Testregel angelegt:
Details:
Ich möchte nun einen Ping zum Testen von 10.0.5.203 an die VM 10.0.10.216 senden. Damit der Hypervisor die Route dahin kennt habe ich diese auf dem Hypervisor (DUNKELBLAU) auf der Powershell mit
New-NetRoute -DestinationPrefix "10.0.10.0/24"-InterfaceIndex 26 -NextHop 10.0.5.254 eine Route dahin gesetzt und in diesem Netzsegment die Sophos (10.0.5.254) angegeben. Achtung, hier ist es wichtig zu wissen das der Hypervisor noch ein zweites Netzwerkinterface hat an dem das Internet / DMZ anliegt. Auf diesem Netzwerkinterface ist auch das Default Gateway (= 172.27.77.1/24) gesetzt.
Der Vollständigkeit halber hier die Routingtabelle des Hypervisors 10.0.5.203:
Ich habe auf allen Systemen aktuell die Windows Firewall für alle Profile (Domäne, Private, Public) ausgestellt.
Sende ich nun von dem Hypervisor der noch nicht in der Domäne ist (DUNKELBLAU 10.0.5.203) einen Ping an die VM 10.0.10.216 kommt keine Antwort zurück. Auf der VM sehe ich allerdings mit Wireshark die eingehenden ICMP Requests:
Auf der Sophos Firewall sehe ich im Packet Capture auch nur diese Richtung:
Soweit also alles stimmig. Nur, warum kommt kein Reply zurück? RDP, Telnet etc. funktioniert ebenso nicht.
Von dem Hypervisor (10.0.5.203/24) kann ich aber die Sophos im anderen Netz auf der 10.0.10.254/24) mit ping erreichen und erhalte eine Antwort.
Ein Traceroute von dem Hypervisor auf die VM sieht so aus, hier abgebrochen da sich nichts mehr ändert:
Ich vermute ich habe nur eine ganze Kleinigkeit vergessen, habe mich nur derart in dem Thema verstrickt das ich es nicht erkenne.
Ich hoffe ihr könnt mir den hilfreichen Hinweis oder die Lösung sagen. Wenn noch andere Informationen etc. notwendig sind kann ich diese nachliefern.
Vielen Dank und beste Grüße!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671706
Url: https://administrator.de/forum/inter-vlan-routing-router-on-a-stick-windows-server-2022-671706.html
Ausgedruckt am: 05.04.2025 um 12:04 Uhr
38 Kommentare
Neuester Kommentar
Moin @Pagra37,
lösche bitte die obere Route wieder raus und mach lieber die hier rein.
😉
Gruss Alex
Ich möchte nun einen Ping zum Testen von 10.0.5.203 an die VM 10.0.10.216 senden. Damit der Hypervisor die Route dahin kennt habe ich diese auf dem Hypervisor (DUNKELBLAU) auf der Powershell mit
eine Route dahin gesetzt und in diesem Netzsegment die Sophos (10.0.5.254) angegeben. Achtung, hier ist es wichtig zu wissen das der Hypervisor noch ein zweites Netzwerkinterface hat an dem das Internet / DMZ anliegt. Auf diesem Netzwerkinterface ist auch das Default Gateway (= 172.27.77.1/24) gesetzt.
New-NetRoute -DestinationPrefix "10.0.10.0/24"-InterfaceIndex 26 -NextHop 10.0.5.254 eine Route dahin gesetzt und in diesem Netzsegment die Sophos (10.0.5.254) angegeben. Achtung, hier ist es wichtig zu wissen das der Hypervisor noch ein zweites Netzwerkinterface hat an dem das Internet / DMZ anliegt. Auf diesem Netzwerkinterface ist auch das Default Gateway (= 172.27.77.1/24) gesetzt.
lösche bitte die obere Route wieder raus und mach lieber die hier rein.
New-NetRoute -DestinationPrefix "10.0.10.0/24"-InterfaceIndex 26 -NextHop 10.0.10.254 Gruss Alex
Hallo Alex,
besten Dank für die Anregung, das funktioniert jedoch nicht, wie auch, woher soll das System jetzt wissen wo es 10.0.10.0/24 zu finden hat. Es wird es wie erwartet dann an das Default Gateway (172.27.77.1./24) senden was es nicht kennt und dann weiter Richtung Internet was es schon längst nicht kennt:
Ich vermute aber es ist wirklich ein ganz triviales Routingproblem...
Gruß
besten Dank für die Anregung, das funktioniert jedoch nicht, wie auch, woher soll das System jetzt wissen wo es 10.0.10.0/24 zu finden hat. Es wird es wie erwartet dann an das Default Gateway (172.27.77.1./24) senden was es nicht kennt und dann weiter Richtung Internet was es schon längst nicht kennt:
Ich vermute aber es ist wirklich ein ganz triviales Routingproblem...
Gruß
Hey Servus,
überprüfe auf den HyperV Hosts die SET Switches.
Das NIC Team muss ein Trunk sein. Die vNICS musst du dann mit entsprechender Vlan-ID anlegen und der VM zuweisen.
Edit:
Noch ein Tipp. Nutze für die Konfiguration nicht den HyperV Manager.
Mach das über die Powershell.
Erst SET Switch erstellen:
Überprüfen:
LoadBalancing Modus auf: Dynamic stellen:
So, jetzt erstellst du den ersten virtuellen Adapter für das Management:
Dann den zweiten virtuellen Adapter für die VM:
Den zweiten Adapter kannst du dan deiner VM zuweisen. Entweder im HyperV Manager oder mit Powershell.
Fertig!
P.S
Wenn deine Sophos das VLAN Routing macht, werden eigentlich keine Routen benötigt. Du musst nur an jedem Host und jeder VM das richtige Gateway eintragen.
Und natürlich auf der Sophos die ACL erstellen, so das die VLAN's untereinander kommunizieren dürfen. Sieht auf deinen Bildern aber so aus, als wäre das schon richtig eingerichtet.
überprüfe auf den HyperV Hosts die SET Switches.
Das NIC Team muss ein Trunk sein. Die vNICS musst du dann mit entsprechender Vlan-ID anlegen und der VM zuweisen.
Edit:
Noch ein Tipp. Nutze für die Konfiguration nicht den HyperV Manager.
Mach das über die Powershell.
Erst SET Switch erstellen:
New-VMSwitch -Name "SET-Switch-01" -NetAdapterName "Embedded FlexibleLOM 1 port 3","Embedded FlexibleLOM 1 port 4" -AllowManagementOS $True Überprüfen:
Get-VMSwitchTeam -Name "SET-Switch-01" | FL LoadBalancing Modus auf: Dynamic stellen:
Set-VMSwitchTeam -Name "SET-Switch-01" -LoadBalancingAlgorithm Dynamic So, jetzt erstellst du den ersten virtuellen Adapter für das Management:
Add-VMNetworkAdapter -ManagementOS -Name "VLAN101" -SwitchName "SET-Switch-01"
Set-VMNetworkAdapterVLAN -VMNetworkAdapterName "VLAN101" -vlanid 101 -Access -ManagementOS Dann den zweiten virtuellen Adapter für die VM:
Add-VMNetworkAdapter -Name "VLAN102" -SwitchName "SET-Switch-01"
Set-VMNetworkAdapterVLAN -VMNetworkAdapterName "VLAN102" -vlanid 102 -Access Den zweiten Adapter kannst du dan deiner VM zuweisen. Entweder im HyperV Manager oder mit Powershell.
Add-VMNetworkAdapter -VMName DC-01 -Name "VLAN102" Fertig!
P.S
Wenn deine Sophos das VLAN Routing macht, werden eigentlich keine Routen benötigt. Du musst nur an jedem Host und jeder VM das richtige Gateway eintragen.
Und natürlich auf der Sophos die ACL erstellen, so das die VLAN's untereinander kommunizieren dürfen. Sieht auf deinen Bildern aber so aus, als wäre das schon richtig eingerichtet.
Das hier habe ich auf dem rechten Hypervisor:
Das hier ist auf dem linken Hypervisor:
(sorry für Bild, ich kann über die Konsole kein Text rauskopieren)
Auf dem linken Hypervisor habe ich kein Team Interface da nur eine LWL auf den Switch geht und dieses System auch nicht die Bandbreite und Zuverlässigkeit benötigen wird.
Wahrscheinlich ist hier das Problem zu suchen. Ich habe mir vor zwei Jahren schon mit dem "neuen" SETswitches die Finger gebrochen und wahrscheinlich ist das so gar nicht richtig... Ich sehe es nur einfach nicht.
PS C:\Windows\system32> Get-VMSwitchTeam -SwitchName SETswitch | FL
Name : SETswitch
Id : 38b9bfa1-0c70-466d-a285-f5965edfc7dc
NetAdapterInterfaceDescription : {Broadcom NetXtreme E-Series Advanced Dual-port 10Gb SFP+ Ethernet OCP 3.0 Adapter,
Broadcom NetXtreme E-Series Advanced Dual-port 10Gb SFP+ Ethernet OCP 3.0 Adapter #2}
NetAdapterInterfaceGuid : {6b45d58b-96a7-4bc2-ad96-b89cec6efedb, f47abaf8-45a6-4f30-be07-1784b748bead}
TeamingMode : SwitchIndependent
LoadBalancingAlgorithm : Dynamic
PS C:\Windows\system32> Get-VMNetworkAdapter -VMName VM16
Name IsManagementOs VMName SwitchName MacAddress Status IPAddresses
---- -------------- ------ ---------- ---------- ------ -----------
server-10 False VM16 SETswitch xxxxx {Ok} {10.0.10.216, fe80::3d...
PS C:\Windows\system32> Get-VMNetworkAdapterVlan -VMName VM16
VMName VMNetworkAdapterName Mode VlanList
------ -------------------- ---- --------
VM16 server-10 Access 10
PS C:\Windows\system32>
PS C:\Windows\system32> Get-VMNetworkAdapterVlan -ManagementOS
VMName VMNetworkAdapterName Mode VlanList
------ -------------------- ---- --------
server-5 Access 5
SETswitch UntaggedDas hier ist auf dem linken Hypervisor:
(sorry für Bild, ich kann über die Konsole kein Text rauskopieren)
Auf dem linken Hypervisor habe ich kein Team Interface da nur eine LWL auf den Switch geht und dieses System auch nicht die Bandbreite und Zuverlässigkeit benötigen wird.
Wahrscheinlich ist hier das Problem zu suchen. Ich habe mir vor zwei Jahren schon mit dem "neuen" SETswitches die Finger gebrochen und wahrscheinlich ist das so gar nicht richtig... Ich sehe es nur einfach nicht.
Ich würde sagen das dein SET Switch im falschen Modus ist.
"Untagged"
Er müsste auf "Trunk" stehen.
"Untagged"
Er müsste auf "Trunk" stehen.
Du musst deinen vSwitch so einstellen, das er VLAN Tagging unterstützt.
-EnableEmbeddedTeaming $true → Stellt sicher, dass der Switch VLAN-Tagging unterstützt.
Set-VMSwitch -Name "SET-Switch-01" -EnableEmbeddedTeaming $true -EnableEmbeddedTeaming $true → Stellt sicher, dass der Switch VLAN-Tagging unterstützt.
Ok, ich meine damals hang es auch an genau dieser Stelle. Der SETswitch ist ja der vom Hypervisor. Wie kann ich den von Untagged auf Trunk umstellen? Der Befehl hier scheitert:
Das geht alles immer nur nicht für das Managementos. Was ist hier der korrekte Befehl oder wo ist mein Gedankenfehler?
Das "EnableEmbeddedTeaming" ist auf dem einem Hypervisor wo das Teaming an ist bereits schon auf true.
Das geht alles immer nur nicht für das Managementos. Was ist hier der korrekte Befehl oder wo ist mein Gedankenfehler?
Das "EnableEmbeddedTeaming" ist auf dem einem Hypervisor wo das Teaming an ist bereits schon auf true.
Sorry für die Verwirrung.
Den SET Switch selbst in den "TRUNK" Modus setzten geht nicht.
Poste bitte mal die Ausgabe von:
Egal von welchem Host. Am besten von beiden.
Den SET Switch selbst in den "TRUNK" Modus setzten geht nicht.
Poste bitte mal die Ausgabe von:
Get-VMSwitch -Name "DeinSETswitch" | fl * Egal von welchem Host. Am besten von beiden.
Wenn deine Sophos das VLAN Routing macht, werden eigentlich keine Routen benötigt. Du musst nur an jedem Host und jeder VM das richtige Gateway eintragen.
Da genau ist das Problem! An jedem Host und jeder VM muss das richtige Gateway eingetragen werden. Ich hatte es nur auf dem Hypervisor jedoch nicht auf der VM eingetragen. Jetzt ist es in der VM mit
New-NetRoute -DestinationPrefix "10.77.5.0/24" -InterfaceIndex 25 -NextHop 10.77.10.254 eingetragen und es geht mit dem Ping in beide Richtungen!
Jedoch weiter gesponnen: Gerade geht es "nur" um die Server, physikalisch und VMs. Jedoch kommen auch die Clients noch mit der Segmentierung in "viele" VLANs dran.
Wie ist denn hier die Best-Practise um allen Clients immer den gesamten Umgebung das Routing für alle VLANs die sie betreffen mitzugeben? Das kann doch unmöglich mit einem Skript auf allen Clients "manuell" angewendet werden müssen? Vor allem wenn ich gerade an Notebooks denke die "draußen" auch mal durch solche Routen-Settings Probleme in anderen LANs/WLANs bekommen könnten.
Oder wird das doch auf der Firewall (Router, Sophos) gemacht um das zu vermeiden?
Gruß
Der rechte Hypervisor:
Der linke Hypervisor:
PS C:\Windows\system32> Get-VMSwitch -Name "SETswitch" | FL *
DefaultQueueVmmqQueuePairs : 0
DefaultQueueVmmqQueuePairsRequested : 16
Name : SETswitch
Id : 38b9bfa1-0c70-466d-a285-f5965edfc7dc
Notes :
Extensions : {Microsoft Windows Filtering Platform, Microsoft NDIS Capture}
BandwidthReservationMode : Absolute
PacketDirectEnabled : False
EmbeddedTeamingEnabled : True
AllowNetLbfoTeams : False
IovEnabled : False
SwitchType : External
AllowManagementOS : True
NetAdapterInterfaceDescription : Teamed-Interface
NetAdapterInterfaceDescriptions : {Broadcom NetXtreme E-Series Advanced Dual-port 10Gb SFP+ Ethernet
OCP 3.0 Adapter, Broadcom NetXtreme E-Series Advanced Dual-port
10Gb SFP+ Ethernet OCP 3.0 Adapter #2}
NetAdapterInterfaceGuid : {6b45d58b-96a7-4bc2-ad96-b89cec6efedb,
f47abaf8-45a6-4f30-be07-1784b748bead}
IovSupport : False
IovSupportReasons : {This network adapter does not support SR-IOV.}
AvailableIPSecSA : 0
NumberIPSecSAAllocated : 0
AvailableVMQueues : 0
NumberVmqAllocated : 0
IovQueuePairCount : 0
IovQueuePairsInUse : 0
IovVirtualFunctionCount : 0
IovVirtualFunctionsInUse : 0
PacketDirectInUse : False
DefaultQueueVrssEnabledRequested : True
DefaultQueueVrssEnabled : False
DefaultQueueVmmqEnabledRequested : True
DefaultQueueVmmqEnabled : False
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 0
DefaultQueueVrssMinQueuePairsRequested : 1
DefaultQueueVrssMinQueuePairs : 0
DefaultQueueVrssQueueSchedulingModeRequested : StaticVrss
DefaultQueueVrssQueueSchedulingMode : Dynamic
DefaultQueueVrssExcludePrimaryProcessorRequested : False
DefaultQueueVrssExcludePrimaryProcessor : False
SoftwareRscEnabled : False
RscOffloadEnabled : False
BandwidthPercentage : 10
DefaultFlowMinimumBandwidthAbsolute : 2000000000
DefaultFlowMinimumBandwidthWeight : 0
CimSession : CimSession: .
ComputerName : HV-202
IsDeleted : FalseDer linke Hypervisor:
Warum hast du das mit einer Netz Route umgesetzt und nicht mit dem standard Gateway?
Im linken Host ist "EmbeddedTeaming" aus!!
Im linken Host ist "EmbeddedTeaming" aus!!
Warum hast du das mit einer Netz Route umgesetzt und nicht mit dem standard Gateway?
Die VM wird noch in andere VLANs gehangen. Welcher virtuelle Adapter sollte denn dann das Standard Gateway erhalten?
Im linken Host ist "EmbeddedTeaming" aus!!
Ja, es ist kein Team Interface, dementsprechend gibt es den Befehl nicht. Oder muss ich da irgendwas noch machen?
Wenn die VM auch noch in andere Vlan's muss, dann braucht sie das standard Gateway.
Ich denke dass das die IP der Sophos für das entsprechende VLan ist.
Wenn die anderen VLan's die du mit der VM erreichen möchtest auch von der Sophos
geroutet werden, dann bedarf es nur einem standard Gateway auf der VM, da deine Sophos ja die Vlan's kennst und routet.
Um einen SET Switch zu erstellen muss nicht zwingend ein NIC Team erstellt werden. Das geht auch mit einer einzelnen NIC. Du kannst auch mit nur einer NIC den SET Switch mit
erstellen und nutzen.
Wenn du mit einer vNIC mehrere Vlan's erreichen möchstest, dann musst du die vNIC so erstellen
Es sollte aber reichen wenn du eine vNIC erstellst und diese in das Vlan deiner Wahl als Access setzt. Das Routing in andere Vlan's sollte dann deine Sophos erledigen. Entsprechende ACL vorausgesetzt
.
Ich denke dass das die IP der Sophos für das entsprechende VLan ist.
Wenn die anderen VLan's die du mit der VM erreichen möchtest auch von der Sophos
geroutet werden, dann bedarf es nur einem standard Gateway auf der VM, da deine Sophos ja die Vlan's kennst und routet.
Um einen SET Switch zu erstellen muss nicht zwingend ein NIC Team erstellt werden. Das geht auch mit einer einzelnen NIC. Du kannst auch mit nur einer NIC den SET Switch mit
New-VMSwitch -Name "SET-Switch" -NetAdapterName "Ethernet1" -EnableEmbeddedTeaming $true -AllowManagementOS $false Wenn du mit einer vNIC mehrere Vlan's erreichen möchstest, dann musst du die vNIC so erstellen
Add-VMNetworkAdapter -VMName "MeineVM" -SwitchName "SET-Switch" -Name "VMNIC-VLAN20"
Set-VMNetworkAdapterVlan -VMName "MeineVM" -Trunk -AllowedVlanIdList "10,20" -NativeVlanId 1 Es sollte aber reichen wenn du eine vNIC erstellst und diese in das Vlan deiner Wahl als Access setzt. Das Routing in andere Vlan's sollte dann deine Sophos erledigen. Entsprechende ACL vorausgesetzt
.
Moin @Pagra37,
doch, das ist schon richtig, denn der nächste Hop aus dem 10.0.5.203/24 zu dem 10.0.10.0/24 Netz, ist laut deiner bisherigen Beschreibung die Schnittstelle/IP der Sophos aus dem entsprechenden Quell-Netz und das ist die 10.0.5.254. 😉
Kannst du den die 10.0.5.254 von dem entsprechenden HV pingen?
Gruss Alex
P.S. Hast du auf dem HV und der VM auch schon testweise die Windows-FireWall deaktiviert?
Die pfuscht bei solchen Dingen auch sehr gerne dazwischen. 🙃
besten Dank für die Anregung, das funktioniert jedoch nicht, wie auch, woher soll das System jetzt wissen wo es 10.0.10.0/24 zu finden hat. Es wird es wie erwartet dann an das Default Gateway (172.27.77.1./24) senden was es nicht kennt und dann weiter Richtung Internet was es schon längst nicht kennt:
doch, das ist schon richtig, denn der nächste Hop aus dem 10.0.5.203/24 zu dem 10.0.10.0/24 Netz, ist laut deiner bisherigen Beschreibung die Schnittstelle/IP der Sophos aus dem entsprechenden Quell-Netz und das ist die 10.0.5.254. 😉
Kannst du den die 10.0.5.254 von dem entsprechenden HV pingen?
Gruss Alex
P.S. Hast du auf dem HV und der VM auch schon testweise die Windows-FireWall deaktiviert?
Die pfuscht bei solchen Dingen auch sehr gerne dazwischen. 🙃
Es sollte aber reichen wenn du eine vNIC erstellst und diese in das Vlan deiner Wahl als Access setzt. Das Routing in andere Vlan's sollte dann deine Sophos erledigen. Entsprechende ACL vorausgesetzt
Genau das war das wirklich kleine Problem was ich überhaupt nicht beachtet hatte! Da die VM eine VM aus der Produktivumgebung ist in der noch nichts segmentiert ist war natürlich dennoch ein Default Gateway gesetzt. Das hatte ich nicht bedacht und dann ist alles dahin zurückgesendet worden und die neue Sophos hat das nicht mitbekommen können!
Default Gateway (erstmal testweise bis Migration stattfinden kann) aus dem "alten" Adapter raus und auf den neuen server-5 als Gateway die Sophos (10.0.10.254/24) und siehe an, es funktioniert!
Dementsprechend bekommen natürlich alle VMs und auch Clients (PC/Laptop) die Sophos via DHCP als Default Gateway und dann funktioniert das auch. Lediglich die Hypervisoren werden mit der zweiten Route mit New-NetRoute konfiguriert da diese einmal das Default Gateway Richtung Router Internet haben und zusätzlich die Sophos für das interne, segmentierte Netzwerk.
Macht man das denn so herum, also das das Default Gateway auf dem Adapter nach dem Internet gesetzt wird und mit Add-NetRoute das Gateway für intern oder eher anders herum die Sophos als Default Gateway und eine 0.0.0.0/0 auf den Internetrouter?
Danke für die gelungene Unterstüzung!!!
Gruß
Schön das es jetzt funktioniert.
Zu deiner Frage: Ich würde sagen, Nein, das macht man nicht so.
Wenn deine Sophos die Tür für das Internet und die Tür für die anderen Vlan's ist,
dann brauchst du auf den VM's und den Hosts nur das default Gateway.
Deine Sophos kennt die Wege ins Internet und in die anderen Vlans's schon.
Du musst die Wege also nicht auch noch den Hosts und VM's extra für jedes Netz angeben. Das regelt dann das default Gateway.
Liebe Grüße
Üba3ba
Zu deiner Frage: Ich würde sagen, Nein, das macht man nicht so.
Wenn deine Sophos die Tür für das Internet und die Tür für die anderen Vlan's ist,
dann brauchst du auf den VM's und den Hosts nur das default Gateway.
Deine Sophos kennt die Wege ins Internet und in die anderen Vlans's schon.
Du musst die Wege also nicht auch noch den Hosts und VM's extra für jedes Netz angeben. Das regelt dann das default Gateway.
Liebe Grüße
Üba3ba
Wenn deine Sophos die Tür für das Internet und die Tür für die anderen Vlan's ist,
dann brauchst du auf den VM's und den Hosts nur das default Gateway.
dann brauchst du auf den VM's und den Hosts nur das default Gateway.
Ja, dann wäre es klar. Die Sophos ist jedoch nur für die Netzwerksegmentierung da und nicht für den Weg ins Internet. Das macht eine andere Firewall. Wie macht man es dann?
OK. Danke für die Klarstellung.
Wenn die eine Sophos nur das Vlan Routing macht und eine andere das Gateway ins Internet ist, würde ich es so machen.
Um ins Internet zu kommen würde ich das default Gateway auf die FW stellen, die den Weg ins Internet kennt.
Um in die anderen Vlan's zu kommen, würde ich dann statische Routen einrichten.
Andersrum kannst du es auch machen.
Default Gateway für das Vlan Routing und statische Route für den Internet Zugang.
Bleibt dir überlassen wie du das machst.
Funktionieren tut beides.
Wenn beide Firewalls an L3 Interfaces eines Switch hängen, kannst du auch auf einer Firewall die Route, entwender ins Internet oder zu den anderen Vlan's einrichten. Dann brauchst du auf den Clients, Hosts und VM's nur das default GW.
Wenn die eine Sophos nur das Vlan Routing macht und eine andere das Gateway ins Internet ist, würde ich es so machen.
Um ins Internet zu kommen würde ich das default Gateway auf die FW stellen, die den Weg ins Internet kennt.
Um in die anderen Vlan's zu kommen, würde ich dann statische Routen einrichten.
Andersrum kannst du es auch machen.
Default Gateway für das Vlan Routing und statische Route für den Internet Zugang.
Bleibt dir überlassen wie du das machst.
Funktionieren tut beides.
Wenn beide Firewalls an L3 Interfaces eines Switch hängen, kannst du auch auf einer Firewall die Route, entwender ins Internet oder zu den anderen Vlan's einrichten. Dann brauchst du auf den Clients, Hosts und VM's nur das default GW.
Wenn beide Firewalls an L3 Interfaces eines Switch hängen, kannst du auch auf einer Firewall die Route, entwender ins Internet oder zu den anderen Vlan's einrichten. Dann brauchst du auf den Clients, Hosts und VM's nur das default GW.
Ja, das wäre meine bevorzugte Option. Leider möchte unser ISB das DMZ und Intranet über getrennte Switche laufen (komplette physikalische Trennung) und das nicht nur auf Layer 2 getrennt haben. Daher geht das so leider nicht.
Ich werde es machen wie dein Vorschlag 1, so habe ich es auch intuitiv gemacht.
DANKE!
Moin @Pagra37,
wenn du den Internetverkehr über eine andere FW händelst, dann route die entsprechenden Anfragen doch einfach über die Sophos an diese weiter, dann musst du auch an den Servern keine zusätlichen Routen händeln. 😉
Gruss Alex
Das macht eine andere Firewall. Wie macht man es dann?
wenn du den Internetverkehr über eine andere FW händelst, dann route die entsprechenden Anfragen doch einfach über die Sophos an diese weiter, dann musst du auch an den Servern keine zusätlichen Routen händeln. 😉
Gruss Alex
Moin @Ueba3ba,
ja, ein SET-Team funktioniert auch nur mit einem Uplink Port.
Jedoch würde ich davon absolut abraten, denn sobald man einen SET Switch konfiguriert, funktioniert VMQ, welches übrigens per Default auf jeder vNIC activiert ist, nicht mehr wirklich so wie es sollte. 😭
Achte einfach mal auf die "AvailableVMQueues" bei einem vSwitch mit SET und vergleiche mal den Wert mit einem vSwitch ohne SET. 😉
Und auch SR-IOV ist bei einem SET-Switch nur mit Vorsicht zu geniessen, daher verwenden wir bei unseren Kunden nach möglichkeit kein SET und auch kein LBFO, weil man ohne VMQ oder SR-IOV, selbst eine 10G NIC, nicht wirklich ausgelastet bekommt.
Gruss Alex
Um einen SET Switch zu erstellen muss nicht zwingend ein NIC Team erstellt werden. Das geht auch mit einer einzelnen NIC. Du kannst auch mit nur einer NIC den SET Switch mit
erstellen und nutzen.
New-VMSwitch -Name "SET-Switch" -NetAdapterName "Ethernet1" -EnableEmbeddedTeaming $true -AllowManagementOS $false ja, ein SET-Team funktioniert auch nur mit einem Uplink Port.
Jedoch würde ich davon absolut abraten, denn sobald man einen SET Switch konfiguriert, funktioniert VMQ, welches übrigens per Default auf jeder vNIC activiert ist, nicht mehr wirklich so wie es sollte. 😭
Achte einfach mal auf die "AvailableVMQueues" bei einem vSwitch mit SET und vergleiche mal den Wert mit einem vSwitch ohne SET. 😉
Und auch SR-IOV ist bei einem SET-Switch nur mit Vorsicht zu geniessen, daher verwenden wir bei unseren Kunden nach möglichkeit kein SET und auch kein LBFO, weil man ohne VMQ oder SR-IOV, selbst eine 10G NIC, nicht wirklich ausgelastet bekommt.
Gruss Alex
Moin @Ueba3ba,
folgend ein paar wichtige Ergänzungen zu deinen Vorschlägen.
Den "LoadBalancingAlgorithm" muss man nicht extra auf "Dynamic" stellen, das ist schon per Default so.
Jedoch sollte man nei Uplink NIC's mit >= 10G, eher den "LoadBalancingAlgorithm" auf "HyperVPort" stellen.
Ich habe diese Info mal irgendwann in einer offiziellen MS Doku gelesen, finde diese jetzt auf die Schnelle jedoch nicht wieder.
In der folgenden, externen, wird das aber auch explizit erwähnt.
https://charbelnemnom.com/deploying-switch-embedded-teaming-set-on-hyper ...
Sprich, der TO sollte bei seinen vSwitchen die an 10G, respektive 25G NIC's dran hängen, eher das folgende ausführen.
Ferner sollte der vSwitch nach dem Erstellen noch unbedingt etwas optimiert werden, sprich ...
10G Uplink:
Hyper-V 2019 bis 2022:
Hyper-V 2025:
25G Uplink:
Hyper-V 2019 bis 2022:
Hyper-V 2025:
Zudem sollte auf den Uplink-NIC’s und zwar am besten vor dem Erstellen des vSwitches, noch mindestens das folgende optimiert werden …
10G:
25G:
Zu dem elenden Thema RSC kannst du genug bei Googel finden und was das Thema „MaxProcessors“ & Co angeht, das werde im Zusammenhang mit einem Post vom TO etwas näher erläutern.
Gruss Alex
folgend ein paar wichtige Ergänzungen zu deinen Vorschlägen.
LoadBalancing Modus auf: Dynamic stellen:
Set-VMSwitchTeam -Name "SET-Switch-01" -LoadBalancingAlgorithm Dynamic Den "LoadBalancingAlgorithm" muss man nicht extra auf "Dynamic" stellen, das ist schon per Default so.
Jedoch sollte man nei Uplink NIC's mit >= 10G, eher den "LoadBalancingAlgorithm" auf "HyperVPort" stellen.
Ich habe diese Info mal irgendwann in einer offiziellen MS Doku gelesen, finde diese jetzt auf die Schnelle jedoch nicht wieder.
In der folgenden, externen, wird das aber auch explizit erwähnt.
https://charbelnemnom.com/deploying-switch-embedded-teaming-set-on-hyper ...
Sprich, der TO sollte bei seinen vSwitchen die an 10G, respektive 25G NIC's dran hängen, eher das folgende ausführen.
Set-VMSwitchTeam -Name "SET-Switch-01" -LoadBalancingAlgorithm HyperVPort Ferner sollte der vSwitch nach dem Erstellen noch unbedingt etwas optimiert werden, sprich ...
10G Uplink:
Hyper-V 2019 bis 2022:
Set-VMSwitch -Name "SWITCH-01" -EnableSoftwareRsc $false -DefaultQueueVrssMaxQueuePairs 2 Set-VMSwitch -Name "X710" -EnableSoftwareRsc $false -EnableRscOffload $false -DefaultQueueVrssMaxQueuePairs 2 25G Uplink:
Hyper-V 2019 bis 2022:
Set-VMSwitch -Name "SWITCH-01" -EnableSoftwareRsc $false -DefaultQueueVrssMaxQueuePairs 4 Set-VMSwitch -Name "X710" -EnableSoftwareRsc $false -EnableRscOffload $false -DefaultQueueVrssMaxQueuePairs 4 Zudem sollte auf den Uplink-NIC’s und zwar am besten vor dem Erstellen des vSwitches, noch mindestens das folgende optimiert werden …
10G:
Set-NetAdapterRss -Name "10G-NIC" -MaxProcessors 2 -NumberOfReceiveQueues 2
Set-NetAdapterVmq -Name "10G-NIC" -MaxProcessors 2 25G:
Set-NetAdapterRss -Name "10G-NIC" -MaxProcessors 4 -NumberOfReceiveQueues 4
Set-NetAdapterVmq -Name "10G-NIC" -MaxProcessors 4 Zu dem elenden Thema RSC kannst du genug bei Googel finden und was das Thema „MaxProcessors“ & Co angeht, das werde im Zusammenhang mit einem Post vom TO etwas näher erläutern.
Gruss Alex
Moin @Pagra37,
ich habe Gestern leider so gut wie überhaupt keine Zeit gehabt, daher habe ich die Beiträge auch eher flüchtig gelesen und auch geschrieben. 🙃
Heute habe ich mir etwas mehr Zeit genommen und habe dabei ein Paar Dinge festgestellt, die mit deinem ursprünglichen Problem zwar nichts direkt zu tun haben, jedoch dennoch nicht wirklich korrekt sind.
Zuerst mal zu deinem rechten Hypervisor.
…
… diese Stelle besagt, dass dein vSwitch nicht mit VMQ läuft …
… und auch nicht mit SR-IOV.
Ohne VMQ oder SR-IOV, kannst du jedoch noch nicht mal die Performance einer 10G NIC ansatzweise auslutschen, geschweige denn einer noch schnelleren Uplink NIC.
… zudem schein SR-IOV, Hardwareseitig (Mainboard BIOS & NIC BIOS) auf diesem System überhaupt nicht aktiviert zu sein, denn die 10G Broadcom-NIC’s supporten grundsätzlich schon VMQ & SR-IOV …
Und auch die folgenden Punkte zeugen davon, …
... dass weder, VMQ noch SR-IOV noch VRSS seitens der entsprechenden Uplink-NIC’s verfügbar sind.
Was bedeutet, dass jedes Ethernet-Packet, beim Transport von der VM zu einer andern VM und insbesondere ausserhalb des HV’s, mehrfach per Software angefasst werden muss, da das ganze SDN (vSwitch & vNIC’s) ohne VMQ oder SR-IOV komplett in Software läuft, wodurch ein um ein mehrfaches höherer CPU und auch RAM-Overhead entsteht, als bei einem Transport mit VMQ oder SR-IOV oder gar ganz ohne Virtualisierung.
Zudem läuft der vSwitch bei dir so nur auf dem Kern 0, was seine Leistung eh sehr deutlich reduziert. 😔
Mach dir wegen der Fehlkonfiguration jetzt aber keinen Kopf, denn diesen Mist habe primär die Hersteller mit ihrer absolut bescheidenen Default-Konfig und den meist absolut be💩nen Dokus (falls überhaupt vorhanden) zu verantworten. 😉
😮 … was ist das denn …
… das ist aber ganz sicher nicht Default ...👍 sehr gut so. 😁
Sprich, bei dem rechten HV solltest du als nächstes mal prüfen, weshalb auf diesem kein VMQ und auch SR-IOV verfügbar ist. Vor allem das selbst VMQ nicht verfügbar ist, ist schon sehr sehr komisch.
Zu dem linken komme ich gleich auch noch, muss jedoch vorher mal den alten Kaffee entsorgen und auch gleich einen neuen holen. 🙃
Gruss Alex
ich habe Gestern leider so gut wie überhaupt keine Zeit gehabt, daher habe ich die Beiträge auch eher flüchtig gelesen und auch geschrieben. 🙃
Heute habe ich mir etwas mehr Zeit genommen und habe dabei ein Paar Dinge festgestellt, die mit deinem ursprünglichen Problem zwar nichts direkt zu tun haben, jedoch dennoch nicht wirklich korrekt sind.
Zuerst mal zu deinem rechten Hypervisor.
PS C:\Windows\system32> Get-VMSwitch -Name "SETswitch" | FL * DefaultQueueVmmqQueuePairs : 0… diese Stelle besagt, dass dein vSwitch nicht mit VMQ läuft …
IovEnabled : False… und auch nicht mit SR-IOV.
Ohne VMQ oder SR-IOV, kannst du jedoch noch nicht mal die Performance einer 10G NIC ansatzweise auslutschen, geschweige denn einer noch schnelleren Uplink NIC.
IovSupport : False
IovSupportReasons : {This network adapter does not support SR-IOV.}… zudem schein SR-IOV, Hardwareseitig (Mainboard BIOS & NIC BIOS) auf diesem System überhaupt nicht aktiviert zu sein, denn die 10G Broadcom-NIC’s supporten grundsätzlich schon VMQ & SR-IOV …
Und auch die folgenden Punkte zeugen davon, …
IovQueuePairCount : 0
…
IovVirtualFunctionCount : 0
…
DefaultQueueVrssEnabled : False
DefaultQueueVmmqEnabled : False
…
DefaultQueueVrssMaxQueuePairs : 0
…
DefaultQueueVrssMinQueuePairs : 0... dass weder, VMQ noch SR-IOV noch VRSS seitens der entsprechenden Uplink-NIC’s verfügbar sind.
Was bedeutet, dass jedes Ethernet-Packet, beim Transport von der VM zu einer andern VM und insbesondere ausserhalb des HV’s, mehrfach per Software angefasst werden muss, da das ganze SDN (vSwitch & vNIC’s) ohne VMQ oder SR-IOV komplett in Software läuft, wodurch ein um ein mehrfaches höherer CPU und auch RAM-Overhead entsteht, als bei einem Transport mit VMQ oder SR-IOV oder gar ganz ohne Virtualisierung.
Zudem läuft der vSwitch bei dir so nur auf dem Kern 0, was seine Leistung eh sehr deutlich reduziert. 😔
Mach dir wegen der Fehlkonfiguration jetzt aber keinen Kopf, denn diesen Mist habe primär die Hersteller mit ihrer absolut bescheidenen Default-Konfig und den meist absolut be💩nen Dokus (falls überhaupt vorhanden) zu verantworten. 😉
😮 … was ist das denn …
SoftwareRscEnabled : False
RscOffloadEnabled : False… das ist aber ganz sicher nicht Default ...👍 sehr gut so. 😁
Sprich, bei dem rechten HV solltest du als nächstes mal prüfen, weshalb auf diesem kein VMQ und auch SR-IOV verfügbar ist. Vor allem das selbst VMQ nicht verfügbar ist, ist schon sehr sehr komisch.
Zu dem linken komme ich gleich auch noch, muss jedoch vorher mal den alten Kaffee entsorgen und auch gleich einen neuen holen. 🙃
Gruss Alex
@MysticFoxDE
Danke für die Hinweise.
Ich weis das du da tief drinnen bist. Habe deine Beiträge gelesen.
Mit VMQ und SRV-IO hab ich mich noch nicht intensiv genug beschäftigt. Steht aber auf der Liste.
Die NUMA Konfiguration für die NIC's ist auch wichtig.
Gerade wenn man 10G + nutzen möchte.
Diese Einstellungen beziehen sich doch auf die NUMA Konfig?
P.S
Dein Link oben funktioniert nicht
Danke für die Hinweise.
Ich weis das du da tief drinnen bist. Habe deine Beiträge gelesen.
Mit VMQ und SRV-IO hab ich mich noch nicht intensiv genug beschäftigt. Steht aber auf der Liste.
Die NUMA Konfiguration für die NIC's ist auch wichtig.
Gerade wenn man 10G + nutzen möchte.
Diese Einstellungen beziehen sich doch auf die NUMA Konfig?
**10G:**
Set-NetAdapterRss -Name "10G-NIC" -MaxProcessors 2 -NumberOfReceiveQueues 2
Set-NetAdapterVmq -Name "10G-NIC" -MaxProcessors 2 P.S
Dein Link oben funktioniert nicht
Moin @Pagra37,
nun zu deinem linken HV.
Dessen vSwitch seint zwar mit VMQ zu laufen, dessen Konfiguration sieht jedoch alles andere als Gesund aus.
Zunächst ist sowohl ...
... als auch ...
... viel zu hoch konfiguriert.
Das sorgt nämlich dafür, dass für jede vNIC, auch die von dem HV selbst, per Default 16 VMQ und oder SR-IOV QP's (QueuePair's) reserviert werden, die jedoch nicht wirklich unendlich sind, was man übrigens an der folgenden Stelle erkennen kann.
Denn dein NIC Port stellt in Summe nur 71 QP's zur Verfügung und zwar sowohl für VMQ als auch SR-IOV.
Und ja, gemäss dem Namen "IovQueuePairCount" könnte man meinen, dass diese QP's nur für SR-IOV bestimmt sind. Aber, wie du sehen kannst, ist bei dir kein SR-IOV aktiviert und dennoch werden auf diesem vSwitch bereits ...
... 32 davon benutzt und zwar durch diese ...
... beiden VMQ VF's (vNIC's), die jeweils 16 QP's belegen. 😉
Welche vNIC's das genau sind, kannst du übrigens damit herausfinden.
Sprich, bei der jetzigen Konfiguration, kannst du genau noch zwei vNIC's mit VMQ aktivieren und dann sind die VQM Ressourcen dieses Ports auch so gut wie ausgelutscht. 😔
Und das, obwohl der vSwitch mit ...
... eigentlich aussagt, dass dieser theoretisch bis zu 56 VF's (vNIC's) mit VMQ bedienen könnte.
Bei 56 VF's mit einer Default-Belegung von 16 QP's pro VF (vNIC), würde der vSwitch jedoch alleine für VMQ 896 QP's benötigen, sprich weit mehr als diesem aktuell zur Verfügung steht. 🙃
Mal abgesehen davon liefert ein 25G NIC-Port einer Brodcom sicherlich mehr als 71 QP's.
Sprich, auch hier schein die NIC entweder BIOS-Seitig oder Treibertechnisch, noch nicht wirklich korrekt konfiguriert zu sein.
Ich schau mal später nach, was die entsprechende NIC laut Datenblatt wirklich liefern sollte, ich schätze jedoch, dass der Chipsatz weit über 1K/Anzahl der Ports, machen sollte.
Gruss Alex
P.S. SR-IOV ist auf dieser NIC übrigens auch nicht wirklich betriebsbereit. 🙃
nun zu deinem linken HV.
Dessen vSwitch seint zwar mit VMQ zu laufen, dessen Konfiguration sieht jedoch alles andere als Gesund aus.
Zunächst ist sowohl ...
DefaultQueueVmmqQueuePairs : 16
DefaultQueueVmmqQueuePairsRequested : 16... als auch ...
DefaultQueueVrssMaxQueuePairsRequested : 16
DefaultQueueVrssMaxQueuePairs : 16... viel zu hoch konfiguriert.
Das sorgt nämlich dafür, dass für jede vNIC, auch die von dem HV selbst, per Default 16 VMQ und oder SR-IOV QP's (QueuePair's) reserviert werden, die jedoch nicht wirklich unendlich sind, was man übrigens an der folgenden Stelle erkennen kann.
IovQueuePairCount : 71Denn dein NIC Port stellt in Summe nur 71 QP's zur Verfügung und zwar sowohl für VMQ als auch SR-IOV.
Und ja, gemäss dem Namen "IovQueuePairCount" könnte man meinen, dass diese QP's nur für SR-IOV bestimmt sind. Aber, wie du sehen kannst, ist bei dir kein SR-IOV aktiviert und dennoch werden auf diesem vSwitch bereits ...
IovQueuePairsInUse : 32... 32 davon benutzt und zwar durch diese ...
NumberVmqAllocated : 2... beiden VMQ VF's (vNIC's), die jeweils 16 QP's belegen. 😉
Welche vNIC's das genau sind, kannst du übrigens damit herausfinden.
Get-NetAdapterVmqQueueSprich, bei der jetzigen Konfiguration, kannst du genau noch zwei vNIC's mit VMQ aktivieren und dann sind die VQM Ressourcen dieses Ports auch so gut wie ausgelutscht. 😔
Und das, obwohl der vSwitch mit ...
AvailableVMQueues : 56... eigentlich aussagt, dass dieser theoretisch bis zu 56 VF's (vNIC's) mit VMQ bedienen könnte.
Bei 56 VF's mit einer Default-Belegung von 16 QP's pro VF (vNIC), würde der vSwitch jedoch alleine für VMQ 896 QP's benötigen, sprich weit mehr als diesem aktuell zur Verfügung steht. 🙃
Mal abgesehen davon liefert ein 25G NIC-Port einer Brodcom sicherlich mehr als 71 QP's.
Sprich, auch hier schein die NIC entweder BIOS-Seitig oder Treibertechnisch, noch nicht wirklich korrekt konfiguriert zu sein.
Ich schau mal später nach, was die entsprechende NIC laut Datenblatt wirklich liefern sollte, ich schätze jedoch, dass der Chipsatz weit über 1K/Anzahl der Ports, machen sollte.
Gruss Alex
P.S. SR-IOV ist auf dieser NIC übrigens auch nicht wirklich betriebsbereit. 🙃
Moin @Ueba3ba,
Sehr gerne.
Für mein Gusto, habe ich mich als quasi Systemintegrator, hier schon viel zu tief eigegraben müssen. 😔
Und je tiefer ich mich hier eingrabe umso mehr sehe ich, dass die meisten Hersteller nur noch einen Kindergarten betreiben. 😭
Das solltest du aber unbedingt machen, denn wie ich schon mehrfach geschrieben habe, kann man einen => 10G (v)NIC in einer Virtualisierten Umgebung nicht wirklich ausreizen und zwar ganz egal ob bei Hyper-V, VMware, Nutanix oder was auch immer, denn alle kochen am Ende auch nur mit demselben Wasser, sprich der verfügbaren Hardwaretechnologie.
Ja, absolut!
Aber, wenn ich das jetzt auch gleich mit auspacken würde, kommt beim TO fürchte ich definitiv nur noch "Bahnhof" an. 🙃
Sprich, lass uns den TO diesbezüglich lieber etwas langsamer überfahren, sonst ergreift er gleich die Flucht oder bekommt noch einen Herzkasper. 🤪
Nicht direkt, diese Einstellung bewirken nur, dass die NIC für die Verarbeitung des Datenverkehrs nur zwei QP's und zwei Prozessoren gleichzeitig belegen darf, was für eine 10G NIC meistens auch vollkommen ausreichend ist, vor allem wenn man VMQ oder SR-IOV verwendet.
Beispiel:
Per Default sieht die RSS-Konfiguration eines Ports einer Intel X710 NIC z.B. folgend aus.
Sprich, für die Verarbeitung der Netzwerkdaten dieser NIC, können bis zu 16 QP's ...
... verwendet werden, die wiederum auf bis zu 16 Cores ...
... ausgeführt werden können.
Auf welchen Cores der entsprechende Port theoretisch laufen kann, erkennt man übrigens an dem "RssProcessorArray" ...
Was in dem oberen Beispiel bedeutet, das die Last theoretisch über jeden verfügbaren Last abgetragen werden kann,
da das RssProcessorArray in diesem Beispiel nicht eingeschränkt ist, was man an ...
... deutlich erkennen kann, denn dieses System hat in Summe nur 20 logische Kerne (0:0, 0:2, 0:4, ... bis 0:38)
Und an der "IndirectionTable" ...
... sieht man dann, welche Kerne aktuell tatsächlich für die Abarbeitung des Datenverkehrs der entsprechenden NIC verwendet werden.
Sprich in dem oberen Beispiel sind es 0:0, 0:2, 0:8, 0:10, 0:12, 0:14, 0:16, 0:18 0:20, 0:22 0:28, 0:30 0:32, 0:34, 0:36, 0:38,
also in Summe 16.
Diese Konfiguration ist jedoch ein absoluter Schwachsinn, da Intel selbst bereits schon vor über 10 Jahren geschrieben hat, dass für eine 10G NIC, nicht mehr wie 4 Prozessoren und Queues benötigt werden und das mit der Core Leistung der damaligen CPU's!
By the Way, die NIC aus meinem jetzigen Beispiel hängt momentan eh an einem 1G Switch, sprich, ist eh nur mit 1G Angebunden, wofür bereits schon ein Prozessor und eine Queue vollkommen ausreichen. 🙃
Aber ja, weil Microsoft sturr vorgibt, dass die NIC's bei einem Windows default mit 16 Prozessoren und Queues laufen sollten, machen das die Hersteller auch ganz brav so mit, obwohl die selbst eigentlich sehr wohl wissen, dass das so nicht wirklich gut ist, da schlichtweg zu viel Overhead erzeug wird. 😭
Wenn man nun den oberen Befehl ...
... auf dieser NIC ausführt, dann sieht man sofort eine deutliche Veränderung ...
... denn nun läuft die NIC nur noch über 2 Cores und zwar 0:8 und 0:28, was schon mal eine deutliche Verbesserung zu der vorherigen Konfiguration ist.
Ferner wirken sich diese Einstellungen bereits schon auf die vSwicht Konfiguration aus, der vSwitch sollte jedoch nach dieser Anpassung erstellt werden und nicht vorher. Sonst muss man an diesem einige Parameter auch noch nachkonfigurieren.
So, jetzt muss ich aber ganz fix noch ein paar andere Dinge erledigen.
Bei mir schon, habe soeben mehrfacht geprüft. 🙃
Gruss Alex
Danke für die Hinweise.
Sehr gerne.
Ich weis das du da tief drinnen bist.
Für mein Gusto, habe ich mich als quasi Systemintegrator, hier schon viel zu tief eigegraben müssen. 😔
Und je tiefer ich mich hier eingrabe umso mehr sehe ich, dass die meisten Hersteller nur noch einen Kindergarten betreiben. 😭
Mit VMQ und SRV-IO hab ich mich noch nicht intensiv genug beschäftigt. Steht aber auf der Liste.
Das solltest du aber unbedingt machen, denn wie ich schon mehrfach geschrieben habe, kann man einen => 10G (v)NIC in einer Virtualisierten Umgebung nicht wirklich ausreizen und zwar ganz egal ob bei Hyper-V, VMware, Nutanix oder was auch immer, denn alle kochen am Ende auch nur mit demselben Wasser, sprich der verfügbaren Hardwaretechnologie.
Die NUMA Konfiguration für die NIC's ist auch wichtig.
Gerade wenn man 10G + nutzen möchte.
Gerade wenn man 10G + nutzen möchte.
Ja, absolut!
Aber, wenn ich das jetzt auch gleich mit auspacken würde, kommt beim TO fürchte ich definitiv nur noch "Bahnhof" an. 🙃
Sprich, lass uns den TO diesbezüglich lieber etwas langsamer überfahren, sonst ergreift er gleich die Flucht oder bekommt noch einen Herzkasper. 🤪
Diese Einstellungen beziehen sich doch auf die NUMA Konfig?
**10G:**
Set-NetAdapterRss -Name "10G-NIC" -MaxProcessors 2 -NumberOfReceiveQueues 2
Set-NetAdapterVmq -Name "10G-NIC" -MaxProcessors 2 Nicht direkt, diese Einstellung bewirken nur, dass die NIC für die Verarbeitung des Datenverkehrs nur zwei QP's und zwei Prozessoren gleichzeitig belegen darf, was für eine 10G NIC meistens auch vollkommen ausreichend ist, vor allem wenn man VMQ oder SR-IOV verwendet.
Beispiel:
Per Default sieht die RSS-Konfiguration eines Ports einer Intel X710 NIC z.B. folgend aus.
Sprich, für die Verarbeitung der Netzwerkdaten dieser NIC, können bis zu 16 QP's ...
NumberOfReceiveQueues : 16... verwendet werden, die wiederum auf bis zu 16 Cores ...
MaxProcessors : 16... ausgeführt werden können.
Auf welchen Cores der entsprechende Port theoretisch laufen kann, erkennt man übrigens an dem "RssProcessorArray" ...
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0
0:16/0 0:18/0 0:20/32767 0:22/32767 0:24/32767 0:26/32767 0:28/32767 0:30/32767
0:32/32767 0:34/32767 0:36/32767 0:38/32767Was in dem oberen Beispiel bedeutet, das die Last theoretisch über jeden verfügbaren Last abgetragen werden kann,
da das RssProcessorArray in diesem Beispiel nicht eingeschränkt ist, was man an ...
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:38... deutlich erkennen kann, denn dieses System hat in Summe nur 20 logische Kerne (0:0, 0:2, 0:4, ... bis 0:38)
Und an der "IndirectionTable" ...
IndirectionTable: [Group:Number] : 0:0 0:20 0:2 0:22 0:8 0:28 0:10 0:30
0:12 0:32 0:14 0:34 0:16 0:36 0:18 0:38
0:0 0:20 0:2 0:22 0:8 0:28 0:10 0:30
0:12 0:32 0:14 0:34 0:16 0:36 0:18 0:38
0:0 0:20 0:2 0:22 0:8 0:28 0:10 0:30
0:12 0:32 0:14 0:34 0:16 0:36 0:18 0:38
0:0 0:20 0:2 0:22 0:8 0:28 0:10 0:30
0:12 0:32 0:14 0:34 0:16 0:36 0:18 0:38
0:0 0:20 0:2 0:22 0:8 0:28 0:10 0:30
0:12 0:32 0:14 0:34 0:16 0:36 0:18 0:38
0:0 0:20 0:2 0:22 0:8 0:28 0:10 0:30
0:12 0:32 0:14 0:34 0:16 0:36 0:18 0:38
0:0 0:20 0:2 0:22 0:8 0:28 0:10 0:30
0:12 0:32 0:14 0:34 0:16 0:36 0:18 0:38
0:0 0:20 0:2 0:22 0:8 0:28 0:10 0:30
0:12 0:32 0:14 0:34 0:16 0:36 0:18 0:38... sieht man dann, welche Kerne aktuell tatsächlich für die Abarbeitung des Datenverkehrs der entsprechenden NIC verwendet werden.
Sprich in dem oberen Beispiel sind es 0:0, 0:2, 0:8, 0:10, 0:12, 0:14, 0:16, 0:18 0:20, 0:22 0:28, 0:30 0:32, 0:34, 0:36, 0:38,
also in Summe 16.
Diese Konfiguration ist jedoch ein absoluter Schwachsinn, da Intel selbst bereits schon vor über 10 Jahren geschrieben hat, dass für eine 10G NIC, nicht mehr wie 4 Prozessoren und Queues benötigt werden und das mit der Core Leistung der damaligen CPU's!
By the Way, die NIC aus meinem jetzigen Beispiel hängt momentan eh an einem 1G Switch, sprich, ist eh nur mit 1G Angebunden, wofür bereits schon ein Prozessor und eine Queue vollkommen ausreichen. 🙃
Aber ja, weil Microsoft sturr vorgibt, dass die NIC's bei einem Windows default mit 16 Prozessoren und Queues laufen sollten, machen das die Hersteller auch ganz brav so mit, obwohl die selbst eigentlich sehr wohl wissen, dass das so nicht wirklich gut ist, da schlichtweg zu viel Overhead erzeug wird. 😭
Wenn man nun den oberen Befehl ...
Set-NetAdapterRss -Name "X710-2" -MaxProcessors 2 -NumberOfReceiveQueues 2
Set-NetAdapterVmq -Name "X710-2" -MaxProcessors 2 ... auf dieser NIC ausführt, dann sieht man sofort eine deutliche Veränderung ...
... denn nun läuft die NIC nur noch über 2 Cores und zwar 0:8 und 0:28, was schon mal eine deutliche Verbesserung zu der vorherigen Konfiguration ist.
Ferner wirken sich diese Einstellungen bereits schon auf die vSwicht Konfiguration aus, der vSwitch sollte jedoch nach dieser Anpassung erstellt werden und nicht vorher. Sonst muss man an diesem einige Parameter auch noch nachkonfigurieren.
So, jetzt muss ich aber ganz fix noch ein paar andere Dinge erledigen.
Dein Link oben funktioniert nicht
Bei mir schon, habe soeben mehrfacht geprüft. 🙃
Gruss Alex
Danke für deine Erklärung.
Ich habe mir bereits vor einiger Zeit das
"HowTo Configure RSS on ConnectX-3 Pro for Windows 2012"
zu Gemüte geführt. HowTo Configure RSS
In diesem HowTo wird es eigentlich gut erklärt wie die NUMA Konfiguration für die Netzwerkkarte vorgenommen werden kann.
Zu SRV-IO:
SRV-IO kann ja leider nicht mit einem SET verwendet werden.
Heißt: Entweder darauf verzichten oder eine dedizierte NIC ohne SET für die VM verwenden die dann SRV-IO verwendet.
Dan lese ich auch das SRV-IO zusammen mit VMQ auf derselben NIC nicht kompatibel zu sein scheint.
VMQ verteilt also den Netzwerkverkehr von VM's auf mehrere CPU-Kerne des HyperV Hosts und muss sorgfältig konfiguriert werden.
Eine falsche oder schlechte VMQ Konfiguration führt zum Einbruch der Netzwerkperformance.
Ich habe mir von meiner Glaskugel sagen lassen, dass standardmäßig Windows den VMQ-Traffic zusammen mit dem Hypervisor-Prozess auf denselben CPU-Kernen ausführt.
Das kann zu CPU-Überlastung und schlechter Performance führen.
Also sollte man verhindern, dass VMQ auf den ersten CPU-Kernen läuft, da diese vom Hypervisor benötigt werden.
1. Reserviere die ersten 2 Kerne für den Hypervisor.
2. Weise VMQ die nächsten Kerne (2-5) zu, um Engpässe zu vermeiden.
Mit weiteren NIC's genauso verfahren, aber andere Kerne zuweisen.
Das zweite Problem scheint eine falsche CPU-Zuweisung bei Verwendung mehrerer NIC's im SET-Switch zu sein.
Werden mehrere NIC's in einem SET-Switch genutzt, können alle VMQ's auf denselben CPU-Kernen landen.
Dadurch wird nur ein Teil der CPU genutzt, während andere Kerne unausgelastet bleiben.
Heißt: VMQ's über mehrere Kerne verteilen, damit jede NIC andere CPU-Kerne nutzt.
1. NIC1 nutzt CPU-Kerne 2-5
2. NIC2 nutzt CPU-Kerne 6-9
Die Last wird gleichmäßig verteilt.
Drittes Problem mit VMQ bei Verwendung von 1-Gbit/s NIC's
VMQ ist für 10-Gbit/s und höher gedacht.
Aktiviertes VMQ auf einer 1-Gbit/s NIC kann die Performance beeinflussen oder verschlechtern.
Lösung? VMQ auf 1-Gbit/s NIC's deaktivieren.
Besser wäre RSS auf 1-Gbit/s NIC's zu nutzen
Kommen wir zum vierten Problem, dem Konflikt mit SRV-IO
VMQ und SRV-IO sind inkompatibel, weil SRV-IO den Netzwerkverkehr direkt an die VM durchreicht, während VMQ diesen über den Host-Stack verteilt.
Ist beides aktiv, kann es zu Performance-Problemen oder sogar Netzwerkfehlern führen.
Heißt: Entscheidung treffen. Will ich VMQ oder SRV-IO auf den NIC's nutzen.
Beider auf derselben NIC funktioniert nicht.
Das bedeutet für mich dass ich, bevor ich den SET-Switch erstelle, ich erst einmal
CPU-Kerne für den Hypervisor reserviere,
Dann verteile ich die VMQ auf verschiedene CPU-Kerne bei mehreren NIC's
Dann deaktiviere ich gegebenenfalls VMQ auf 1-Gbit/s NIC's und aktiviere RSS
RSS ist kompatibel mit SRV-IO.
Benötige ich in einer VM, die mit einer 10-Gbit/s oder höher, NIC angebunden ist,
niedrige Latenzen, dann sollte ich die NIC nicht im SET-Switch nutzten, sondern
SRV-IO auf der NIC aktivieren und diese direkt an die VM durchreichen.
An und für sich klingt das alles plausibel.
Ich habe jetzt wieder richtig Lust mein Labor hochzufahren und ein paar Tests zu machen.
Dafür muss ich aber erst mal wieder Zeit finden.
Leider stelle ich immer wieder fest dass bei unseren Kunden einfach nur der Server hingestellt und hochgefahren wird. Da werden sich keine Gedanken über Optimierungen gemacht. Größtenteils aus Unwissenheit.
Das möchte ich natürlich ändern. Ich lerne jeden Tag etwas dazu.
So, das wars jetzt erstmal von mir.
Ich habe mir bereits vor einiger Zeit das
"HowTo Configure RSS on ConnectX-3 Pro for Windows 2012"
zu Gemüte geführt. HowTo Configure RSS
In diesem HowTo wird es eigentlich gut erklärt wie die NUMA Konfiguration für die Netzwerkkarte vorgenommen werden kann.
Zu SRV-IO:
SRV-IO kann ja leider nicht mit einem SET verwendet werden.
Heißt: Entweder darauf verzichten oder eine dedizierte NIC ohne SET für die VM verwenden die dann SRV-IO verwendet.
Dan lese ich auch das SRV-IO zusammen mit VMQ auf derselben NIC nicht kompatibel zu sein scheint.
VMQ verteilt also den Netzwerkverkehr von VM's auf mehrere CPU-Kerne des HyperV Hosts und muss sorgfältig konfiguriert werden.
Eine falsche oder schlechte VMQ Konfiguration führt zum Einbruch der Netzwerkperformance.
Ich habe mir von meiner Glaskugel sagen lassen, dass standardmäßig Windows den VMQ-Traffic zusammen mit dem Hypervisor-Prozess auf denselben CPU-Kernen ausführt.
Das kann zu CPU-Überlastung und schlechter Performance führen.
Also sollte man verhindern, dass VMQ auf den ersten CPU-Kernen läuft, da diese vom Hypervisor benötigt werden.
Set-VMHost -ReserveManagementToolsProcessor 2
Set-NetAdapterVmq -Name "NIC1" -BaseProcessorNumber 2 -MaxProcessors 4 1. Reserviere die ersten 2 Kerne für den Hypervisor.
2. Weise VMQ die nächsten Kerne (2-5) zu, um Engpässe zu vermeiden.
Mit weiteren NIC's genauso verfahren, aber andere Kerne zuweisen.
Das zweite Problem scheint eine falsche CPU-Zuweisung bei Verwendung mehrerer NIC's im SET-Switch zu sein.
Werden mehrere NIC's in einem SET-Switch genutzt, können alle VMQ's auf denselben CPU-Kernen landen.
Dadurch wird nur ein Teil der CPU genutzt, während andere Kerne unausgelastet bleiben.
Heißt: VMQ's über mehrere Kerne verteilen, damit jede NIC andere CPU-Kerne nutzt.
Set-NetAdapterVmq -Name "NIC1" -BaseProcessorNumber 2 -MaxProcessors 4
Set-NetAdapterVmq -Name "NIC2" -BaseProcessorNumber 6 -MaxProcessors 4 1. NIC1 nutzt CPU-Kerne 2-5
2. NIC2 nutzt CPU-Kerne 6-9
Die Last wird gleichmäßig verteilt.
Drittes Problem mit VMQ bei Verwendung von 1-Gbit/s NIC's
VMQ ist für 10-Gbit/s und höher gedacht.
Aktiviertes VMQ auf einer 1-Gbit/s NIC kann die Performance beeinflussen oder verschlechtern.
Lösung? VMQ auf 1-Gbit/s NIC's deaktivieren.
Disable-NetAdapterVmq -Name "NIC1" Besser wäre RSS auf 1-Gbit/s NIC's zu nutzen
Enable-NetAdapterRss -Name "NIC1" Kommen wir zum vierten Problem, dem Konflikt mit SRV-IO
VMQ und SRV-IO sind inkompatibel, weil SRV-IO den Netzwerkverkehr direkt an die VM durchreicht, während VMQ diesen über den Host-Stack verteilt.
Ist beides aktiv, kann es zu Performance-Problemen oder sogar Netzwerkfehlern führen.
Heißt: Entscheidung treffen. Will ich VMQ oder SRV-IO auf den NIC's nutzen.
Beider auf derselben NIC funktioniert nicht.
Das bedeutet für mich dass ich, bevor ich den SET-Switch erstelle, ich erst einmal
CPU-Kerne für den Hypervisor reserviere,
Set-VMHost -ReserveManagementToolsProcessor 2Dann verteile ich die VMQ auf verschiedene CPU-Kerne bei mehreren NIC's
Set-NetAdapterVmq -Name "NIC1" -BaseProcessorNumber 2 -MaxProcessors 4
Set-NetAdapterVmq -Name "NIC2" -BaseProcessorNumber 6 -MaxProcessors 4 Dann deaktiviere ich gegebenenfalls VMQ auf 1-Gbit/s NIC's und aktiviere RSS
RSS ist kompatibel mit SRV-IO.
Disable-NetAdapterVmq -Name "NIC1"
Enable-NetAdapterRss -Name "NIC1" Benötige ich in einer VM, die mit einer 10-Gbit/s oder höher, NIC angebunden ist,
niedrige Latenzen, dann sollte ich die NIC nicht im SET-Switch nutzten, sondern
SRV-IO auf der NIC aktivieren und diese direkt an die VM durchreichen.
Set-VMNetworkAdapter -VMName "HighPerfVM" -SRIOVEnabled $true An und für sich klingt das alles plausibel.
Ich habe jetzt wieder richtig Lust mein Labor hochzufahren und ein paar Tests zu machen.
Dafür muss ich aber erst mal wieder Zeit finden.
Leider stelle ich immer wieder fest dass bei unseren Kunden einfach nur der Server hingestellt und hochgefahren wird. Da werden sich keine Gedanken über Optimierungen gemacht. Größtenteils aus Unwissenheit.
Das möchte ich natürlich ändern. Ich lerne jeden Tag etwas dazu.
So, das wars jetzt erstmal von mir.
Moin @Ueba3ba,
die Doku finde ich zwar nicht schlecht wenn man ein System mit nur einem NUMA Knoten konfigurieren möchte, jedoch sehe ich in dieser nicht wirklich viel, was bei Systemen mit mehreren NUMA Knoten wirklich helfen würde. 😔
Siehe z.B.
https://community.spiceworks.com/t/server-2019-network-performance/72496 ...
Doch, theoretisch zumindest funktioniert das schon, praktisch ist es jedoch nicht wirklich ganz einfach. 😔
Wenn man stand heute SR-IOV bei einer Hyper-V Umgebung verwenden, jedoch so wenig wie möglich Stress damit haben möchte, dann sollte man meiner bisherigen Erfahrung nach, auf ein SET Team eher verzichten, da dieses die Angelegenheit noch komplizierter macht und dadurch viel schwerer zu händeln ist.
Du verwechselst zudem hier glaube ich LBFO mit SET, denn bei LBFO ist weder VMQ noch SR-IOV möglich, mitunter auch deshalb, sollte man ab Server 2016 eigentlich auch kein LBFO mehr benutzen, sondern eher zu SET greifen. Mit SET funktioniert das Teaming jedoch auch bei einem Server 2025 nicht wirklich korrekt. 😭
Ähm, Vorsicht, das ist so nicht wirklich ganz richtig.
Also ja, bei einer vNIC sollte man entweder VMQ oder SR-IOV aktivieren, beides geht beim Hyper-V übrigens auch, ist aber nicht wirklich gut.
Aber, damit SR-IOV korrekt funktioniert, muss mindestens ab Server 2019, auf der/den entsprechenden Uplink NIC’s eines vSwitches, sowohl RSS, als auch VRSS und auch VMQ und auch SR-IOV aktiviert und auch korrekt konfiguriert sein, zumindest wenn du mehrere QP’s (Channel‘s) per VF benutzen möchtest. Denn die Mehrkanalfähigkeit von SR-IOV, wird von Microsoft bei Windows irgendwie durch RSS + VRSS + VMQ realisiert. 🙃
Für die Verteilung des Netzwerkverkehrs über unterschiedliche CPU-Kerne ist nicht wirklich VMQ zuständig, sondern eher RSS, respektive VRSS, und zwar auch bei VMQ und SR-IOV und auch RDMA und auch bei SMB-Multichannel. 😉
Daher muss RSS heutzutage eigentlich in so gut wie jedem Anwendungsfall korrekt konfiguriert sein, was jedoch per Default nicht wirklich so ist. 😭
VMQ selber und auch SR-IOV, sind hingegen Netzwerk Beschleunigungs-Technologien, die primär dafür sorgen sollen, dass der Datenverkehr eines SDN‘s, so ressourcenschonend wie möglich, sprich, so hardwarenahe wie möglich verarbeitet wird.
Weitere Detail siehe z.B.
https://www.itprotoday.com/server-virtualization/q-are-vmdq-and-sr-iov-p ...
https://www.intel.com/content/dam/www/public/us/en/documents/technology- ...
Das passiert aber auch bei einer falschen RSS oder SR-IOV Konfiguration.
Jup, genau das passiert, wenn RSS nicht wirklich korrekt konfiguriert oder überhaupt nicht funktionsfähig ist. 🙃
👍
Oder per RSS dafür sorgen, dass die entsprechende Last auch über andere Kerne abgetragen werden kann. 😁
OK, den kannte ich so auch noch nicht, sehr interessant, danke. 👍
Ich verteilen den Datenverkehr einer NIC wenn möglich eh nicht gerne über den Kern 0 oder auch den nächsten, sondern eher ab den dritten, sprich meist ab 0:4 (bei aktiviertem HT). 🙃
Das schaue ich mir auf jeden Fall etwas genauer an.
Vorsicht, bei aktiviertem HT/MT, wird nur jeder zweite Kern für das RSS Handling benutzt, sprich, die Fake-Kerne werden bei RSS nicht mitberücksichtigt. 🙃
👍 zumindest wenn möglich, aber wenn dann nur auf dem NUMA, über den die entsprechende NIC auch physikalisch angebunden ist.
👏
👍 👏
Selbes gilt übrigens auch für eine 10G NIC die jedoch nur mit 1G angebunden ist.
Und ... dasselbe gilt genauso auch für SR-IOV, sprich, nix gut bei 1G auch nicht über eine 10G fähige NIC. 🙃
Das ist so wie schon weiter ober geschrieben, nicht wirklich ganz richtig.
RSS, respektive VRSS funktioniert bei einem vSwitch ohne dass auf der Uplink NIC VMQ aktiviert ist, aber nicht wirklich. 🙃
RSS ist wie ich schon geschrieben habe, mittlerweile auch eine Voraussetzung bei VMQ, respektive VMMQ.
https://learn.microsoft.com/de-de/windows-hardware/drivers/network/overv ...
😉
Ja +- kann man das stand heute schon so sagen.
👍👍👍 bitte auch unbedingt machen, denn es bringt schon eine um zum Teil Faktoren bessere Performance, wenn das SDN/NIC's nicht irgendwie, sondern wirklich richtig konfiguriert ist/sind!
Das ist sehr oft leider auch so, auch das mit der Unwissenheit.
Ich bin auf die entsprechenden Kollegen jedoch keineswegs in irgendeiner Weise sauer, weil ein Grossteil des Wissens was für eine korrekte Konfiguration notwendig ist, seitens der Hersteller entweder überhaupt nicht oder nicht korrekt zur Verfügung gestellt wird. 😭🤢🤮 (@Hersteller)
👏👏👏
Gruss Alex
Ich habe mir bereits vor einiger Zeit das
"HowTo Configure RSS on ConnectX-3 Pro for Windows 2012"
zu Gemüte geführt. HowTo Configure RSS
In diesem HowTo wird es eigentlich gut erklärt wie die NUMA Konfiguration für die Netzwerkkarte vorgenommen werden kann.
"HowTo Configure RSS on ConnectX-3 Pro for Windows 2012"
zu Gemüte geführt. HowTo Configure RSS
In diesem HowTo wird es eigentlich gut erklärt wie die NUMA Konfiguration für die Netzwerkkarte vorgenommen werden kann.
die Doku finde ich zwar nicht schlecht wenn man ein System mit nur einem NUMA Knoten konfigurieren möchte, jedoch sehe ich in dieser nicht wirklich viel, was bei Systemen mit mehreren NUMA Knoten wirklich helfen würde. 😔
Siehe z.B.
https://community.spiceworks.com/t/server-2019-network-performance/72496 ...
Zu SRV-IO:
SRV-IO kann ja leider nicht mit einem SET verwendet werden.
SRV-IO kann ja leider nicht mit einem SET verwendet werden.
Doch, theoretisch zumindest funktioniert das schon, praktisch ist es jedoch nicht wirklich ganz einfach. 😔
Heißt: Entweder darauf verzichten oder eine dedizierte NIC ohne SET für die VM verwenden die dann SRV-IO verwendet.
Wenn man stand heute SR-IOV bei einer Hyper-V Umgebung verwenden, jedoch so wenig wie möglich Stress damit haben möchte, dann sollte man meiner bisherigen Erfahrung nach, auf ein SET Team eher verzichten, da dieses die Angelegenheit noch komplizierter macht und dadurch viel schwerer zu händeln ist.
Du verwechselst zudem hier glaube ich LBFO mit SET, denn bei LBFO ist weder VMQ noch SR-IOV möglich, mitunter auch deshalb, sollte man ab Server 2016 eigentlich auch kein LBFO mehr benutzen, sondern eher zu SET greifen. Mit SET funktioniert das Teaming jedoch auch bei einem Server 2025 nicht wirklich korrekt. 😭
Dan lese ich auch das SRV-IO zusammen mit VMQ auf derselben NIC nicht kompatibel zu sein scheint.
Ähm, Vorsicht, das ist so nicht wirklich ganz richtig.
Also ja, bei einer vNIC sollte man entweder VMQ oder SR-IOV aktivieren, beides geht beim Hyper-V übrigens auch, ist aber nicht wirklich gut.
Aber, damit SR-IOV korrekt funktioniert, muss mindestens ab Server 2019, auf der/den entsprechenden Uplink NIC’s eines vSwitches, sowohl RSS, als auch VRSS und auch VMQ und auch SR-IOV aktiviert und auch korrekt konfiguriert sein, zumindest wenn du mehrere QP’s (Channel‘s) per VF benutzen möchtest. Denn die Mehrkanalfähigkeit von SR-IOV, wird von Microsoft bei Windows irgendwie durch RSS + VRSS + VMQ realisiert. 🙃
VMQ verteilt also den Netzwerkverkehr von VM's auf mehrere CPU-Kerne des HyperV Hosts und muss sorgfältig konfiguriert werden.
Für die Verteilung des Netzwerkverkehrs über unterschiedliche CPU-Kerne ist nicht wirklich VMQ zuständig, sondern eher RSS, respektive VRSS, und zwar auch bei VMQ und SR-IOV und auch RDMA und auch bei SMB-Multichannel. 😉
Daher muss RSS heutzutage eigentlich in so gut wie jedem Anwendungsfall korrekt konfiguriert sein, was jedoch per Default nicht wirklich so ist. 😭
VMQ selber und auch SR-IOV, sind hingegen Netzwerk Beschleunigungs-Technologien, die primär dafür sorgen sollen, dass der Datenverkehr eines SDN‘s, so ressourcenschonend wie möglich, sprich, so hardwarenahe wie möglich verarbeitet wird.
Weitere Detail siehe z.B.
https://www.itprotoday.com/server-virtualization/q-are-vmdq-and-sr-iov-p ...
https://www.intel.com/content/dam/www/public/us/en/documents/technology- ...
Eine falsche oder schlechte VMQ Konfiguration führt zum Einbruch der Netzwerkperformance.
Das passiert aber auch bei einer falschen RSS oder SR-IOV Konfiguration.
Ich habe mir von meiner Glaskugel sagen lassen, dass standardmäßig Windows den VMQ-Traffic zusammen mit dem Hypervisor-Prozess auf denselben CPU-Kernen ausführt.
Jup, genau das passiert, wenn RSS nicht wirklich korrekt konfiguriert oder überhaupt nicht funktionsfähig ist. 🙃
Das kann zu CPU-Überlastung und schlechter Performance führen.
👍
Also sollte man verhindern, dass VMQ auf den ersten CPU-Kernen läuft, da diese vom Hypervisor benötigt werden.
Oder per RSS dafür sorgen, dass die entsprechende Last auch über andere Kerne abgetragen werden kann. 😁
Set-VMHost -ReserveManagementToolsProcessor 2OK, den kannte ich so auch noch nicht, sehr interessant, danke. 👍
Set-NetAdapterVmq -Name "NIC1" -BaseProcessorNumber 2 -MaxProcessors 4 Ich verteilen den Datenverkehr einer NIC wenn möglich eh nicht gerne über den Kern 0 oder auch den nächsten, sondern eher ab den dritten, sprich meist ab 0:4 (bei aktiviertem HT). 🙃
1. Reserviere die ersten 2 Kerne für den Hypervisor.
Das schaue ich mir auf jeden Fall etwas genauer an.
2. Weise VMQ die nächsten Kerne (2-5) zu, um Engpässe zu vermeiden.
Vorsicht, bei aktiviertem HT/MT, wird nur jeder zweite Kern für das RSS Handling benutzt, sprich, die Fake-Kerne werden bei RSS nicht mitberücksichtigt. 🙃
Mit weiteren NIC's genauso verfahren, aber andere Kerne zuweisen.
👍 zumindest wenn möglich, aber wenn dann nur auf dem NUMA, über den die entsprechende NIC auch physikalisch angebunden ist.
Das zweite Problem scheint eine falsche CPU-Zuweisung bei Verwendung mehrerer NIC's im SET-Switch zu sein.
Werden mehrere NIC's in einem SET-Switch genutzt, können alle VMQ's auf denselben CPU-Kernen landen.
Dadurch wird nur ein Teil der CPU genutzt, während andere Kerne unausgelastet bleiben.
Heißt: VMQ's über mehrere Kerne verteilen, damit jede NIC andere CPU-Kerne nutzt.
1. NIC1 nutzt CPU-Kerne 2-5
2. NIC2 nutzt CPU-Kerne 6-9
Die Last wird gleichmäßig verteilt.
Werden mehrere NIC's in einem SET-Switch genutzt, können alle VMQ's auf denselben CPU-Kernen landen.
Dadurch wird nur ein Teil der CPU genutzt, während andere Kerne unausgelastet bleiben.
Heißt: VMQ's über mehrere Kerne verteilen, damit jede NIC andere CPU-Kerne nutzt.
Set-NetAdapterVmq -Name "NIC1" -BaseProcessorNumber 2 -MaxProcessors 4
Set-NetAdapterVmq -Name "NIC2" -BaseProcessorNumber 6 -MaxProcessors 4 1. NIC1 nutzt CPU-Kerne 2-5
2. NIC2 nutzt CPU-Kerne 6-9
Die Last wird gleichmäßig verteilt.
👏
Drittes Problem mit VMQ bei Verwendung von 1-Gbit/s NIC's
VMQ ist für 10-Gbit/s und höher gedacht.
Aktiviertes VMQ auf einer 1-Gbit/s NIC kann die Performance beeinflussen oder verschlechtern.
Lösung? VMQ auf 1-Gbit/s NIC's deaktivieren.
VMQ ist für 10-Gbit/s und höher gedacht.
Aktiviertes VMQ auf einer 1-Gbit/s NIC kann die Performance beeinflussen oder verschlechtern.
Lösung? VMQ auf 1-Gbit/s NIC's deaktivieren.
👍 👏
Selbes gilt übrigens auch für eine 10G NIC die jedoch nur mit 1G angebunden ist.
Und ... dasselbe gilt genauso auch für SR-IOV, sprich, nix gut bei 1G auch nicht über eine 10G fähige NIC. 🙃
Kommen wir zum vierten Problem, dem Konflikt mit SRV-IO
VMQ und SRV-IO sind inkompatibel, weil SRV-IO den Netzwerkverkehr direkt an die VM durchreicht, während VMQ diesen über den Host-Stack verteilt.
Ist beides aktiv, kann es zu Performance-Problemen oder sogar Netzwerkfehlern führen.
Heißt: Entscheidung treffen. Will ich VMQ oder SRV-IO auf den NIC's nutzen.
Beider auf derselben NIC funktioniert nicht.
VMQ und SRV-IO sind inkompatibel, weil SRV-IO den Netzwerkverkehr direkt an die VM durchreicht, während VMQ diesen über den Host-Stack verteilt.
Ist beides aktiv, kann es zu Performance-Problemen oder sogar Netzwerkfehlern führen.
Heißt: Entscheidung treffen. Will ich VMQ oder SRV-IO auf den NIC's nutzen.
Beider auf derselben NIC funktioniert nicht.
Das ist so wie schon weiter ober geschrieben, nicht wirklich ganz richtig.
Dann deaktiviere ich gegebenenfalls VMQ auf 1-Gbit/s NIC's und aktiviere RSS
RSS, respektive VRSS funktioniert bei einem vSwitch ohne dass auf der Uplink NIC VMQ aktiviert ist, aber nicht wirklich. 🙃
RSS ist kompatibel mit SRV-IO.
RSS ist wie ich schon geschrieben habe, mittlerweile auch eine Voraussetzung bei VMQ, respektive VMMQ.
https://learn.microsoft.com/de-de/windows-hardware/drivers/network/overv ...
😉
Benötige ich in einer VM, die mit einer 10-Gbit/s oder höher, NIC angebunden ist,
niedrige Latenzen, dann sollte ich die NIC nicht im SET-Switch nutzten, sondern
SRV-IO auf der NIC aktivieren und diese direkt an die VM durchreichen.
niedrige Latenzen, dann sollte ich die NIC nicht im SET-Switch nutzten, sondern
SRV-IO auf der NIC aktivieren und diese direkt an die VM durchreichen.
Ja +- kann man das stand heute schon so sagen.
Ich habe jetzt wieder richtig Lust mein Labor hochzufahren und ein paar Tests zu machen.
👍👍👍 bitte auch unbedingt machen, denn es bringt schon eine um zum Teil Faktoren bessere Performance, wenn das SDN/NIC's nicht irgendwie, sondern wirklich richtig konfiguriert ist/sind!
Leider stelle ich immer wieder fest dass bei unseren Kunden einfach nur der Server hingestellt und hochgefahren wird. Da werden sich keine Gedanken über Optimierungen gemacht. Größtenteils aus Unwissenheit.
Das ist sehr oft leider auch so, auch das mit der Unwissenheit.
Ich bin auf die entsprechenden Kollegen jedoch keineswegs in irgendeiner Weise sauer, weil ein Grossteil des Wissens was für eine korrekte Konfiguration notwendig ist, seitens der Hersteller entweder überhaupt nicht oder nicht korrekt zur Verfügung gestellt wird. 😭🤢🤮 (@Hersteller)
Das möchte ich natürlich ändern. Ich lerne jeden Tag etwas dazu.
👏👏👏
Gruss Alex
Hallo zusammen,
erstmal vielen lieben Dank für die ganze Hilfe und Lösungen. Das Thema wie stelle ich die Netzwerkgeräte korrekt ein war mir einfach nicht in dem Sinne bewusst. Ganz genau trifft es das:
Als alleinkämpfender Admin in einem mittelständischem Unternehmen mit 80 Mitarbeitern kommen so viele Dinge auf einen zu, da kann man sich gar nicht mit einem Thema fest beschäftigen. Von "Ist der Stecker drin?" bis "Raktenwissenschaft" muss ich alles alleine abdecken und grob überblicken. Quasi unmöglich.
Ich habe mich mit den SR-IOV, VMQs etc. mal versucht ein wenig einzudenken, ich verstehe wie es irgendwo stand mehr Bahnhof (eher Hauptbahnhof) wie alles andere.
Ich bin auch nicht in der glücklichen Lage eine Testumgebung zu haben, d.h. alles was ich einstelle "muss sitzen" und darf keine negativen Auswirkungen auf die produktive Umgebung haben.
Aktuell versuche ich herauszufinden wie ich überhaupt aufd der Broadcom 10/25 G Karte das SR-IOV anbekomme. Ich habe das Poweredge BIOS jetzt schon auf links gedreht - ich finde nichts dazu. Wo ist das versteckt? Oder geht das ganz wo anders?
Was wären denn die einfachsten Maßnahmen zur "Basis-Optimierung" in einer produktiven Landschaft ohne Beeinträchtigungen zu erzeugen?
Gruß
erstmal vielen lieben Dank für die ganze Hilfe und Lösungen. Das Thema wie stelle ich die Netzwerkgeräte korrekt ein war mir einfach nicht in dem Sinne bewusst. Ganz genau trifft es das:
Leider stelle ich immer wieder fest dass bei unseren Kunden einfach nur der Server hingestellt und hochgefahren wird. Da werden sich keine Gedanken über Optimierungen gemacht. Größtenteils aus Unwissenheit.
Als alleinkämpfender Admin in einem mittelständischem Unternehmen mit 80 Mitarbeitern kommen so viele Dinge auf einen zu, da kann man sich gar nicht mit einem Thema fest beschäftigen. Von "Ist der Stecker drin?" bis "Raktenwissenschaft" muss ich alles alleine abdecken und grob überblicken. Quasi unmöglich.
Ich habe mich mit den SR-IOV, VMQs etc. mal versucht ein wenig einzudenken, ich verstehe wie es irgendwo stand mehr Bahnhof (eher Hauptbahnhof) wie alles andere.
Ich bin auch nicht in der glücklichen Lage eine Testumgebung zu haben, d.h. alles was ich einstelle "muss sitzen" und darf keine negativen Auswirkungen auf die produktive Umgebung haben.
Aktuell versuche ich herauszufinden wie ich überhaupt aufd der Broadcom 10/25 G Karte das SR-IOV anbekomme. Ich habe das Poweredge BIOS jetzt schon auf links gedreht - ich finde nichts dazu. Wo ist das versteckt? Oder geht das ganz wo anders?
Was wären denn die einfachsten Maßnahmen zur "Basis-Optimierung" in einer produktiven Landschaft ohne Beeinträchtigungen zu erzeugen?
Gruß
Moin @Pagra37,
dafür sind wir körperlich zwar oft etwas älteren ... aber mindestens geistig noch sehr fitte IT 🐰sen und auch 🦊se, ja mitunter auch noch da. 😁
Mach dir jetzt bitte auch persönlich keine Vorwürfe, du hast überhaupt nichts falsch gemacht!
Denn wenn jemand an diesem Desaster irgendeine Schuld trägt, dann sind das in erster Linie die Hersteller selbst und nicht die Systemintegratoren oder gar die Endkunden-Admins.
Denn würden die Hersteller die Default-Konfiguration halbwegs sinnvoller machen, würde mindestens die Hälfte dessen was bisher angesprochen wurde nicht nötig sein.
Würden die Hersteller zudem auch etwas mehr auf eine vollständige und auch korrekte Dokumentation achten, dann hätten die zum einen untereinander viel weniger Probleme und wir als Systemintegratoren und du als Admin dann glaube ich auch.
U.s.w. 😭
Auch diesbezüglich solltest du dir auf jeden Fall keinen Vorwurf machen.
Denn wegen den oben angesprochenen Missständen, die leider täglich immer schlimmer als besser werden, ist dieses Thema für jeden normalen Admin durchaus eine Raktenwissenschaft, da sich ein solcher um es richtig zu beherrschen/anzuwenden, zum Teil auf Hersteller-Level in diese Thema auch einarbeiten muss. 😔
Dazu haben die meisten Admins und auch die Systemintegratoren die ich kenne, jedoch nicht wirklich die Zeit. Und es ist eigentlich auch nicht wirklich unsere Aufgabe/Pflicht, diesen ganzen Hersteller-Murks auf diesem Level wirklich verstehen, respektive, händeln zu müssen.
Wenn man das mal mit einem Kauf eines neuen Autos vergleicht, dann würde das bedeuten, dass wenn die Werkstatt und oder der Kunde, nach dem Kauf eines neuen Fahrzeugs, nicht selbst den Motor einmal komplett auseinandernimmt und diesen wieder korrekt zusammenbaut, weil der Hersteller selber dazu schlichtweg nicht in der Lage ist, dann muss sich der entsprechende Endkunde im Schlimmsten Fall eben mit einem Fahrzeug zufriedengeben, welches irgendwie vielleicht max. ~50 km/h erreicht, selbst wenn er sich soeben einen Ferrari gekauft und bezahlt hat. 😭
Das kenne ich nur viel zu gut, sprich, ist bei den meisten anderen auch nicht viel anders.
Du musst sowohl im BIOS des Boards einiges Einstellen und auch im BIOS der jeweiligen NIC selber, muss auch noch einiges konfiguriert werden. Sprich, so ganz einfach ist selbst das nicht wirklich, zumal hier sowohl die Dell als auch die Broadcom Dokus eher sehr dürftig sind. 😔
https://www.dell.com/support/kbdoc/de-de/000129905/sr-iov-netzwerk-i-o-v ...
https://www.dell.com/community/en/conversations/poweredge-hardware-gener ...
https://dl.dell.com/manuals/all-products/esuprt_ser_stor_net/esuprt_pedg ...
https://techdocs.broadcom.com/us/en/storage-and-ethernet-connectivity/et ...
😭
Hier z.B. eine von Intel mit ebenfalls ein paar interessanten Infos.
https://www.intel.de/content/www/de/de/support/articles/000088702/ethern ...
Welchen Dell Server hast du denn genau?
Mit viel Vorsicht den Murks nach und nach herauszuoperieren.
Dafür benötigt man jedoch etwas an Erfahrung, die man am besten nicht auf einem Produktivem System machen sollte.
Gruss Alex
erstmal vielen lieben Dank für die ganze Hilfe und Lösungen.
dafür sind wir körperlich zwar oft etwas älteren ... aber mindestens geistig noch sehr fitte IT 🐰sen und auch 🦊se, ja mitunter auch noch da. 😁
Das Thema wie stelle ich die Netzwerkgeräte korrekt ein war mir einfach nicht in dem Sinne bewusst. Ganz genau trifft es das:
Als alleinkämpfender Admin in einem mittelständischem Unternehmen mit 80 Mitarbeitern kommen so viele Dinge auf einen zu, da kann man sich gar nicht mit einem Thema fest beschäftigen. Von "Ist der Stecker drin?" bis "Raktenwissenschaft" muss ich alles alleine abdecken und grob überblicken. Quasi unmöglich.
Leider stelle ich immer wieder fest dass bei unseren Kunden einfach nur der Server hingestellt und hochgefahren wird. Da werden sich keine Gedanken über Optimierungen gemacht. Größtenteils aus Unwissenheit.
Als alleinkämpfender Admin in einem mittelständischem Unternehmen mit 80 Mitarbeitern kommen so viele Dinge auf einen zu, da kann man sich gar nicht mit einem Thema fest beschäftigen. Von "Ist der Stecker drin?" bis "Raktenwissenschaft" muss ich alles alleine abdecken und grob überblicken. Quasi unmöglich.
Mach dir jetzt bitte auch persönlich keine Vorwürfe, du hast überhaupt nichts falsch gemacht!
Denn wenn jemand an diesem Desaster irgendeine Schuld trägt, dann sind das in erster Linie die Hersteller selbst und nicht die Systemintegratoren oder gar die Endkunden-Admins.
Denn würden die Hersteller die Default-Konfiguration halbwegs sinnvoller machen, würde mindestens die Hälfte dessen was bisher angesprochen wurde nicht nötig sein.
Würden die Hersteller zudem auch etwas mehr auf eine vollständige und auch korrekte Dokumentation achten, dann hätten die zum einen untereinander viel weniger Probleme und wir als Systemintegratoren und du als Admin dann glaube ich auch.
U.s.w. 😭
Ich habe mich mit den SR-IOV, VMQs etc. mal versucht ein wenig einzudenken, ich verstehe wie es irgendwo stand mehr Bahnhof (eher Hauptbahnhof) wie alles andere.
Auch diesbezüglich solltest du dir auf jeden Fall keinen Vorwurf machen.
Denn wegen den oben angesprochenen Missständen, die leider täglich immer schlimmer als besser werden, ist dieses Thema für jeden normalen Admin durchaus eine Raktenwissenschaft, da sich ein solcher um es richtig zu beherrschen/anzuwenden, zum Teil auf Hersteller-Level in diese Thema auch einarbeiten muss. 😔
Dazu haben die meisten Admins und auch die Systemintegratoren die ich kenne, jedoch nicht wirklich die Zeit. Und es ist eigentlich auch nicht wirklich unsere Aufgabe/Pflicht, diesen ganzen Hersteller-Murks auf diesem Level wirklich verstehen, respektive, händeln zu müssen.
Wenn man das mal mit einem Kauf eines neuen Autos vergleicht, dann würde das bedeuten, dass wenn die Werkstatt und oder der Kunde, nach dem Kauf eines neuen Fahrzeugs, nicht selbst den Motor einmal komplett auseinandernimmt und diesen wieder korrekt zusammenbaut, weil der Hersteller selber dazu schlichtweg nicht in der Lage ist, dann muss sich der entsprechende Endkunde im Schlimmsten Fall eben mit einem Fahrzeug zufriedengeben, welches irgendwie vielleicht max. ~50 km/h erreicht, selbst wenn er sich soeben einen Ferrari gekauft und bezahlt hat. 😭
Ich bin auch nicht in der glücklichen Lage eine Testumgebung zu haben, d.h. alles was ich einstelle "muss sitzen" und darf keine negativen Auswirkungen auf die produktive Umgebung haben.
Das kenne ich nur viel zu gut, sprich, ist bei den meisten anderen auch nicht viel anders.
Aktuell versuche ich herauszufinden wie ich überhaupt aufd der Broadcom 10/25 G Karte das SR-IOV anbekomme. Ich habe das Poweredge BIOS jetzt schon auf links gedreht - ich finde nichts dazu. Wo ist das versteckt? Oder geht das ganz wo anders?
Du musst sowohl im BIOS des Boards einiges Einstellen und auch im BIOS der jeweiligen NIC selber, muss auch noch einiges konfiguriert werden. Sprich, so ganz einfach ist selbst das nicht wirklich, zumal hier sowohl die Dell als auch die Broadcom Dokus eher sehr dürftig sind. 😔
https://www.dell.com/support/kbdoc/de-de/000129905/sr-iov-netzwerk-i-o-v ...
https://www.dell.com/community/en/conversations/poweredge-hardware-gener ...
https://dl.dell.com/manuals/all-products/esuprt_ser_stor_net/esuprt_pedg ...
https://techdocs.broadcom.com/us/en/storage-and-ethernet-connectivity/et ...
😭
Hier z.B. eine von Intel mit ebenfalls ein paar interessanten Infos.
https://www.intel.de/content/www/de/de/support/articles/000088702/ethern ...
Welchen Dell Server hast du denn genau?
Was wären denn die einfachsten Maßnahmen zur "Basis-Optimierung" in einer produktiven Landschaft ohne Beeinträchtigungen zu erzeugen?
Mit viel Vorsicht den Murks nach und nach herauszuoperieren.
Dafür benötigt man jedoch etwas an Erfahrung, die man am besten nicht auf einem Produktivem System machen sollte.
Gruss Alex
@fox
Ich bin immer noch am lesen. Dom ist eben dazugekommen.
Spannend..
Ich bin immer noch am lesen. Dom ist eben dazugekommen.
Spannend..
Welchen Dell Server hast du denn genau?
Das sind in dem Beispiel von oben ein R750xs sowie ein R760.
Ich werde kommende Woche mal schauen ob ich das zumindest im BIOS finde. Oder ich muss mal "ins richtige BIOS" denn ich gehe momentan (kein Reboot möglich) über den iDRAC ins "BIOS".
Moin @Ueba3ba,
Dom ... 🤔 ... meinst du etwa Dom C.?
Ansonsten stehe ich gerade etwas auf dem Schlauch. 🙃
Ähm ja, wenn sich das Gerücht bewahrheitet welches mir gestern zu den Ohren gekommen ist, dann wird die Sache in nächster Zeit noch viel spannender. 😔
Auf jeden Fall habe ich gestern einen unserer Lab-Server mit WS 2025 hochgefahren um das Gerücht etwas zu verifizieren und das was ich dabei wieder alleine nur VMQ technisch sehen musste ...
... ist einfach nur zum 🤢. 😭
Und das, obwohl bis auf die Broadcom und die X540, alle anderen NIC's mittlerweile sogar für Server 2025 mit der Zusatzqualifikation Compute (Premium) zertifiziert sind, sprich, von Microsoft selbst als absolut VMQ/VMMQ tauglich qualifiziert sind. 🙈
Gruss Alex
Dom ist eben dazugekommen.
Dom ... 🤔 ... meinst du etwa Dom C.?
Ansonsten stehe ich gerade etwas auf dem Schlauch. 🙃
Spannend..
Ähm ja, wenn sich das Gerücht bewahrheitet welches mir gestern zu den Ohren gekommen ist, dann wird die Sache in nächster Zeit noch viel spannender. 😔
Auf jeden Fall habe ich gestern einen unserer Lab-Server mit WS 2025 hochgefahren um das Gerücht etwas zu verifizieren und das was ich dabei wieder alleine nur VMQ technisch sehen musste ...
... ist einfach nur zum 🤢. 😭
Und das, obwohl bis auf die Broadcom und die X540, alle anderen NIC's mittlerweile sogar für Server 2025 mit der Zusatzqualifikation Compute (Premium) zertifiziert sind, sprich, von Microsoft selbst als absolut VMQ/VMMQ tauglich qualifiziert sind. 🙈
Gruss Alex
Ich meine mit "Dom" den MS Mitarbeiter der sich in den Beitrag den du weiter oben verlinkt hast, eingeschaltet hat.
Soweit bin ich noch nicht. Ich werde erst deine Beiträge fertig lesen.
Ähm ja, wenn sich das Gerückt bewahrheitet welches mir gestern zu den Ohren gekommen ist, dann wird die Sache in nächster Zeit noch viel spannender. 😔
Soweit bin ich noch nicht. Ich werde erst deine Beiträge fertig lesen.
Moin @Pagra37,
du musst in das Mainboard-BIOS und von dort in das entsprechende NIC-BIOS rein und zwar über die GUI die nur nach dem Reboot verfügbar ist, was ja auch per iDRAC Remoteconsole geht, über die reine Webconsole von iDRAC, kannst du diese Einstellungen jedoch nicht machen.
Grus Alex
Ich werde kommende Woche mal schauen ob ich das zumindest im BIOS finde. Oder ich muss mal "ins richtige BIOS" denn ich gehe momentan (kein Reboot möglich) über den iDRAC ins "BIOS".
du musst in das Mainboard-BIOS und von dort in das entsprechende NIC-BIOS rein und zwar über die GUI die nur nach dem Reboot verfügbar ist, was ja auch per iDRAC Remoteconsole geht, über die reine Webconsole von iDRAC, kannst du diese Einstellungen jedoch nicht machen.
Grus Alex
Ähm ja, wenn sich das Gerücht bewahrheitet welches mir gestern zu den Ohren gekommen ist, dann wird die Sache in nächster Zeit noch viel spannender.
Welches Gerücht ist dir zu Ohren gekommen?
Jetzt bin ich doch neugierig.
Moin @Ueba3ba,
... 😯 ... jetzt bin noch mehr verwirrt. 🙃
Zu geil, wie klein doch die Welt ist. 😁
Richte dem Dom auf jeden Fall einen sehr lieben Gruss aus, jetzt können wir mit ihn ja etwas offener über die Redmond-Microsoftianer rumlästern. 🤪
Das entsprechende Gerücht habe ich hier auch noch gar nicht thematisiert und werde es auch nicht, solange es nicht zu 100% bestätigt ist. Denn wenn sich das wirklich bewahrheiten sollte, dann wäre das schon ein richtig böser Hammer. 😔
Gruss Alex
Ich meine mit "Dom" den MS Mitarbeiter der sich in den Beitrag den du weiter oben verlinkt hast, eingeschaltet hat.
... 😯 ... jetzt bin noch mehr verwirrt. 🙃
Zu geil, wie klein doch die Welt ist. 😁
Richte dem Dom auf jeden Fall einen sehr lieben Gruss aus, jetzt können wir mit ihn ja etwas offener über die Redmond-Microsoftianer rumlästern. 🤪
Soweit bin ich noch nicht. Ich werde erst deine Beiträge fertig lesen.
Das entsprechende Gerücht habe ich hier auch noch gar nicht thematisiert und werde es auch nicht, solange es nicht zu 100% bestätigt ist. Denn wenn sich das wirklich bewahrheiten sollte, dann wäre das schon ein richtig böser Hammer. 😔
Gruss Alex
Moin @Ueba3ba,
wenn du dir unbedingt das Wochenende verderben möchtest, dann klingel einfach mal durch.
Siehe PM. 😉
Gruss Alex
Welches Gerücht ist dir zu Ohren gekommen?
Jetzt bin ich doch neugierig.
Jetzt bin ich doch neugierig.
wenn du dir unbedingt das Wochenende verderben möchtest, dann klingel einfach mal durch.
Siehe PM. 😉
Gruss Alex
