VLAN bridge на Линуксе и транк-порт

т.е. пакет, выходящий из бриджа через br0, очищается от VLAN тега, приложение «слушающее» на br0 получает чистый IP пакет.

для br0 это происходит в случае если номер vlan совпадает с pvid

Для работы с другими vlan нужно создать vlan-интерфейсы

Но как сделать чтобы ответный пакет, выходящий из бриджа в направлении L2 свитча, тегировался бы правильным VLAN тэгом?

оно так и работает на br0 для vlan совпадающим с pvid.

Все замечательно работает. Прочти документацию.

IMHO здесь есть все необходимое

для br0 это происходит в случае если номер vlan совпадает с pvid

Для того чтобы br0 удалял тег, я его сконфигурировал так:

# bridge vlan del dev br0 vid 1 self
# bridge vlan add dev br0 vid 10 untagged pvid self

Но все это прекрасно работает на vlan_filtering бриджах только для не-транк портов входящих в бридж — то есть траффик от хоста, входящий через br1 в бридж, тегируется PVID и отправляется в нужный порт. Но pvid может быть только один на порт.

В моем случае транки, обратный траффик нет возможности тегировать разными vlan-ами.

То есть ваше предложение: создать несколько vlan sub-интерфейсов (ip link add link eth0 name eth0.10 type vlan id 10 и т.д.), добавить их в br0, при этом br0 это обвычный transparent мост, vlan_filtering=0, правильно я понимаю?

В моем случае транки, обратный траффик нет возможности тегировать разными vlan-ами.

Я после ковида такие сложные фразу не могу понять.

включать vlan_filtering или нет - зависит от задачи. Если тебе нужно ограничить список vlan на интерфейсе, то vlan_filtering нужно включить и потом не забыть настроить список vlan-ов на каждом порту бриджа.

Если тебе нужно на хосте иметь доступ к более чем одному vlan-у, то почему-то рекомендуется создавать их именно на самом бридже, а не на каком-то порту входящим в бридж. т.е. «ip link add link br0 name br0.10 type vlan id 10» и потом уже на него вешать ip-адреса.

Мне пока непонятно, что у тебя не работает.

Зачем тебе бридж? Тебе нужно обеспечить доступ через 1 физическией интерфейс в разные vlan для кучи контейнеров/виртуалок?

Я после ковида такие сложные фразу не могу понять.

:-) Хорошо, постараюсь попроще объяснить.

Имеется бридж br0, на который заведены интерфейсы сетевой карты (карта проприетарная и что делает не принципиально, но смысл в том, что клиенты подключенные к ней должны обслуживаться DHCP сервером слушающем на br0, помимо этого на br0 висят еще демоны).

a) первоначально речи не шло о VLAN-ах, все было просто по рабоче-крестьянски: transparent bridge и все дела

б) потом добавилась требование, что клиенты-девайсы могут поддерживать VLAN-ы (все девайсы в одном VLAN), причем карточка не понимает vlan теги и направляет тегированные пакеты хосту на обработку. Подумав, я сконфигурировал bridge с vlan_filtering и добавил порты в соответствующий vlan:

# ip link add br0 type bridge vlan_filtering 1
# ip link set dev eth0 master br0
# ip link set dev eth1 master br0
# ip link set dev eth2 master br0
# ip link set dev eth3 master br0
#
# for i in 0 1 2 3; do bridge vlan add dev eth$i vid ${default_vid}; done
#
# bridge vlan del dev br0 vid 1 self
# bridge vlan add dev br0 vid ${default_vid} pvid untagged self

в) все работало исправно, пока не появилось новое требование - девайсы могут быть в разных VLAN. Сделал следующее:

# ip link add br0 type bridge vlan_filtering 1
# ip link set dev eth0 master br0
# ip link set dev eth1 master br0
# ip link set dev eth2 master br0
# ip link set dev eth3 master br0
#
# for i in 0 1 2 3; do bridge vlan add dev eth$i vid 1-4094; done
#
# bridge vlan del dev br0 vid 1 self
# bridge vlan add dev br0 vid ${default_vid} pvid untagged self

И вот здесь засада - поскольку на br0 возможен только один pvid, то получается что трафик в обе стороны возможен только для vlan совпадающего c pvid (о чем вы выше сообщили), и сделать pvid 1-4094 невозможно и естественно нелогично.

Что требуется: тегированные пакеты с разных VLAN доходят до br0, тэг убирается, пакет обрабатывается, и отправляется ответ с правильным тегом.

То есть я вижу только один выход здесь:

а) создать обычный bridge с vlan_filtering=0

б) создать vlan sub-интерфейсы поверх ethX, ethX.vid

в) добавить ethX.vid в бридж

Данная конструкция работает, vlan tag/untag делается на уровне ethX.vid драйвера, а не на уровне бриджа.

