网卡绑定这件事说起来不复杂但真正在生产环境里把它用对的并不多。bond 技术指的是把多块物理网卡在系统内核里合并成一个逻辑网卡对外只暴露一个接口名和一组 IP而mode 模式决定了这个逻辑网卡到底怎么把数据包分摊到各块物理网卡上、主备怎么切换、需不需要交换机配合。很多人配完mode4发现ip link全是 UP但业务就是不通最后折腾一晚上问题往往出在交换机那一侧根本不是动态聚合。这篇内容面向正在做服务器网络冗余、想做带宽扩展、或者被 bond 的几种模式搞晕的运维和开发人员从协议栈位置、七种模式的转发逻辑、选型判断依据一直讲到手工配置细节和上线后的排查链路。不管你是第一次配 bond还是配过好几次但总觉得心里没底下面的内容应该都能对上你的场景。1. 内核层做网卡绑定到底解决了什么先把定位说清楚后面所有的模式选择才有判断依据。bond 是内核 netdev 层的一个虚拟设备它下面挂若干个真实的 slave 网卡上面接着 IP 层。对 IP 层而言bond0和一块普通网卡没有区别路由、iptables、socket 绑定全部感知不到下面有几块物理网卡。这个透明特性是它好用的地方也是它容易出问题的根源——上层完全不知道底层什么时候切了口。1.1 单网卡故障的代价与两种冗余思路一块网卡出故障链路 down 掉服务器就从网络上消失了。表现可能是 SSH 卡死、可能是数据库主从断连、也可能是负载均衡健康检查失败后整台机器被摘除。如果这块网卡还承载着心跳或者存储流量后果会更难看。对付这个问题的思路只有两条一条是在协议层做冗余比如两块网卡各配一个 IP靠上层软件的探测和重连来容错另一条是在链路层做冗余把多块网卡合成一个让切换发生在毫秒级、对上层完全无感。bond 走的是后一条路。选它而不是前者核心原因就一个上层软件的探测周期通常是秒级的而 bond 的 miimon 探测默认是 100 毫秒差了整整一个数量级。1.2 bond 设备在协议栈里的位置意味着什么理解下面这句话能省掉很多误判bond 只处理从哪个 slave 发出去和从哪个 slave 收进来这两件事它不改变 IP、不改 VLAN tag 的处理顺序、也不参与路由决策。由此可以推出几条实操结论。第一bond0 上可以再建 VLAN 子接口、可以配 IPv6、可以挂网桥这些都正常工作因为它在 netdev 层就是一个完备的接口。第二bond 无法帮你解决对端交换机只有一条上行链路这类问题那条上行链路本身就是单点。第三bond 的负载均衡是按流的不是按包的除非你选mode0但那个选择会带来乱序问题后面细说。1.3 交换机侧的配合是绕不过去的硬约束bond 里最容易翻车的地方在这里。内核侧配置得再漂亮只要交换机侧没按对应方式配置结果就是全不通或者部分不通。非堆叠的两台交换机分别接一根线到同一台服务器的两块网卡这种情况下你能用的只有active-backup和balance-tlb/alb这几类不需要交换机配合的模式。想在两台独立交换机上做链路聚合交换机必须支持堆叠或跨设备聚合M-LAG 一类否则两台的 MAC 表和 STP 状态会互相打架。这个约束不是配置技巧能绕过去的是硬件能力问题。判断顺序建议反过来先去交换机上看它支持什么、已经配了什么再回来决定内核侧写哪个 mode。很多人习惯先在系统里配好再去求交换机侧配合结果发现对面是台老设备只能推倒重来。2. 七种 mode 的转发逻辑逐条拆开看mode的取值是 0 到 6一共七种。文档上每种的描述都很短实际用起来差异巨大。下面按发送策略和对交换机的要求两个维度把它们拆开。2.1 balance-rr 与 broadcast两个极端的取舍mode0 balance-rr是轮询第一个包从 slave0 发第二个从 slave1 发依次循环。看起来最均衡但问题在于同一条 TCP 流的报文会被拆到不同物理链路上而两条链路的延迟不可能完全一致到达对端就会乱序。接收端要重排重排缓冲满了就丢包重传实测吞吐经常比单网卡还差。它适合的场景非常窄多路径存储、某些对乱序不敏感的 UDP 流。mode3 broadcast更极端每个包从所有 slave 都发一份。这等于把所有带宽浪费在冗余上除了极端容错场景比如需要保证任意一块网卡故障时对端都能收到几乎没人用。它不需要交换机做任何配置。2.2 active-backup最不花哨但最靠谱的兜底mode1同一时刻只有一个 slave 处于 active 状态其余备份。故障时内核把 MAC 和 IP 迁到备份口上配合primary参数可以指定回切偏好。这个模式有两个非常实用的特性。一是它完全不需要交换机配置插上就能用这在跨交换机、跨机柜的场景里是唯一选择。二是它支持fail_over_macactive切换时由新 active 口对外通告自己的 MAC 做免费 ARP避免交换机 MAC 表还指向旧口。缺点是带宽只有单口那么多另一块网卡纯闲置。但在绝大多数要求高可用、不要求带宽的业务里这个模式是性价比最高的选择我个人的默认推荐就是它。2.3 balance-xor 与 802.3ad哈希与协商的区别mode2 balance-xor按哈希值选出口哈希因子由xmit_hash_policy决定默认是layer2源 MAC 目的 MAC 协议号。它不做任何协商交换机侧必须手工配置成静态聚合不启用 LACP。mode4 802.3ad是动态聚合走 IEEE 802.3adLACP协议。内核会周期性发 LACPDU和交换机协商哪些口属于同一个聚合组只有协商成功的口才会参与转发。这是唯一一个能自动感知交换机侧配置是否正确的模式——配错了它就老老实实不通反而好排查。两者的关键差异在收敛行为mode2的口只要物理链路 up 就会被加入哈希池交换机侧如果还没配好流量就会丢mode4要等 LACP 协商完成才会加入中间有一段链路 up 但不可用的状态这段状态是排查时最容易误判的地方。2.4 balance-tlb 与 balance-alb需要驱动配合的软件方案mode5 balance-tlb做发送方向的负载均衡接收方向仍然只用当前 active 口。它不需要交换机配置但每块 slave 网卡驱动必须支持ethtool -K修改收发哈希设置。mode6 balance-alb在 tlb 基础上增加了接收负载均衡靠 ARP 应答把不同客户端的入向流量引导到不同 slave 上。它同样不需要交换机配置但要求驱动支持修改 MAC 地址。这两种模式在虚拟化环境里比较有用宿主机对端接的是普通接入交换机没法做聚合但希望尽量用上多块网卡的带宽。代价是它们对驱动的依赖比较强网卡型号换一个可能就不生效了而且抓包分析会变得很麻烦因为不同 slave 上的 MAC 不一样。mode名称发送策略交换机要求典型场景0balance-rr逐包轮询静态聚合多路径存储、UDP1active-backup单口转发故障切换无需配置高可用优先2balance-xor哈希选口静态聚合多流、带宽优先3broadcast全口复制发送无需配置极端容错4802.3adLACP 协商 哈希动态聚合LACP标准数据中心方案5balance-tlb发送均衡、接收单口无需配置交换机能力受限6balance-alb收发均均衡无需配置虚拟化宿主机3. mode 选型的判断依据从交换机侧往回推选型这件事网上一堆推荐 mode4的说法其实害了不少人。正确的推法是从外往里推先确认交换机能力再看流量模型最后看业务对中断的容忍度。3.1 第一步永远先问交换机支持什么问三个问题就够了这几根线是不是接在同一台交换机或者堆叠后的同一逻辑设备上交换机端口能不能配成聚合组聚合组是静态还是 LACP 动态如果答案是接在两台独立交换机上那么 0/2/4 全部出局只能在 1/5/6 里挑通常直接选 1。如果答案是同一台但交换机端口只能配静态聚合那就选 2 或 0其中 2 更稳。如果答案是支持 LACP且运维愿意配合配置选 4。这个顺序很重要因为内核侧的配置随时能改交换机侧的变更通常要走审批、要窗口期。先确认后者能省掉大量返工。3.2 流量模型决定了哈希策略而不是反过来很多人抱怨配了 mode4两块万兆网卡测速加起来还是只有 10G 出头。这不是 bond 坏了是哈希撞车了。默认的xmit_hash_policylayer2只按 MAC 做哈希如果两台机器之间只有一条 TCP 连接源 MAC 和目的 MAC 都是固定的哈希结果恒定所有包都从同一个口出去。要解决这个问题得看你的流量特征大量小流量会话Web 服务、微服务调用源 IP 分散用layer34效果最好端口号参与哈希分布最均匀。存储流量、备份流量通常是少数几条大连接无论什么策略都只有个别口跑满这时候追求带宽叠加没意义应该考虑上更大速率的单口。中间夹着 VLAN 的场景vlansrcmac在某些交换机上更匹配对端的哈希算法能减少我这头发得匀对端收得不匀的情况。判断哈希是否均匀最直接的办法是看各 slave 的收发计数增长速度cat /proc/net/dev连看几次如果几个口增长速度差不多说明分发正常如果只有一个口在涨就是哈希撞车或者策略选错了。3.3 虚拟化宿主机和容器节点要单独考虑宿主机上跑着几十台虚拟机或者上百个容器源 MAC 极度分散此时layer2哈希反而效果很好因为虚拟机的 MAC 是天然随机的。这种情况下 mode4 配layer2是常见组合。如果是容器节点且用的是 overlay 网络那么多出来的封装头会影响哈希因子的选取可以考虑encap23或encap34这类策略让哈希落在内层包头而不是外层隧道地址上——外层地址往往是固定的两个节点 IP拿来做哈希因子几乎没有区分度。3.4 一份可以直接抄的组合参考环境特征推荐 mode关键参数理由两台独立交换机接入1primaryfail_over_macactive跨设备无法聚合只求切换同交换机、支持 LACP4miimon100、lacp_ratefast标准方案可自动校验配置同交换机、不支持 LACP2xmit_hash_policylayer34静态聚合下的稳定选择云主机 / 虚拟网卡不用 bond—底层不支持配了也没意义交换机侧完全不能动6 或 1依赖驱动支持纯软件方案4. 手工配置全过程与参数细节配置本身不难难在参数取舍。下面按配置文件怎么写和参数为什么这么填两条线并行走。4.1 三种主流配置路径的差异第一类是传统 ifcfg 风格在/etc/sysconfig/network-scripts/下建一个ifcfg-bond0然后每个 slave 的配置文件里写MASTERbond0和SLAVEyes同时在/etc/modprobe.d/bonding.conf里加一行alias bond0 bonding选项通过options bond0 miimon100 mode4传入。这种方式的坑是如果系统上 NetworkManager 和传统 network 服务同时在跑重启后谁生效不一定配置会莫名其妙丢失。第二类是 NetworkManager 的 nmcli命令式不用手写文件nmcli con add type bond ifname bond0 con-name bond0 mode 802.3ad miimon 100 lacp_rate fast nmcli con add type ethernet ifname eno1 master bond0 nmcli con add type ethernet ifname eno2 master bond0 nmcli con mod bond0 ipv4.method manual ipv4.addresses 192.0.2.10/24 nmcli con up bond0这种方式的好处是状态统一由 NetworkManager 管不会和别的服务打架。建议在新版本系统上优先用它。第三类是 netplanDebian 系较新的版本用 YAML 描述network: version: 2 ethernets: eno1: {} eno2: {} bonds: bond0: interfaces: [eno1, eno2] parameters: mode: 802.3ad mii-monitor-interval: 100 lacp-rate: fast transmit-hash-policy: layer34 addresses: [192.0.2.10/24]注意 YAML 对缩进敏感parameters下的键名用的是连字符风格和内核参数名不完全一样写错不会报错但会静默失效配置完一定要去/proc/net/bonding/bond0核对实际生效值。4.2 miimon 和 arp_interval 该用哪个miimon是基于网卡物理层的链路状态检测间隔单位毫秒常用 100。它反映的是网线插着没、光模块有没有信号速度快但有个盲区如果中间隔着传输设备或者交换机端口处于 err-disable 状态物理层可能还是 up 的miimon 检测不出来。arp_interval是主动发 ARP 请求探测对端是否可达配合arp_ip_target指定探测目标。它能发现链路 up 但对端不通的情况但对端设备必须响应 ARP且目标 IP 要选稳定在线的设备网关或者同网段的另一台服务器。两者可以同时用实际配置里常见miimon100 arp_interval1000 arp_ip_target192.0.2.1这种组合。这里有个细节arp_ip_target最多只能写 16 个且多个目标会轮询探测配太多会拖慢单次探测周期。一个容易被忽略的坑downdelay和updelay默认是 0意味着检测到故障立刻切换。如果链路上有光模块抖动会导致频繁 flap日志里满屏切换记录。建议downdelay设成 miimon 的 2 到 3 倍比如miimon100 downdelay300能过滤掉大部分瞬时抖动。4.3 802.3ad 专属的几个参数lacp_rate控制 LACPDU 的发送频率slow是 30 秒一次fast是 1 秒一次。默认slow收敛慢但开销小。如果对故障切换时间敏感比如承载数据库心跳改成fast。ad_select决定聚合组内怎么选 active 口stable是默认值选第一个可用口bandwidth选带宽最大的count选口数最多的。多数场景用默认就行只有在成员口速率不一致时才需要动它。min_links是个很实用的保护参数表示至少要有几个 slave 处于 up 状态这个 bond 才保持 up。比如配min_links2当只剩一个口时整个 bond 直接 down 掉。这看起来是自断后路但在某些存储网络里是正确的取舍——用一条链路跑不如不跑让上层感知到故障比降级运行更安全。# 查看当前生效的全部参数 cat /proc/net/bonding/bond0 # 临时改哈希策略重启失效 echo layer34 /sys/class/net/bond0/bonding/xmit_hash_policy4.4 配完之后必须做的三项验证第一项是结构验证ip link show里 bond0 和两块 slave 都在slave 的master字段指向 bond0。第二项是协商验证看/proc/net/bonding/bond0里每个 slave 的MII Status、Aggregator IDmode4 时还要看Partner Mac Address是不是非零——全零说明对端没发 LACPDU交换机侧没配。第三项是切换验证这一步最容易被跳过。手工把一根网线拔掉或者ip link set eno1 down同时开一个持续 ping观察丢几个包。active-backup 正常丢 1 到 3 个包mode4 正常也差不多。如果丢十几个甚至几十个说明downdelay设置不合理或者交换机侧 STP 在收敛需要回头调。5. bond 起来了但不通完整排查链路这一节按真实排查顺序写每一步给出判断依据方便你对着复现。5.1 第一层判断链路是否真的 upethtool eno1 | grep -E Link detected|Speed|Duplex如果Link detected: no问题在物理层跟 bond 配置无关先查光模块、跳线、交换机端口状态。如果 up 但Speed显示Unknown!通常是协商失败检查两端速率和双工是否强制一致——一边强制千兆一边自协商最容易出这种状态。这一层还有一个隐蔽情况光模块不兼容导致链路 up 但误码率极高ethtool -S eno1里能看到 CRC 错误计数持续增长。这种情况下 bond 会不停切换日志里全是link status definitely up。5.2 第二层判断LACP 协商有没有成功mode4 时去/proc/net/bonding/bond0看这一段Slave Interface: eno1 MII Status: up Speed: 10000 Mbps Duplex: full Link Failure Count: 0 Permanent HW addr: xx:xx:xx:xx:xx:01 Slave queue ID: 0 Aggregator ID: 1 Actor Churn State: none Partner Churn State: none关键看Aggregator ID和Partner部分。两个 slave 的Aggregator ID必须相同不同说明它们没有协商到同一个聚合组通常是交换机侧只配了其中一个端口。Partner Mac Address如果是全零100% 是交换机侧没启 LACP 或者启在了错误的端口上。想在系统侧直接确认 LACPDU 有没有收到可以抓包tcpdump -i eno1 -c 10 ether proto 0x8809有回包说明对端在发没回包就是对端没配。这一步能直接定位责任边界比在交换机上翻配置快得多。5.3 第三层判断MAC 表和 ARP 是否打架配置都对了但只有单向通或者通一会儿断一会儿八成是 MAC 表问题。现象是ping前几个包能通之后就丢了。原因是交换机在多个端口上学习到同一个源 MACMAC 表不停翻转。判断方法是在服务器上arping网关同时在交换机上看 MAC 地址表里这个 MAC 挂在几个端口上。如果是active-backup模式出现这个问题检查fail_over_mac是不是配成了none——两个 slave 用同一个 MAC交换机分不清该往哪个口送。这个坑我第一次遇到时排查了很久因为ip link看一切都是正常的bond 状态 activeslave 都 up就是丢包。最后在交换机侧看 MAC 表才发现同一个 MAC 在两个口上来回跳。5.4 一份对照表覆盖最常见的报错形态现象最可能原因验证方法处理bond0 起不来无 slaveslave 配置里缺MASTERip link看 slave 的 master 字段补配置后重建 bondmode4 全不通MII 都 up交换机未启 LACP抓 0x8809 报文交换机侧配动态聚合只能单向通信MAC 表翻转 / 哈希策略不匹配交换机 MAC 表调xmit_hash_policy或fail_over_mac测速只有一个口跑满单流场景哈希撞车cat /proc/net/dev对比增速换layer34策略频繁切换日志刷屏链路抖动 /downdelay0Link Failure Count持续增长加downdelay查光模块重启后配置丢失NetworkManager 与 network 服务冲突systemctl status看两个服务关掉不用的那个虚拟机里配了不生效虚拟网卡不支持ethtool -i看驱动放弃 bond改用上层方案6. 上线之后怎么盯观测点与变更风险bond 配好只是开始长期运行里有几个指标值得持续盯。6.1 从 /proc 里读出的健康信号/proc/net/bonding/bond0里每个 slave 都有一个Link Failure Count这是累计值正常情况下应该长期不变。如果发现它每隔几小时涨一次说明链路在周期性抖动多半是光模块老化或者跳线接触不良。这个字段比看日志直观因为它不会因为日志轮转而丢失历史。另一个值得关注的是Slave queue ID和Aggregator ID的一致性尤其在做过交换机固件升级之后聚合组重新协商可能导致 ID 变化。mode4 下如果两个 slave 的 Aggregator ID 不一致说明它们被分到了不同聚合组此时带宽实际只有一半。6.2 监控指标怎么采集比起看单个数值更有效的是看增速的比值。采集每个 slave 的rx_bytes和tx_bytes算出一段时间内的增量再算各 slave 占总量的比例。mode4 下这个比例应该大致均衡如果长期是 100% / 0%说明哈希策略在这个流量模型下失效了。这个指标比单纯看网卡是否 up有价值得多因为它是能用和用得好的区别。告警阈值建议这样设任一 slave 的 Link Failure Count 在 1 小时内增长超过 3 次触发告警slave 数量低于 bond 的min_links触发严重告警哈希分布比例偏离超过 80/20 触发提示级告警。6.3 变更时最容易出事的两个动作第一个动作是改 mode。mode是 bond 创建时的参数运行时不能通过 sysfs 修改必须 down 掉 bond0、改配置、再 up。这个过程中网络会中断远程操作等于自断连接。正确做法是走带外管理口或者本地控制台操作千万别在 SSH 里改。第二个动作是往一个已经运行的 bond 里加 slave。对于 mode4新加的 slave 需要重新协商期间可能引起短暂抖动。如果业务对抖动敏感建议在维护窗口做并且提前把min_links设为当前 slave 数量防止加入过程中 bond 意外 down 掉。# 安全地往运行中的 bond 加一个 slave echo eno3 /sys/class/net/bond0/bonding/slaves ip link set eno3 down ip link set eno3 master bond0 ip link set eno3 up最后分享一个实际踩过的细节给 bond0 配 IP 的时候如果系统上还残留着之前给物理网卡配的 IP 或者默认路由会出现bond 通了但走错出口的情况。检查方式是ip route get 8.8.8.8看它选哪个源地址出去。清理干净旧配置再上 bond能少走很多弯路。