LACP между 22.04 и Open vSwitch: Ubuntu не отвечает и не отправляет LACP PDU

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

У меня есть свежий Ubuntu 22.04, работающий в KVM с 6 интерфейсами virtio, эмулирующими e1000. Это подключено к Open vSwitch, и LACP настроен как на коммутаторе, так и на Ubuntu.

Суть моей проблемы заключается в том, что когда я выполняю tcpdump на любом интерфейсе в bond0, я вижу LACP pdu, отправленный ovs, но ответа от Ubuntu не видно. Ubuntu, похоже, также не отправляет LACP pdu самостоятельно.

Мои конфигурационные данные следующие:

/etc/netplan/00-installer-config.yaml

  bonds:
    bond0:
      addresses: [192.168.201.141/24]
      interfaces:
        - enp2s0
        - enp3s0
        - enp4s0
        - enp5s0
        - enp6s0
        - enp7s0
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100

ip link

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:bd:d6:54 brd ff:ff:ff:ff:ff:ff
3: enp2s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 32:4c:6b:d8:b0:dc brd ff:ff:ff:ff:ff:ff permaddr 52:54:00:aa:fb:bb
4: enp3s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 32:4c:6b:d8:b0:dc brd ff:ff:ff:ff:ff:ff permaddr 52:54:00:0d:61:fc
5: enp4s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 32:4c:6b:d8:b0:dc brd ff:ff:ff:ff:ff:ff permaddr 52:54:00:d4:cc:88
6: enp5s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 32:4c:6b:d8:b0:dc brd ff:ff:ff:ff:ff:ff permaddr 52:54:00:79:8e:a0
7: enp6s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 32:4c:6b:d8:b0:dc brd ff:ff:ff:ff:ff:ff permaddr 52:54:00:24:36:a7
8: enp7s0: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bond0 state UP mode DEFAULT group default qlen 1000
    link/ether 32:4c:6b:d8:b0:dc brd ff:ff:ff:ff:ff:ff permaddr 52:54:00:c7:90:3c
9: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 32:4c:6b:d8:b0:dc brd ff:ff:ff:ff:ff:ff

Я вижу, что все ссылки в состоянии UP.

/proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v5.15.0-86-generic

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2 (0)
MII Status: up
MII Polling Interval (ms): 100  
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0 

802.3ad info
LACP active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: 32:4c:6b:d8:b0:dc
Active Aggregator Info:
        Aggregator ID: 1
        Number of ports: 1
        Actor Key: 0
        Partner Key: 1
        Partner Mac Address: 00:00:00:00:00:00

Slave Interface: enp7s0
MII Status: up
Speed: Unknown
Duplex: Unknown
Link Failure Count: 0
Permanent HW addr: 52:54:00:c7:90:3c
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: churned
Actor Churned Count: 0
Partner Churned Count: 1
details actor lacp pdu:
    system priority: 65535
    system mac address: 32:4c:6b:d8:b0:dc
    port key: 0
    port priority: 255
    port number: 1
    port state: 77
details partner lacp pdu:
    system priority: 65535
    system mac address: 00:00:00:00:00:00
    oper key: 1
    port priority: 255
    port number: 1
    port state: 1
<snip>

Вывод выше показывает детали actor и partner pdu, но tcpdump не показывает, что pdu отправляется от Ubuntu.

Также скорость и дуплекс неизвестны, возможно, это связано с тем, что подлежащий интерфейс virtio, но может ли это быть причиной того, что Ubuntu не отправляет LACP pdu?

Вот как интерфейс описан в kvm:

   <interface type="bridge">
      <mac address="52:54:00:d4:cc:88"/>
      <source bridge="ovsbr-lacp0"/>
      <virtualport type="openvswitch">
        <parameters interfaceid='0e117751-fd45-4840-9c30-41ea8f76bdce'/>
      </virtualport>
      <model type="e1000"/>
      <address type="pci" domain='0x0000' bus="0x04" slot="0x00" function='0x0'/>
    </interface>

Это вывод tcpdump, который виден как на Open vSwitch, так и в Ubuntu. fe:54:00:c7:90:3c — это MAC одного из подчиненных интерфейсов в ovs, а a6:a0:01:43:3a:41 — это MAC интерфейса bond в ovs.

