При отказе от 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 эта конструкция работает.
Created attachment 9945 [details] пример конфигурации etcnet Тут есть два интерфейса, bridge0.900 и ether0.899.900, которые НЕ должны быть активны одновременно. Если их по очереди поднимать, то с хоста, подключенного к ether0, bridge0.900 недоступен, ether0.899.900 доступен.
https://www.altlinux.org/Etcnet#Linux_bridge_%D0%BF%D0%BE%D1%81%D1%80%D0%B5%D0%B4%D1%81%D1%82%D0%B2%D0%BE%D0%BC_iproute2_(%D0%BD%D0%B0%D1%87%D0%B8%D0%BD%D0%B0%D1%8F_%D1%81_p9) VLAN_AWARE=yes
Это фича.
(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.
Да, точно, и я же про него писал в документации, когда сам на такое поведение нарвался: https://www.altlinux.org/Etcnet#%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_VLAN
(In reply to Anton Farygin from comment #2) > VLAN_AWARE=yes Если это написать в bridge0/options, то это только ломает работу локального интерфейса, которая чинится посредством VLAN_REORDER_HDR=1, и никак не влияет на транзит. Попытка добавить что-то вроде VIDS="2-4000" тоже к нужному результату не приводит. Пока переоткрою, так как решения для транзитного трафика пока не вижу.
(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" А зачем? Всё же работало?
bridge-utils не при чём значит, и minor заодно.
Это уже два релиза бранчей, я тоже возмущался. Было/стало так потому что в iproute другой дефолт. Теперь этот новый default уже стал стандартом с p9, обратно откатывать себе дороже.
(In reply to Anton Farygin from comment #9) > Было/стало так потому что в iproute другой дефолт. > Теперь этот новый default уже стал стандартом с p9 А какие преимущества этот дефолт даёт, и что сломаестся от его смены?
Сломаются существующие конфигурации. Преимущества и недостатки врятли можно рассматривать. Надо учитывать, что это полярные точки зрения на данную опцию.
(In reply to Anton Farygin from comment #11) > Сломаются существующие конфигурации. Так а какие? Где реально надо убирать VLAN ID у исходящего трафика? По ссылке из Comment 5 в примере, как раз, VLAN_REORDER_HDR=0, но зачем? У меня и с VLAN_REORDER_HDR=1 этот вариант конфигурации работает.
(In reply to Anton Farygin from comment #9) > Было/стало так потому что в iproute другой дефолт. Так, то есть это изменение связано с "use ip utility for vlan interface types" в 0.9.16-alt1. Что ещё и VLAN иначе начали делаться я что-то тоже пропустил.
(Ответ для 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
(In reply to Anton Farygin from comment #14) > Все существующие конфигурации, в которых не нужно использование REORDER_HDR Логично. :-) Но хотелось бы пример. До p9, когда это было включено, я вообще про этот параметр не знал, всё всегда работало.
Давай спросим у автора изменения bd74a577 Алексея Шабалина.
(Ответ для 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.