Если тебе нужно на хосте иметь доступ к более чем одному vlan-у, то почему-то рекомендуется создавать их именно на самом бридже, а не на каком-то порту входящим в бридж. т.е. «ip link add link br0 name br0.10 type vlan id 10» и потом уже на него вешать ip-адреса.

Непонятно как это будет работать, получается что tcp/ip стек получит тегированный пакет?

Непонятно как это будет работать, получается что tcp/ip стек получит тегированный пакет?

На L3 наличие тегов никого не волнует. Пакеты с лишними заголовками будут прото дропаться.

Аппаратная поддержка vlan-ов это хорошо, но совсем не обязательно. У нас vlan-ы работают на любой сетевой карте, а отличии от мелкомягких поделок.

Для приложений которые совсем не ожидают vlan-тега есть отдельная настройка reorder_hdr on|off. Без «reorder_hdr on» isc dhcpd не будет получать пакеты, т.к. он использует bpf-фильтр который не проверяет наличие vlan-тегов.

Сделай на бридже vlan-интерфейсы с «reorder_hdr on» если там должен отвечать isc dhcpd. isc dhcpd в явном виде укажи список интерфейсов (vlan) с которыми нужно работать.

А вообще, все достаточно просто - если на интерфейсе зарегистрирован vlan-интерфейс, то все что приходит на этот vlan попадает в соответствующий vlan-интерфейс, а иначе попадает в основной интерфейс с тегом. Это на обычном интерфейсе.

В случае бриджа, можно фильровать или не фильтровать все лишние vlan-ы.

В зависимости от аппаратной поддержки vlan, теоретически, может быть разница в том, получит ли сокет типа packet или raw (который используется некоторыми приложениями типа tcpdump/wireshark/...) пакет которой предназначеный vlan-интерфейсу или нет.

Для приложений которые совсем не ожидают vlan-тега есть отдельная настройка reorder_hdr on|off.

Спасибо, не знал. То есть reorder_hdr как был откладывает операцию c vlan-ом «до упора».

Все же остается неясность: если создать на бридже br0.10, br0.20 и т.д., то зачем мне на каждый заводить отдельный IP?

И чем принципиально эта схема отличается от той что я ранее объяснил: eth0.10, eth0.20 и др. заведенные в бридж.

Все же остается неясность: если создать на бридже br0.10, br0.20 и т.д., то зачем мне на каждый заводить отдельный IP?

А для чего тебе тогда создавать vlan-интерфейсы на хосте? Смотреть на них?

ЕСЛИ тебе нужно иметь доступ по ip в несколько vlan-ов с хоста, то создается vlan-интерфейc на бридже, а не на портах. В случае создания vlan-ов на портах наблюдаются странные глюки при работе с ipv4, которых нет при создании vlan-ов на бридже.

Еще раз поясню что я пытаюсь добиться: тегированные пакеты от клиентов с разных VLAN доходят до br0, тэг удаляется, пакет обрабатывается, отправляется ответный пакет с _правильным_ тегом; при этом все клиенты в одной IP подсети (192.168.1.0/24), т.е. мне не нужны IP на каждый vlan интерфейс.

А для чего тебе тогда создавать vlan-интерфейсы на хосте?

На хосте vlan-интерфейсы мне нужны для того чтобы добавлять/убирать теги. Я бы это сделал средствами бриджа, но он не может тегировать исходящие пакеты с одного бридж-интерфейса _разными_ VLAN-ами.

В случае создания vlan-ов на портах наблюдаются странные глюки при работе с ipv4, которых нет при создании vlan-ов на бридже.

Можно об это подробнее? По каким ключевым словам гуглить?

Еще раз поясню что я пытаюсь добиться: тегированные пакеты от клиентов с разных VLAN доходят до br0, тэг удаляется, пакет обрабатывается, отправляется ответный пакет с _правильным_ тегом; при этом все клиенты в одной IP подсети (192.168.1.0/24), т.е. мне не нужны IP на каждый vlan интерфейс.

Если тебе нужно изолировать клиентов друг от друга в пределах одной ip-сети, то возможно тебе подойдет режим изоляции порта (bridge link set dev xxx isolated on)

Второй вариант - ebtables. Запрет форвардинга между портами. В этом случае можно выборочно разрешать обмен данными между несколькими портами

т.е. в любом случае создаем кучу портов в виде vlan-интерфейсов на физических портах с reoreder_hdr on. Всех пихаем в бридж. А далее либо через ebtables либо через «isolation on» разделяем клиентов.

Можно об это подробнее? По каким ключевым словам гуглить?

История очень древняя. Сам пару раз сталкивался, но давно (лет 10 назад).

Ставим ip на интерфейс, все работает.

Пихаем интерфейс в бридж, далее пихаем в бридж еще интерфейс. И в каких-то случаях оно частично не работало.

Может это был какой-то баг, который сейчас уже починили. Но если ip вешали на бридж, а все интерфейсы/порты были без ip, то все всегда работало.

Что то мне подсказывает, что тебе нужен openvswitch

Это полноценный свич с вланами. А то, что в ядре просто ерунда.