Про qemu и протокол 802.1p

Наткнулся на днях на довольно забавный артефакт, и решил поделиться. Потому что в гугле по этому поводу — чуть лучше «белого шума».

В общем, довелось поднимать «playground» на платформе Cisco UCS. Немного б/у и не без странностей, но речь сейчас не об этом. Для запуска всякой телематики и управляющего ядра openStack в наших краях используется «греческий» (в свете последних новостей про linux, кавычки здесь могут исчезнуть) GANETI. Proxmox и прочие XCP в своё время были для этой цели забракованы как чересчур сложные. А команда собралась достаточно сильная для того чтобы добавить желаемые «мелочи».

Схемотехника подобрана так чтобы было практически нечему падать. Всё основное запускается в нативном (растегированном) vlan. (Обычный 802.1q для максимизации производительности. L3+ — между датацентрами.) Ещё пара vlan — для приоритизации вспомогательного трафика. Никаких network manager’ов/openvswitch’ей. (Openvswitch — на следующем уровне абстракции, и у меня именно про него нет интересных историй. Что, согласитесь, определённым образом продукт характеризует.)

Ключевые виртуальные машины (ВМ) также едут в нативном vlan. Решение не без изъянов (на прикрученные к обычному linux-бриджу tap-интерфейсы ВМ в таком режиме попадают тегированные пакеты с разведённых на том же бридже vlan). Но за полтора десятка лет эксплуатации сюрпризов именно там не случалось.

Теперь, обрисовав общую картину, перехожу к делу. Выпускаю первую ВМ. По сети не пингуется. Локально с гипервизора — всё ок. Лезу на консоль, запускаю что-то типа "tcpdump -nvvvi any" (по-умолчанию выставляется promisc-режим) — ping побежал. Выключаю tcpdump — опять глухо. При запуске с ключом «-p» (запретить неразборчивый режим) tcpdump вообще ничего не видит.

Причина, очевидно, локализуется в (virtio-)network.

Как говорил один киногерой в полосатом свитере, «посмотрим поглубже». При внимательном рассмотрении видно, что «правый хвост длиннее левого». «Туда» улетают 42 байта, а обратно тот же ARP-кадр (who-has и ответ имеют одинаковый размер) возвращается в пакете 54 байта. Потому что на него навешен дополнительно 802.1q заголовок, только с vlan id = 0 (изначально его резервировали для служебных целей). Беглое гугление показывает, что так работает относительно свежая реализация протокола 802.1p (способ таскать информацию о приоритетах трафика). «Давайте мы будем отправлять кадр без метки с меткой 0», как-то так.

Вот так оно смотрится в tcpdump на входе в гипервизор:

# tcpdump -nvvvi bond0 -e dst host 172.x.x.x | head 15:07:32.847072 00:3a:9c:57:51:fc > ae:9b:f1:f1:90:83, ethertype 802.1Q (0x8100), length 70: vlan 0, p 0, ethertype IPv4, (tos 0x0, ttl 62, id 44387, offset 0, flags [DF], proto

Дальше в подробности лезть не стал, т.к. это — «не мой хлеб». Предложение коллегам переключить политику на UCS с «Platinum» на что-нибудь попроще также энтузиазма не вызвало (оно в целом понятно, новая же игрушка). Ну ладно, «мы и сами с усами»…

QEMU у нас достаточно свежий (из Oracle appStream), и с этой стороны ловить особо нечего. Или потом на досуге поразбираться, или тупо сдать багу. (Понятно что в промышленной эксплуатации именно такой usecase не собирал примерно никто, поэтому до сих пор и осталось незамеченным.) Поэтому, сразу переходим к «плану Б».

Пытаться снять нулевой тег «в лоб» представляется довольно дурной затеей. Даже если удастся пропатчить модуль для работы с vlan, это будет лютый эксклюзив. Сразу смотрим в сторону «ip» ("ip filter" etc.), т.к. он (в принципе) позволяет проделать большинство из тех фокусов, для которых в своё время во freeBSD придумали «netmap»netgraph.

