Сети для маленьких?) Немного читал его. Посмотрю там но не думаю, что там про настройку бриджа есть(

какую задачу ты решаешь? )

Да я задачу себе сам поставил. Просто ковыряю, разбираюсь и экспериментирую. Хотя, на самом деле, есть ожидаемый результат от этого. В итоге хочу в одном из контейнеров ftp сервер поднять.

У тебя, на самом деле, вопрос не про bridge, а про то, как IP работает поверх L2.

Рассматривай sw bridge как реальный коммутатор

Я его и рассматриваю как реальный коммутатор. У меня опыта не так много работы с сетями, но я предполагаю, что ip на свитче настраивается для удаленного доступа к нему. В таком случае мне надо в него аплинк ткнуть от физ. интерфейса (enp1s0). Но как только я добавляю в бридж этот интерфейс, у меня, конечно же, теряется соединение с серваком. Приходится откатывать настройки и думать, что я не понимаю и где лажаю.

Мне кажется, здесь есть правда. Хотя как l3 работает, я понимаю, вроде. Может, я просто не понял вас? Куда мне копнуть, чтобы понять?

ip на свитче служит гейтвеем между разными подсетями

точнее, по одному ip на подсеть

Видимо я правда чего-то не понимаю. Разве гетвей не на маршрутизаторе? Хост отправляет данные на этот самый гетвей, если видит, что адрес назначения находится в другой подсети. Данные проходят просто через свитч и все. А то, о чем вы говорите, это в моем понимании уже маршрутизатор, в котором уже и таблица маршрутизации есть, из которой понятно как сети на l3 соединяются.

Если коротко, то:
* brigde интерфейс является портом самого хоста в L2 сети, которую bridge и создает.
* потому  для пропуска трафика через хост нужен IP-адрес на самом bridge-интерфейса (если не рассматривать всякие прозрачные мосты)
* контейнер при отправке пакета смотрит в таблицы маршрутизации (local и main, именно в таком порядке). Таблица local заполняется исходя из настроек интерфейса (сеть берется из адреса и маски).
* выбор нужного маршрута происходит по правилу longest prefix match (выбирается тот маршрут, в который попадает адрес назначения, и при этом маска у маршрута наибольшая).
* если ты отправляешь пакет на 8.8.8.8, то он попадает под default route из таблицы main, где gateway-ем выступает ip на bridge-интерфейсе.
* после этого надо понять, как отправть трафик на этот гейтвей: для этого происходит лукап адреса гейтвея, который для которого обнаруживается маршрут в таблице local, из которого видно, через какой интерфейс послать пакет и с каким source-адресом.
* далее по arp определяется mac-адрес, соответствующий IP-адресу гейтвея и уже тогда отправляется ethernet-фрейс с dst mac адресом гейтвея и src mac адресом исходящего интерфейса контейнера, а внутри фрейма находится ip пакет с dst ip адресом 8.8.8.8 и src ip адресом контейнера.

Это что касается отправки пакета контейнером, далее рассмотрим то, как он пройдет через хост

* ip-пакет попадает на bridge-интерфейс хоста и выталкивается на уровень L3
* хост смотрит на dst адрес (который 8.8.8.8) и подбирает для него подходящий маршрут из своей таблицы марштуризации.
* далее повторяется та же самая история с выбором исходящего интерфейса и помещением IP-пакета в ethernet-фрейм.

Если у тебя пакет идет из контейнера в одном бридже в контейнер в другом бридже, то он роутится хостом их сети одного бриджа в сеть другого. Если у тебя в одном бридже обе сети, то пакет все равно отроутится хостом, просто он при этом уйдет в тот же интерфейс, из которого пришел.

Вот, в общем-то, и все. Это его грубо описать, что происходит с пакетом, опустив по дороге 90% деталей.

@DeMysteriisMundi
в качестве домашнего задания посмотри сам таблицы маршрутизации командой ip route show table <main/local> и посмотри на хосте и в контейнерах командой ip route get <dst ip addr>, какой маршрут выбирает сетевой стек.

Хахах. Сейчас разберу все, что вы написали, уложу в голове, потом к дз приступлю :D

Вообще, кажется, я понял, где же я конкретно был не прав, но надо проверить. Спасибо всем большое. Особенно Alexander)

Я заметил, что тут система репутации есть какая-то, верно?

Спасибо.