В чем принципиальное отличие от bridge с набором vlan интерфейсов от bridge c vlan

Как минимум, разница в производительности.
1 мост быстрее чем 2.

С другой стороны, если нужна фильтрация, то может оказаться так, что с двумя мостами будут значительно проще наборы правил.

Другой вопрос - а куда эти порты потом пихать и какая ОС их будет использовать. IMHO в контейнер/виртуалку нужно отдавать 1 порт, а они там уже его делить на vlan-ы. Но с оффтопиком это может оказаться технически трудно исполнимым.

Ну а вопросы удобства каждый считает по-своему. IMHO любой вариант можно автоматизировать так, чтобы было удобно.

Софтварный бридж, как сказал предыдущий оратор, действительно упирается в производительность. Для примера возьмём qemu-kvm. Там если пилить бридж, то его потолок будет в районе 3 гбит/с, а если организовать macvtap, то десяточку он смело тянет. На большее я не тестировал.

Я столкнулся с необходимостью раздать wifi в vlan. Взял роутер прошил его в openwrt и начал настраивать. Выяснилось что есть косяк.
eth0.12 вместе с wlan0 в месте br0 имеет баг, такой что пакеты из eth0.12 не форвардятся в wlan0. При этом все остальное «работает» (например из wlan0 в eth0.12). Если взять eth0 (т.е. без vlan) то все работает как ожидалось.

На форуме openwrt меня заткнули решением с vlan bridge. И да оно работает.

Но лично мне визуально привычнее «по старинке» (ну согласен, просто привычка и старый уже:) )

В чем принципиальное отличие

Принципиальное отличие в изолированности (vlan)сетей/пакетов во II случае (условно switch), в отличие от хаба в I случае.

Ну с wifi есть некоторые сложности если он клиент, а не АР.

Все нормальные точки доступа такую схему когда клиент подключается в vlan c vid != 1, реализуют без проблем. Хоть доставай старый роутер на openwrt и проверяй.

Правльно ли я понял, что wifi сеть должна быть в vlan 12 и для клиентов этой сети это должен быть native vlan, т.е. без тегов?
Или тебе нужно было отдать в wifi vlan 12 c тегами?

Не, это совсем другое.
Если использовать мост для подключения виртуалки, то трафик гонится через tap, а это 2 лишних пересылки данных из сети в userspace и назад.
Тормоз именно в использовании интерфейса tap в qemu.

Да, нужно просто клиентов Wifi зарулить в VLAN.12 в формате Untagged.

сделал так:

brctl addif br-lan eth0.12
brctl addif br-lan wlan0

brctl addif br-lan eth0.12
brctl addif br-lan wlan0

IMHO это совсем неправилно.
vlan-интерфейсы на портах (eth0) после подключения в мост использовать нельзя. Точно так же как и назначать на порты (eth0) адреса.

brctl это конечно хорошо, но пора бы уже использовать bridge. Твой вариант на новоязе выглядит примерно так:

ip li add br-lan type bridge forward_delay 1 vlan_filtering 1 vlan_protocol 802.1Q
ip li set dev eth0 master br-lan
ip li set dev eth0 up
ip li set wlan0 master br-lan
bridge vlan add dev eth0 vid 12
bridge vlan add dev wlan0 vid 12 pvid untagged
bridge vlan del dev wlan0 vid 1 pvid untagged
ip li set dev wlan0 up

Если на хосте нужен доступ в vlan из бриджа, то нужно заклинание

bridge vlan add dev br-lan vid 12 self
ip li add name vlan12 link br-lan type vlan id 12 reorder_hdr on
ip a ad 10.10.10.10/24 dev vlan12 brd +
ip li set dev vlan12 up

«reorder_hdr on» нужен если на этом интерфейсе работают программы не ожидающие появления vlan-тегов, например isc-dhcpd.

ip a ad

d

оно и «ip a a» без вопросов понимает.

но для наглядности да, «ip addr add»

точно.. что-то я запамятовал об этой возможности ))

Ну это уже как раз второй метод который я упомянул в самом начале.
А тот который ИЮХО не правильный был описан ещё давным давно в HOW-TO где то в дебрях документации Онтопика. И работает по сей день за исключением этого железа.

На скорую руку нагуглил Красношапковый мануал https://developers.redhat.com/blog/2017/09/14/vlan-filter-support-on-bridge#

Там и «первый» и «второй» методы.

Как я уже говорил мне было привычнее когда у меня для каждого vlan+wifi был отдельный мост.
Даааа. Сейчас тоже как бы отдельный мост. Но он все же не отдельный.
Кстати переименовать br0.12 в что-то типа br-vlan12 как то можно? :))

У меня в закладках два видоса:

• Настройка firewall и vlan для домашней сети
• Отличия в OpenWrt21

По теме сильно ближе второй видос, но первый можно для контекста посмотреть.

Кстати переименовать br0.12 в что-то типа br-vlan12 как то можно

ip li set dev br0.12 name br-vlan12

Есть еще одна интересная поделка - openvswitch :)
Мануалы там безумных размеров, но и возможностей тоже. Без пол-литра там не разобраться.

Года 3 назад я на нём сидел с lxc контейнерами, а теперь вернулся на linux-bridge.

я делал vlan интерфейсы через ip … vlan и уже эти vlan (к примеру eth0.12) добавлял через addif в мост.

читая твой опус что то вспомнилась новость, как какой то индус таки смог сам себе отсосать.

vlan-интерфейсы на портах (eth0) после подключения в мост использовать нельзя.

это почему?

Если на хосте нужен доступ в vlan из бриджа, то нужно заклинание

да что же вы такое творите то? один влан с интерфейса добавляет в мост в котором уже есть этот порт в нефильтрованом виде, второй прочитал про vlan-aware bridge и лепит тег к тегированому бриджу.

принципиально там ничего не изменилось. все тоже самое. просто конфиги стали короче.

в мост в котором уже есть этот порт в нефильтрованом виде

Что? Где?

второй прочитал про vlan-aware bridge и лепит тег к тегированому бриджу.

Аналогично. Где?
Оно так по мануалу так то. И даже в OpenWRT так и сделано. Чтобы попасть в vlan сеть внутри dsa vlan bridge его надо сам загнать в vlan... как нистранно.

Если интерфейс не является портом моста, то его vlan-интерфейсы можно спокойно подключать в мосты. При этом нужно не забыть про «reorder_hdr on», т.к. если он выключен, то входящий пакет будет с vlan-тегом и что с ним сделает мост зависит от его настроек.

Здесь неоднократно обсуждалась ситуация, когда в br0 добавляют eth0, а потом на eth0 назначают адрес или создают vlan, назначают ему адрес и оно начинает странно работать. Чтобы этого небыло, нужно все это делать с интерфейсом моста, а не с интерфейсами портов.