Я пытаюсь реализовать MTU размером 9000 байт для обмена данными между гостевыми KVM-устройствами и хост-системой. У хоста есть мост (br1) с размером MTU 9000 байт:
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
У гостей есть интерфейс, подключенный к этому мосту, который также имеет MTU 9000 байт:
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 на каком-либо из компонентных устройств. Как я показал в исходном вопросе, хост-мост, хост-интерфейс tun и гостевой интерфейс имели одинаковую настройку MTU (9000 байт).
Фактическая проблема заключалась в проблеме конфигурации libvirt / kvm. По умолчанию libvirt делает не использовать virtio устройств. При отсутствии явной конфигурации вы получаете сетевую карту RealTek RTL-8139. Эта виртуальная сетевая карта не поддерживает 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 и физические сетевые адаптеры, к которым подключен мост (если у вас есть связи и vlan на пути - их тоже)