Мы активно используем QinQ VLAN и были ограничены Linux bridge. Однако Linux Bridge не поддерживает VLAN, из-за чего возникали другие неудобства, с которыми постоянно приходилось бороться. Я также обновил Bugzilla, но рады сообщить, что поддержка 'dot1q-tunnel' в OVS работает прекрасно... Эрик Гарвер, ответственный за внедрение этого в OVS и ядро, опубликовал несколько очень интересных статей по производительности (программный QinQ сравним с аппаратным VXLAN) и применению:  
https://developers.redhat.com/blog/2017/06/06/open-vswitch-overview-of-802-1ad-qinq-support/  
https://developers.redhat.com/blog/2017/06/27/open-vswitch-qinq-performance/

Мы завершили тестирование и планируем перевести первые пару виртуальных роутеров и фаерволов в продакшен на эту технологию. Наши заметки:

1. Сначала запустите OVS с пакетами по умолчанию из Proxmox  
2. Скачайте Debian-бинарники для SID:  
https://packages.debian.org/sid/openvswitch-common  
https://packages.debian.org/sid/openvswitch-switch  
3. Обновите пакеты: dpkg -i *.deb; apt-get -f install;  
4. Примените патч к /usr/share/perl5/PVE/Network.pm

Код патча:  
--- /root/Network.pm    2018-02-19 12:41:12.000000000 +0200  
+++ /usr/share/perl5/PVE/Network.pm    2018-04-05 11:42:12.904719562 +0200  
@@ -251,9 +251,9 @@  
    $trunks =~ s/;/,/g if $trunks;

    my $cmd = "/usr/bin/ovs-vsctl add-port $bridge $iface";  
-    $cmd .= " tag=$tag" if $tag;  
-    $cmd .= " trunks=". join(',', $trunks) if $trunks;  
-    $cmd .= " vlan_mode=native-untagged" if $tag && $trunks;  
+    $cmd .= " vlan_mode=dot1q-tunnel tag=$tag other-config:qinq-ethtype=802.1q" if $tag;  
+    $cmd .= " cvlans=". join(',', $trunks) if $trunks && $tag;  
+    $cmd .= " trunks=". join(',', $trunks) if $trunks && !$tag;

    $cmd .= " -- set Interface $iface type=internal" if $internal;  
    system($cmd) == 0 ||  

Это устанавливает порт сетевого адаптера ВМ как 'dot1q-tunnel', который будет инкапсулировать все пакеты при входе и удалять внешний тег при выходе. Voilà — роутер на одной шине, фаервол на одной шине и т.д.

Настройка порта dot1q-tunnel работает безупречно, я бы настоятельно порекомендовал Proxmox рассмотреть возможность стандартизации на OVS и внедрения относительно простой патчи.

Запуск виртуальных файрволов или роутеров без необходимости большого количества интерфейсов возможен с использованием QinQ VLAN. Разные сайты, зоны или сервисы доставляются виртуальному гостю, поддерживающему VLAN, с помощью внешнего VLAN доставки клиента. Это фактически требует от Proxmox снимать внешний тег VLAN на выходе к виртуальной машине и оборачивать все фреймы, исходящие из виртуалки, в такой же VLAN тег.

Пример виртуального роутера:  
Код:  
vlan950 - Кастомер А  
vlan10 - интернет  
vlan11 - хостинг  
vlan12 - Сайт А  
vlan13 - Сайт Б  
vlan14 - Сайт В  

Пакет при выходе с хоста виртуальной машины будет иметь внешний тег 950 и внутренний тег 10, если он идет из виртуального роутера клиента в сторону интернета. Это можно реализовать либо с помощью запуска Proxmox с нелокальным Linux bridge, который не поддерживает VLAN, либо используя более свежий пакет openvswitch, чтобы использовать возможности QinQ VLAN в ядре версии 4.9 и новее.

Нелокальный Linux bridge — решение не идеальное, ведь при хостинге виртуальных роутеров и файрволов он будет путаться, так как исходящий MAC-адрес будет выглядеть, как будто приходит из разных направлений. Установка опции 'vlan_protocol' у VLAN-aware Linux bridge на 802.1ad (0x88a8), вместо стандартного 802.1Q (0x8100), может помочь, но тогда все коммутаторы и маршрутизаторы должны будут обрабатывать внешний тег как тег VLAN провайдера услуг.

Эрик Гарвер руководил разработкой QinQ VLAN патчей для OVS, а также изменениями в ядре. Он также публиковал информацию о производительности, показывая, что такой подход работает лучше, чем аппаратно-ускоренный VXLAN или GENEVE:  
https://developers.redhat.com/blog/2017/06/06/open-vswitch-overview-of-802-1ad-qinq-support/  
https://developers.redhat.com/blog/2017/06/27/open-vswitch-qinq-performance/

