Trames géantes entre l'invité KVM et l'hôte?


11

J'essaie d'implémenter une MTU de 9 000 octets pour la communication de stockage entre les invités KVM et le système hôte. L'hôte a un pont ( br1) avec un MTU de 9 000 octets:

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

Les invités ont une interface attachée à ce pont qui a également un MTU de 9000 octets:

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

Je peux cingler de l'hôte à l'invité:

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

Mais si j'augmente la taille du paquet ping au-delà de 1490 octets, je n'ai plus de connectivité:

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

Une trace de paquet montre que ces paquets n'atteignent jamais l'invité. Tout ce que j'ai lu indique que l'interface du pont Linux et les virtiolecteurs réseau prennent tous en charge les trames jumbo, mais cela me semble être un problème MTU.

Suis-je en train de manquer quelque chose de vraiment évident?

Mise à jour

Affichage du côté hôte de l'interface invité:

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

Quel est le MTU sur l'interface tun pour la VM sur l'hôte?
mgorven

C'est aussi 9000 octets; J'ai mis à jour la question avec la sortie de brctlet ip addr showpour cette interface.
larsks

Quel est exactement le système hôte?
Michael Hampton

Arch Linux, avec Linux 3.6.10 (x86_64), qemu-kvm 1.2.0, libvirt 1.0.1.
larsks

Réponses:


7

Bien que ce soit un problème MTU, il s'avère que cela n'avait rien à voir avec les paramètres MTU sur aucun des composants. Comme je l'ai montré dans la question d'origine, le pont hôte, l'interface hôte tun et l'interface invité avaient tous le même paramètre MTU (9000 octets).

Le problème réel était un problème de configuration de libvirt / kvm. Par défaut, libvirt ne pas utiliser les virtioappareils. En l'absence d'une configuration explicite, vous vous retrouvez avec une carte réseau RealTek RTL-8139. Cette carte réseau virtuelle ne prend pas en charge les trames jumbo .

Pour utiliser des virtioappareils, vous devez spécifier un modèle explicite. Lors de l'utilisation virt-install:

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

Ou après coup en ajoutant une <model>balise à l' <interface>élément approprié dans le domaine XML:

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

Avec ce changement en place, tout fonctionne comme prévu.


0

pour que le MTU plus grand fonctionne, la pile entière doit avoir le MTU le plus élevé, qui comprend les invités, les tapdevs et les cartes réseau physiques auxquelles le pont est attaché (si vous avez des liaisons et des vlans en chemin - eux aussi)


Savez-vous si des exemples spécifiques, comme GigaEthernet et au-delà, où cela serait le résultat de l'auto-négociation? Ce message peut être un doublon: google.com/…
ArrowInTree

non, doit être fait manuellement, toute la pile doit être réglée sur le MTU le plus élevé d'un composant donné
dyasny

Oui, je m'en rends compte; c'est bien documenté partout. Comme vous pouvez le voir dans la question, les invités, les tapdevs et le pont ont tous le MTU le plus élevé. Voyez-vous quelque chose de mal configuré dans les exemples que j'ai donnés?
larsks

pour utiliser les paramètres MTU non définis par défaut, tout doit respecter le MTU non défini par défaut. Cela, de haut en bas, devrait être le NIC invité, le robinet, le pont, eth (+ vlan + bond) sous le pont, et bien sûr le port du commutateur. Je l'ai testé il y a quelques minutes et il fonctionne parfaitement sur RHEL avec kvm
dyasny

Exact, et je pense que j'ai clairement montré dans la question la valeur de toutes les parties de la pile. Voyez-vous des informations manquantes ou quelque chose qui n'est pas configuré correctement?
larsks
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.