做Linux服务器运维久了你就明白网卡bonding这玩意儿配置好只是开始真正考验人的是它运行之后怎么去检查、怎么判断它到底健不健康。重庆思庄的日常巡检里我们几乎每次都要处理跟网卡bonding相关的问题客户说业务慢、链路时断时续、交换机端口报错查到最后十有八九是bonding某个从属口掉了或者模式跟对端不匹配。这篇就把我们实际检查网卡bonding运行情况的方法、踩过的坑、以及一些容易忽略的细节完整梳理一遍给正在跟bonding纠缠的运维同学做个参考。很多人以为bonding配好就一劳永逸其实完全不是这么回事。物理链路会静默失效光模块会劣化交换机端口配置会被误改驱动升级后参数可能丢失主备切换不一定每次都触发告警。所以你不仅要会配bonding更要会“看”bonding从内核、驱动、物理链路、配置持久化几个层面去确认它是否真的按预期运行。1. 为什么网卡bonding状态需要“定期检查”1.1 bonding解决什么问题它到底在保护什么网卡bonding也叫网卡绑定、链路聚合核心目的就两个冗余和带宽。冗余对应主备模式active-backupmode 1一块网卡干活另一块在边上待命干活的那块挂了备用口立刻顶上。带宽对应负载均衡模式balance-rr、balance-xor、802.3ad这些把多块物理网卡聚合成一个逻辑口流量分散到多条链路上走。用生活里的比喻一个像备胎平时不用但必须保证能用一个像多车道收费站车多了多开几个窗口。但注意备胎如果长期不检查真爆胎了拿出来才发现也没气了那就尴尬。bonding也一样主备模式下备用口长期没有流量如果它物理链路早就断了、只是没人发现等你主口出问题需要切换的时候一切换就断网冗余形同虚设。1.2 检查bonding到底要看哪几个维度实际检查中我习惯从四个层次看缺一不可。链路层看物理网卡的光纤/网线状态、速率、双工是否正常bonding层看内核态的绑定状态、主备角色、成员网卡是否都在网络层看bond口的IP、网关、路由是否正常能否ping通对端配置层看配置文件、开机自启项、NetworkManager托管状态确保系统重启后bonding还能按原样起来。这四个层次不是孤立的。比如你在巡检时发现/proc/net/bonding/bond0里有个slave的MII Status是down那基本不用再往下查链路层问题已经定死了。反过来如果链路层一切正常、bond口状态也是up但业务那边依旧卡顿那就要考虑是不是负载均衡策略跟交换机聚合策略不匹配甚至bond口本身协商出来的速率就是百兆而不是千兆。检查bonding的周期我建议日常巡检每周至少看一次状态文件变更后交换机配置调整、网卡驱动升级、服务器重启立刻做一次专项检查。别等业务报障才想起来查那时往往已经断网半天了。2. 检查bonding运行状态的几个核心命令2.1 /proc/net/bonding/bond0第一现场Linux内核把bonding的实时状态都暴露在/proc/net/bonding/目录下每个bond口对应一个文件。查看命令很简单cat /proc/net/bonding/bond0这是我最先看的文件没有之一。输出内容里信息密度非常高。看Bonding Mode是哪种模式Active Slave是当前活跃口主备模式下特别关键MII Status表示每个从属口的链路状态up就是正常down就是挂了。Link Failure Count记录了链路断开次数这个数字如果一直在涨说明链路不稳定。还要看Permanent HW addr和Interface确认绑定的物理网卡是不是预期的那些。有时候配置写错了把eth0和eth1写进bond0但实际上服务器的物理口编号跟配置时已经变了特别是加了新网卡之后你会看到绑定的是两张完全不在预期位置的网卡。有一次我们排查客户一台数据库服务器bond1主备模式业务正常但打开/proc/net/bonding/bond1一看Active Slave是eth3而配置里预期的主口应该是eth2。原因是网卡驱动升级后PCIe分配顺序变了物理口和系统接口名的对应关系被重新映射。这个问题不检查状态文件根本发现不了等eth3也挂了想切回eth2才发现eth2对应的物理口插的网线早就被拔了。2.2 ethtool与ip命令确认物理链路/proc/net/bonding/bond0里写了MII Status但我从不只信它一个。会用ethtool对每一块从属物理网卡做确认ethtool eth0 ethtool eth1重点看三个值Speed速率、Duplex双工、Link detected链路检测。正常情况下千兆口应该显示Speed: 1000Mb/sDuplex: FullLink detected: yes。如果有从属口显示Speed: 100Mb/s那说明网线质量、水晶头、对端交换机端口协商出了问题即使bonding状态还是up这条链路也已经拖后腿了。再看bond口本身的速率ethtool bond0注意不同bonding模式下bond0的速率显示逻辑不一样。主备模式mode 1下bond0显示的是当前活跃从属口的速率如果切到百兆口bond0也就变成百兆。802.3admode 4下bond0显示的是所有从属口速率之和双千兆就是2000Mb/s。ip命令也要配合用ip link show bond0 ip addr show bond0 ip -s link show eth0ip -s可以看每个口的收发包统计、错误包、丢包。如果某个从属口RX errors、TX errors数值异常大链路质量多半有问题。2.3 dmesg和journalctl日志里找线索状态文件和ethtool看到的是当前快照日志看到的是历史过程。bonding切换的时候内核会打日志比如dmesg | grep -i bonding journalctl -k | grep -i bonding主备模式下从属口down掉再up回来日志里会有bonding link down/up的记录。如果日志频繁出现类似“bond0: link status down for active interface eth0, disabling it”的条目说明链路在反复抖动这时候光看状态文件是看不出频率的必须翻日志。网卡驱动层面的问题也会在dmesg里体现。有些网卡比如某些型号在高负载下会报tx timeout、firmware error之类的信息这些是物理链路正常但驱动已经异常的信号。我们还遇到过光模块兼容性问题内核日志里报SFP unrecognized换模块之前bonding状态看着完全正常但业务流量一上来就疯狂丢包。2.4 NetworkManager场景下用nmcli补充检查如果你用的是Rocky Linux 8/9、CentOS Stream这类系统网卡默认受NetworkManager管理那除了/proc/net/bonding还要用nmcli确认连接配置是否active、是否设置了开机自启nmcli connection show nmcli device status注意NetworkManager有自己的一套连接配置文件如果bonding是通过/etc/sysconfig/network-scripts/ifcfg-bond0配置的但NM_CONTROLLEDno那nmcli里看不到是正常的。反过来如果NM托管了bonding但你在/etc/sysconfig下面改动配置后忘了nmcli connection reload那系统重启后实际生效的可能还是NetworkManager里存的旧配置。这类“配置漂移”问题我们工单里出现过不止一次。3. 配置文件核查与开机自启验证3.1 Rocky/CentOS/RHEL系列的核心配置文件检查bonding最后一个环节是确认配置能扛过重启。RHEL系的传统配置方式是/etc/sysconfig/network-scripts/下的一组文件bond0对应的ifcfg-bond0两块物理网卡对应ifcfg-eth0和ifcfg-eth1。一个典型的bond0配置# ifcfg-bond0 DEVICEbond0 NAMEbond0 TYPEBond BONDING_MASTERyes ONBOOTyes BOOTPROTOnone IPADDR192.168.1.100 PREFIX24 GATEWAY192.168.1.1 BONDING_OPTSmode1 miimon100物理口配置# ifcfg-eth0 DEVICEeth0 NAMEeth0 TYPEEthernet BOOTPROTOnone ONBOOTyes MASTERbond0 SLAVEyeseth1照葫芦画瓢。这里有个关键点物理口的ONBOOT必须设为yes不然系统启动后物理口不会自动加入bond。这也是“linux网卡开机自启”这个搜索词高频出现的原因——很多人配了bond但漏了从属口的ONBOOT导致重启后bond0只有一张卡在工作另一张不加入。3.2 从ifcfg到NetworkManager的迁移差异Rocky Linux 9开始官方越来越倾向于用NetworkManager替代直接读写ifcfg文件。方式变了坑也变了。用nmcli创建bond的正确姿势是nmcli connection add type bond con-name bond0 ifname bond0 mode active-backup miimon 100 nmcli connection add type ethernet con-name bond0-port1 ifname eth0 master bond0 nmcli connection add type ethernet con-name bond0-port2 ifname eth1 master bond0有一点非常容易踩用nmcli创建的连接默认autoconnect是yes但如果你手工改过ifcfg文件、又执行过nmcli connection reload系统可能把旧的connection配置文件重新加载导致端口从bond里脱离。我在生产环境碰到过一次客户说“重启后bond1居然消失了”进去一看NetworkManager里bond1的连接配置文件丢失只剩两片物理网卡的独立配置。所以检查配置层时建议把这两个命令的输出都保留下来系统里有哪些网络连接nmcli connection show、每个连接是否autoconnectnmcli -f name,autoconnect connection show。确保bond0和它的从属口全部autoconnectyes。3.3 麒麟V10、Ubuntu等不同系统的差异国产化环境里麒麟V10基于CentOS/RHEL系其实沿用了ifcfg和NetworkManager的思路配置文件路径一样在/etc/sysconfig/network-scripts/。但麒麟V10默认可能不再预装network-scripts包而是由NetworkManager统一管理。碰到这种情况别硬找ifcfg-eth0直接用nmcli处理更快。Ubuntu/Debian系用的是netplanbonding配置写在/etc/netplan/*.yaml里network: version: 2 renderer: networkd ethernets: eth0: dhcp4: no eth1: dhcp4: no bonds: bond0: interfaces: [eth0, eth1] addresses: [192.168.1.100/24] gateway4: 192.168.1.1 parameters: mode: active-backup mii-monitor-interval: 100配置完netplan apply检查时用networkctl status bond0看状态。Ubuntu这边检查的逻辑不变看bond口状态、看从属口是否都加入了bond。唯一的坑是netplan在不同版本里字段略有差异比如gateway4在新的24.04里被弃用了换成routes字段你如果拿着旧配置模板往上套apply会报错。关于“麒麟v10一个网卡设置多个ip”的情况这里提一句bond口上配多个IP完全可行在ifcfg-bond0里写多个IPADDR/IPADDR2/PREFIX/PREFIX2或者用nmcli connection modify bond0 ipv4.addresses追加。这不影响bonding状态检查但巡检时要额外确认所有IP都真实生效了别漏看。4. 实战一次bonding故障排查记录4.1 故障现象业务间歇性卡顿讲一个我们自己遇到的真实案例把上面那些检查手段串起来。客户那边一台数据库服务器双口千兆绑了bond1802.3ad模式接在交换机两个口上做链路聚合。报障现象是业务上午偶尔卡顿持续时间不长但每天都有DBA查完数据库没发现异常网络组怀疑是服务器网卡问题转给我们看。到现场第一件事查bond状态cat /proc/net/bonding/bond1结果发现两块从属口都是up但Slave Interface的顺序跟交换机侧预期不一致而且其中一块网卡的Link Failure Count已经累计到一千多次。这说明这条链路隔一阵子就断一次断完又自动恢复。频率不高所以业务侧只是偶发卡顿不是完全断网。4.2 逐步定位从速率到物理链路接着用ethtool看从属口ethtool eth2 ethtool eth3eth2显示Link detected: yesSpeed: 1000Mb/seth3同样千兆。表面看着没问题。但Link Failure Count高到这个程度物理链路一定有问题。我们让现场的同事把eth3对应的光纤跳线两端都重新插拔了一下再清空计数echo 0 /sys/class/net/bond1/bonding/... # 实际对应网卡驱动的统计实际上是重启了网卡或者用ethtool -S看驱动层计数清零。同时让网络组检查交换机侧端口发现eth3对端交换机端口日志里有大量CRC错误判断是该端口对应光模块脏了或者光衰过大。4.3 修复与验证换了光模块、重新做了光纤跳线之后Link Failure Count不再增长业务卡顿消失。这里要强调如果只看/proc/net/bonding/bond1的MII Status两块口都是up你根本发现不了这条链路在反复抖。这就是为什么检查bonding绝不能只看状态文件必须结合日志、错误计数、物理层参数一起判断。验证阶段我们做了一个主动切换测试。先把当前活跃的从属口手动down掉ip link set eth2 down观察bond1是否在miimon100ms周期内切到eth3业务是否中断。确认正常后把eth2重新up回来。但要注意802.3ad模式mode 4下这种测试需要在交换机侧配合观察聚合组是否正常收敛还要注意xmit_hash_policy导致流量分布不均是正常现象不要误判为故障。三星、Intel、Mellanox的网卡驱动层都会有自己的详细统计ethtool -S可以看到比如rx_errors、tx_timeout这些比/proc/net/bonding里的宏观状态更细。检查时养成习惯状态文件看宏观、ethtool -S看微观、日志看过程三者对照才能还原真相。5. 常见网卡问题排查速查5.1 虚拟化场景VirtualBox和VMware的网卡消失问题热搜词里“virtualbox host-only network 网卡消失”“vmware虚拟网卡装不上”这类问题核心原因基本都是虚拟网卡驱动跟宿主系统网络组件冲突或者Windows更新把驱动覆盖了。VirtualBox里Host-Only网卡消失最常见的是安装VirtualBox新版本后旧版Host-Only驱动残留导致服务无法启动。处理方法控制面板里卸载VirtualBox Host-Only Network Adapter重新安装VirtualBox或手动添加Host-Only网络如果还不行检查设备管理器里网络适配器是否有黄色感叹号卸载设备后点扫描硬件改动。VMware虚拟网卡装不上的原因很大概率是Windows自带的Hyper-V或者Credential Guard占用了WFPWindows Filtering Platform的底层导致VMware的虚拟网卡驱动无法正常加载。这个问题的排查手段是确认Hyper-V功能是否开启、内核隔离是否打开内存完整性如果开了要么关掉要么改用Hyper-V自带的虚拟交换机。5.2 克隆系统后网卡找不到、开机不自启“克隆了一个Ubuntu系统网卡找不到了”“linux网卡开机自启”这两个搜索词放在一起说因为成因类似。克隆虚拟机或者物理机迁移后系统里残留了原来那台机器的udev网络规则网卡MAC地址对不上新网卡在系统里变成“未命名”状态表现为ip link里只有lo没有eth0。解决方法删除udev规则文件/etc/udev/rules.d/70-persistent-net.rules或者直接检查/etc/default/grub里net.ifnames0参数重启让系统重新识别网卡。顺手把/etc/netplan里的配置改好再确认systemctl enable systemd-networkd、NetworkManager自启最后test配置后apply。开机不自启多半是配置文件里ONBOOTno或者netplan renderer跟实际使用的网络管理服务不一致。Ubuntu Server默认用systemd-networkd做renderer如果你手动改成NetworkManager但没装好开机就不会自动拉起网卡。5.3 网卡速率异常被限制在百兆打开ethtool看到Speed: 100Mb/s这就是热搜词“网卡被限制在百兆”的典型症状。先确认网线是至少超五类、双绞线接头压线顺序正确再查对端交换机端口是否被强制成了百兆。其次看自协商autoneg状态很多情况下是因为网线里某一对线路断开千兆协商失败自动回退到百兆。还有一种可能性是网卡驱动没有正确加载Intel和其他品牌网卡在系统内识别为普通netdriver如e1000e、igb、ixgbe时如果驱动版本偏旧可能不识别某些新光模块/电口模块的速率ethtool里给出的最大速度就是百兆。这种排查要对着网卡芯片型号去厂商官网找对应驱动比如Realtek 8821ce这种无线网卡Linux下默认驱动rate低的问题尤其常见。5.4 无线网卡与高级参数信道宽度、监听模式、RSS热搜词里“网卡信道宽度”“网卡监听模式”“网卡开启rss”其实分属不同层次。信道宽度是无线网卡的概念比如2.4G频段20MHz/40MHz5G频段80MHz/160MHz。Linux下用iw命令查看和调整iw dev wlan0 info iw list | grep -A 5 Channel widths监听模式promiscuous mode在有线、无线网卡上都存在配置IP层抓包时需要把网卡设为混杂模式ip link set eth0 promisc on不过这跟bonding检查关系不大倒是跟安全审计、流量镜像场景关联密切。需要提醒的是如果bonding从属口被误设为promisc某些驱动下会表现为流量异常、CPU占用升高。RSSReceive Side Scaling是网卡多队列的功能让多个CPU核并行处理收包。检查命令ethtool -l eth0 ethtool -L eth0 combined 4对bonding场景建议从属口和bond口都检查RSS是否开启否则高并发下单个CPU软中断满载bonding多链路聚合的带宽优势会被软件瓶颈抵消。我们在一台跑满万兆的bond4服务器上遇到过物理口都是万兆聚合后逻辑带宽20Gbps但业务压测只有8Gbps查完发现是RSS队列数默认只有1CPU0被打满。调成4队列后直接跑到17Gbps。5.5 Windows Server与AD域DC网卡DNS配置“ad域内3台dc域控制器”“dc的网卡dns应该如何配置”这两个热搜词虽然是Windows Server场景但在混合环境里做网络变更时经常跟着一起来。AD域内多台域控制器每个DC的网卡DNS配置第一项都应该指向自己或另一台DC的IP绝不能指向外部DNS或者路由器地址。因为AD的SRV记录解析依赖DNSDC之间复制也要靠DNS解析。如果DC网卡DNS配置成了外部公共DNS轻则域内客户端找不到域控重则多台DC之间的复制链路直接断裂表现出来就是域内用户登录缓慢、组策略不同步。在检查物理服务器bonding的同时把Windows服务器网卡的DNS配置顺带确认一下能避免很多莫名奇妙的域问题。6. 实操心得与最后几个提醒6.1 检查bonding的几件小事把bonding检查做成一个固定脚本比每次手工敲命令可靠得多。脚本逻辑很简单读取/proc/net/bonding/bond*检查Mode、MII Status、Link Failure Count用ethtool确认从属口速率再用ping一个对端网关IP验证三层连通性有异常就输出告警。放到crontab里每小时跑一次日志重定向到固定文件。检查时机的选择变更窗口后必查重启后必查交换机端口割接后必查。这三个场景是最容易出问题、也最容易在出问题后掩盖问题的时机。配置层面要“重启验证”我见过太多人配完bonding不重启就确认“正常”——其实配置没在重启路径上生效等真正需要重启才发现起不来。6.2 miimon、主备切换和模式选择的一些经验miimon配置的间隔建议在100ms左右别设太短也别太长。太短比如10ms在网线抖动时特别容易误判链路down触发频繁切换太长1000ms导致故障感知慢业务中断时间长。配合fail_over_mac1主备模式下建议开启切换时MAC地址不会变避免对端交换机ARP表混乱。关于模式选择求稳选active-backup求性能选802.3ad。balance-rr轮询虽然两条链路都能跑但数据包乱序风险高很多业务协议对乱序敏感不建议生产环境使用。xmit_hash_policy在802.3ad下建议用layer34流量分布比默认的layer2更均衡但需要确认对端交换机支持同样的hash策略。6.3 踩坑清单这些坑我真踩过最后分享几个真实踩坑记录。第一个曾经在一台服务器上配置了bond0和bond1两个绑组分别接不同网段结果ifcfg文件里两个bond都用了一个物理网卡做slave配置不报错但一重启网络就乱套。检查配置时一定要确认每张物理网卡只属于一个bond。第二个bond口配了VLAN子接口很多教程会告诉你VLAN直接建在bond0上。但在某些系统版本里VLAN子接口需要设置VLAN_ID和物理设备名正确匹配不然标签打不上二层直接不通。碰到这种情况用ip link show看VLAN子接口是否真的up再用tcpdump抓包确认带了VLAN tag。第三个日志里看到bonding切换但是业务依旧丢包原因往往不在服务器而在交换机侧STP收敛。物理链路恢复后交换机端口要经历Learning状态这段时间内交换机不转发数据帧。如果交换机配置了PortFast/Edge Port这种特性恢复速度会快很多。这个点很多人忽略排查时钻到网卡驱动里出不来其实问题在邻居设备上。第四个主备模式下默认的active-backup切换需要miimon检测周期检测周期内流量中断。如果业务要求高的高可用可以配合链路追踪或者直接上teamd的lacp等更复杂的方案但复杂度也会上来。一个小技巧是调低miimon到50ms让切换更快同时把fail_over_mac设成1减少MAC切换时间。这些经验都是拿实际生产环境的告警和割接熬出来的。检查网卡bonding这件事看起来就是cat一个文件的事但真正深入进去链路层、驱动层、交换层、协议层全都牵连着。把基础的状态检查做扎实再结合日志和物理层排查绝大多数bonding问题都能提前发现不至于等到业务中断才去救火。