roundrobin能兼顾冗余和负载：每包轮询分发至不同物理口，天然流量分散，单链路故障时自动跳过，其余链路持续工作，无需交换机聚合支持，适合内网多连接场景。
team模式选哪个runner能兼顾冗余和负载？
不能直接用 activebackup，它只有一张网卡干活，另一张纯 standby，完全不参与流量分担；也不能盲目上 loadbalance，它依赖哈希（如源/目的 IP+端口），在单 TCP 连接下仍走固定物理口，实际负载并不均衡。
真正兼顾冗余与轻量级负载的选项是 roundrobin：每包轮询发往不同从网卡，天然分散流量，且任一链路断开后自动跳过，其余链路继续工作。
-
roundrobin适合多数内网服务、HTTP/HTTPS 多连接场景，无需交换机特殊配置 -
loadbalance需要交换机支持 LACP 或静态聚合，且对哈希分布敏感，小流量可能集中于某口 -
activebackup只解决故障切换，不提升吞吐，别被“负载”二字误导
nmcli创建team0并绑定两张网卡的最小可行命令集
关键不是堆参数，而是顺序不能错：先建逻辑 team 接口，再加物理 slave，最后 up —— 少一步，ping 就不通。
- 创建 team0（使用
roundrobin）：nmcli connection add type team con-name team0 ifname team0 config '{"runner":{"name":"roundrobin"}}' ip4 192.168.10.100/24 - 添加第一张物理网卡（如
ens224）：nmcli connection add type team-slave con-name team0-port1 ifname ens224 master team0 - 添加第二张物理网卡（如
ens256）：nmcli connection add type team-slave con-name team0-port2 ifname ens256 master team0 - 启动两个 slave 和主接口：
nmcli connection up team0-port1nmcli connection up team0-port2nmcli connection up team0
注意：con-name 是连接名（可自定义），ifname 必须是真实网卡名，用 ip -br a 确认，别写成 eth0 这类旧命名。
为什么配置完 ping 不通？常见链路级疏漏点
不是配置语法错，而是 team 启动后默认不自动启用物理口，或链路检测失败导致 runner 拒绝启用任何 slave。
- 检查
teamd是否运行：systemctl status teamd—— 若 inactive，手动systemctl start teamd并enable - 查看 team 状态是否识别到 link up：
teamdctl team0 state—— 若显示link watches: [ethtool]但所有 port 状态为down，大概率是物理线没插、交换机端口 shutdown、或网卡被nmcli device disconnect过 - 确认物理网卡未被其他 connection 占用：
nmcli connection show --active—— 若ens224出现在列表中，先nmcli connection down ens224再 up 对应的team0-port1 - 别忽略 MTU：若两块网卡 MTU 不一致（如一个 1500，一个 9000），
teamd会静默拒绝激活，统一设为1500最稳妥
验证冗余与负载是否真生效？别只看 up/down
光 ping 通不代表负载分担，也看不出故障切换是否平滑。得看数据面行为。
- 实时观察流量出口：
watch -n 1 'cat /proc/net/team/team0 | grep -A 5 "ports:"'—— 正常时两块口都应显示link up和speed - 模拟单链路故障：
nmcli device disconnect ens224（别用ifconfig down，nmcli 管理更干净）—— 观察teamdctl team0 state中 port 切换是否秒级完成，ping是否无丢包 - 验证负载分发：在另一台机器上并发发起多个
curl请求（如for i in {1..20}; do curl -s http://192.168.10.100/test & done），然后在 server 上执行：tcpdump -i ens224 -c 10 'port 80' -w /tmp/224.pcap & tcpdump -i ens256 -c 10 'port 80' -w /tmp/256.pcap—— 查看两个 pcap 中的包数是否接近（roundrobin下大致 1:1）
真正容易被忽略的是 runner 的初始化延迟：首次 up team0 后，teamd 需约 2–3 秒完成 link watch 启动和 port 选举，这期间 ping 会丢 2–3 包，不是配置失败，是正常握手过程。
