Bug 41368

Summary: регрессия в работе моста с QinQ в 0.9.16-alt1
Product: Sisyphus Reporter: Sergey Y. Afonin <asy>
Component: etcnetAssignee: Mikhail Efremov <sem>
Status: CLOSED NOTABUG QA Contact: qa-sisyphus
Severity: minor    
Priority: P5 CC: ldv, rider, sem, shaba, vseleznv
Version: unstable   
Hardware: x86_64   
OS: Linux   
Attachments:
Description Flags
пример конфигурации etcnet none

Description Sergey Y. Afonin 2021-11-17 13:45:51 MSK
При отказе от bridge-utils и переходе на iproute2 произошла регрессия. Если формировать мост из VLAN, то SVLAN срезается на исходящем трафике. Если смотреть tcpdump-ом, то выглядит это так:

ether0 in:
14:00:48.094532   B 00:1c:c0:18:fc:89 ethertype 802.1Q (0x8100), length 62: vlan 899, p 0, ethertype 802.1Q, vlan 900, p 0, ethertype ARP, Request who-has 10.10.10.253 tell 10.10.10.254, length 38

ether1 out:
14:00:48.094536   B 00:1c:c0:18:fc:89 ethertype 802.1Q (0x8100), length 58: vlan 900, p 0, ethertype ARP, Request who-has 10.10.10.253 tell 10.10.10.254, length 38

На выходе один тэг потерялся. С локальным интерфейсом на бридже ситуация выглядит аналогично, так что для воспроизведения достататочно двух устройств по идее. В p8 эта конструкция работает.
Comment 1 Sergey Y. Afonin 2021-11-17 13:50:10 MSK
Created attachment 9945 [details]
пример конфигурации etcnet

