Интерфейсы SR-IOV VF не поднимаются при перезагрузке, если я создаю на них мост.

Вопрос или проблема

Я использую Proxmox VE 8.3 (основан на Debian), установленный на машине с двухпортовым SFP+ NIC (X710-DA2). Я настроил свои SR-IOV VF’ы с использованием этих правил udev:

ACTION=="add", SUBSYSTEM=="net", ENV{INTERFACE}=="enp1s0f0np0", ATTR{device/sriov_numvfs}="3"
ACTION=="add", SUBSYSTEM=="net", ENV{INTERFACE}=="enp1s0f1np1", ATTR{device/sriov_numvfs}="3"

Я настроил свои интерфейсы следующим образом, чтобы объединить два VF, а затем создать мост на объединении:

auto lo
iface lo inet loopback

auto enp1s0f0v0
iface enp1s0f0v0 inet manual

auto enp1s0f1v0
iface enp1s0f1v0 inet manual

auto bond0
iface bond0 inet manual
        bond-slaves enp1s0f0v0 enp1s0f1v0
        bond-miimon 100
        bond-mode active-backup
        bond-primary enp1s0f0v0

auto vmbr0
iface vmbr0 inet manual
        bridge-ports bond0
        bridge-vlan-aware yes
        bridge-vids 2-4094
        bridge-stp off
        bridge-fd 0

auto vmbr0.10
iface vmbr0.10 inet static
        address 10.7.0.20/24
        gateway 10.7.0.1

