Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
VMware ESXi 6.7, vSwitch, "fremder" Traffic
10 views
Skip to first unread message
Paul Muster
Nov 17, 2020, 3:22:03 PM11/17/20
to
Hallo zusammen,
auf einem ESXi 6.7 habe ich einen klassischen vSwitch erstellt. Daran
"links" diverse Portgruppen mit VMs. "Rechts" ist sind mehrere phys.
Interfaces angebunden, mehrere davon up, eines noch down (weil die
Infrastruktur-Leute das Kabel noch nicht gesteckt haben).
Alle Portgruppen sind einzelnen phys. Interfaces zugeordnet, indem
a) [X] override Teaming and Failover, "Use Explicit Failover Order" gewählt
und
b) bei der Reihenfolge nur _das eine_ zu nutzende phys. Interface als
"active" angegeben ist und alle anderen als "unused".
Dieses Vorgehen entspricht meinem Verständnis nach der Dokumentation [1][2].
Erwartetes Ergebnis:
a) Die VMs der Portgruppen mit aktiven phys. Interfaces können
untereinander und mit der Außenwelt kommunizieren.
b) Die VMs der Portgruppe, deren phys. Interface down ist, können
untereinander kommunizieren, aber nicht mit der Außenwelt.
Beobachtete Situation:
a) passt
b) Die VMs sehen jede Menge Traffic der anderen phys. Interfaces dieses
vSwitch.
Was meint ihr dazu? Lese ich die Doku falsch? Wie muss ich den vSwitch
bzw. die Portgruppe(n) konfigurieren, um eine saubere Trennung des
Traffic sicherzustellen, auch wenn z.B. mal der Switch wackelt?
Danke & viele Grüße
Paul
[1]
<https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-5D367C45-7650-4636-B2F4-590EDF9E9176.html>
[2]
<https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-41162039-13CB-48C9-A1F4-6F52EABEDC6D.html>
auf einem ESXi 6.7 habe ich einen klassischen vSwitch erstellt. Daran
"links" diverse Portgruppen mit VMs. "Rechts" ist sind mehrere phys.
Interfaces angebunden, mehrere davon up, eines noch down (weil die
Infrastruktur-Leute das Kabel noch nicht gesteckt haben).
Alle Portgruppen sind einzelnen phys. Interfaces zugeordnet, indem
a) [X] override Teaming and Failover, "Use Explicit Failover Order" gewählt
und
b) bei der Reihenfolge nur _das eine_ zu nutzende phys. Interface als
"active" angegeben ist und alle anderen als "unused".
Dieses Vorgehen entspricht meinem Verständnis nach der Dokumentation [1][2].
Erwartetes Ergebnis:
a) Die VMs der Portgruppen mit aktiven phys. Interfaces können
untereinander und mit der Außenwelt kommunizieren.
b) Die VMs der Portgruppe, deren phys. Interface down ist, können
untereinander kommunizieren, aber nicht mit der Außenwelt.
Beobachtete Situation:
a) passt
b) Die VMs sehen jede Menge Traffic der anderen phys. Interfaces dieses
vSwitch.
Was meint ihr dazu? Lese ich die Doku falsch? Wie muss ich den vSwitch
bzw. die Portgruppe(n) konfigurieren, um eine saubere Trennung des
Traffic sicherzustellen, auch wenn z.B. mal der Switch wackelt?
Danke & viele Grüße
Paul
[1]
<https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-5D367C45-7650-4636-B2F4-590EDF9E9176.html>
[2]
<https://docs.vmware.com/en/VMware-vSphere/6.7/com.vmware.vsphere.networking.doc/GUID-41162039-13CB-48C9-A1F4-6F52EABEDC6D.html>
Sven Hartge
Nov 18, 2020, 1:39:01 AM11/18/20
to
Paul Muster <exp-3...@news.muster.net> wrote:
> auf einem ESXi 6.7 habe ich einen klassischen vSwitch erstellt. Daran
> "links" diverse Portgruppen mit VMs. "Rechts" ist sind mehrere phys.
> Interfaces angebunden, mehrere davon up, eines noch down (weil die
> Infrastruktur-Leute das Kabel noch nicht gesteckt haben).
> Alle Portgruppen sind einzelnen phys. Interfaces zugeordnet, indem
> a) [X] override Teaming and Failover, "Use Explicit Failover Order" gewählt
> und
> b) bei der Reihenfolge nur _das eine_ zu nutzende phys. Interface als
> "active" angegeben ist und alle anderen als "unused".
Warum? Was ist dein Ziel? Bitte beschreibe deine Struktur genauer.
> auf einem ESXi 6.7 habe ich einen klassischen vSwitch erstellt. Daran
> "links" diverse Portgruppen mit VMs. "Rechts" ist sind mehrere phys.
> Interfaces angebunden, mehrere davon up, eines noch down (weil die
> Infrastruktur-Leute das Kabel noch nicht gesteckt haben).
> Alle Portgruppen sind einzelnen phys. Interfaces zugeordnet, indem
> a) [X] override Teaming and Failover, "Use Explicit Failover Order" gewählt
> und
> b) bei der Reihenfolge nur _das eine_ zu nutzende phys. Interface als
> "active" angegeben ist und alle anderen als "unused".
> Dieses Vorgehen entspricht meinem Verständnis nach der Dokumentation [1][2].
> Erwartetes Ergebnis:
> a) Die VMs der Portgruppen mit aktiven phys. Interfaces können
> untereinander und mit der Außenwelt kommunizieren.
> b) Die VMs der Portgruppe, deren phys. Interface down ist, können
> untereinander kommunizieren, aber nicht mit der Außenwelt.
> Beobachtete Situation:
> a) passt
> b) Die VMs sehen jede Menge Traffic der anderen phys. Interfaces dieses
> vSwitch.
alle im selben vSwitch?
Das funktioniert so nicht.
Deine Portgruppen-Zuordnung zu externen Interfaces gilt nur für
*ausgehenden* Traffic, nicht für *eingehenden*!
Wenn alle externen Interfaces einen jeweils unterschiedlichen
Netzbereich haben aber keine VLANs benutzt werden, dann brauchst du je
einen separaten vSwitch pro externem Interface/Netzbereich.
Das Standard-ESX-Setup ist, dass man die einzelnen Netz-Bereiche mittels
getaggter VLANs an den ESX führt, parallel über mehrere
Interfaces/VMNICs für Redundanz.
In der Portgruppe wählt man dann, welches VLAN für diese genutzt werden
soll und fertig.
Dann hat man keinen Crosstalk zu VMs anderer Portgruppen, so wie bei
einem normalen physikalischen Switch mit VLANs.
S!
--
Sigmentation fault. Core dumped.
Paul Muster
Nov 18, 2020, 3:22:03 PM11/18/20
to
On 18.11.20 07:38, Sven Hartge wrote:
> Das funktioniert so nicht.
Ja, offenbar. ;-)
> Deine Portgruppen-Zuordnung zu externen Interfaces gilt nur für
> *ausgehenden* Traffic, nicht für *eingehenden*!
>
> Wenn alle externen Interfaces einen jeweils unterschiedlichen
> Netzbereich haben aber keine VLANs benutzt werden, dann brauchst du je
> einen separaten vSwitch pro externem Interface/Netzbereich.
>
> Das Standard-ESX-Setup ist, dass man die einzelnen Netz-Bereiche mittels
> getaggter VLANs an den ESX führt, parallel über mehrere
> Interfaces/VMNICs für Redundanz.
>
> In der Portgruppe wählt man dann, welches VLAN für diese genutzt werden
> soll und fertig.
>
> Dann hat man keinen Crosstalk zu VMs anderer Portgruppen, so wie bei
> einem normalen physikalischen Switch mit VLANs.
Alles klar. Wenn man es weiß, leuchtet es ein. Habe das Setup
dementsprechend umgebaut...
1) alle Anbindungen, bei denen es möglich war, auf tagged VLAN
umgestellt; für den outgoing Verkehr die "Explicit Failover Order" belassen
2) die anderen auf jeweils eigene vSwitches
... und nun ist kein Traffic mehr an unerwünschter Stelle zu sehen.
Wie schon öfter: Sven, ganz herzlichen Dank für die schnelle, präzise
und verständliche Hilfe!
Viele Grüße
Paul
> Paul Muster <exp-3...@news.muster.net> wrote:
>> Beobachtete Situation:
>> a) passt
>> b) Die VMs sehen jede Menge Traffic der anderen phys. Interfaces dieses
>> vSwitch.
>
> Nutzt du keine VLANs? Sind die externen Interfaces untagged und landen
> alle im selben vSwitch?
Ja.
>> Beobachtete Situation:
>> a) passt
>> b) Die VMs sehen jede Menge Traffic der anderen phys. Interfaces dieses
>> vSwitch.
>
> Nutzt du keine VLANs? Sind die externen Interfaces untagged und landen
> alle im selben vSwitch?
> Das funktioniert so nicht.
Ja, offenbar. ;-)
> Deine Portgruppen-Zuordnung zu externen Interfaces gilt nur für
> *ausgehenden* Traffic, nicht für *eingehenden*!
>
> Wenn alle externen Interfaces einen jeweils unterschiedlichen
> Netzbereich haben aber keine VLANs benutzt werden, dann brauchst du je
> einen separaten vSwitch pro externem Interface/Netzbereich.
>
> Das Standard-ESX-Setup ist, dass man die einzelnen Netz-Bereiche mittels
> getaggter VLANs an den ESX führt, parallel über mehrere
> Interfaces/VMNICs für Redundanz.
>
> In der Portgruppe wählt man dann, welches VLAN für diese genutzt werden
> soll und fertig.
>
> Dann hat man keinen Crosstalk zu VMs anderer Portgruppen, so wie bei
> einem normalen physikalischen Switch mit VLANs.
dementsprechend umgebaut...
1) alle Anbindungen, bei denen es möglich war, auf tagged VLAN
umgestellt; für den outgoing Verkehr die "Explicit Failover Order" belassen
2) die anderen auf jeweils eigene vSwitches
... und nun ist kein Traffic mehr an unerwünschter Stelle zu sehen.
Wie schon öfter: Sven, ganz herzlichen Dank für die schnelle, präzise
und verständliche Hilfe!
Viele Grüße
Paul
Sven Hartge
Nov 18, 2020, 3:35:55 PM11/18/20
to
Paul Muster <exp-3...@news.muster.net> wrote:
> 1) alle Anbindungen, bei denen es möglich war, auf tagged VLAN
> umgestellt; für den outgoing Verkehr die "Explicit Failover Order" belassen
Das ist generell keine gute Idee, wenn man nicht wirklich einen
> 1) alle Anbindungen, bei denen es möglich war, auf tagged VLAN
> umgestellt; für den outgoing Verkehr die "Explicit Failover Order" belassen
expliziten Anwendungsfall dafür hat.
Beispiel: Meine aktuellen ESXe haben 8x10GB NICs,
+ 2 NICs sind im Management-vSwitch. Hier habe ich das VMotion-VMK auf
NIC2 mit NIC1 als Fallback und das Management-VMK auf NIC1 mit NIC2 als
Fallback, damit weder der potentielle NBD-Traffic vom Backup oder der
VMotion-Traffic sich stören, aber dennoch ein Fallback möglich ist,
sollte ein Port einmal down sein.
+ 2 NICs sind für den Storage-vSwitch, in diesem Fall NFS. Hier wird
ausgehender Traffic via "Route by IP-Hash" verteilt, der Switch hat
ebenso einen statischen Port-Channel mit gleicher Einstellung.
+ 2 NICs sind für den VM-LAN-Traffic an einem Dist-vSwitch. Hier kommen
die ~50 VLANs an, in denen VMs liegen können mit entsprechenden
Port-Gruppen dahinter, hier ist "Route by NIC Load" konfiguriert, damit
der ESX den Datenverkehr gut verteilen kann und eine VM auch auf eine
andere NIC umschalten kann, sollte längerfristig mehr wie 75% Netzlast
entstehen.
Alternativ kann man hier natürlich die Default-Einstellung lassen, nach
der beim Einschalten der VM ein Port selektiert und fest behalten wird.
+ 2 NICs sind noch frei für zukünftige Nutzung. Wahrscheinlich werden
diese dem LAN-dvSwitch zugeteilt werden, was dort die Uplinks dann von 2
auf 4 erhöht. Alternativ kann es sein, dass ich FT machen muss, dann
sind die beiden NICs dafür nutzbar.
Wie man sieht, habe ich nur auf dem Management-vSwitch einen
Anwendungsfall dafür, dem ESX strikt vorzugeben, wo der Traffic laufen
soll. Für den Rest vertraue ich dem System und bin bisher damit gut
gefahren.
Paul Muster
Nov 19, 2020, 7:42:02 AM11/19/20
to
Am 18.11.2020 um 21:35 schrieb Sven Hartge:
> Paul Muster <exp-3...@news.muster.net> wrote:
>> 1) alle Anbindungen, bei denen es möglich war, auf tagged VLAN
>> umgestellt; für den outgoing Verkehr die "Explicit Failover Order" belassen
>
> Das ist generell keine gute Idee, wenn man nicht wirklich einen
> expliziten Anwendungsfall dafür hat.
Hier[tm] gehen die Kabel halt leider alle in unterschiedliche
> Paul Muster <exp-3...@news.muster.net> wrote:
>> 1) alle Anbindungen, bei denen es möglich war, auf tagged VLAN
>> umgestellt; für den outgoing Verkehr die "Explicit Failover Order" belassen
>
> Das ist generell keine gute Idee, wenn man nicht wirklich einen
> expliziten Anwendungsfall dafür hat.
Himmelsrichtungen und nicht zu /dem einen/ (oder den beiden) sauber an-
und eingebunden großen Switch(es), auf dem/denen die VLANs schön
ordentlich konsolidiert und auf die Trunks zu den ESXi geführt werden.
D.h. für z.B. Voice-Traffic muss ich das Kabel zum Voice-Switch nehmen,
der Daten-Switch könnte mit dem VLAN-Tag nichts anfangen.
Für den Traffic zur Testumgebung des Produkts XY muss in das Kabel
nehmen, das in diese Richtung geht, weil nur dort das VLAN-Tag korrekt
verstanden wird.
Usw.
> Beispiel: Meine aktuellen ESXe haben 8x10GB NICs,
Viele Grüße
Paul
Sven Hartge
Nov 19, 2020, 8:41:37 AM11/19/20
to
Paul Muster <exp-3...@news.muster.net> wrote:
> Am 18.11.2020 um 21:35 schrieb Sven Hartge:
>> Paul Muster <exp-3...@news.muster.net> wrote:
>>> 1) alle Anbindungen, bei denen es möglich war, auf tagged VLAN
>>> umgestellt; für den outgoing Verkehr die "Explicit Failover Order" belassen
>> Das ist generell keine gute Idee, wenn man nicht wirklich einen
>> expliziten Anwendungsfall dafür hat.
> Hier[tm] gehen die Kabel halt leider alle in unterschiedliche
> Himmelsrichtungen und nicht zu /dem einen/ (oder den beiden) sauber
> an- und eingebunden großen Switch(es), auf dem/denen die VLANs schön
> ordentlich konsolidiert und auf die Trunks zu den ESXi geführt werden.
Örx.
> Am 18.11.2020 um 21:35 schrieb Sven Hartge:
>> Paul Muster <exp-3...@news.muster.net> wrote:
>>> 1) alle Anbindungen, bei denen es möglich war, auf tagged VLAN
>>> umgestellt; für den outgoing Verkehr die "Explicit Failover Order" belassen
>> Das ist generell keine gute Idee, wenn man nicht wirklich einen
>> expliziten Anwendungsfall dafür hat.
> Hier[tm] gehen die Kabel halt leider alle in unterschiedliche
> Himmelsrichtungen und nicht zu /dem einen/ (oder den beiden) sauber
> an- und eingebunden großen Switch(es), auf dem/denen die VLANs schön
> ordentlich konsolidiert und auf die Trunks zu den ESXi geführt werden.
> D.h. für z.B. Voice-Traffic muss ich das Kabel zum Voice-Switch nehmen,
> der Daten-Switch könnte mit dem VLAN-Tag nichts anfangen.
> Für den Traffic zur Testumgebung des Produkts XY muss in das Kabel
> nehmen, das in diese Richtung geht, weil nur dort das VLAN-Tag korrekt
> verstanden wird.
0 new messages