HP服务器双网卡绑定后，流量由绑定的工作模式决定走向：主备模式仅由主网卡承担收发，备用网卡只在故障切换时接管；负载均衡/LACP模式则通过哈希算法把不同流量分散到双网卡上，最终由交换机配合完成双向路径分配。
HP服务器双网卡绑定后流量走向分析
双网卡绑定是服务器上常见的网络加固手段,逻辑上，操作系统只看到一个bond接口，例如Linux里的bond0或Windows Server里的Team；物理上，两块网卡各自连接交换机端口，流量最终怎么走，完全取决于bond驱动选择的工作模式。
绑定模式决定转发逻辑
主备模式（active-backup）下，平时只有一块网卡在收发数据，另一块保持备用状态，只监听链路是否可用，所有流量的路径都走主网卡，备用网卡虽然链路up，却不承载任何数据。
负载均衡模式（balance-rr、balance-xor、adaptive等）下的流量会被拆开，发送和接收可能分别走不同的物理网卡，Linux内核bonding模块根据xmit_hash_policy选择网卡，默认按网络层地址做哈希。
链路聚合模式（802.3ad，即LACP）要求服务器和交换机同时开启LACP，出站流量由服务器哈希计算后选择一块网卡发送，入站流量则由交换机根据对端地址计算哈希，决定从哪块网卡送到服务器。
行业共识是,主备模式最稳妥，负载均衡模式能提升吞吐，但对外部网络环境和哈希策略敏感。
出站和入站流量分别怎么走
出站路径比较好理解,应用发数据到bond口，bond驱动按模式计算哈希，从对应物理网卡发出，例如Linux绑定模式4下，默认的xmit_hash_policy是layer2，根据源 MAC 和目的 MAC 做异或运算，再对网卡数量取模，决定从第一块还是第二块网卡发出。
入站路径则没那么直观,以LACP模式为例，流量进物理网卡前，先经过交换机端口，交换机在聚合组的成员端口之间做负载均衡，决定数据从哪个端口送入服务器，服务器虽然只看到流量正常进入bond口，却不一定知道它落地在哪块物理网卡，据Linux内核bonding文档说明，802.3ad模式下的接收方向无法完全保证按入站会话均匀分布，因为它依赖交换机侧的哈希算法。
比如搭建HP DL380 Gen10时，常见到第二块网卡
rx_bytes持续增长，第一块网卡却相对空闲，这正是交换机对入站流量哈希倾斜的表现。
绑定后IP与MAC地址的归属
绑定后逻辑接口的MAC地址默认取自第一块物理网卡,或者由bond驱动统一生成，物理网卡的MAC地址会被修改为与逻辑口相同，方便外部设备记住一台服务器的地址，主备模式下，切换发生时，新主网卡的MAC始终保持与逻辑口一致，所以对网络中的对端设备是透明的。
这里就引出了绑定模式之间的核心差异,也是排查问题最常遇到的坑。
双网卡绑定负载均衡和主备模式有什么区别
主备模式：全部流量由单个网卡承担
主备模式适合追求稳定、不要求吞吐翻倍的场景，绑定后只有active网卡处理流量，backup网卡链路up但无数据包，切换触发靠miimon或arp_interval检测链路，实际切换时间通常在秒级（例如100毫秒探测一次，连续三次失败触发切换）。
负载均衡模式：哈希决定流量如何拆分
Linux的balance-rr是每个包轮流走两块网卡，balance-xor则用哈希值选择网卡，发送方向可以做到相对均匀，接收方向仍依赖交换机，Windows Server的Address Hash模式按IP和端口哈希选择出站网卡，入站由交换机负责分配，动态模式（Dynamic）是微软推荐的模式，通过软件协商减少对交换机静态配置的依赖，但同样需要交换机端开启LACP才能形成外部聚合链路。
模式对比
| 模式 | 出站 | 入站 | 对交换机要求 | 适用场景 |
|---|---|---|---|---|
| 主备 | 走主网卡 | 走主网卡 | 无 | 数据库单点、业务连续性要求高 |
| 负载均衡（balance-xor） | 哈希分摊 | 由对端交换机哈希分配 | 需要交换机支持静态聚合 | 多用户高并发访问 |
| LACP | 哈希分摊 | 由交换机哈希分配 | 必须开启LACP | 核心业务，吞吐和冗余并重 |
负载均衡模式和主备模式的本质区别在于：负载均衡模式期望流量同时走两块网卡，主备模式则期望减少变量，相当一部分运维团队在部署hp服务器双网卡绑定时候，会因为不清楚这个区别，在负载均衡模式下发现流量总走一块网卡，误以为绑定无效。
HP服务器双网卡绑定 切换与故障恢复
故障切换的关注点不在流量怎么算,而在于切换过程是否丢包、对端设备是否感知。
网卡故障切换触发时间
Linux bonding的miimon=100表示每100毫秒检查一次设备链路状态，连续三次失败后触发切换，Windows NIC Teaming主备模式下，默认故障恢复时间约为10秒，可手动调整，切换期间bond接口不会down，但不保证正在进行的TCP会话不受影响。
故障切换时流量实际路径
主备模式下,备用网卡接管后，会重新发送一个Gratuitous ARP，把自身MAC通告给交换机，让对端把流量导到新物理口，LACP模式下，端口状态变化会通过LACPDU通知交换机，交换机更新转发表，流量收敛更快。
不少生产环境里,hp服务器双网卡绑定后出现丢包，不一定是绑定本身的问题，而是交换机端口配置了STP，端口要经历阻塞、侦听、学习、转发等状态，最长可达几十秒，切换时就会出现明显超时，据公开技术资料，绑定项目实施中因STP边缘端口未开启而导致的切换丢包，占到相当比例。
HP服务器双网卡绑定 交换机配置要点
绑定和交换机是同一枚硬币的两面,主备模式不需要交换机做任何配置，但如果要走LACP，交换机上必须把两个端口划分到同一个聚合组，并开启动态LACP。
交换机侧常见配置逻辑
华为交换机上,需要创建Eth-Trunk，将物理口加入，并设置链路聚合模式为LACP。 思科交换机上，对应配置是Port-channel加channel-group模式active。
无论华为还是思科,连接服务器的端口都需要开启边缘检测或关闭STP延迟，否则端口切换后要等STP收敛，业务中断时间会放大到几十秒。
交换机侧哈希策略影响入站流量
入站流量由交换机选择成员口,服务器侧无法干预接收方向的均匀性，如果交换机默认按源MAC哈希，同一台客户端访问服务器的持续流量就只会有一条路径，另一块网卡成了摆设，要让多客户端流量被分散，交换机侧需要把负载分担模式设为按源MAC+目的MAC，或按IP+端口哈希。
服务器侧绑定负载均衡不均衡时,第一件事是检查交换机端口的负载分担算法是否配置正确。
HP服务器双网卡绑定后流量打不满？先查这三处
- 检查bond模式与交换机是否匹配,LACP模式下交换机端口必须是动态聚合，否则LACPDU协商失败，聚合口一直起不来。
- 检查
xmit_hash_policy，默认layer2在VLAN环境里只用MAC计算，源目MAC变化少，哈希结果容易倾斜，改成layer2+3或layer3+4效果更明显。 - 检查物理网卡速率与双工是否一致,两块网卡速率不匹配会让哈希结果整体偏向快的网卡。
这些排查步骤来自真实的hp服务器双网卡绑定部署场景,适合在流量异常时逐条验证，具体命令包括：cat /proc/net/bonding/bond0查看当前活动网卡和哈希策略，ethtool bond0查看负载分布，再用iperf3分别走两条物理链路做吞吐测试。
Q&A：hp服务器双网卡绑定常见问题
Q：hp服务器双网卡绑定后流量都走第一块网卡，正常吗？
如果配置的是主备模式,这是正常现象，如果是负载均衡或LACP模式，先看/proc/net/bonding/bond0显示的当前活动网卡是否为两块，再确认交换机聚合组处于up状态，最后检查哈希策略，多数情况下是交换机侧未生效或哈希维度单一造成的。
Q：绑定后两块网卡的带宽能叠加吗？
不能,绑定解决的是冗余和连接数分散，不是单条会话的带宽叠加，单个大流量会话在哈希模式下只会落在一块网卡上，除非使用balance-rr或按包轮询策略，但后者会带来乱序和TCP性能副作用，生产环境不建议使用。
Q：LACP绑定和主备绑定的切换延迟差异大吗？
LACP绑定切换更快,因为LACPDU能提前感知链路状态，交换机也能同步更新转发路径；主备绑定完全依赖服务器端检测，默认miimon设置下切换在秒级完成，但交换机STP未配置边缘端口时，实际延迟会放大到几十秒，生产环境建议将交换机端口配置为静态聚合或带LACP的边缘模式，结合服务器侧arp_interval=1000，切换速度和收敛效果都更可控。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/699282.html
