¿Tramas gigantes entre el huésped KVM y el host?


11

Estoy tratando de implementar una MTU de 9000 bytes para la comunicación de almacenamiento entre los invitados KVM y el sistema host. El host tiene un bridge ( br1) con una MTU de 9000 bytes:

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

Los invitados tienen una interfaz conectada a este puente que también tiene una MTU de 9000 bytes:

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

Puedo hacer ping desde el host al invitado:

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

Pero si aumento el tamaño del paquete de ping más allá de 1490 bytes, ya no tengo conectividad:

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

Un rastreo de paquetes muestra que estos paquetes nunca llegan al invitado. Todo lo que he leído indica que tanto la interfaz de puente de Linux como las virtiounidades de red son compatibles con tramas gigantes, pero esto seguramente me parece un problema de MTU.

¿Me estoy perdiendo algo realmente obvio?

Actualizar

Mostrando el lado del host de la interfaz de invitado:

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

¿Cuál es la MTU en la interfaz tun para la VM en el host?
mgorven

Eso también es 9000 bytes; He actualizado la pregunta con la salida de brctly ip addr showpara esa interfaz.
lanza

¿Qué es exactamente el sistema host?
Michael Hampton

Arch Linux, con Linux 3.6.10 (x86_64), qemu-kvm 1.2.0, libvirt 1.0.1.
lanza

Respuestas:


7

Si bien este era un problema de MTU, resulta que no tenía nada que ver con la configuración de MTU en ninguno de los dispositivos componentes. Como mostré en la pregunta original, el puente de host, la interfaz de tun de host y la interfaz de invitado tenían la misma configuración de MTU (9000 bytes).

El problema real era un problema de configuración de libvirt / kvm. Por defecto, libvirt no usa virtiodispositivos. En ausencia de una configuración explícita, termina con una NIC RealTek RTL-8139. Esta NIC virtual no admite tramas gigantes .

Para usar virtiodispositivos, debe especificar un modelo explícito. Al usar virt-install:

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

O después del hecho agregando una <model>etiqueta al <interface>elemento apropiado en el dominio XML:

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

Con este cambio en su lugar, todo funciona según lo previsto.


0

Para que la MTU más grande funcione, toda la pila debe tener la MTU más alta, que incluye a los invitados, los tapdevs y las NIC físicas a las que está conectado el puente (si tienes enlaces y vlans en el camino, también a ellos)


¿Sabes si ejemplos específicos, como GigaEthernet y más allá, donde esto sería el resultado de la negociación automática? Esta publicación puede ser un duplicado: google.com/…
ArrowInTree

no, tiene que hacerse manualmente, toda la pila establecida en la MTU más alta de cualquier componente dado
dyasny

Sí, me doy cuenta de eso; eso está bien documentado en todo el lugar. Como puede ver en la pregunta, los invitados, los tapdevs y el puente tienen el MTU más alto. ¿Ves algo mal configurado en los ejemplos que he dado?
larsks

para usar configuraciones de MTU no predeterminadas, todo debe cumplir con la MTU no predeterminada. Eso, de arriba a abajo, debe ser la NIC invitada, el grifo, el puente, eth (+ vlan + bond) debajo del puente y, por supuesto, el puerto del conmutador. Lo probé hace unos minutos y funciona perfectamente en RHEL con kvm
dyasny

Correcto, y creo que he mostrado claramente en la pregunta el valor en todas las partes de la pila. ¿Ves alguna información faltante o algo que no está configurado correctamente?
larsks
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.