ALT Linux Bugzilla – #45305

(Ответ для Сергей Иванов на комментарий #0)
> При попытке добавить port ovs с нужным вланом к ovs vmbr0 мосту, сеть падает.
> Выяснил, что  причина падения - строчка 
> host='bond0 vlan30' которая при этом генерится в файле options моста vmbr0

  Пожалуйста, пришлите содержимое каталогов /etc/net/ifaces/*
  (все файлы, можно текстом).

> Если убрать vlay30 из нее то все стартует, но тогда ломается конфигурация в
> самом PVE

  Что значит "ломается конфигурация в самом PVE"? Скриншот или описание?

Столкнулся с аналогичной проблемой.

Бридж openvswitch с агрегацией (bonding) - работает
Бридж openvswitch с внутренним(internal) портом - работает
Бридж openvswitch агрегацией И внутренним портом - НЕ РАБОТАЕТ

Created attachment 12897 [details]
рабочая конфигурация(ovs bridge + bond)

Created attachment 12898 [details]
нерабочая конфигурация(ovs bridge + bond + internal port)

После применения настроек нерабочей конфигурации через веб-интерфейс Proxmox, сеть выглядит следующим образом:

[root@altvlag01 ~]# ovs-vsctl show
15c6f70f-d9aa-433c-bef7-7c7f6f3a182e
    ovs_version: "2.16.1"

[root@altvlag01 ~]# ip link show
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: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:b1:1f:5d brd ff:ff:ff:ff:ff:ff
    altname enp11s0
3: ens224: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:b1:45:e1 brd ff:ff:ff:ff:ff:ff
    altname enp19s0
4: ens256: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:b1:31:8c brd ff:ff:ff:ff:ff:ff
    altname enp27s0
18: vmbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN mode DEFAULT group default qlen 1000
    link/ether ae:e3:a0:c2:54:d4 brd ff:ff:ff:ff:ff:ff

Ничего, связанного с Openvswitch нет. Перезагрузка не помогает - конфигурация сети после перезагрузки остаётся такой же нерабочей - никакого упоминания об Openvswitch.

Данная проблема присутствует в Альт Линукс СП на текущий момент, есть ли решение проблемы?

Очень нужно экспертное мнение человека, разбирающегося в скриптах etcnet. Миша?

Поддержку ovs в etcnet делал не я. А вообще надо поднимать стенд в проблемной конфигурации и отлаживать.

в моём случае pve создает файл конфига с несколькими значениями переменной HOST в интерфейсе ovsbr, и так же удаляет бридж

в логах показывает следующее:

июн 18 11:15:42 boy.stavropol.microgen.ru network[130581]: ERROR: /etc/net/scripts/ifup: Could not ifup dependency for interface 'vmbr0'
июн 18 11:15:42 boy.stavropol.microgen.ru /etc/net[130636]: ERROR: /etc/net/scripts/ifup: Could not ifup dependency for interface 'vmbr0'
июн 18 11:15:42 boy.stavropol.microgen.ru ovs-vsctl[130637]: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl -t 10 -- --if-exists del-port vmbr0 vlan4_1
июн 18 11:15:42 boy.stavropol.microgen.ru ovs-vsctl[130641]: ovs|00001|vsctl|INFO|Called as /usr/bin/ovs-vsctl -t 10 -- add-port vmbr0 vlan4_1 tag=4 -- set interface v>
июн 18 11:15:42 boy.stavropol.microgen.ru ovs-vsctl[130641]: ovs|00002|db_ctl_base|ERR|no bridge named vmbr0
июн 18 11:15:42 boy.stavropol.microgen.ru network[130641]: ovs-vsctl: no bridge named vmbr0

SDN тоже не рабочий, как минимум при создании типа зоны типа simple и с добавлением vnet c подсетью

Тоже столкнулся с данной проблемой. Сеть поднимается, если один порт в кавычках, либо в HOST не ставить кавычки и несколько портов.

[root@altpve1 ifaces]# cat vmbr10/options
BOOTPROTO=static
CONFIG_IPV4=yes
HOST=enp2s29 enp3s12 vlan255
ONBOOT=yes
TYPE=ovsbr

[root@altpve1 ifaces]# cat vlan255/options 
BOOTPROTO=static
BRIDGE=vmbr10
CONFIG_IPV4=yes
OVS_OPTIONS='tag=255'
TYPE=ovsport

[root@altpve1 ~]# ovs-vsctl show
499625aa-3c9a-4a6a-8a28-27de3b925475
    Bridge vmbr10
        Port vmbr10
            Interface vmbr10
                type: internal
        Port enp2s29
            Interface enp2s29
        Port vlan255
            tag: 255
            Interface vlan255
                type: internal
        Port enp3s12
            Interface enp3s12
    ovs_version: "2.17.8"

### Bug 1 ###

Product: etcnet
Component: network
Hardware: All
Importance: major
Priority: high
Assigned To: -
URL: -
Summary: Incorrect VLAN on bridge conversion from Debian format
Keywords: vlan, bridge, debian, conversion

Description:
When converting network configuration from Debian format to ALT Linux format, VLAN interfaces on bridge (vmbr) are incorrectly converted to type 'brivlanport'. This causes VLAN functionality to break.

Steps to Reproduce:
1. Create Debian format configuration with VLAN on bridge:
   auto vmbr0
   iface vmbr0 inet static
       bridge-ports bond0
       bridge-stp off
       bridge-fd 0
       bridge-vlan-aware yes
       bridge-vids 2-4094

   auto vmbr0.237
   iface vmbr0.237 inet static
       address 10.67.37.21
       netmask 255.255.255.0

2. Convert configuration using script:
   perl -MPVE::INotify -MPVE::INotifyEtcnetOverride -e '$fh = IO::File->new("/etc/network/interfaces.new", "r") or die "Error opening file: $!"; my $cfg = PVE::INotify::__read_etc_network_interfaces($fh); PVE::INotifyEtcnetOverride::__write_etc_net_interfaces($cfg);'

Actual Results:
- Converter tries to create 'brivlanport' type interface
- VLANs do not work properly

Expected Results:
- VLAN interfaces should remain type 'vlan'
- Parent interface should be determined from VLAN name

Proposed Fix:
See attached patch: fix-vlan-bridge-conversion-v7.patch

### Bug 2 ###

Product: etcnet
Component: network
Hardware: All
Importance: major
Priority: high
Assigned To: -
URL: -
Summary: VLANs not added to bridge interface itself
Keywords: vlan, bridge, vlan-aware

Description:
When creating a VLAN-aware bridge, VLANs are only added to bridge ports but not to the bridge interface itself. This prevents tagged traffic from passing through the bridge.

Steps to Reproduce:
1. Create VLAN-aware bridge configuration:
   BOOTPROTO=static
   BRIDGE_OPTIONS="stp_state 0"
   CONFIG_IPV4=yes
   HOST='bond0'
   ONBOOT=yes
   TYPE=bri
   VIDS=2-4094
   VLAN_AWARE=1

2. Bring up interface:
   ifup vmbr0

3. Check VLAN configuration:
   bridge vlan show

Actual Results:
- bridge vlan show shows VLANs only on bridge ports
- Tagged traffic does not pass
- ARP requests sent but no responses received

Expected Results:
- VLANs should be added to both bridge interface and ports
- Tagged traffic should pass through bridge

Additional Information:
Running 'bridge vlan add vid 2-4094 dev vmbr0 self' manually fixes the issue, but this should be automatic.

Proposed Fix:
See attached patch: fix-bridge-vlan-self.patch

Test Results:
After applying both patches:
1. VLANs correctly convert from Debian format
2. VLANs automatically added to bridge and ports
3. Tagged traffic passes through bridge
4. ARP and other protocols work in VLANs

# Проблемы с VLAN на bridge интерфейсах

## Баг 1: Некорректная конвертация VLAN на bridge из Debian формата

**Компонент**: etcnet  
**Серьезность**: major  
**Приоритет**: high  
**Статус**: NEW  

### Описание
При конвертации конфигурации сети из Debian формата в ALT Linux формат, VLAN интерфейсы на bridge (vmbr) некорректно преобразуются в тип 'brivlanport'. Это приводит к проблемам с работой VLAN.

### Шаги воспроизведения
1. Создать конфигурацию в Debian формате с VLAN на bridge:
```
auto vmbr0
iface vmbr0 inet static
    bridge-ports bond0
    bridge-stp off
    bridge-fd 0
    bridge-vlan-aware yes
    bridge-vids 2-4094

auto vmbr0.237
iface vmbr0.237 inet static
    address 10.67.37.21
    netmask 255.255.255.0
```

2. Конвертировать конфигурацию с помощью скрипта:
```bash
perl -MPVE::INotify -MPVE::INotifyEtcnetOverride -e '$fh = IO::File->new("/etc/network/interfaces.new", "r") or die "Error opening file: $!"; my $cfg = PVE::INotify::__read_etc_network_interfaces($fh); PVE::INotifyEtcnetOverride::__write_etc_net_interfaces($cfg);'
```

### Текущее поведение
- Конвертер пытается создать интерфейс типа 'brivlanport'
- VLAN не работают корректно

### Ожидаемое поведение
- VLAN интерфейсы должны оставаться типа 'vlan'
- Родительский интерфейс должен определяться из имени VLAN

### Предлагаемый патч
Файл: patches/fix-vlan-bridge-conversion-v7.patch
```patch
--- /usr/share/perl5/PVE/INotifyEtcnetOverride.pm.orig
+++ /usr/share/perl5/PVE/INotifyEtcnetOverride.pm
@@ -392,14 +392,13 @@
     } elsif ($type eq 'vlan') {
        $options->{'TYPE'}='vlan';
-       $options->{'HOST'}=$vlan_raw_device;
+       my $parent_iface;
+       if ($vlan_raw_device) {
+           $parent_iface = $vlan_raw_device;
+       } elsif ($iface =~ /^([^.]+)\./) {
+           $parent_iface = $1;
+       }
+       $options->{'HOST'}=$parent_iface if $parent_iface;
        if ($iface =~ /(\d+)(?::\d+)?$/) { # id.VID:ALIAS
            $options->{'VID'}=$1;
-       }
-       if ($vlan_raw_device =~ /^vmbr/) {
-           if ($iface =~ /^$vlan_raw_device\./) {
-               $options->{'TYPE'}='brivlanport';
-           } else {
-               die "Oops! etcnet writer: vlan brivlanport $iface: name expected to start from $vlan_raw_device";
-           }
        }
```

## Баг 2: VLAN не добавляются на bridge интерфейс

**Компонент**: etcnet  
**Серьезность**: major  
**Приоритет**: high  
**Статус**: NEW  

### Описание
При создании VLAN-aware bridge, VLAN добавляются только на порты bridge, но не на сам bridge интерфейс. Это приводит к тому, что тегированный трафик не может проходить через bridge.

### Шаги воспроизведения
1. Создать VLAN-aware bridge с разрешенными VLAN:
```
BOOTPROTO=static
BRIDGE_OPTIONS="stp_state 0"
CONFIG_IPV4=yes
HOST='bond0'
ONBOOT=yes
TYPE=bri
VIDS=2-4094
VLAN_AWARE=1
```

2. Поднять интерфейс:
```bash
ifup vmbr0
```

### Текущее поведение
- В выводе `bridge vlan show` VLAN видны только на портах bridge
- Тегированный трафик не проходит
- ARP запросы отправляются, но ответы не приходят

### Ожидаемое поведение
- VLAN должны добавляться и на сам bridge интерфейс
- Тегированный трафик должен проходить через bridge

### Предлагаемый патч
Файл: patches/fix-bridge-vlan-self.patch
```patch
--- /etc/net/scripts/create-bri.orig
+++ /etc/net/scripts/create-bri
@@ -18,6 +18,15 @@
 is_yes "$VLAN_AWARE" && BRIDGE_OPTIONS="${BRIDGE_OPTIONS:+"$BRIDGE_OPTIONS" }vlan_filtering 1"
 $IP link set $NAME type bridge $BRIDGE_OPTIONS
 
+# Add VLANs to bridge itself if VLAN-aware
+is_yes "$VLAN_AWARE" && {
+    if [ -n "$VIDS" ]; then
+        for vid in $VIDS; do
+            $BRIDGE vlan add dev $NAME vid $vid self && print_progress
+        done
+    fi
+}
+
 for host in $HOST; do
     $IP link set $host master $NAME && print_progress
     is_yes "$VLAN_AWARE" && {
```

### Тестирование
После применения обоих патчей:
1. VLAN корректно конвертируются из Debian формата
2. VLAN автоматически добавляются на bridge и его порты
3. Тегированный трафик проходит через bridge
4. ARP и другие протоколы работают в VLAN

А почему RESOLVED/FIXED ?

патчи приложил, надеюсь на включение

  Если закрыть тикет, то его уже никогда не прочитают.

Created attachment 17642 [details]
Патч парсинга сетевых настроек proxmox

для исправления работы стандартной (не openvswith) схемы bond > bridge > vlan-s назначаемой из WEB интерфейса

В p11 закрыто этим заданием:
https://packages.altlinux.org/tasks/385334

В p10 тоже исправлено https://packages.altlinux.org/ru/tasks/384351/