Есть у меня пакетик «network-scripts-extra», дополняющий функциональность «network-scripts» всякими macvlan’ами, veth’ами и прочими приятными вещами. Там же лежит сценарий «ifup-eth-bond» для автоматизации настройки буферов и очередей на «физике». Ну и QoS, «до кучи». В принципе, ничего секретного, постараюсь как-нибудь выложить. (Но, скорее всего, ближе ко взятию на сопровождение объявленного устаревшим «network-scripts». Потому что замены с приемлемыми ТТХ тупо не предложено, а бороться с «фатальным недостатком» — не в моих привычках.)

Для работы со входящими «очередями» есть в «tc qdisc» такая специальная дисциплина «ingress». Полагаю, даже не слишком подкованный в сетевых кунштюках читатель сообразит, что это не совсем «очередь» (пакет-то уже́ принят!). Обычно эта штука используется чтобы «заполисить» входящий трафик (грубо откинуть входящие пакеты сверх какого-то лимита). Здесь мы её задействуем для более интересных манипуляций.

Дополненный кусок «ifup-eth-bond» теперь выглядит так:

# tc -d -s qdisc show dev em1 tc qdisc del dev ${DEVICE} root # >> net.core.default_qdisc=fq_codel tc qdisc replace dev ${DEVICE} handle ffff: ingress tc qdisc replace dev ${DEVICE} root handle 1: htb default 0 # tc -d -s class show dev em1 tc class add dev ${DEVICE} parent 1:1 classid 1:10 htb prio 1 rate ${SPEED}gbit tc class add dev ${DEVICE} parent 1:1 classid 1:20 htb prio 2 rate ${SPEED}gbit tc class add dev ${DEVICE} parent 1:1 classid 1:30 htb prio 3 rate ${SPEED}gbit tc qdisc add dev ${DEVICE} parent 1:10 handle 10: pfifo_fast  # Multi-band pfifo_fast for VM's like the default # Since UEKR7 kernels, multiq needs "kernel-uek-modules-extra" to be installed. if modprobe sch_multiq; then   # Try to use hardware queues   tc qdisc add dev ${DEVICE} parent 1:20 handle 20: multiq || tc qdisc add dev ${DEVICE} parent 1:20 handle 20: fq_codel else   tc qdisc add dev ${DEVICE} parent 1:20 handle 20: fq_codel fi  tc qdisc add dev ${DEVICE} parent 1:30 handle 30: pfifo_fast # tc -d -s filter show dev em1 tc filter add dev ${DEVICE} protocol all prio 10 basic match "meta(vlan mask 0xfff eq ${VLAN_LOW_PRIO})" flowid 1:30 tc filter add dev ${DEVICE} protocol all prio 10 basic match "meta(vlan mask 0xfff eq ${VLAN_HIGH_PRIO})" flowid 1:10 tc filter add dev ${DEVICE} protocol all prio 100 u32 match u32 0 0 flowid 1:20               # default, neutral prio # "Untag" vlan 0 from 802.1p in native vlan (ingress) #tc filter add dev ${DEVICE} parent ffff: protocol 802.1q basic match 'meta(vlan eq 0)' action vlan pop continue tc filter add dev ${DEVICE} parent ffff: protocol all basic match "meta(vlan mask 0xfff eq 0)" action vlan pop continue

○ Скорость на интерфейсе обычно можно подглядеть в «/sys/class/net/», хотя бывают нюансы.

• Создаём пару qdisc («оттуда» ingress и «туда» htb). ○ HTB даёт минимальный оверхед из протестированных. Гипервизору есть чем заняться, кроме как таскать сетевой трафик.

• Расписываем по классам 3 приоритета: управляющий канал, общая толпа (её, по возможности, оффлоадим на multiq) и «что осталось».

• Загоняем фильтрами исходящий трафик по классам, в зависимости от метки vlan.

• И, наконец, во входящем трафике ищем пакеты с заголовком 802.1Q (0x8100) и меткой vlan 0. И командуем растегировать. ○ Со стороны маршрутизатора срабатывает только "meta(vlan mask 0xfff eq 0)". Потому что https://en.wikipedia.org/wiki/IEEE_P802.1p, а lunux "meta(vlan)" зачем-то захватывает и верхние биты тоже.

¿ Почему я вместо «all» не указал «802.1q»? Просто побоялся ещё какой-нибудь глюк поймать. Приоритизация вылизана за последний десяток лет, влияние на производительность — на уровне стат. погрешности. Пускай остаётся «all». (Но «802.1q» — лучше читается, да. )

Всё. Надеюсь, эта заметка кому-нибудь пригодится.