15.07.2025
1010
10
0Probleme Hyper-V SET Switch mit Cisco SG500X
Hallo zusammen,
ich suche aktuell einen etwas merkwürdigen Fehler.
Folgende Situation:
- Hyper-V Host (HPE Server Gen10) ist redundant an zwei gestackten Cisco SG500x Switchen angebunden (10GBe LWL)
(auf diesem Host war zuvor ESXi installiert, gleiche Verkabelung)
- der Hyper-V Host hat Clusterdienste installiert (kommt später ein weiterer hinzu, aktuell ist es der einzige Server -> wir migrieren von VMWare weg) - bei den Prüfungen für das Cluster keinerlei Fehler/Probleme
- ein weiterer ESXi Host, der ebenfalls redundant an die Switche angebunden ist
- diverse VLANs (Server, Clients, Management, ...)
- Treiber / Firmware wurde durchaktualisiert
Nun ist es so, dass es zu Netzwerkproblemen kommt, die wir nicht genau eingrenzen können. Das äußert sich so, dass es Konnektivitätsprobleme gibt - teilweise finden (= Ping) sich die Server (des Hyper-V Hosts) untereinander nicht, teilweise finden weitere physikalische Hosts die Server nicht.
ABER: Das ist nicht 100% reproduzierbar - mal geht´s, mal geht´s nicht. Teilweise von dem einen auf den anderen Moment.
Merkwürdig auch: ein Scan mit dem Advanced IP Scanner findet nur VMs auf dem ESXi Host - das habe ich aber erst einmal gemacht, ist noch kein zweites Mal getestet.
Das betrifft nur den Hyper-V Server, mit dem ESXi ist alles prima. Als zuvor noch ESXi auch auf dem jetzigen HyperV lief, gab es ebenfalls keine Probleme. VLAN Zuordnungen auf den Ports sind kontrolliert, wir haben testweise auch bereits jeweils eine Netzwerkkarte des SET-Teams mal deaktiviert (spätestens das müsste bei einer falschen VLAN Konfiguration zu einer dauerhaften Verbindungsstörung führen, das war aber nicht der Fall).
Ich vermute, dass der Grund irgendwie im Zusammenspiel der Netzwerkadapter / des SET-Teams / der Switche zu suchen ist.
STP haben wir kontrolliert (vielleicht ist es aber trotzdem noch falsch - der ESXi funktioniert mit gleicher Konfiguration aber einwandfrei).
Als nächstes würde ich mir die Einstellungen des Hyper-V Switches ansehen (u.a. VMQ, MultiChannel, RDMA, ...), aber das geht nur vernünftig am Wochenende
Mir ist klar, dass die Frage immer noch ziemlich unspezifisch ist, aber vielleicht hat jemand schon mal etwas ähnliches erlebt und kann mir einen Hinweis in die Richtige Richtung geben?
Danke,
Sebastian
ich suche aktuell einen etwas merkwürdigen Fehler.
Folgende Situation:
- Hyper-V Host (HPE Server Gen10) ist redundant an zwei gestackten Cisco SG500x Switchen angebunden (10GBe LWL)
(auf diesem Host war zuvor ESXi installiert, gleiche Verkabelung)
- der Hyper-V Host hat Clusterdienste installiert (kommt später ein weiterer hinzu, aktuell ist es der einzige Server -> wir migrieren von VMWare weg) - bei den Prüfungen für das Cluster keinerlei Fehler/Probleme
- ein weiterer ESXi Host, der ebenfalls redundant an die Switche angebunden ist
- diverse VLANs (Server, Clients, Management, ...)
- Treiber / Firmware wurde durchaktualisiert
Nun ist es so, dass es zu Netzwerkproblemen kommt, die wir nicht genau eingrenzen können. Das äußert sich so, dass es Konnektivitätsprobleme gibt - teilweise finden (= Ping) sich die Server (des Hyper-V Hosts) untereinander nicht, teilweise finden weitere physikalische Hosts die Server nicht.
ABER: Das ist nicht 100% reproduzierbar - mal geht´s, mal geht´s nicht. Teilweise von dem einen auf den anderen Moment.
Merkwürdig auch: ein Scan mit dem Advanced IP Scanner findet nur VMs auf dem ESXi Host - das habe ich aber erst einmal gemacht, ist noch kein zweites Mal getestet.
Das betrifft nur den Hyper-V Server, mit dem ESXi ist alles prima. Als zuvor noch ESXi auch auf dem jetzigen HyperV lief, gab es ebenfalls keine Probleme. VLAN Zuordnungen auf den Ports sind kontrolliert, wir haben testweise auch bereits jeweils eine Netzwerkkarte des SET-Teams mal deaktiviert (spätestens das müsste bei einer falschen VLAN Konfiguration zu einer dauerhaften Verbindungsstörung führen, das war aber nicht der Fall).
Ich vermute, dass der Grund irgendwie im Zusammenspiel der Netzwerkadapter / des SET-Teams / der Switche zu suchen ist.
STP haben wir kontrolliert (vielleicht ist es aber trotzdem noch falsch - der ESXi funktioniert mit gleicher Konfiguration aber einwandfrei).
Als nächstes würde ich mir die Einstellungen des Hyper-V Switches ansehen (u.a. VMQ, MultiChannel, RDMA, ...), aber das geht nur vernünftig am Wochenende
Mir ist klar, dass die Frage immer noch ziemlich unspezifisch ist, aber vielleicht hat jemand schon mal etwas ähnliches erlebt und kann mir einen Hinweis in die Richtige Richtung geben?
Danke,
Sebastian
Kommentieren
Teilen
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: 673873
Url: https://administrator.de/forum/hyper-v-netzwerk-switch-probleme-673873.html
Ausgedruckt am: 16.07.2025 um 20:07 Uhr
10 Kommentare
Neuester Kommentar
Moin,
ist evtl. LACP auf den switchports an denen der Hyper-V hängt eingerichtet ? Das funktioniert nicht zusammen mit SET
ist evtl. LACP auf den switchports an denen der Hyper-V hängt eingerichtet ? Das funktioniert nicht zusammen mit SET
2
Hallo,
vielen Dank für deinen Input (genauso etwas habe ich mir gewünscht!).
Ich muss gestehen, dass ich normalerweise HP/Aruba Switche mache - deswegen bin ich bei Cisco nicht so tief drin (hinzu kommt, dass die verwendeten Switche auch schon etwas betagt sind).
Ich finde in der Config nichts LCAP betreffend; allerdings so etwas:
Auf "Port-channel1" oder auch "channel-group" gibt es allerdings keine weiteren Verweise / keine weitere Verwendung. Somit vermute ich, dass das alte Relikte sind (kommen noch von vor meiner Zeit), die nicht relevant sind (?).
Grüße
Sebastian
vielen Dank für deinen Input (genauso etwas habe ich mir gewünscht!).
Ich muss gestehen, dass ich normalerweise HP/Aruba Switche mache - deswegen bin ich bei Cisco nicht so tief drin (hinzu kommt, dass die verwendeten Switche auch schon etwas betagt sind).
Ich finde in der Config nichts LCAP betreffend; allerdings so etwas:
interface Port-channel1
description "Data Trunk ESX02"
switchport trunk allowed vlan add 10-11,20-21,220,250-251
switchport trunk native vlan 254
switchport default-vlan tagged Auf "Port-channel1" oder auch "channel-group" gibt es allerdings keine weiteren Verweise / keine weitere Verwendung. Somit vermute ich, dass das alte Relikte sind (kommen noch von vor meiner Zeit), die nicht relevant sind (?).
Grüße
Sebastian
Moin,
Portchannel = LACP
Du musst auf dem Hyper-V Server ein NIC-Teaming einrichten. Sonst geht das nicht.
Hängt der Pirt-channel denn an den besagten Ports?
Alternativ und die unschöne Variante ist den Port-channel auf dem Cisco Switch aufzulösen.
Gruß
Spirit
Portchannel = LACP
Du musst auf dem Hyper-V Server ein NIC-Teaming einrichten. Sonst geht das nicht.
Hängt der Pirt-channel denn an den besagten Ports?
Alternativ und die unschöne Variante ist den Port-channel auf dem Cisco Switch aufzulösen.
Gruß
Spirit
1
Moin,
Komme/ bin auch in der VMware-Welt unterwegs - da muss man sich nicht mit LAGs rumschlagen (kann es aber).
Schaue mal hier Das ist zwar für HyperV und Catalysten, sollte sich aber auch konzeptionell auf den SG500 übertragen lassen.
Edit: zu langsam
interface Port-channel1
Das ist deine LAG Komme/ bin auch in der VMware-Welt unterwegs - da muss man sich nicht mit LAGs rumschlagen (kann es aber).
Schaue mal hier Das ist zwar für HyperV und Catalysten, sollte sich aber auch konzeptionell auf den SG500 übertragen lassen.
Edit: zu langsam
Wenn man kann, dann sollte man aus Performance und Loadbalancing Gründen LACP nutzen.
Bei VMware ist das leider nur mit Enterprise Lizenz im VSAN per Distri-Switchen möglichen.
Aber bei Hyper-V geht das wie bei jedem normalen guten Produkt auch so als basic Feature.
Bei VMware ist das leider nur mit Enterprise Lizenz im VSAN per Distri-Switchen möglichen.
Aber bei Hyper-V geht das wie bei jedem normalen guten Produkt auch so als basic Feature.
NIC-Teaming im sinne von LBFO gibt es nicht mehr seit Server 2022, deshalb muss zwingend das LACP auf den switchports an dem der Hyper-V hängt ausgeschaltet werden.
1
Hallo,
geht ja rund hier Danke für euer Feedback.
Das heisst, ich lösche auf dem Switch die ganzen "interface Port-channel*" interfaces?
Was mir nicht klar ist - in der gesamten Switch-Config gibt es keinerlei Referenzen da drauf - wie weiss denn der Switch, welche physikalischen Interfaces er in den Port-Channel einbeziehen soll?
Eben nicht - hatte ich ja auch geschrieben: "gibt es allerdings keine weiteren Verweise / keine weitere Verwendung"
Hier noch die Config der beiden Ports:
Sebastian
geht ja rund hier
Danke für euer Feedback.Das heisst, ich lösche auf dem Switch die ganzen "interface Port-channel*" interfaces?
Was mir nicht klar ist - in der gesamten Switch-Config gibt es keinerlei Referenzen da drauf - wie weiss denn der Switch, welche physikalischen Interfaces er in den Port-Channel einbeziehen soll?
Hängt der Port-channel denn an den besagten Ports?
Eben nicht - hatte ich ja auch geschrieben: "gibt es allerdings keine weiteren Verweise / keine weitere Verwendung"
Hier noch die Config der beiden Ports:
interface tengigabitethernet1/1/2
description HYV2-1
ip dhcp snooping trust
switchport trunk allowed vlan add 10-11,20-21,30-31,36,41,43,220,240
switchport trunk allowed vlan add 250-251
switchport trunk native vlan 254
switchport default-vlan tagged
interface tengigabitethernet2/1/2
description HYV2-2
ip dhcp snooping trust
switchport trunk allowed vlan add 10-11,20-21,30-31,36,41,43,220,240
switchport trunk allowed vlan add 250-251
switchport trunk native vlan 254
switchport default-vlan tagged Sebastian
wie weiss denn der Switch, welche physikalischen Interfaces er in den Port-Channel einbeziehen soll?
sh int Port-Channel 1SG500#sh int Port-Channel 1
Load balancing: src-dst-mac-ip.
Gathering information...
Channel Ports
------- -----
Po1 Active: te1/1/1,te2/1/1und via
SG550# sh run!
interface tengigabitethernet1/1/1
channel-group 1 mode auto
!
...
!
interface tengigabitethernet2/1/1
channel-group 1 mode auto
!
Zitat von @slemke:
interface tengigabitethernet1/1/2
description HYV2-1
ip dhcp snooping trust
switchport trunk allowed vlan add 10-11,20-21,30-31,36,41,43,220,240
switchport trunk allowed vlan add 250-251
switchport trunk native vlan 254
switchport default-vlan tagged
interface tengigabitethernet2/1/2
description HYV2-2
ip dhcp snooping trust
switchport trunk allowed vlan add 10-11,20-21,30-31,36,41,43,220,240
switchport trunk allowed vlan add 250-251
switchport trunk native vlan 254
switchport default-vlan tagged Hallo,
ich mag mich irren und es bislang nur anders gemacht haben, aber das sind doch imperative Kommandos und keine Konfiguration ("vlan add"). Oder warum hast Du nicht jeweils nur eine Zeile "switchport trunk allowed vlan <ids>"?
Insofern ist auch nicht ersichtlich, ob noch ein "channel-group"-Eintrag unter dem Interface besteht, solange nicht im Rahmen dieser Kommandos auch "no channel-group" abgesetzt wird.
Grüße
Richard
Der Cisco des TO's ist ein Switch der nicht IOS basierten SG / CBS Modellreihe! Also kein Catalyst und die SGs führen das vlan add... Kommando aus dem WebGUI so automatisch im CLI zusammen.
Wenn als letztes Kommando in der Interface Konfig kein "channel-group x mode auto"steht, ist der Port auch nicht für Link Aggregation (LAG) konfiguriert!
Da, wie oben schon gesagt wurde, LACP LAGs generell kein Thema mehr sind bei Hyper-V darf folglich auf den Ports dahin auch keinerlei Link Aggregation switchseitig aktiv sein.
Abgesehen davon ist diese Port Konfig aber auch etwas unsauber.
Das Native (PVID) VLAN kann man ja auf ein anderes VLAN setzen aber es dann zu taggen ist etwas von hinten durch die Brust ins Auge nach dem Motto warum einfach machen.... Dann kann man es auch ohne Umweg gleich als tagged Port angeben.
Ob der interne Hyper-V vSwitch auch ohne untagged PVID VLAN arbeitet ist fraglich. Oftmals werden darüber Infrastruktur Informationen per CDP oder LLDP übertragen.
Wenn als letztes Kommando in der Interface Konfig kein "channel-group x mode auto"steht, ist der Port auch nicht für Link Aggregation (LAG) konfiguriert!
Da, wie oben schon gesagt wurde, LACP LAGs generell kein Thema mehr sind bei Hyper-V darf folglich auf den Ports dahin auch keinerlei Link Aggregation switchseitig aktiv sein.
Abgesehen davon ist diese Port Konfig aber auch etwas unsauber.
Das Native (PVID) VLAN kann man ja auf ein anderes VLAN setzen aber es dann zu taggen ist etwas von hinten durch die Brust ins Auge nach dem Motto warum einfach machen.... Dann kann man es auch ohne Umweg gleich als tagged Port angeben.
Ob der interne Hyper-V vSwitch auch ohne untagged PVID VLAN arbeitet ist fraglich. Oftmals werden darüber Infrastruktur Informationen per CDP oder LLDP übertragen.