tcpdump -evni enp7s0

tcpdump: listening on enp7s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
19:41:47.129221 fe:54:00:c7:90:3c > 01:80:c2:00:00:02, ethertype Slow Protocols (0x8809), length 124: LACPv1, length 110
        Actor Information TLV (0x01), length 20
          System a6:a0:01:43:3a:41, System Priority 65534, Key 15, Port 17, Port Priority 65535
          State Flags [Activity, Aggregation, Collecting, Distributing, Default]
        Partner Information TLV (0x02), length 20
          System 00:00:00:00:00:00, System Priority 0, Key 0, Port 0, Port Priority 0
          State Flags [none]
        Collector Information TLV (0x03), length 16
          Max Delay 0
        Terminator TLV (0x00), length 0

Ubuntu, похоже, не читает этот пакет и не отправляет на него ответ, она даже не генерирует свою собственную LACP pdu.

В dmesg я вижу такие логи:

[ 4722.457866] bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond
[ 4752.513642] bond0: Warning: No 802.3ad response from the link partner for any adapters in the bond

Что странно, потому что я вижу пакеты, отправленные ovs в tcpdump.

Есть один связанный вопрос на serverfault, который, похоже, отвечает на мою ситуацию.

Я проверил все на стороне ovs, и эта тема показывает результаты.

Я исчерпал все свои методы отладки, и любые подсказки, чтобы заставить это работать, будут非常 оценены.

X.

Я снова попробовал это на другом наборе ВМ, и теперь это работает!

Разница, которую я вижу, заключается в том, что я добавил интерфейсы в yml netplan, то есть:

network:
  ethernets:
    ens1:
      addresses:
      - 192.168.200.148/24
      nameservers:
        addresses:
        - 8.8.8.8
        - 8.8.4.4
      routes:
      - to: default
        via: 192.168.200.1
    enp2s11:
      dhcp4: no
    enp2s12:
      dhcp4: no
    enp2s13:
      dhcp4: no
    enp2s14:
      dhcp4: no
    enp2s15:
      dhcp4: no
    enp2s16:
      dhcp4: no
    enp2s17:
      dhcp4: no
    enp2s18:
      dhcp4: no
  bonds:
    bond0:
      addresses: [192.168.201.141/24]
      interfaces:
         - enp2s11
         - enp2s12
         - enp2s13
         - enp2s14
         - enp2s15
         - enp2s16
         - enp2s17
         - enp2s18
      parameters:
        mode: 802.3ad
        mii-monitor-interval: 100
  renderer: networkd
  version: 2

Если вы заметите, устройство enp2s11 добавлено дважды, первый раз под ethernets, а затем под bond:interfaces. Это единственное изменение, о котором я могу подумать, в сравнении с предыдущей конфигурацией.

На стороне OVS:

sudo ovs-appctl bond/show bond0
---- bond0 ----
bond_mode: active-backup
bond may use recirculation: no, Recirc-ID : -1
bond-hash-basis: 0
lb_output action: disabled, bond-id: -1
updelay: 0 ms
downdelay: 0 ms
lacp_status: negotiated
lacp_fallback_ab: false
active-backup primary: <none>
active member mac: fe:54:00:7c:71:79(vnet365)

member vnet365: enabled
  active member
  may_enable: true

member vnet366: enabled
  may_enable: true

member vnet367: enabled
  may_enable: true

member vnet368: enabled
  may_enable: true

member vnet369: enabled
  may_enable: true

member vnet370: enabled
  may_enable: true

member vnet371: enabled
  may_enable: true

member vnet372: enabled
  may_enable: true

Я могу пинговать между другим хостом в одной сети/коммутаторе, и поэтому, думаю, это работает нормально.

У меня была точно такая же проблема, и когда я выполнил следующую команду:

cat /proc/net/bonding/bond0

я увидел это:

Ethernet Channel Bonding Driver: v5.15.0-78-generic

