Jumbo frames entre o convidado KVM e o host?

Question

Estou tentando implementar uma MTU de 9000 bytes para comunicação de armazenamento entre convidados KVM e o sistema host. O host tem uma ponte ( br1 ) com uma 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

Os convidados têm uma interface anexada a essa ponte que também tem uma 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

Eu posso fazer ping do host para o convidado:

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

Mas se eu aumentar o tamanho do pacote de ping além dos 1490 bytes, não tenho mais conectividade:

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

Um rastreamento de pacote mostra que esses pacotes nunca alcançam o convidado. Tudo o que li indica que tanto a interface bridge do Linux quanto a virtio de drives de rede suportam frames gigantes, mas isso certamente parece um problema de MTU para mim.

Estou sentindo falta de algo realmente óbvio?

Atualizar

Mostrando o lado do host da interface do convidado:

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

    

Answer 1

Embora este seja um problema MTU, verifica-se que não tem nada a ver com as configurações de MTU em qualquer um dos dispositivos componentes. Como mostrei na pergunta original, a ponte do host, a interface do host e a interface do convidado tinham a mesma configuração de MTU (9000 bytes).

O problema real foi um problema de configuração do libvirt / kvm. Por padrão, libvirt não usa virtio devices. Na ausência de uma configuração explícita, você acaba com uma NIC RealTek RTL-8139. Este NIC virtual não suporta quadros jumbo .

Para usar virtio dispositivos, você precisa especificar um modelo explícito. Ao usar virt-install :

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

Ou após o fato, adicionando uma tag <model> ao elemento <interface> apropriado no domínio XML:

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

Com essa mudança, tudo funciona conforme o esperado.

    

Answer 2

para o MTU maior funcionar, toda a pilha precisa ter o MTU mais alto, que inclui os convidados, os tapdevs e os NICs físicos aos quais a ponte está conectada (se você tiver vínculos e vlans no caminho - eles também)