Тут есть два интерфейса, bridge0.900 и ether0.899.900, которые НЕ должны быть активны одновременно. Если их по очереди поднимать, то с хоста, подключенного к ether0, bridge0.900 недоступен, ether0.899.900 доступен.
Comment 3 Anton Farygin 2021-11-17 14:04:57 MSK
Это фича.
Comment 4 Sergey Y. Afonin 2021-11-17 14:39:16 MSK
(In reply to Sergey Y. Afonin from comment #1)

> Тут есть два интерфейса, bridge0.900 и ether0.899.900, которые НЕ должны
> быть активны одновременно. Если их по очереди поднимать, то с хоста,
> подключенного к ether0, bridge0.900 недоступен, ether0.899.900 доступен.

Это ошибочный пример, к делу отношения не имеет, как выяснилось сейчас. Проверять надо на трёх устройствах. Описанный локальный пример лечится наличием VLAN_REORDER_HDR=1 в ether0.899/options.
Comment 5 Anton Farygin 2021-11-17 14:40:48 MSK
Да, точно, и я же про него писал в документации, когда сам на такое поведение нарвался:
https://www.altlinux.org/Etcnet#%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_VLAN
Comment 6 Sergey Y. Afonin 2021-11-17 14:53:34 MSK
(In reply to Anton Farygin from comment #2)

> VLAN_AWARE=yes

Если это написать в bridge0/options, то это только ломает работу локального интерфейса, которая чинится посредством VLAN_REORDER_HDR=1, и никак не влияет на транзит. Попытка добавить что-то вроде VIDS="2-4000" тоже к нужному результату не приводит. Пока переоткрою, так как решения для транзитного трафика пока не вижу.
Comment 7 Sergey Y. Afonin 2021-11-17 15:49:36 MSK
(In reply to Sergey Y. Afonin from comment #4)

> > Тут есть два интерфейса, bridge0.900 и ether0.899.900, которые НЕ должны
> > быть активны одновременно. Если их по очереди поднимать, то с хоста,
> > подключенного к ether0, bridge0.900 недоступен, ether0.899.900 доступен.
> 
> Это ошибочный пример, к делу отношения не имеет

Нет, не ошибочный. Я просто забыл, что третий хост, как и промежуточный, тоже на p10, и там тоже надо VLAN_REORDER_HDR=1. Надо было внимательнее в вывод tcpdump смотреть.

Однако регрессия, всё же есть, в виде этого VLAN_REORDER_HDR=0 по умолчанию. Точнее была замена 

is_no "$VLAN_REORDER_HDR" && VLAN_REORDER_PARAM="reorder_hdr off" || VLAN_REORDER_PARAM="reorder_hdr on"

на 
is_yes "$VLAN_REORDER_HDR" && VLAN_REORDER_PARAM="reorder_hdr on" || VLAN_REORDER_PARAM="reorder_hdr off"

А зачем? Всё же работало?
Comment 8 Sergey Y. Afonin 2021-11-17 17:29:50 MSK
bridge-utils не при чём значит, и minor заодно.
Comment 9 Anton Farygin 2021-11-17 17:59:49 MSK
Это уже два релиза бранчей, я тоже возмущался.

Было/стало так потому что в iproute другой дефолт. Теперь этот новый default уже стал стандартом с p9, обратно откатывать себе дороже.
Comment 10 Sergey Y. Afonin 2021-11-17 21:10:01 MSK
(In reply to Anton Farygin from comment #9)

> Было/стало так потому что в iproute другой дефолт.
> Теперь этот новый default уже стал стандартом с p9

А какие преимущества этот дефолт даёт, и что сломаестся от его смены?
Comment 11 Anton Farygin 2021-11-18 08:36:10 MSK
Сломаются существующие конфигурации.

Преимущества и недостатки врятли можно рассматривать. Надо учитывать, что это полярные точки зрения на данную опцию.
Comment 12 Sergey Y. Afonin 2021-11-18 09:05:55 MSK
(In reply to Anton Farygin from comment #11)

> Сломаются существующие конфигурации.

Так а какие? Где реально надо убирать VLAN ID у исходящего трафика? По ссылке из Comment 5 в примере, как раз, VLAN_REORDER_HDR=0, но зачем? У меня и с VLAN_REORDER_HDR=1 этот вариант конфигурации работает.
Comment 13 Sergey Y. Afonin 2021-11-18 09:11:36 MSK
(In reply to Anton Farygin from comment #9)

> Было/стало так потому что в iproute другой дефолт.

Так, то есть это изменение связано с "use ip utility for vlan interface types" в 0.9.16-alt1. Что ещё и VLAN иначе начали делаться я что-то тоже пропустил.
Comment 14 Anton Farygin 2021-11-18 09:25:01 MSK
(Ответ для Sergey Y. Afonin на комментарий #12)
> (In reply to Anton Farygin from comment #11)
> 
> > Сломаются существующие конфигурации.
> 
> Так а какие? Где реально надо убирать VLAN ID у исходящего трафика? По
> ссылке из Comment 5 в примере, как раз, VLAN_REORDER_HDR=0, но зачем? У меня
> и с VLAN_REORDER_HDR=1 этот вариант конфигурации работает.

Все существующие конфигурации, в которых не нужно использование REORDER_HDR
Comment 15 Sergey Y. Afonin 2021-11-18 10:09:06 MSK
(In reply to Anton Farygin from comment #14)

> Все существующие конфигурации, в которых не нужно использование REORDER_HDR

Логично. :-) Но хотелось бы пример. До p9, когда это было включено, я вообще про этот параметр не знал, всё всегда работало.
Comment 16 Anton Farygin 2021-11-18 10:38:39 MSK
Давай спросим у автора изменения bd74a577 Алексея Шабалина.
Comment 17 Alexey Shabalin 2021-11-24 20:08:45 MSK
(Ответ для Anton Farygin на комментарий #16)
> Давай спросим у автора изменения bd74a577 Алексея Шабалина.

Потому что REORDER_HDR нужен в редких случаях, и влияет на производительность.

REORDER_HDR  When this is set, the VLAN device will move the
            ethernet header around to make it look exactly like a real
            ethernet device.  This may help programs such as DHCPd which
            read the raw ethernet packet and make assumptions about the
            location of bytes.  If you don't need it, don't turn it on, because
            there will be at least a small performance degradation.