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


11

Я намагаюся реалізувати 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 в інтерфейсі tun для VM на хості?
mgorven

Це також 9000 байт; Я оновив питання з результатами brctlта ip addr showдля цього інтерфейсу.
larsks

Яка саме система хостів?
Майкл Хемптон

Arch Linux, з Linux 3.6.10 (x86_64), qemu-kvm 1.2.0, libvirt 1.0.1.
larsks

Відповіді:


7

Хоча це була проблема 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>

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


0

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


Чи знаєте ви, якщо на конкретних прикладах, таких як GigaEthernet і далі, де це буде результатом автоматичних переговорів? Ця публікація може бути дублікатом: google.com/…
ArrowInTree

ні, це потрібно робити вручну, весь стек встановлений на найвищий MTU будь-якого компонента
діасний

Так, я усвідомлюю це; це добре документально підтверджено всюди. Як видно із запитання, у гостей, тапдеїв та мосту все вище MTU. Чи бачите ви щось неправильно налаштоване в приведених нами прикладах?
larsks

щоб використовувати налаштування MTU, які не використовуються за замовчуванням, все повинно відповідати MTU, що не використовується за замовчуванням. Це зверху вниз має бути гостьовим NIC, краном, мостом, eth (+ vlan + bond) під мостом, і, звичайно, порт комутатора. Я перевірив це лише кілька хвилин тому, і він ідеально працює на RHEL з kvm
діасний

Правильно, і я думаю, що я чітко показав у питанні значення у всіх частинах стеку. Ви бачите будь-яку відсутні інформацію або щось неправильно налаштоване?
larsks
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.