Джамбо кадри між гостем та господарем KVM?

Я намагаюся реалізувати 9000 байт MTU для зберігання зв'язку між гостями KVM та хост-системою. Хост має міст ( br1) з 9000 байт 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

Для цього мосту приєднаний інтерфейс до цього мосту, який також має 9000 байт MTU:

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

Я можу пінг від господаря до гостя:

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

Але якщо я збільшить розмір пакета ping понад 1490 байт, у мене більше не буде підключення:

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

Слід пакету показує, що ці пакети ніколи не доходять до гостя. Все, що я читав, вказує на те, що і мостовий інтерфейс Linux, і virtioмережа управляють усіма підтримками jumbo-кадрів, але це впевнено виглядає як проблема MTU для мене.

Я пропускаю щось дійсно очевидне?

Оновлення

Показано на стороні хоста гостьового інтерфейсу:

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

Хоча це була проблема MTU, виявляється, що вона не мала нічого спільного з налаштуваннями MTU на будь-якому з компонентних пристроїв. Як я показав в оригінальному запитанні, хост-міст, інтерфейс хосту і інтерфейс гостя мали всі однакові настройки MTU (9000 байт).

Актуальною проблемою була проблема конфігурації libvirt / kvm. За замовчуванням libvirt не використовує virtioпристрої. Якщо явна конфігурація відсутня, ви закінчите RealTek RTL-8139 NIC. Цей віртуальний NIC не підтримує рамки jumbo .

Для використання virtioпристроїв потрібно вказати чітку модель. При використанні virt-install:

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

Або після факту, додавши <model>тег до відповідного <interface>елемента в домені XML:

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

З цією зміною на місці все працює за призначенням.

щоб більша MTU працювала, весь стек повинен мати вищий MTU, який включає гостей, tapdevs та фізичні NIC, до яких приєднаний міст (якщо у вас є облігації та vlans - теж їх)