source /etc/network/interfaces.d/*

Если я настрою все после загрузки системы и выполню ifreload -a, это работает. Но если я перезагружаюсь, интерфейсы не поднимаются:

> ip link
2: enp1s0f0np0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 68:05:ca:9b:d6:84 brd ff:ff:ff:ff:ff:ff
    vf 0     link/ether ba:4e:ac:fb:fe:ef brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
    vf 1     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
    vf 2     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
3: enp1s0f1np1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 68:05:ca:9b:d6:85 brd ff:ff:ff:ff:ff:ff
    vf 0     link/ether ba:4e:ac:fb:fe:ef brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
    vf 1     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off
    vf 2     link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

5: enp1s0f0v0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN mode DEFAULT group default qlen 1000
    link/ether ba:4e:ac:fb:fe:ef brd ff:ff:ff:ff:ff:ff
6: enp1s0f1v0: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN mode DEFAULT group default qlen 1000
    link/ether ba:4e:ac:fb:fe:ef brd ff:ff:ff:ff:ff:ff

11: bond0: <NO-CARRIER,BROADCAST,MULTICAST,MASTER,UP> mtu 1500 qdisc noqueue master vmbr0 state DOWN mode DEFAULT group default qlen 1000
    link/ether ba:4e:ac:fb:fe:ef brd ff:ff:ff:ff:ff:ff
12: vmbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether ba:4e:ac:fb:fe:ef brd ff:ff:ff:ff:ff:ff
13: vmbr0.10@vmbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state LOWERLAYERDOWN mode DEFAULT group default qlen 1000
    link/ether ba:4e:ac:fb:fe:ef brd ff:ff:ff:ff:ff:ff

Выполнение ifreload -a или ifup enp1s0f0v0 enp1s0f1v0 проходят успешно, но фактически не поднимают интерфейсы. Если я сначала выполню ifdown enp1s0f0v0 enp1s0f1v0, то любая из команд успешно поднимет интерфейсы, и когда все поднято, сеть работает как ожидалось.

В dmesg или журналах ifupdown2 (https://pastebin.com/V69L8Wjg) нет ничего, что указывало бы на ошибку. Более того, логи ifupdown2 показывают выполнение команд для поднятия всего!

Теперь возникает нечто странное… если я убираю мост и ставлю статический IP на объединение, все прекрасно работает. (См. логи ifupdown2 – https://pastebin.com/feU1bChf).

auto lo
iface lo inet loopback

auto enp1s0f0v0
iface enp1s0f0v0 inet manual

auto enp1s0f1v0
iface enp1s0f1v0 inet manual

auto bond0
iface bond0 inet static
        bond-slaves enp1s0f0v0 enp1s0f1v0
        bond-miimon 100
        bond-mode active-backup
        bond-primary enp1s0f0v0
       address 10.1.0.20/24
       gateway 10.1.0.1

source /etc/network/interfaces.d/*

Точно так же, если я использую настоящие сетевые карты (т.е. PF) с желаемой сетевой конфигурацией, все также работает отлично. Так что что-то в комбинации VF’ов и моста вызывает проблемы.

Это должно быть какое-то состояние гонки, потому что я могу поднять все после загрузки. Я подозреваю, что это связано либо с назначениями MAC-адресов, либо с драйверами, но я не могу понять, что попробовать дальше. Любая помощь будет очень признательна!!

Ответ или решение

Ваш случай с Proxmox VE, где SR-IOV VF интерфейсы не поднимаются после перезагрузки, когда вы устанавливаете мост над ними, иллюстрирует типичную проблему конфигурации виртуализации сетей с использованием SR-IOV и бриджинга. Давайте рассмотрим более подробно, что может происходить и какие решения могут помочь исправить данную ситуацию.

Теория

Сетевые интерфейсы системы на основе SR-IOV предназначены для поднятия производительности сетевого трафика путем создания Виртуальных Функций (VF), которые позволяют предоставить виртуальные сетевые интерфейсы виртуальным машинам. Ваша конфигурация предполагает использование PCIe карты Intel X710, для которой вы создали три виртуальные функции на каждом из портов, используя правила udev.

Когда вы создаете мост (bridge) над интерфейсами, особое внимание должно уделяться последовательности поднятия инициализации интерфейсов. Проблемы с запуском мостового интерфейса над VF могут возникнуть из-за нескольких факторов, включая порядок загрузки, управление MAC-адресами и состояние интерфейсов.

Возможная причина может заключаться в некорректном порядке инициализации при загрузке, где определенные события происходят до того, как все компоненты (VF и их родительские интерфейсы, мосты) оказываются полностью готовы для соединения. Мост VMbr, возможно, пытается подняться до того, как его подчиненные интерфейсы готовы.

Пример

Ваш пример конфигурации сетевых интерфейсов показывает, что мост VMbr0 работает поверх канала bond0, который, в свою очередь, объединяет два VF из X710. Однако когда вы делаете post-boot настройку через ifreload -a, все успешно работает — это указывает на возможную временную или последовательностную проблему или наличие некоего условия состязания (race condition).

Также ваше объяснение, что задание статического IP адреса на канал bond0 работает безупречно на уровне загрузки, когда мост отсутствует, ещё больше намекает на серьёзное влияние временного фактора.

Применение

  1. Отложенный запуск: Попробуйте настроить отложенный запуск для ваших VF. Это можно сделать, установив зависимости для системных сервисов, например, через systemd или конфигурационные скрипты в /etc/network/interfaces. Попробуйте воспользоваться pre-up скриптами, чтобы убедиться, что VF готовы до того, как начнется поднятие моста.

  2. MAC-адреса и драйверы: Проверьте, чтобы MAC-адреса ваших VMbr не совпадали с MAC VF, поскольку это может нарушить корректность сетевой работы. Убедитесь, что используемые вами драйверы (например, ixgbevf для Intel SR-IOV) имеют возможность корректной работы с бриджами. Вы можете протестировать их обновление или проверку на наличие известных проблем.

  3. Консистентные правила udev: Убедитесь, что правила udev срабатывают корректно и VF действительно создаются и настраиваются до того, как networking.service начинает свою работу.

  4. Логи и отладочные данные: Пересмотрите доступные логи, возможно, увеличив их уровень детализации. Это может быть сделано для системных журналов и журналов конкретных сетевых компонентов.

  5. Тестирование изменения конфигурации: Попробуйте изменить и тестировать настройки конфигурации для увеличения вероятности воспроизведения и выявления проблемы. Например, протестируйте с отключением VLANs или изменением режима агрегации (например, активированный режим bond0 можно заменить на 802.3ad).

  6. Управление состоянием интерфейсов: Используйте скрипты или сетевые хуки для управления последовательностью поднятия интерфейсов их состояний, используя if-up/if-down скрипты, которые гарантируют, что целевые интерфейсы загружаются в предполагаемом порядке.

Если выполнить все вышеупомянутые шаги, вы можете найти потенциальные причины осуществления некорректного перехода интерфейсов в состояние UP в вашем окружении. Варианты обхода такого рода проблем часто требуют точной отладки и тестирования, поскольку их повторение и устранение могут варьироваться в зависимости от особенностей инфраструктуры.

Оцените материал
Добавить комментарий

Капча загружается...