ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | регрессия в работе моста с QinQ в 0.9.16-alt1 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sergey Y. Afonin <asy> | ||||
| Component: | etcnet | Assignee: | 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
Sergey Y. Afonin
2021-11-17 13:45:51 MSK
Created attachment 9945 [details]
пример конфигурации etcnet
Тут есть два интерфейса, bridge0.900 и ether0.899.900, которые НЕ должны быть активны одновременно. Если их по очереди поднимать, то с хоста, подключенного к ether0, bridge0.900 недоступен, ether0.899.900 доступен.
Это фича. (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. |
