服务器 bond 对接交换机为什么容易出问题
服务器双网卡聚合对接是链路聚合里最容易踩坑的场景，因为它同时涉及三件事：服务器侧的 bond 模式、交换机侧的聚合模式、以及流量哈希方式。三者必须匹配，尤其是服务器用 LACP（bond mode 4）而交换机配的是静态聚合时，协商永远建立不起来，服务器侧看到的是成员口状态异常、链路不承载流量。对接前先确定用动态还是静态，然后两边按同一约定配置，最后用服务器侧的 bond 状态文件与交换机显示命令双向确认。
基本信息
| 适用场景 | 服务器双上联、数据库与存储节点链路冗余 |
|---|---|
| Linux 侧模式 | bond mode 4 = 802.3ad，对应交换机 LACP |
| 华为命令族 | Eth-Trunk + mode lacp-static + load-balance |
| 思科命令族 | channel-group mode active + port-channel load-balance |
| H3C 命令族 | Bridge-Aggregation + link-aggregation mode dynamic |
| 验证入口 | Linux 看 /proc/net/bonding，交换机看聚合显示命令 |
典型使用场景
- 数据库主备节点：双网卡接入两台交换机或同一台交换机的两个板卡
- 存储网络：iSCSI 或分布式存储节点需要链路冗余与更大带宽
- 虚拟化宿主机：多网卡聚合后承载虚拟机流量，避免单点故障
- 服务器上线验收：确认聚合真的生效，而不是看似配置完成实际只在单卡转发
- 故障演练：断开一个成员口，验证业务不中断且流量自动切换
交换机侧（三厂）
交换机侧（三厂）
! 华为 VRP
[Huawei] interface Eth-Trunk 20
[Huawei-Eth-Trunk20] mode lacp-static
[Huawei-Eth-Trunk20] load-balance src-dst-ip
[Huawei-GigabitEthernet0/0/23] eth-trunk 20
[Huawei-GigabitEthernet0/0/24] eth-trunk 20
! 思科 IOS
SW-A(config)# interface range GigabitEthernet1/0/23-24
SW-A(config-if-range)# channel-group 20 mode active
SW-A(config)# port-channel load-balance src-dst-ip
! H3C Comware
[H3C] interface Bridge-Aggregation 20
[H3C-Bridge-Aggregation20] link-aggregation mode dynamic
[H3C-GigabitEthernet1/0/23] port link-aggregation group 20服务器侧（Linux bonding）
服务器侧（Linux bonding）
# mode 4 即 802.3ad，与交换机 LACP 对应
ip link add bond0 type bond mode 802.3ad miimon 100 lacp_rate fast
ip link set eth0 down && ip link set eth0 master bond0
ip link set eth1 down && ip link set eth1 master bond0
ip link set eth0 up && ip link set eth1 up
cat /proc/net/bonding/bond0 # 看成员状态与 LACP 协商结果两端模式对应
| 服务器 bond 模式 | 交换机侧要求 | 常见问题 |
|---|---|---|
| mode 4（802.3ad） | 必须配 LACP 动态聚合 | 交换机配静态时永远协商不上 |
| mode 0（balance-rr） | 需固定成员顺序的静态聚合 | 乱序导致性能异常，不建议跨设备使用 |
| mode 1（active-backup） | 通常不需要交换机做聚合 | 交换机误配聚合会引发环路 |
| 哈希方式 | 两端尽量对称配置 | 不对称时单条流仍走单卡，测不出聚合带宽 |
单线程测速测不出聚合带宽是正常现象：聚合是在流级别做哈希，一条 TCP 流只走一个成员口。要验证总带宽需要开多条并发流，或者在交换机和服务器两端分别看各成员的流量分布。
建议把两个成员口接到同一台交换机的不同板卡，或按规划接到两台堆叠交换机的对应端口。接法决定了能防的是网卡故障、板卡故障还是整机故障。