双网卡绑定后吞吐减半的主因是策略错位：模式选错（如误用mode=1）、交换机未配lacp、哈希策略失衡（如layer2导致同流全走单卡）；需查/proc/net/bonding/bond0状态、交换机lag协商结果、实时收发包分布及xmit_hash_policy适配性，并排查mode=6驱动兼容性问题。
双网卡绑定后吞吐减半，不是带宽没叠加，而是策略配置错位导致流量压在单卡上——最常见原因就三个：模式选错、交换机没配对、哈希策略失衡。下面直接说怎么一层层揪出来。
看 /proc/net/bonding/bond0 确认实际工作状态
这是第一眼必须查的地方，不看这个，其他全是瞎猜：
- 如果只显示一块网卡是 Active，另一块是 Backup 或 Down，那大概率是 mode=1（主备）被误用，或者 mode=4/6 因驱动或交换机问题降级运行
- 如果两块都标 Active，但 MII Status 一个 up 一个 down，说明物理链路或 miimon 检测异常，备卡根本没真正参与
- 若显示 xmit_hash_policy: layer2，而你跑的是大量同源同目的 TCP 流（比如客户端固定 IP 访问服务端固定 IP），那所有包都会哈希到同一张网卡，吞吐自然卡在单卡上限
查交换机侧是否真正启用 LACP（仅 mode=4 场景）
mode=4（802.3ad）下，服务器起得来 ≠ 聚合生效。必须双向确认：
- 服务器端执行：cat /proc/net/bonding/bond0 | grep -A5 "LACP"，看到 LACP partner 信息才表示协商成功
- 交换机侧执行对应命令：show etherchannel summary（Cisco）、display eth-trunk（华为）或 show lacp sys-id，确认状态为 UP 且协议列为 LACP
- 若交换机显示 Individual 或 StandAlone，说明端口没加入 LAG 组，或 LACP 模式设成了 active/passive 却未在服务器侧匹配
验证流量是否真实分发到两张网卡
不能只信 ifconfig 或 ip link 的 UP 状态，要看实时收发包分布：
- 执行：watch -n1 'cat /proc/net/dev | grep -E "(eth|bond)"'，观察 eth0/eth1 的 RX/TX 字节数是否同步增长；若长期只有 eth0 动，eth1 几乎为 0，就是哈希或模式失效
- 用 tcpdump -i eth0 port 80 & tcpdump -i eth1 port 80 & 同时抓包，对比两个文件的包数量比例；理想情况应接近 1:1（mode=4/6 下）
- 检查 xmit_hash_policy 是否适配业务：默认 layer2 不适合 Web 服务，建议改为 layer2+3 或 encap2+3（需内核 ≥ 3.16），尤其当后端是负载均衡器或容器集群时
排除驱动与 ethtool 兼容性陷阱（mode=6 专用）
mode=6（balance-alb）看似免交换机，实则对网卡驱动要求最严：
- 运行：ethtool eth0 | grep -i "perm\|mac"，确认 Permanent address 存在且可读；再执行 ethtool -s eth0 wol d，不报错才算基础支持
- 查看 /var/log/messages 或 dmesg | grep bonding，搜索关键词 "alb: failed to set mac" 或 "ethtool not supported"，这类日志一出现，mode=6 就已自动回退到单卡行为
- 临时降级测试：把 BONDING_OPTS 改成 "mode=1 miimon=100"，重启 bond0，再跑同样流量测试吞吐。若立马翻倍，基本锁定是 mode=6 驱动不兼容
