teamd的activebackup与bonding mode=1本质相同但初始化不同：teamd默认不预选主端口，需显式配置runner.active_backup.primary，否则可能因link up顺序导致非预期端口接管流量。
teamd 的 activebackup 和 bonding 的 mode=1 本质一样，但初始化行为不同
两者都只允许一个端口发包，故障时切换；但 teamd 默认不预选主端口，依赖 runner.active_backup.primary 配置或运行时选举，而 bonding 的 primary 参数在加载时即锁定主设备。没配 primary 时，teamd 可能因 link up 顺序导致非预期端口先接管流量。
- 常见错误现象：
teamdctl team0 state显示runner: activebackup，但主备切换后 IP 响应延迟高、ARP 表未刷新 - 必须显式设置
runner.active_backup.primary "ens3"，否则依赖link_watch的探测间隔（默认 100ms），比 bonding 的miimon=100更易漏判瞬断 -
teamd不支持fail_over_mac类似 bonding 的 MAC 行为控制，切换时交换机 MAC 表老化可能引发短暂丢包
teamd 的 loadbalance 没有 bonding 的 mode=2（balance-xor）哈希粒度控制
两者都按源/目的地址哈希分发包，但 bonding 允许用 xmit_hash_policy 指定 layer2 / layer3+4 等策略，teamd 的 runner.load_balance.tx_balancer 只支持 basic（仅 MAC）和 xor（MAC + IP + port，但无法单独禁用 port）。
- 使用场景：后端是多台服务器且希望连接级负载均衡 →
teamd的xor会把同一 TCP 连接始终压到同一物理口，但若对端交换机也做 L4 哈希，可能造成二次偏斜 - 参数差异：
bonding的xmit_hash_policy=layer3+4可应对 NAT 后的源端口变化，teamd的xor在 SNAT 场景下容易让多个内网 IP 被哈希到同一从口 - 性能影响：两者都不做 per-packet 负载，但
teamd缺少resend_igmp类似机制，组播路由切换后 IGMP 报文可能卡在旧端口
teamd 的 lacp 与 bonding 的 mode=4 兼容性关键在 lacp_rate 和 aggregator_select_policy
表面上都走 802.3ad，但 teamd 默认用 lacp_rate=fast（每秒发 LACPDU），而 bonding 默认 slow（每 30 秒）；若交换机只支持 slow，teamd 侧会持续报 LAG not aggregatable 错误。
- 常见错误现象：
teamdctl team0 state显示runner: lacp，但ports下所有接口状态为disabled，dmesg出现lacpdu rx timeout - 必须同步配置：
runner.lacp.lacp_rate "slow"且runner.lacp.aggregator_select_policy "stable"（bonding 的ad_select=stable），否则遇到端口 flapping 时teamd可能频繁重建 aggregator - 兼容性影响：某些老交换机（如 Cisco IE-3000）不识别
teamd发出的 LACP actor key 中的扩展字段，需关掉runner.lacp.port_enabled的自动协商回退逻辑
替换 bonding 为 teamd 时，sysfs 接口和监控方式彻底不同
不能再查 /proc/net/bonding/bond0 或 /sys/class/net/bond0/bonding/slaves，teamd 只暴露 teamdctl CLI 和 D-Bus 接口；脚本中硬编码路径会直接失效。
- 监控要点：
teamdctl team0 state -v输出是 JSON-like 结构，但无标准 schema，解析需依赖正则或jq -r '.runner.port_state.ens3.state'这类字段路径 - 容易踩的坑：systemd service 文件里写
ExecStartPost=/bin/sh -c 'echo 1 > /sys/class/net/team0/bonding/miimon'会报错 ——teamd根本不创建bonding子目录 - 调试建议：用
teamd -d -c /etc/teamd/team0.conf -o team0启动看实时日志，重点盯runner_notify和link_watch模块输出，而不是查/var/log/messages
teamd 的 ethtool 检测默认不启用 delay_up，端口刚 up 就切流量，但 PHY 层实际未稳定；而 bonding 的 updelay 是内置行为。这个时间差在堆叠交换机环境里容易引发 STP 振荡。 
