Linux 网络高级配置实战：Bonding、RAID 卡、故障诊断与虚拟交换机

一台服务器插着两根网线、背后挂着一组 RAID，看起来很稳。但是"断一根没事"这句话，只有在你真的拔过一根并计时之后才成立。

因为冗余的关键从来不在"有没有备用路径"，而在主路径失效到备用路径接管之间的那段时间。而那段时间不是硬件给的，是软件参数给的。

#一、同一个抽象：冗余把故障检测挪进了软件

把 Bonding、RAID、网桥放在一起看，会发现它们在做同一件事：

共同点是：冗余把"故障"从一次硬件事件，变成了一段软件可以观测（或观测不到）的过程。 硬件失效是瞬间的；软件发现它却需要时间，而这段时间里系统可能仍认为一切正常——这就是"半边通"的来源。

#二、Bonding 模式在回答两个不同的问题

Bonding 有 7 种模式，但可以先按它们回答的问题分成两类：

第二行有两个必须接受的现实：

1. LACP 需要交换机侧预先配置。 一边配了、一边没配，会出现很难查的连通性异常——因为两端对"这是个聚合组"的理解不一致。
2. 带宽叠加不等于单连接变快。 哈希算法按流分配，单个 TCP 连接只会走一条成员链路。想靠 Bonding 让一个 SCP 变快，基本不会成功。

所以第一类（可用性）和第二类（带宽）是不同目标。把"我要冗余"和"我要更快"写在同一个需求里，通常会导致配出一个两边都不理想的东西。

#三、真正在调的是"断多久"

这是全篇最实用的一节。miimon、updelay、downdelay 这三个参数决定的不是"会不会切换"，而是切换的速度与稳定性：

miimon=100     每 100ms 检查一次链路（默认量级）
updelay=...    成员恢复后，等多久才启用它
downdelay=...  链路异常后，等多久才判它坏了

它们的关系里有一个必须理解的取舍：

• miimon 太小 → 链路抖动（比如交换机做 STP 收敛、光模块瞬断）会被判成故障，切换过于频繁，反而制造中断。
• miimon 太大 → 真故障时切换慢，中断时间变长。
• updelay 太短 → 成员刚"看起来好了"就被启用，可能马上又坏，形成来回抖动（flapping）。

所以判断标准不是"哪个值更安全"，而是：这台机器能容忍多长的中断，和它的链路有多爱抖。 对波动大的链路，宁可切换慢一点也别来回跳——这正是"工程选择"与"价值选择"混在一起的典型：miimon 是个参数，但选它是选择"更怕中断还是更怕抖动"。

# 看当前 bond 状态（哪块是 active、切换统计）
cat /proc/net/bonding/bond0

# 关键几行：
#   Currently Active Slave: eth0
#   MII Status: up
#   Link Failure Count: 2        ← 切换过几次，静默发生的故障在这里

Link Failure Count 是这块最容易被忽略的一行。它是一个"沉默的故障账本"——如果你的告警从来没有触发过，但这个计数却在涨，说明有过短暂中断且没人知道。巡检时值得把它纳入采集。

#四、交换机侧的配合，以及"半边通"

Bonding 出问题最麻烦的形态是"半边通"：两张网卡都 up，但流量只走其中一张，或者某些目标通、某些不通。

典型原因有三个：

1. LACP 静默模式不一致：一边期望协商、一边没配，最终可能只有一个成员在转发。
2. 哈希不一致：两端对流的哈希结果不同，导致回程走了另一条链路（在有状态设备如防火墙中间时直接不通）。
3. ARP/邻居表问题：切换后对端交换机仍缓存着旧端口的 MAC 表项（MAC 表项老化需要时间），表现为"切了但几分钟内不通"。

第三条常被忽略：网络设备的转发表是有记忆的。 二层的收敛时间不只看服务器侧，也要看交换机侧的老化时间。这也是为什么"同一网段切换很快、跨网段切换很慢"有时是真的——中间的设备越多，需要重新学习的表就越多。

#五、RAID 与缓存：另一个冗余，同一个道理

RAID 卡和 Bonding 的相似性比看起来高：

第四行是 RAID 独有的要害：开启写缓存能大幅提升写性能，但如果没有电池/超级电容保护（BBU/超级电容），掉电时缓存中的数据会丢。 这不是"风险有多大"的问题，是"你在性能和一致性之间选了哪一边"的问题——而且很多 RAID 卡的默认策略并不保守，需要显式检查。

与 Bonding 呼应的一句：RAID 卡也会"沉默地降级"。阵列从 RAID 10 掉一块盘之后通常还能跑，性能与冗余度却都下降了。状态要主动巡检，不要等它坏了再发现（因为那时已经晚了）。

#六、诊断顺序：从计数器开始

网络诊断最常见的错误是从"猜"开始（换网线、换交换机端口），而不是从可观测证据开始。我的顺序是：

# 1) 物理层与协商（看起来 up 不等于协商正常）
ethtool eth0 | grep -E "Speed|Duplex|Link detected"

# 2) 错误计数器 —— 最直接的证据
ethtool -S eth0 | grep -Ei "err|drop|discard|crc|fifo"

# 3) 网卡与驱动
ethtool -i eth0        # 驱动与固件版本
dmesg | grep -i eth0   # 有没有 link down / reset 记录

# 4) 上层：路由、连接、抓包
ip -s link show eth0   # 内核视角的收发统计与错误
ss -s                  # 连接状态汇总

第二行的计数器是这块最值钱的东西。crc_errors 涨说明物理层有问题（线、模块、端口）；rx_missed / rx_dropped 涨更像是主机侧处理不过来（ring buffer、中断、CPU）；tx_dropped 可能指向队列或虚拟化层。计数器把"网络慢"分成了几个完全不同的方向，而猜是分不出来的。

dmesg 里那些 link down / link up 的记录，配合 Bonding 的 Link Failure Count，往往能还原出"什么时候抖过"——这个时间线对判断是偶发还是趋势非常关键。

#七、虚拟交换机：两套不同的思维

Linux Bridge 和 Open vSwitch 都是"交换机"，但思维不同：

最后要说一个容易踩的坑：虚拟交换机的性能和"卸载"能力与物理设备不同。 某些 offload 特性（如大包分段、校验和卸载）在经过虚拟交换机后行为会变化，抓包看到的和实际发出的可能不一致（经典的"抓到的包看着不对但通信正常"）。抓包不一致时先怀疑卸载，而不是先怀疑网卡坏了。

#八、这篇没写什么

• 没写完整的 nmcli / ifcfg 配置模板。 发行版之间差异太大（RHEL 系、Debian 系、NetworkManager 与传统网络脚本），抄一份模板的误导性大于帮助。
• 没写 RAID 卡厂商工具的具体命令。 storcli / perccli / MegaCli 版本语法差异明显，且用它改配置是有风险的操作，请以对应工具文档为准。
• 没写性能调优清单。 中断绑定、RPS/RFS、ring buffer 大小这些都很有效，但全部依赖具体负载与硬件，脱离场景给数值等于让读者替我试错。
• 没写 Kubernetes 网络。 那已经是另一层（CNI 有自己的抽象），虽然底层仍在用这里的概念。

如果只带走一句：冗余的价值不取决于"有备用"，而取决于"多快发现主用坏了"。 那个"多快"是可配的，也是该被计时验证的——顺手拔一根网线，测一次。