Bonding Mode: load balancing (round-robin)```

Таким образом, mode: 802.3ad не был применен, мне пришлось перезагрузить сервер или выполнить это, чтобы действительно применить изменения:

ip link del dev bond0 && netplan apply

У меня была такая же проблема, как у вас. Может быть, это будет интересно, но моя проблема заключалась в автооговорке на виртуальном Ubuntu 22.04. Коммутатор ARISTA и Ubuntu провели обмен LACP, но процесс застрял на согласовании скорости, что я увидел в syslog и также заметил статус на стороне коммутатора.

Мне нужно было принудительно установить виртуальные ссылки Ubuntu на 1000, и после этого все заработало как часы. 🙂

Всего наилучшего,

Герго

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

Решение проблемы LACP между Ubuntu 22.04 и Open vSwitch

Введение

Виртуализация и настройка сетевых интерфейсов в окружении KVM с использованием Open vSwitch (OVS) часто создают сложности, особенно когда дело касается динамического объединения каналов с использованием протокола LACP (Link Aggregation Control Protocol). В этом ответе мы проанализируем проблему отсутствия ответов на LACP PDU (Protocol Data Unit) со стороны Ubuntu 22.04 и предложим шаги для её устранения.

Описание проблемы

Вы указали, что при настройке Ubuntu 22.04 на KVM с использованием интерфейсов VirtIO Virtual (эмулирующих e1000) не видно ответов на LACP PDU от системы, хотя OVS отправляет такие пакеты. Результатом этого является отсутствие успешного создания агрегированных каналов связи. Проверка состояния сети, а также выводы из таких инструментов, как tcpdump и cat /proc/net/bonding/bond0, показывают, что:

  • Все интерфейсы в состоянии UP.
  • Проблема заключается в том, что система не отправляет собственные LACP PDU, что подтверждается отсутствием соответствующих записей в выводе tcpdump.
  • Прежние сообщения в нем сообщают о том, что нет ответа на запросы LACP от партнёра по объединению.

Потенциальные причины проблемы

  1. Неправильная настройка сети: Ваша конфигурация сетевого интерфейса может включать элементы, не поддерживаемые вашим оборудованием или программным обеспечением.
  2. Недостаточная поддержка VirtIO: Интерфейсы VirtIO могут иметь некоторые ограничения в отношении поддержки LACP.
  3. Ошибки или неоптимальные значения в конфигурациях Open vSwitch: Неправильная или несовместимая версия OVS или его настроек может привести к проблемам совместимости.
  4. Производительность / настройки других параметров сети: Возможные проблемы с автоопределением скорости и дуплекса могут влиять на взаимодействие.

Шаги по устранению неполадок

  1. Проверка конфигурации Netplan: Убедитесь, что в вашем файле конфигурации /etc/netplan/00-installer-config.yaml все интерфейсы правильно указаны. Возможно, вы добавили интерфейсы в два места, что может быть причиной проблемы (как было отмечено в ваших последующих тестах).

  2. Перезагрузка или применение изменений: Если изменения в конфигурации не были применены, имейте в виду, что возможно потребуется либо перезагрузка сервера, либо удаление bond0 и повторное его создание с помощью команд ip link del и netplan apply.

  3. Настройка параметров скорости и дуплекса: Рассмотрите возможность принудительной установки скорости и дуплекса для ваших виртуальных интерфейсов. Например, использование команды:

    ip link set dev enp2s0 speed 1000 duplex full

    Это изменение может помочь решить проблемы с автоопределением.

  4. Использование инструмента ovs-vsctl для проверки статуса OVS: Команда sudo ovs-vsctl list interface может помочь в диагностике интерфейсов и их статуса.

  5. Обновление версий: Убедитесь, что вы используете последние версии Ubuntu и Open vSwitch, так как обновления часто содержат исправления ошибок и улучшения производительности.

Заключение

Проблемы с LACP в Ubuntu 22.04 в окружении Open vSwitch могут быть вызваны множеством факторов, и эффективное решение требует системного подхода к диагностике и устранению неисправностей. Проведя вышеуказанные проверки конфигурации и настройки, вы можете выявить и устранить скорее всего причину, по которой Ubuntu не отправляет LACP PDU, что в свою очередь должно обеспечить успешное установление и функционирование агрегированных каналов.

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

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