Jumbo-Frames zwischen KVM-Gast und Host?

11

Ich versuche, eine 9000-Byte-MTU für die Speicherkommunikation zwischen KVM-Gästen und dem Hostsystem zu implementieren. Der Host hat eine Bridge ( br1) mit einer 9000-Byte-MTU:

host# ip link show br1
8: br1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP 
    link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
    inet 172.16.64.1/24 brd 172.16.64.255 scope global br1
    inet6 fe80::21b:21ff:fe0e:ee39/64 scope link 
       valid_lft forever preferred_lft forever

Die Gäste haben eine Schnittstelle zu dieser Brücke, die auch eine 9000-Byte-MTU hat:

guest# ip addr show eth2
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
    inet 172.16.64.10/24 brd 172.16.64.255 scope global eth2
    inet6 fe80::5054:ff:fe50:f355/64 scope link 
       valid_lft forever preferred_lft forever

Ich kann vom Gastgeber zum Gast pingen:

host# ping -c4 172.16.64.10
PING 172.16.64.10 (172.16.64.10) 56(84) bytes of data.
64 bytes from 172.16.64.10: icmp_seq=1 ttl=64 time=1.15 ms
64 bytes from 172.16.64.10: icmp_seq=2 ttl=64 time=0.558 ms
64 bytes from 172.16.64.10: icmp_seq=3 ttl=64 time=0.566 ms
64 bytes from 172.16.64.10: icmp_seq=4 ttl=64 time=0.631 ms

--- 172.16.64.10 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.558/0.727/1.153/0.247 ms

Wenn ich jedoch die Größe des Ping-Pakets über 1490 Byte hinaus erhöhe, habe ich keine Konnektivität mehr:

host# ping -c4 -s 1491 172.16.64.10
PING 172.16.64.10 (172.16.64.10) 1491(1519) bytes of data.

--- 172.16.64.10 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms

Eine Paketverfolgung zeigt, dass diese Pakete den Gast niemals erreichen. Alles, was ich gelesen habe, deutet darauf hin, dass sowohl die Linux-Bridge-Schnittstelle als auch die virtioNetzwerklaufwerke Jumbo-Frames unterstützen, aber das scheint mir ein MTU-Problem zu sein.

Vermisse ich etwas wirklich Offensichtliches?

Aktualisieren

Anzeigen der Hostseite der Gastschnittstelle:

host# brctl show
bridge name bridge id       STP enabled interfaces
br1     8000.fe540050f355   no      vnet2

host# ip addr show vnet2
11: vnet2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc pfifo_fast master br1 state UNKNOWN qlen 500
    link/ether fe:54:00:50:f3:55 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe50:f355/64 scope link 
       valid_lft forever preferred_lft forever
Larsks
quelle
Was ist die MTU auf der Tun-Schnittstelle für die VM auf dem Host?
mgorven
Das sind auch 9000 Bytes; Ich habe die Frage mit der Ausgabe von brctlund ip addr showfür diese Schnittstelle aktualisiert .
Larsks
Was genau ist das Hostsystem?
Michael Hampton
Arch Linux mit Linux 3.6.10 (x86_64), qemu-kvm 1.2.0, libvirt 1.0.1.
Larsks

Antworten:

7

Obwohl dies ein MTU-Problem war, stellte sich heraus, dass es nichts mit den MTU-Einstellungen auf einem der Komponentengeräte zu tun hatte. Wie ich in der ursprünglichen Frage gezeigt habe, hatten die Host-Bridge, die Host-Tun-Schnittstelle und die Gast-Schnittstelle alle dieselbe MTU-Einstellung (9000 Byte).

Das eigentliche Problem war ein Konfigurationsproblem mit libvirt / kvm. Standardmäßig wird libvirt nicht verwenden virtioGeräte. Ohne eine explizite Konfiguration erhalten Sie eine RealTek RTL-8139-Netzwerkkarte. Diese virtuelle Netzwerkkarte unterstützt keine Jumbo-Frames .

Um virtioGeräte verwenden zu können, müssen Sie ein explizites Modell angeben. Bei Verwendung von virt-install:

virt-install ... -w bridge=br1,model=virtio

Oder nachträglich durch Hinzufügen eines <model>Tags zum entsprechenden <interface>Element in der Domänen-XML:

<interface type="bridge">
  <model type="virtio"/>
  <source bridge="br1"/>
  <target dev="vnet2"/>
</interface>

Mit dieser Änderung funktioniert alles wie beabsichtigt.

Larsks
quelle
0

Damit eine größere MTU funktioniert, muss der gesamte Stapel über die höhere MTU verfügen, einschließlich der Gäste, der Tapdevs und der physischen Netzwerkkarten, an die die Brücke angeschlossen ist (wenn Sie unterwegs Anleihen und VLANs haben - auch diese).

dyasny
quelle
Wissen Sie, ob bestimmte Beispiele wie GigaEthernet und darüber hinaus das Ergebnis einer automatischen Verhandlung sind? Dieser Beitrag ist möglicherweise ein Duplikat: google.com/…
ArrowInTree
nein, muss manuell durchgeführt werden, der gesamte Stapel wird auf die höchste MTU einer bestimmten Komponente gesetzt
dyasny
Ja, das merke ich; das ist überall gut dokumentiert. Wie Sie der Frage entnehmen können, haben die Gäste, die Tapdevs und die Brücke alle die höhere MTU. Sehen Sie in den Beispielen, die ich gegeben habe, etwas falsch konfiguriert?
Larsks
Um nicht standardmäßige MTU-Einstellungen zu verwenden, muss alles der nicht standardmäßigen MTU entsprechen. Das sollte von oben nach unten die Gast-Netzwerkkarte, der Abgriff, die Brücke, eth (+ vlan + bond) unter der Brücke und natürlich der Switch-Port sein. Ich habe es erst vor ein paar Minuten getestet und es funktioniert perfekt auf RHEL mit kvm
dyasny
Richtig, und ich denke, ich habe in der Frage den Wert an allen Teilen des Stapels deutlich gezeigt. Sehen Sie entweder fehlende Informationen oder etwas, das nicht richtig konfiguriert ist?
Larsks