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

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

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.

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)