LACP双活需服务器与交换机协同配置：服务器设mode=4，交换机须全局启用LACP、聚合组内端口参数完全一致、模式设为active；服务器侧需正确设置miimon、lacp_rate、xmit_hash_policy等参数，并验证协商状态、成员口状态、真实带宽及故障切换效果。
Linux网卡双活模式（LACP）本质是让多张物理网卡同时工作、智能分担流量并自动容错，但它的高可用不是单靠服务器配置就能实现的——必须两端协同：服务器启用 mode=4，交换机同步开启 LACP 并严格匹配参数。
交换机端必须满足的三个硬性条件
LACP 能否上线，不取决于服务器配得有多准，而取决于交换机是否“认账”：
-
全局启用 LACP 协议：华为用
lacp enable，思科用feature lacp，H3C 需开启link-aggregation global enable；未启用则 LACPDU 报文被静默丢弃 - 聚合组内端口参数完全一致：速率（全设为 10000baseT-FD）、双工（全强制 full）、MTU（建议统一为 1500 或 9000）、VLAN trunk 允许范围必须相同；任何一项不匹配，LACP 协商直接失败
- 聚合模式设为 active（非 passive）：服务器 bond 接口默认 active，交换机也需设为 active 模式才能双向发起协商；若一端 passive，可能长期卡在 “Agg-Selected” 状态无法 UP
服务器侧关键配置项与避坑点
配置文件中几个字段看似简单，填错一个就导致 bond0 无法获取 IP 或持续 down：
- miimon=100：链路检测间隔，单位毫秒；低于 100 容易误判抖动，高于 200 故障响应变慢；生产环境固定用 100
- lacp_rate=1：对应 fast 模式（每秒发 LACPDU），必须与交换机配置一致；若交换机设 slow（30 秒），服务器会因超时判定对端不可达
- xmit_hash_policy=layer3+4：按源/目的 IP + 端口哈希分流，适合 Web、数据库等多连接场景；仅 layer2 容易导致单连接始终走同一物理口，带宽无法叠加
-
确保 bonding 模块已加载且网卡命名稳定：运行
lsmod | grep bonding；若使用 systemd-networkd，需在 bonds 段明确指定成员接口 MAC 地址，避免重启后 enp3s0 变成 enp4s0 导致 SLAVE 失效
验证是否真正双活运行
不能只看 ip a 显示 bond0 UP，要逐层确认实际效果：
- 查协商状态：
cat /proc/net/bonding/bond0中看到 “Bonding Mode: IEEE 802.3ad Dynamic link aggregation” 和 “Aggregator ID: 1” 表示 LACP 已成功建立 - 看成员口状态：每个 slave 接口下应有 “MII Status: up” 和 “Speed: 10000 Mbps”，且 “Agg Id” 值全部相同
- 测真实带宽：用
iperf3 -c [server] -P 4启动 4 并发流，观察两块物理网卡的 tx_bytes 是否同步增长（cat /proc/net/dev对比）；若只有一张卡跑满，说明哈希策略或交换机负载分发有问题 - 模拟单链路故障：
ifconfig ens33 down，观察业务是否无感切换（ping 不丢包、TCP 连接不断），且 bonding 日志中出现 “link status down for eth0, disabling it” 类提示
为什么 mode=4 比 mode=1 更适合核心业务
mode=1 是主备，永远只用一张卡，故障切换虽快但带宽浪费严重；mode=4 是真双活：
- 两张万兆网卡可稳定跑出 18–19Gbps 实际吞吐（受 TCP 栈和接收端影响），不是理论值的简单相加
- 单物理链路中断时，流量在毫秒级内重哈希到剩余链路，上层应用无感知
- 交换机可基于 LACPDU 主动感知服务器状态，避免“黑洞”转发（即交换机仍往已断链路发包）
- 支持标准 SNMP 监控聚合组状态，便于接入 Zabbix 或 Prometheus 做告警
