ip link add name br0 type bridge 创建的网桥默认 DOWN，需 ip link set br0 up 启用，并清空物理接口 IP 后将其加入网桥，再为 br0 配置 IP 才可用。
直接用 ip link add name br0 type bridge 创建的网桥默认不可用，必须显式 ip link set br0 up，且物理接口不能保留 IP —— 否则流量会走错路径，SSH 断连、DHCP 失败都是常见后果。
用 iproute2 手动创建并启用网桥
这是最底层、最可控的方式，适合脚本化或调试场景。它绕过 NetworkManager 或 netplan 的抽象，直操作内核网络设备。
-
ip link add name br0 type bridge创建网桥设备，此时br0状态为DOWN -
ip link set br0 up启用网桥，但此时它仍是“空桥”，没有端口，无法转发 - 把物理接口（如
eno1）加入网桥前，必须先清空它的 IP：ip addr flush dev eno1；否则协议栈仍会尝试从eno1收发包，与网桥行为冲突 - 执行
ip link set eno1 master br0将接口挂到网桥下，bridge link可验证是否成功 - 最后给
br0配 IP（如ip addr add 192.168.1.100/24 dev br0），该 IP 才是主机对外的网络身份
Netplan 配置网桥时 interface 和 bridges 的依赖关系
Netplan 不允许物理接口和网桥同时配置 IP。配置错误会导致 netplan apply 静默失败，或系统启动后无网络。
- 在
ethernets下对物理接口（如enp3s0）必须设dhcp4: no且不配addresses，否则 netplan 会试图单独启用它 -
bridges下的br0必须通过interfaces: [enp3s0]明确绑定，不能只写设备名而不声明归属 - 若启用了
renderer: networkd，则不能在bridges中使用nameservers—— DNS 需由systemd-resolved或外部管理，否则被忽略 -
parameters: stp: false建议始终显式关闭，尤其在单接口桥接场景；开启 STP 会导致约 30 秒初始延迟（forward-delay + max-age），影响服务启动顺序
nmcli 创建网桥后 SSH 断连的修复逻辑
用 nmcli connection add type bridge ifname br0 添加网桥时，NetworkManager 默认不会自动迁移原连接的 IP 和路由，导致连接中断。这不是 bug，而是设计行为。
- 断连后不要直接 reboot，用本地终端或带 IPMI 的服务器继续操作
- 先查原连接名：
nmcli con show，找到绑定在eno1上的连接（通常叫Wired connection 1或类似） - 把该连接的 IPv4 设置改为 manual 并清空地址：
nmcli con mod "Wired connection 1" ipv4.addresses "" ipv4.method disabled - 再为新网桥连接配置 IP：
nmcli con mod br0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns "8.8.8.8" ipv4.method manual - 最后激活：
nmcli con down "Wired connection 1" && nmcli con up br0
brctl 已废弃，但 bridge link 不能替代所有功能
brctl 在较新内核中已被标记为 deprecated，其功能大部分由 ip link 和 bridge 子命令接管。但仍有关键差异。
-
bridge fdb可查 MAC 地址表，等效于旧版brctl showmacs；但bridge vlan仅支持带 802.1Q 标签的端口，无法查看纯 access 口的 PVID -
brctl showstp br0输出人类可读的 STP 状态，而bridge link只显示state forwarding这类简略状态，不暴露 port id、role、designated bridge 等细节 - 如果需要修改 STP 参数（如
hello-time），必须用ip link set dev br0 type bridge hello-time 2，bridge命令本身不提供 set 接口 - 某些嵌入式系统（如 OpenWrt）仍默认只装
brctl，没装iproute2的完整版，此时不能假设bridge link一定可用
真正容易被忽略的是：网桥的 MAC 地址默认继承第一个加入的接口，但如果你先加 veth 再加物理网卡，MAC 可能变成随机生成的本地地址，导致交换机学习到错误的端口映射 —— 这种问题在虚拟化环境里要靠 ip link set dev br0 address xx:xx:xx:xx:xx:xx 强制固定。
