не-а?

«запихнуть» в скрипт. создать юнит, в Exec прописать скрипт. Задать «зависимость» стартовать этот юнит после старта systemd.networkd (если чо перепутал меня щас поправят)

Ну вообще в целом оно сейчас так и сделано...

[Unit]
Description = Bridge

[Service]
Type = oneshot
RemainAfterExit = yes
ExecStart = /bin/ip link add dev br0 type bridge
ExecStart = /bin/ip link set br0 up
ExecStart = /bin/ip -6 route add 2a01:7e01:e001:a3::/64 dev br0
ExecStop = /bin/ip link set dev br0 down
ExecStop = /bin/ip link del br0

[Install]
WantedBy = multi-user.target

Но думал сделать это по-нормальному через systemd-networkd.
Но что-то пока складывается ощущение, что без костылей это сделать нельзя...

Вопрос по systemd-networkd

Выглядит костыльно...

Я не совсем уверен, но возможно данный вопрос будет решён после принятия этого PR.

https://github.com/systemd/systemd/pull/10187

Пока что проблему решил лишь частично, указав ConfigureWithoutCarrier = true

Хотя еще есть вот такой PR.

https://github.com/systemd/systemd/pull/9956

Не хватает ещё одного юнита, в котором будут перечислены интерфейсы входящие в br0.

15-br0.network

[Match]
Name=e*

[Network]
Bridge=br0

Всё работает, никакие патчи не нужны. Никого не слушай, особенно тех двоечников, которые не читают маны по systemd.

Так-с. А зачем eth0 должен входить в br0?
У меня вроде такой необходимости раньше не возникало.
Да и как мне говорили, это вроде нужно только в том случае, если выделенный IPv4 адрес должен выступать шлюзом для выделенной IPv4 подсети.
Но я могу ошибаться, т.к. давно это было.

Ну не знаю. Вроде как ActivationMode как раз то, что нужно.
Т.к. сейчас вроде это единственный нерешённый вопрос.
Если бы br0 после создания был в состоянии UP, вопросов бы не возникало.

Зачем тебе вообще тогда bridge в который не входят другие интерфейсы?

Посмотри уже наконец man systemd.netdev там целая таблица виртуальных интерфейсов на все случаи жизни.

Если бы br0 после создания был в состоянии UP, вопросов бы не возникало.

А вопроса зачем вообще bridge придумали не возникало?

Я видел эту таблицу.
Все относящиеся к systemd-networkd маны я более-менее почитал.
Bridge у меня сделан для того, чтобы сетка в LXC контейнерах работала.
Сейчас это выглядит примерно так (на счёт v4 не уверен, т.к. конфиги не окончательные, а вот v6 точно работает):

cat /etc/systemd/system/bridge.service

[Unit]
Description = Bridge

[Service]
Type = oneshot
RemainAfterExit = yes
ExecStart = /bin/ip link add dev br0 type bridge
ExecStart = /bin/ip link set br0 up
ExecStart = /usr/bin/ip -4 route add 10.10.10.0/24 dev br0
ExecStart = /bin/ip -6 route add 2a01:7e01:e001:a3::/64 dev br0
ExecStop = /bin/ip link set dev br0 down
ExecStop = /bin/ip link del br0

[Install]
WantedBy = multi-user.target

cat /etc/nftables.conf

table ip filter {
	chain forward {
		type filter hook forward priority 0;
		counter continue
	}
}

table ip nat {
	chain prerouting {
		type nat hook prerouting priority 0;
		counter continue
	}

	chain postrouting {
		type nat hook postrouting priority 0;
		ip saddr 10.10.10.0/24 counter snat 172.xx.xx.xx
		counter continue
	}
}

cat /etc/sysctl.d/00-sysctl.conf

net.ipv6.conf.all.forwarding = 1
net.ipv4.ip_forward = 1

cat /var/lib/lxc/example/config

lxc.net.0.type = veth
lxc.net.0.flags = up
lxc.net.0.link = br0
lxc.net.0.name = eth0
lxc.net.0.ipv4.gateway = auto
lxc.net.0.ipv4.address = 10.10.10.2/32
lxc.net.0.ipv6.gateway = auto

# Внутри контейнера
cat /etc/systemd/network/eth0.network

[Match]
Name=eth0

[Network]
Address = 2a01:7e01:e001:a3::1a2f/128

Когда-то возникал, когда только учился настраивать.

Вот подсказка!
systemd-nspawn использует veth с двух сторон.

За подсказку конечно спасибо, но не совсем понял, что с этим делать.
Использовать systemd-nspawn вместо LXC или организовать сетку по тому же принципу?