Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Jumboframes auf ESXi 4.1-Cluster
10 views
Skip to first unread message
Werner Flamme
Feb 1, 2012, 8:41:57 AM2/1/12
to
Hallo miteinander,
wir haben ein Dell-Bladecenter mit einigen Blades bestückt. Auf den
Blades läuft ESXi 4.1. Nun sollen einige VMs untereinander mit
Jumboframes kommunizieren. Alle VMs laufen unter SLES11 SP1. Ein vCenter
ist vorhanden :-)
Der ersten VM eine e1000-Karte verpasst. Jumboframes eingestellt
(MTU=9000). Mit der zweiten VM das gleiche. Dann aufeinander ge-ping-t.
Geht, etwa so:
---snip---
> ping -c3 xsapuft1
PING xsapuft1.intranet (192.168.171.54) 56(84) bytes of data.
64 bytes from xsapuft1.intranet (192.168.171.54): icmp_seq=1 ttl=64
time=6.40 ms
64 bytes from xsapuft1.intranet (192.168.171.54): icmp_seq=2 ttl=64
time=0.331 ms
64 bytes from xsapuft1.intranet (192.168.171.54): icmp_seq=3 ttl=64
time=0.375 ms
--- xsapuft1.intranet ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.331/2.368/6.400/2.851 ms
---pins---
Das gleiche nochmal mit "-c3 -s 2000", klappt auch.
Also alles klar. Der dritten VM die Netzwerkkarte reingefriemelt,
Jumboframes aktiviert, ping. Geht. "ping -c3 -s 2000" geht nicht. WTF?
Nach einigem Probieren auf ca. 20 VMs kommt heraus, dass VMs, die auf
demselben Virtualisierungshost laufen, über Jumboframes kommunizieren
können. Sie können aber nicht miteinander, wenn die andere VM auf einem
andern Host läuft. Ach ja, im Zuge des Probierens haben wir die
e1000-Karten gegen VMXNET3-Karten getauscht, keine Änderung.
Das Verhalten ist nicht nur auf ping beschränkt: "ls /etc/sysconfig"
bringt eine Ausgabe, "ls -l /etc/sysconfig" rennt in einen Timeout, wenn
die Ausgabe > ca. 1400 Bytes (Standard-MTU) ist.
Da das nun nicht gerade im Sinne des Erfinders ist: Muss man noch etwas
konfigurieren, damit auch hostübergreifende Jumbo-Frames funktionieren?
Wie gesagt, ist ein Dell-Bladecenter, externe Switches kommen also gar
nicht ins Spiel (sind aber wohl auch alle auf 9k-Frames eingestellt).
Nach Angabe der ESX-Admins erlauben alle ESX-internen Switches 9k-Frames.
Ist es ein VMWare-Problem oder ein Dell-Problem? Oder einfach nur
PEBKAC? ;-)
Gruß
Werner
--
wir haben ein Dell-Bladecenter mit einigen Blades bestückt. Auf den
Blades läuft ESXi 4.1. Nun sollen einige VMs untereinander mit
Jumboframes kommunizieren. Alle VMs laufen unter SLES11 SP1. Ein vCenter
ist vorhanden :-)
Der ersten VM eine e1000-Karte verpasst. Jumboframes eingestellt
(MTU=9000). Mit der zweiten VM das gleiche. Dann aufeinander ge-ping-t.
Geht, etwa so:
---snip---
> ping -c3 xsapuft1
PING xsapuft1.intranet (192.168.171.54) 56(84) bytes of data.
64 bytes from xsapuft1.intranet (192.168.171.54): icmp_seq=1 ttl=64
time=6.40 ms
64 bytes from xsapuft1.intranet (192.168.171.54): icmp_seq=2 ttl=64
time=0.331 ms
64 bytes from xsapuft1.intranet (192.168.171.54): icmp_seq=3 ttl=64
time=0.375 ms
--- xsapuft1.intranet ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.331/2.368/6.400/2.851 ms
---pins---
Das gleiche nochmal mit "-c3 -s 2000", klappt auch.
Also alles klar. Der dritten VM die Netzwerkkarte reingefriemelt,
Jumboframes aktiviert, ping. Geht. "ping -c3 -s 2000" geht nicht. WTF?
Nach einigem Probieren auf ca. 20 VMs kommt heraus, dass VMs, die auf
demselben Virtualisierungshost laufen, über Jumboframes kommunizieren
können. Sie können aber nicht miteinander, wenn die andere VM auf einem
andern Host läuft. Ach ja, im Zuge des Probierens haben wir die
e1000-Karten gegen VMXNET3-Karten getauscht, keine Änderung.
Das Verhalten ist nicht nur auf ping beschränkt: "ls /etc/sysconfig"
bringt eine Ausgabe, "ls -l /etc/sysconfig" rennt in einen Timeout, wenn
die Ausgabe > ca. 1400 Bytes (Standard-MTU) ist.
Da das nun nicht gerade im Sinne des Erfinders ist: Muss man noch etwas
konfigurieren, damit auch hostübergreifende Jumbo-Frames funktionieren?
Wie gesagt, ist ein Dell-Bladecenter, externe Switches kommen also gar
nicht ins Spiel (sind aber wohl auch alle auf 9k-Frames eingestellt).
Nach Angabe der ESX-Admins erlauben alle ESX-internen Switches 9k-Frames.
Ist es ein VMWare-Problem oder ein Dell-Problem? Oder einfach nur
PEBKAC? ;-)
Gruß
Werner
--
Marcel Müller
Feb 1, 2012, 5:32:40 PM2/1/12
to
Hallo,
On 01.02.2012 14:41, Werner Flamme wrote:
> Also alles klar. Der dritten VM die Netzwerkkarte reingefriemelt,
> Jumboframes aktiviert, ping. Geht. "ping -c3 -s 2000" geht nicht. WTF?
> Nach einigem Probieren auf ca. 20 VMs kommt heraus, dass VMs, die auf
> demselben Virtualisierungshost laufen, über Jumboframes kommunizieren
> können. Sie können aber nicht miteinander, wenn die andere VM auf einem
> andern Host läuft. Ach ja, im Zuge des Probierens haben wir die
> e1000-Karten gegen VMXNET3-Karten getauscht, keine Änderung.
allen voran, der ESX Host im Zusammenspiel mit der Netzwerkhardware der
Blades.
> Wie gesagt, ist ein Dell-Bladecenter, externe Switches kommen also gar
> nicht ins Spiel (sind aber wohl auch alle auf 9k-Frames eingestellt).
> Nach Angabe der ESX-Admins erlauben alle ESX-internen Switches 9k-Frames.
Was ist ein ESX-interner Switch? Und was hat der mit den Blades zu tun?
Natürlich hat das Bladecenter einen eingebauten Switch. Und der muss es
natürlich auch können.
> Ist es ein VMWare-Problem oder ein Dell-Problem? Oder einfach nur
> PEBKAC? ;-)
Hast Du denn jemals ein Jumboframe von einem Blade zu einem anderen
bekommen, also jenseits von VMs und ESX?
Marcel
On 01.02.2012 14:41, Werner Flamme wrote:
> Also alles klar. Der dritten VM die Netzwerkkarte reingefriemelt,
> Jumboframes aktiviert, ping. Geht. "ping -c3 -s 2000" geht nicht. WTF?
> Nach einigem Probieren auf ca. 20 VMs kommt heraus, dass VMs, die auf
> demselben Virtualisierungshost laufen, über Jumboframes kommunizieren
> können. Sie können aber nicht miteinander, wenn die andere VM auf einem
> andern Host läuft. Ach ja, im Zuge des Probierens haben wir die
> e1000-Karten gegen VMXNET3-Karten getauscht, keine Änderung.
> Da das nun nicht gerade im Sinne des Erfinders ist: Muss man noch etwas
> konfigurieren, damit auch hostübergreifende Jumbo-Frames funktionieren?
Naja, alle Komponenten auf dem Weg müssen mitspielen. Also da wären
> konfigurieren, damit auch hostübergreifende Jumbo-Frames funktionieren?
allen voran, der ESX Host im Zusammenspiel mit der Netzwerkhardware der
Blades.
> Wie gesagt, ist ein Dell-Bladecenter, externe Switches kommen also gar
> nicht ins Spiel (sind aber wohl auch alle auf 9k-Frames eingestellt).
> Nach Angabe der ESX-Admins erlauben alle ESX-internen Switches 9k-Frames.
Natürlich hat das Bladecenter einen eingebauten Switch. Und der muss es
natürlich auch können.
> Ist es ein VMWare-Problem oder ein Dell-Problem? Oder einfach nur
> PEBKAC? ;-)
bekommen, also jenseits von VMs und ESX?
Marcel
Juergen P. Meier
Feb 2, 2012, 12:13:26 AM2/2/12
to
begin 1 followup to Werner Flamme <werner...@ufz.de>:
> Alle VMs laufen unter SLES11 SP1. Ein vCenter
> ist vorhanden :-)
>
mit einer weniger ueblichen Bedeutung von B.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
> Hallo miteinander,
>
> wir haben ein Dell-Bladecenter mit einigen Blades bestückt. Auf den
> Blades läuft ESXi 4.1. Nun sollen einige VMs untereinander mit
> Jumboframes kommunizieren.
WIESO?
>
> wir haben ein Dell-Bladecenter mit einigen Blades bestückt. Auf den
> Blades läuft ESXi 4.1. Nun sollen einige VMs untereinander mit
> Jumboframes kommunizieren.
> Alle VMs laufen unter SLES11 SP1. Ein vCenter
> ist vorhanden :-)
>
> Ist es ein VMWare-Problem oder ein Dell-Problem? Oder einfach nur
> PEBKAC? ;-)
Bei Jumboframes ist idR. von letzterem auszugehen, in einigen Faellen
> PEBKAC? ;-)
mit einer weniger ueblichen Bedeutung von B.
Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
Juergen P. Meier
Feb 2, 2012, 12:16:17 AM2/2/12
to
Marcel Müller <news.5...@spamgourmet.com>:
Um die virtuellen Netzwerkschnittstellen virtuell mit einander zu
verbinden. Verloren hat man eigentlich genau dann, wenn an diesen* Switch
(wie auch in realen Switches) neben Jumboframe nutzenden Hosts auch
noch andere angeschlossen sind, die keine Jumboframes unterstuetzen
(z.B. der Host, ein externer Switch, andere VMs etc.pp.). Also in der
Regel immer.
> Natürlich hat das Bladecenter einen eingebauten Switch. Und der muss es
> natürlich auch können.
Nicht jedes Bladecenter hat einen Switch eingebaut, es gibt auch
Versionen mit virtuellen Kabelpeitschen bzw. Trunk-splittern (die
keine Bridges nach IEEE 802.1d darstellen). Da muss dann der extern
angeschlossene Switch vermitteln.
Diese HW kann idR. Jumboframes (notfalls erst konfigurieren).
Bei Problemen mit Jumboframes sind es meist nicht die Switche oder die
Jumboframe-sprechenden Geraete, die Probleme verursachen.
> Hast Du denn jemals ein Jumboframe von einem Blade zu einem anderen
> bekommen, also jenseits von VMs und ESX?
Das ist idR. nicht das Problem. Zum problem werden ans gleiche VLAN
angeschlossene Stationen oder Switche oder Router, die mit Jumboframes
nichts anzufangen wissen - dann hast du Frame errors, Kollisionen und
lustige andere Stoerungen.
* Genauer: Innerhalb der selben Broadcastdomain aka VLAN.
>> Nach Angabe der ESX-Admins erlauben alle ESX-internen Switches 9k-Frames.
>
> Was ist ein ESX-interner Switch? Und was hat der mit den Blades zu tun?
VM Server haben ueblicherweise einen in Software emulierten Switch.
>
> Was ist ein ESX-interner Switch? Und was hat der mit den Blades zu tun?
Um die virtuellen Netzwerkschnittstellen virtuell mit einander zu
verbinden. Verloren hat man eigentlich genau dann, wenn an diesen* Switch
(wie auch in realen Switches) neben Jumboframe nutzenden Hosts auch
noch andere angeschlossen sind, die keine Jumboframes unterstuetzen
(z.B. der Host, ein externer Switch, andere VMs etc.pp.). Also in der
Regel immer.
> Natürlich hat das Bladecenter einen eingebauten Switch. Und der muss es
> natürlich auch können.
Versionen mit virtuellen Kabelpeitschen bzw. Trunk-splittern (die
keine Bridges nach IEEE 802.1d darstellen). Da muss dann der extern
angeschlossene Switch vermitteln.
Diese HW kann idR. Jumboframes (notfalls erst konfigurieren).
Bei Problemen mit Jumboframes sind es meist nicht die Switche oder die
Jumboframe-sprechenden Geraete, die Probleme verursachen.
> Hast Du denn jemals ein Jumboframe von einem Blade zu einem anderen
> bekommen, also jenseits von VMs und ESX?
angeschlossene Stationen oder Switche oder Router, die mit Jumboframes
nichts anzufangen wissen - dann hast du Frame errors, Kollisionen und
lustige andere Stoerungen.
* Genauer: Innerhalb der selben Broadcastdomain aka VLAN.
Werner Flamme
Feb 3, 2012, 4:32:35 AM2/3/12
to
Juergen P. Meier [02.02.2012 06:13]:
Distributed vSwitch.
>> Alle VMs laufen unter SLES11 SP1. Ein vCenter
>> ist vorhanden :-)
>>
>> Ist es ein VMWare-Problem oder ein Dell-Problem? Oder einfach nur
>> PEBKAC? ;-)
>
> Bei Jumboframes ist idR. von letzterem auszugehen, in einigen Faellen
> mit einer weniger ueblichen Bedeutung von B.
>
> Juergen
Ach so, Du magst keine Jumbos. Na dann, danke für Deine Hilfe!
Gruß
Werner
> begin 1 followup to Werner Flamme <werner...@ufz.de>:
>> Hallo miteinander,
>>
>> wir haben ein Dell-Bladecenter mit einigen Blades bestückt. Auf den
>> Blades läuft ESXi 4.1. Nun sollen einige VMs untereinander mit
>> Jumboframes kommunizieren.
>
> WIESO?
Um weniger Overhead bei iSCSI zu haben. Ist ein separates VLAN auf der
>> Hallo miteinander,
>>
>> wir haben ein Dell-Bladecenter mit einigen Blades bestückt. Auf den
>> Blades läuft ESXi 4.1. Nun sollen einige VMs untereinander mit
>> Jumboframes kommunizieren.
>
> WIESO?
Distributed vSwitch.
>> Alle VMs laufen unter SLES11 SP1. Ein vCenter
>> ist vorhanden :-)
>>
>> Ist es ein VMWare-Problem oder ein Dell-Problem? Oder einfach nur
>> PEBKAC? ;-)
>
> Bei Jumboframes ist idR. von letzterem auszugehen, in einigen Faellen
> mit einer weniger ueblichen Bedeutung von B.
>
> Juergen
Gruß
Werner
0 new messages