Proxmox версии 5.0 и выше содержит нужное ядро для поддержки этого из коробки, а также поддерживает более свежие версии OVS. Пакеты openvswitch 2.8.1+dfsg1-6 из Debian Sid стабильны и без проблем работают на Debian Stretch.

Применение патча к файлу '/usr/share/perl5/PVE/Network.pm' (описанному выше) просто превращает интерфейс ВМ в порт инкапсуляции и повышает безопасность, так как обмен VLAN будет невозможен — на порту просто не будет нативного VLAN. Это полностью совместимо с обычными хостами (например, Windows-гостями), но при этом даёт возможность использовать QinQ VLAN, когда это нужно.

Опция транкинга VLAN продолжает работать так же, как и сейчас.

Proxmox 6 теперь включает OvS 2.10, нужно всего лишь пропатчить /usr/share/perl5/PVE/Network.pm, как описано выше (изменить 3 строки). В любом случае спасибо за поддержку!

Всё работает как задумано: живая миграция, управление через GUI и так далее. Протестировано и работает в продакшене с нетегированными (trunks всех VLAN), выборочным trunking или указанием тега, в этом случае порт OvS инкапсулирует все пакеты, получаемые от ВМ. Это то же самое, что подключить файрвол или роутер к коммутатору Cisco, где порт настроен как 'dot1q-tunnel'.

Навряд ли без кастомизации GUI и скрипта, который вы уже редактировали. OvS поддерживает обработку двойной инъекции тегов на стороне хоста. Однако мы не делали патчи, так как рассматриваем OvS как обычный стандартный коммутатор. Мы транзитируем все или выбранные VLAN на несколько виртуальных маршрутизаторов и подключаем серверы, маршрутизаторы арендаторов и межсетевые экраны через режим dot1q-tunnel. Виртуальные устройства могут накладывать столько тегов, сколько нужно, используя максимальный размер MTU системы (обычно 64KiB), после чего пакет передается для аппаратного оффлоада, который либо передаст пакет как есть, либо добавит тег. То есть: виртуальные маршрутизаторы, межсетевые экраны и серверы могут использовать свои VLAN, а порт dot1q-tunnel выступит как инкапсулятор для всего. Виртуальная машина будет работать в VLAN 10, Proxmox добавит VLAN 50.

Привет! В посте Эрика Гарвера подробно описаны примеры настройки портов QinQ на стороне OvS, чтобы ВМ могла работать просто с нетегированными пакетами. Сейчас у нас такой задачи нет, и для этого требуется настроить две отдельные правила для входящего и исходящего трафика каждого интерфейса ВМ. Вот ссылка на пост: https://developers.redhat.com/blog/2017/06/06/open-vswitch-overview-of-802-1ad-qinq-support/

Кратко по сути:  
ovs-vsctl set Open_vSwitch . other_config:vlan-limit=2  
ovs-appctl revalidator/purge  
ovs-ofctl in_port=1 action=push_vlan:0x88a8,mod_vlan_vid=1000,output:2  
ovs-ofctl in_port=2 action=pop_vlan,output:1  

P.S. Первые две команды глобально настраивают OvS на обработку двух VLAN-тегов и, скорее всего, их стоит добавить в скрипт инициализации системы. Третю и четвёртую команды надо запускать из скрипта /usr/share/perl5/PVE/Network.pm, там, вероятно, понадобится дополнительная логика для определения номеров портов OvS для этих действий.

Для сравнения: режим dot1q-tunnel во многом автоматизирует процесс, требуя всего одной команды. Вот так QinQ пакеты при этом принимаются с тегами VLAN 100 или 200:  
ovs-vsctl set port ovs-p0 vlan_mode=dot1q-tunnel tag=1000 cvlans=100,200

Как я пытался объяснить выше, у нас в основном работают виртуальные маршрутизаторы и файрволы с VLAN, а все пакеты, уходящие из ВМ, дополнительно оборачиваются в VLAN. В итоге пакет становится QinQ-тегированным, при этом ВМ обрабатывает внутренние теги, а OvS просто добавляет и снимает внешние.

Это именно то поведение, которого я сейчас пытаюсь достичь. Я вношу предложенные изменения в нашу тестовую систему, но понимаю, что боюсь использовать эту конфигурацию до её нативной реализации, так как возврат назад может быть проблемой. Я не видел никаких обновлений по фактической нативной реализации этой функции. Есть ли какой-то прогресс по поводу OVS в PVE 6 с использованием dot1q-tunneling?