41368 2021-11-17 13:45:51 +0300 регрессия в работе моста с QinQ в 0.9.16-alt1 2021-11-24 20:08:45 +0300 1 1 4 Development Sisyphus etcnet unstable x86_64 Linux CLOSED NOTABUG P5 minor --- 1 asy sem ldv rider sem shaba qa-sisyphus oldest_to_newest 204981 0 asy 2021-11-17 13:45:51 +0300 При отказе от 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 эта конструкция работает. 204982 1 9945 asy 2021-11-17 13:50:10 +0300 Created attachment 9945 пример конфигурации etcnet Тут есть два интерфейса, bridge0.900 и ether0.899.900, которые НЕ должны быть активны одновременно. Если их по очереди поднимать, то с хоста, подключенного к ether0, bridge0.900 недоступен, ether0.899.900 доступен. 204983 2 rider 2021-11-17 14:04:14 +0300 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 204984 3 rider 2021-11-17 14:04:57 +0300 Это фича. 204985 4 asy 2021-11-17 14:39:16 +0300 (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. 204986 5 rider 2021-11-17 14:40:48 +0300 Да, точно, и я же про него писал в документации, когда сам на такое поведение нарвался: https://www.altlinux.org/Etcnet#%D0%9D%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0_VLAN 204987 6 asy 2021-11-17 14:53:34 +0300 (In reply to Anton Farygin from comment #2) > VLAN_AWARE=yes Если это написать в bridge0/options, то это только ломает работу локального интерфейса, которая чинится посредством VLAN_REORDER_HDR=1, и никак не влияет на транзит. Попытка добавить что-то вроде VIDS="2-4000" тоже к нужному результату не приводит. Пока переоткрою, так как решения для транзитного трафика пока не вижу. 204989 7 asy 2021-11-17 15:49:36 +0300 (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" А зачем? Всё же работало? 204996 8 asy 2021-11-17 17:29:50 +0300 bridge-utils не при чём значит, и minor заодно. 204998 9 rider 2021-11-17 17:59:49 +0300 Это уже два релиза бранчей, я тоже возмущался. Было/стало так потому что в iproute другой дефолт. Теперь этот новый default уже стал стандартом с p9, обратно откатывать себе дороже. 205001 10 asy 2021-11-17 21:10:01 +0300 (In reply to Anton Farygin from comment #9) > Было/стало так потому что в iproute другой дефолт. > Теперь этот новый default уже стал стандартом с p9 А какие преимущества этот дефолт даёт, и что сломаестся от его смены? 205005 11 rider 2021-11-18 08:36:10 +0300 Сломаются существующие конфигурации. Преимущества и недостатки врятли можно рассматривать. Надо учитывать, что это полярные точки зрения на данную опцию. 205006 12 asy 2021-11-18 09:05:55 +0300 (In reply to Anton Farygin from comment #11) > Сломаются существующие конфигурации. Так а какие? Где реально надо убирать VLAN ID у исходящего трафика? По ссылке из Comment 5 в примере, как раз, VLAN_REORDER_HDR=0, но зачем? У меня и с VLAN_REORDER_HDR=1 этот вариант конфигурации работает. 205007 13 asy 2021-11-18 09:11:36 +0300 (In reply to Anton Farygin from comment #9) > Было/стало так потому что в iproute другой дефолт. Так, то есть это изменение связано с "use ip utility for vlan interface types" в 0.9.16-alt1. Что ещё и VLAN иначе начали делаться я что-то тоже пропустил. 205011 14 rider 2021-11-18 09:25:01 +0300 (Ответ для 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 205012 15 asy 2021-11-18 10:09:06 +0300 (In reply to Anton Farygin from comment #14) > Все существующие конфигурации, в которых не нужно использование REORDER_HDR Логично. :-) Но хотелось бы пример. До p9, когда это было включено, я вообще про этот параметр не знал, всё всегда работало. 205013 16 rider 2021-11-18 10:38:39 +0300 Давай спросим у автора изменения bd74a577 Алексея Шабалина. 205278 17 shaba 2021-11-24 20:08:45 +0300 (Ответ для 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. 9945 2021-11-17 13:50:10 +0300 2021-11-17 13:50:10 +0300 пример конфигурации etcnet etcnet-bri-qinq.tgz application/gzip 821 asy H4sIAAAAAAAAA+2cS2vbQBSFs/av8C47Z+4864UXDQ40UOpCTKFLB5vWNLWCH/n9nRkrtionlRU8 N6p1PgIWSUCCM3fmnJkr3y/n0x8zcXWREOFxxsRPT/kzXpMmbSQJp/3viYS1F12T8qGe2azWk2W3 e7HMsvW//q/q7/8p97n+88cnPZlOl7PV6uT3CAJbrV/Xn1yuf7hUXn8llddfnPxJXqDl+pPohZ+e NOpK6s57Pw5g5rn+s8f1PFucvvYDlfVvZWn+l0ZI1D8Hw9u7j9efb4aDRdYZf/96M/ADovNpdDce XM7WP2dL0fvQ73fjJYXLS0wRZ0Ve/72+SOcBj/d/QihHwf8pp+H/OCjqHzzgMtusZye+R+X8H/RX zpB0VpGM/s8KzP8clPVPkQEq9Zfl+ldGOejPQe7/BQJAOynWf6oMUO3/zbb+ySpp4vwvJKH+ORh9 uR6NxsH9HySBp4fJYhsF8kHS+XY7HPiBgknifPh7/X+YL36d/h7V+3+0W/+l0DH/O/g/Fn6vN10y qOm2st3kSXr8Uy//y+D/hVMK+Z+DXP9U0T9SP/9LKzXmfw4K+qc6/qunf1z/FRH0ZyHXP+XxzxH7 Pz7/KastCe10rH/lIyH0Z+Ag9fkBAS/YHnbzf5roF6mT/xTZUP+kkf9YyPMfNn5byv6QP10GPD7/ kbAm1L93gg75j4OC/skyYP38p8jA/7NQ0j9JBnxD/tMa+rNQ0D9ZBqzU3+o4/2sntVXR/zns//Bw 1PnfdpDE4z8/UGAVz4h9/adrAazj/5wI6z8Zh/c/WCjpn8QDvsH/+XUA8z8HL+h/cg9Yqf9h/1/Y Bob+DKD/r92U6j9JBqisf1de/5Uk9P+xUMP/h0GCFsAz42D9T3AOVFn/h/1/zsH/sYD+v3azfbOz Qf1/8fw3vgaM/M9Arn/z+v/Q/8NCQf9m9f9BfxZy/ZvX/4fvf2EB/X/tZjf/N63/D/s/LKD/r93s v9mnGf1/Bv1/rBT0b1b/H/w/CyX9m9P/B/1ZKOj/7v1/hqyf98W2/w/+j4Xjz/8I/X8AAAAAAAAA AAAAAAAAAAAAAABAQ/kDGYMYSAB4AAA=