LINUX.ORG.RU

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

 ,


0

1

Привет.

Не знаю как правильно утолкать суть в заголовок...
В общем при настройке software bridge в Linux классический подход (для меня) это создать bridge интерфейс к пример утилей brctl и напихать в ней интерфейсов через addif. При этом если вдруг надо использовать VLAN, то я делал vlan интерфейсы через ip ... vlan и уже эти vlan (к примеру eth0.12) добавлял через addif в мост.
Но тут мир не стоит на месте и у моста появился функционал VLAN. При этом в моста добавляется eth0, а уже потом там теггируется под VLAN и на выходе имеем к примеру br0.12, который будет использовать указанные интерфейсы согласно VLAN или без него.
При этом пока абсолютно не понятно как это работает :))

Может кто-нить объяснить или навести на литературу какую зачем это ? и чем был плох предыдущий подход?

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

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

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

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

vel ★★★★★
()

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

Shprot ★★
()
Ответ на: комментарий от vel

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

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

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

Spider55
() автор топика

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

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

futurama ★★★★★
()
Ответ на: комментарий от Spider55

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

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

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

vel ★★★★★
()
Ответ на: комментарий от Shprot

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

сделал так:

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


в результате не взлетело. И да! Не взлетело конкретно на этом железе, я даже нашёл issue в github (щас уже не хочу искать) где я оказался не одинок.

Следующий роутер с тем же OpenWRT но другим железом отлично реализовал эту схему.

т.е. косяк там с каким-то конкретным железом. Он даже напрашивается из организации железа.

Spider55
() автор топика
Ответ на: комментарий от Spider55
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-ами нужно включить vlan_filtering, в противном случае все тегированные пакеты будут дропаться.
Все порты подключаемые в мост по умолчанию имеют «vid 1 pvid untagged». Если это не так, то нужно на все порты прописать необходимые vlan-ы.

Если на хосте нужен доступ в 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
Последние 2 строки можно заменить на ifconfig vlan12 10.10.10.10/24, но для этого нужен ifconfig.

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

vel ★★★★★
()
Ответ на: комментарий от vel

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

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

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

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

Spider55
() автор топика
Последнее исправление: Spider55 (всего исправлений: 3)