fedora 40 使用 NetworkManager 创建的网桥无法把配置给它的网卡关联起来，这个问题有 v 友遇到过吗？

[wniming]

正常情况下，如果我用 NetworkManager 创建了一个 eth-br 网桥，并把 eth0 配置为 eth-br 的一个 slave ，eth-br up 起来后，eth0 会自动 master eth-br ， 但是在 fedora 40 的情况下，eth-br up 起来后，eth0 没有 master eth-br 。

我配置网桥的方法用了好多年都没问题（从 fedora 28 到 fedora 39 都可以），但是 fedora 40 不行，网上我没搜到别人遇到相关的问题，但是这个问题在我的任意一台装了 fedora 40 的机器上都能复现，只有很偶尔的情况下是可以直接把 eth0 master eth-br 的。

有 fedora 40 机器的 v 友能帮忙试一下你能用 NetworkManager 配置一个 up 起来能后自动把配置给它的 slave 接口给关联起来的网桥吗?

[passive]

上周折腾了一会儿，最后关了 networkmanager 用 systemd-networkd 搞了。

[wniming]

@passive 你也是遇到同样的问题了吗？

[wniming]

@passive 没了解过 systemd-networkd ，但是不是很想用，上次看这个帖子： https://global.v2ex.com/t/1047924

中科大镜像管理员说他们镜像服务挂掉就是 systemd-networkd 的问题导致的

[kuanat]

看起来是 bug 。

F40 changeset 里面有一些关于 NM 的改动，然后看打包情况 F40 现在是 1.46 ，而 F39 是 1.44 ，可能是中间某个版本引入的。

这个直接向上游 NM 反馈可能比较麻烦，可以试试先向 Fedora Bugzilla 报一下 bug 试试。

[ho121]

可以用 livecd 测试一下

[wniming]

@ho121 我 3 台 x86 机器和 3 台 arm64 机器都有这个问题，虚拟机里也一样，用 NetworkManager 配置好后，每次系统启动后 eth0 能正常 master 一次，但如果用 nmcli down 掉 eth-br 再 up ，eth0 就没有 master

[ho121]

@wniming 我刚用 f40 的 livecd ，拿 usb 网卡测了一下，创建一个 bridge ，usb 网卡作为仅有的 slave 连接互联网。
不管是 ipv6 还是 ipv4 ，不管是插拔网卡还是插拔网线，都能在 1 分钟内恢复网络

[wniming]

@ho121 #7

nmcli con down eth-br
nmcli con up eth-br

这样试试

我之前都是用 nmtui 操作的，但 nmcli 和 nmtui 结果应该一样

[wniming]

@ho121 如果你那里正常的话，把 ip a 的输出贴出来看一下

[wniming]

@ho121 插拔网卡后等待网络恢复要 1 分钟吗？这个感觉也不正常，如果 fedora 40 之前用 nmcli down 掉再 up ，一瞬间网络就会恢复的

[wniming]

@ho121 在 fedora 39 上用 journalctl -f -u NetworkManager 查看 nmcli up 后的日志输出是下面这样子的，而 fedora 40 的日志输出会少很多，没有任何包含 enp1s0 的输出，如果你那里正常的话，能把这个输出贴出来看一下吗？


Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5629] agent-manager: agent[31c1f356d9e3a4c0,:1.90/nmtui/0]: agent registered
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5640] device (eth-br): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5644] device (eth-br): state change: unavailable -> disconnected (reason 'user-requested', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5645] device (eth-br): Activation: starting connection 'eth-br' (1bf47946-d465-465e-87b6-70b5f1e568ff)
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5646] audit: op="connection-activate" uuid="1bf47946-d465-465e-87b6-70b5f1e568ff" name="eth-br" pid=2170 uid=0 result="success"
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5646] device (eth-br): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5646] manager: NetworkManager state is now CONNECTING
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5650] device (eth-br): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5651] policy: auto-activating connection 'eth' (7bb978ea-9354-4f02-be7a-d27b7bcedae7)
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5652] device (enp1s0): Activation: starting connection 'eth' (7bb978ea-9354-4f02-be7a-d27b7bcedae7)
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5652] device (enp1s0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5652] device (enp1s0): state change: prepare -> config (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5752] device (eth-br): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5837] device (enp1s0): state change: config -> ip-config (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5866] device (eth-br): attached bridge port enp1s0
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5866] device (enp1s0): Activation: connection 'eth' enslaved, continuing activation
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5868] device (eth-br): carrier: link connected
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5870] dhcp4 (eth-br): activation: beginning transaction (timeout in 45 seconds)
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5873] device (enp1s0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5879] device (enp1s0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5880] device (enp1s0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.5884] device (enp1s0): Activation: successful, device activated.
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.6335] dhcp4 (eth-br): state changed new lease, address=192.168.1.104
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.6337] policy: set 'eth-br' (eth-br) as default for IPv4 routing and DNS
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.6501] device (eth-br): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.6515] device (eth-br): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.6515] device (eth-br): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.6518] manager: NetworkManager state is now CONNECTED_SITE
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.6521] device (eth-br): Activation: successful, device activated.
Jun 22 19:34:36 fedora NetworkManager[586]: <info> [1719056076.6522] manager: NetworkManager state is now CONNECTED_GLOBAL

[iBugOne]

@wniming 我把 systemd-networkd 跑挂了是因为我尝试用它管理 50 万条路由表条目，超出了内核 netlink 的某种数字范围；我在自己的机器上用 sd-nd 管理网络，只导入了一个大陆 IP 路由表，4000 多条，就没有任何问题

除了配置文件有点啰嗦之外，我还是很推荐 sd-nd 的，尤其是当你已经在用 netplan 之类的前端的时候

[iBugOne]

@wniming #12 我记串了，50 万条路由表跑挂 sd-nd 是另一台机器，镜像站挂的原因是我们自己的一些操作（删了 pref 32766 和 pref 32767 这两条默认的路由规则）导致 sd-nd 导入路由表的时候 netlink 报错，也就是正常操作情况下不应该遇到的问题。当然暂时也不要用 sd-nd 管理 10 万量级的路由表就是了（ systemd 255 修了这个问题）

[wniming]

@iBugOne 听你推荐 sd-nd ，刚才我照着 arch 的教程把网桥配置起来了，感觉 sd-nd 配置不算很复杂，想问一下 systemd-resolved 这个你们有在用吗？我很早之前被这个坑过（具体什么问题忘了）所以一直都觉得这个是个很垃圾的玩意，每次新装系统都要先干掉这个， 你们如果有在有这个的话下次我也尝试用用。

[wniming]

@wniming #14 你们如果有在用这个的话下次我也尝试用用。

[iBugOne]

@wniming #14 除非你的网络结构非常简单（单上游，无分流），否则不推荐 sd-resolved ，只能作为一个最基础的本地 dns 缓存用，没有什么实际意义。我们内部用的是 bind9 （也是学长们留下来的设施，过于高端），普通用户还是推荐 dnsmasq 或者 AdGuard Home 。