nmcli 是主流发行版配置网卡绑定的首选方式，需严格按顺序停用原连接、创建 team 主接口（指定 runner.name）、添加 slave（绑定 con-name）、最后依次启用 slave 再启用 team0。
nmcli 是当前主流发行版（RHEL 7+/CentOS 7+/银河麒麟等）配置网卡绑定的首选方式，比传统 bonding 更轻量、无需手动加载内核模块、原生集成 NetworkManager。但直接套用命令容易失败——问题通常出在顺序、JSON 格式、slave 启用时机或模式选错上。
确认可用网卡并停用已有连接
运行 nmcli device status 或 ip -br a，找出状态为 connected 或 UP 的物理接口（如 ens33、ens34）。若它们已关联某个连接（比如 "System ens33"），必须先停用：
nmcli connection down "System ens33"nmcli connection down "System ens34"
不执行这步，后续添加 team-slave 会报错 device is already managed；也不能用 ip link set down 临时禁用，因为 NetworkManager 会自动重启它。
创建 team 主接口时必须显式指定 runner.name
team 不像 bonding 那样靠 mode=1 这类数字参数，而是通过 JSON 的 runner.name 字段定义行为。常见写法有三种，但注意格式细节：
- 主备冗余（最稳）：
config '{"runner": {"name": "activebackup"}}' - 轮询负载（吞吐优先）：
config '{"runner": {"name": "roundrobin"}}' - 哈希负载（推荐多数场景）：
config '{"runner": {"name": "loadbalance", "tx_hash": ["eth", "ipv4", "ipv6"]}}'
关键点：JSON 外层必须用单引号包裹，内部双引号不能省；con-name 和 ifname 建议统一为 team0，避免后续引用混乱；IP 地址、网关、DNS 必须在创建后用 nmcli connection modify 补全，不能留空。
添加 slave 必须绑定到 con-name，不是 ifname
这条命令常被抄错：nmcli connection add type team-slave ifname ens33 master team0 con-name team0-ens33。重点是 master team0 中的 team0 指的是主连接的 con-name，不是接口名（ifname）。如果创建主连接时用了 con-name myteam，这里就必须写 master myteam，否则 nmcli connection up 会提示 master connection not found。
另外，team-slave 连接本身不配 IP，也不设 ipv4.method，所有网络参数只在 team0 上配置。
启用顺序错误会导致 teamd 不启动
teamd 守护进程只在第一个 team-slave 被启用时自动拉起。所以必须严格按顺序执行：
nmcli connection up team0-ens33nmcli connection up team0-ens34nmcli connection up team0
如果先 up team0，会提示 No suitable device found for this connection；如果漏掉任一 slave，teamdctl team0 state 会显示 runner: initializing 卡住，且 teamnl team0 ports 查不到成员端口。
真正容易被忽略的是：故障恢复后流量默认不切回主网卡（尤其 activebackup 模式），除非你在 config 中加 "runner": {"name": "activebackup", "notify_peers": 5, "mcast_retransmit": 5} 或设置 sticky ——但这不是默认行为，得自己加。
