企业官网建设流程全解析

信创项目里最容易被低估的一个活儿就是网络配置。前阵子给一批银河麒麟V10 SP3服务器做上线前的网络加固，业务方提的要求很直接：数据库和NFS存储都在这台机器上，网卡一旦断了，整个产线都跟着停。那就做双网卡绑定吧，也就是Linux运维里常说的bond。听起来是基础操作，但真正在国产系统上落地的时候，你还是能踩出不少以前玩CentOS/RedHat时没遇到过的坑。这篇文章就把我在银河麒麟SP3服务器上做双网卡绑定的完整过程拆开讲，从场景判断、模式选择、配置写法、踩坑排错到验证演练都过一遍，给同样在搞国产化替代、信创迁移的朋友做个参考。

1. 先想清楚：双网卡绑定到底解决什么问题

1.1 两种核心诉求：链路冗余与带宽叠加

做双网卡绑定之前，先问自己一个问题：你到底是为了什么才绑？我见过不少人拿到服务器就顺手把两张网卡绑了，结果业务场景根本不需要，反而给自己增加了一堆维护负担。双网卡绑定的核心诉求其实只有两类。

第一类是链路冗余，也就是高可用。一张网卡挂了，另一张立刻顶上，网络不中断。数据库服务器、NFS存储服务器、核心应用节点这类机器，业务方对网络连续性要求很高，网卡故障或者网线被误拔都不能导致服务不可用。这类诉求在bond里对应的是主备模式，比如mode=1（active-backup），平时只有一张网卡在工作，另一张处于热备状态，链路一断就切换过去。

第二类是带宽叠加，或者更准确地说是负载均衡。单张千兆网卡跑不满业务流量，希望通过多张网卡聚合提高吞吐量。这类诉求对应的是mode=0（round-robin）、mode=4（802.3ad LACP）这类模式。但这里有个很多新手容易忽略的前提：带宽叠加不是服务器自己想叠就能叠的，交换机端口必须配合，否则配置完带宽上不去，还可能丢包。

用生活化的类比来说，双网卡绑定就像你上班通勤的两条路线。冗余模式下，你每天都走同一路线，这条路堵死了就换备用的那条，保证你能到公司。负载均衡模式下，你同时把包平均分到两条路线上，路虽然多了，但前提是两条路都能走得通，而且不允许其中一条路突然施工堵死。很多人在部署时没搞清楚自己该选哪种，直接套用网上找的mode=0配置，结果就是交换机不支持、包乱序、业务偶发卡顿，排查了半天才发现问题出在模式选错了。

1.2 bond模式横向对比：别一上来就mode=4

Linux bonding的内核模块一共支持7种模式，从mode=0到mode=6。实际生产环境里最常见的就是mode=1和mode=4，其余模式各有各的适用场景，但坑也更多。我习惯用一张表把这些模式全部列出来，给新接手的人讲起来特别直观。

这里我重点强调一下mode=1和mode=4的选择逻辑。如果你的交换机端口配置不是你能掌控的，或者说网络管理员告诉你"端口我们已经设好了静态聚合"之前，你最好默认选mode=1。原因很简单：mode=1不依赖任何交换机特性，不需要LACP协商，配完就能用，物理层的事情都交给了服务器自己判断。mode=4虽然带宽优势明显，但交换机端必须设置对应的链路聚合组（LAG）或者端口通道（port-channel），而且两边的协商模式必须一致。我自己就经历过一次mode=4配完，服务器端一直报链路up但数据不通，查到最后发现交换机端口被误配成了静态聚合而不是LACP动态协商，两边模式对不上，链路就一直起不来。如果你的网络环境是机房标配、交换机归网络组管的，那一定要提前把交换机的聚合配置做在前面，别等服务器都调完了才发现两边对不上。

另外有个冷知识：很多人以为mode=5和mode=6是无交换机配合时的"最佳方案"，因为不需要交换机端配置，还能一定程度提升发送和接收性能。真实情况是这两个模式在国产网卡驱动上的兼容性并不稳定，我遇到过在部分国产平台上网卡驱动对balance-alb的ARP协商支持不到位，导致主备切换时对端ARP表混乱，网络要过几十秒才能恢复。所以在银河麒麟SP3这种国产化环境里，我倾向于稳字当头，能选mode=1就不用花里胡哨的其他模式。

1.3 不需要绑定的场景

说完了做什么，再说说什么情况下根本不需要做。这个观点可能跟一些人的直觉相反，但确实是实战经验：不是每一台服务器都需要双网卡绑定。判断标准很简单，看这台机器如果断网10分钟，业务能不能扛得住。

如果是一个普通的日志采集节点、一个只跑非核心业务的开发测试环境，断了网顶多业务方骂两句，重启一下就能恢复，那绑不绑都无所谓，反而配置绑定会增加排障复杂度。另外如果高可用是靠上一层架构实现的，比如有多台节点组了集群，单台机器宕机后流量会自动切换到其他节点，那单台机器的网卡冗余就不是必须的，你把钱花在集群层的健康检查上反而更值。

还有一种情况是物理硬件根本不给力——一台只有单网卡的机器，想绑也绑不出来。很多低端服务器只有一个板载千兆口，插上扩展卡也只有一个多余插槽，这种配置上bond的意义就不大，反而因为bond本身的开销和复杂度降低了整体稳定性。

所以做双网卡绑定之前先做个简单的判断：这台机器是不是承载了不可替代的、需要持续在线的核心业务？如果是，绑；如果不是，可以缓缓。这个判断做完，后边所有配置动作才有意义。

2. 动手前的环境确认与交换机协调

2.1 确认银河麒麟SP3版本与网卡硬件

拿到机器之后，别急着敲配置命令，先把系统环境和硬件情况摸清楚。银河麒麟V10 SP3这个版本在不同架构下的行为略有差异，虽然bond的原理是通用的，但网卡驱动、内核模块的表现会因为平台不同而不同。我习惯先跑三条命令确认环境。

cat /etc/os-release uname -a lspci | grep -i ethernet

第一条看系统版本，确保确实是V10 SP3，第二条看内核版本，SP3服务器版的内核一般是4.19系列，新一些的SP3可能升级到5.10甚至更高，这些信息决定了加载bonding模块的方式是否有差异，第三条直接看物理网卡的型号和总线位置。如果是基于飞腾、鲲鹏、海光、龙芯这些国产处理器的平台，网卡命名可能会直接继承固件里的PCIe槽位编号，比如enP4p1s0f0、ens3f1这种，不像传统的eth0、eth1那么直观。

环境确认阶段还有一个容易忽略的点，就是用ethtool看一下网卡的协商速率。如果两张网卡一张协商成千兆、另一张协商成百兆，做mode=1的主备没问题，但做负载均衡类模式就会出怪象：快的网卡跑满了，慢的网卡成了瓶颈，整体吞吐比单张千兆还低。

ethtool enp4s0f0 ethtool enp4s0f1

输出里的Speed字段一眼就能看出来。如果两张网卡的速率不一致，建议先把自动协商搞定，或者干脆在交换机端把端口速率先强制成统一值，然后再考虑bond。这个检查说起来简单，但很多人配置bond失败，回头排查才发现是物理链路本身就没协商好。

2.2 备份原始网络配置

备份这一步是保命的。银河麒麟V10 SP3的网络配置路径跟红帽系基本一致，主要是/etc/sysconfig/network-scripts/目录，还有NetworkManager的连接文件存放在/etc/NetworkManager/system-connections/。配置之前先把这两个地方备份好。

cp -a /etc/sysconfig/network-scripts /root/backup/network-scripts.bak.$(date +%Y%m%d) cp -a /etc/NetworkManager/system-connections /root/backup/NM-connections.bak.$(date +%Y%m%d)

别小看这两条命令，真出事的时候能让你半小时内恢复到原始状态。我在一次现场操作中遇到过一个问题：配置完bond之后，远程登录的会话直接断了，原因是操作过程中把当前SSH会话所依赖的网卡配置给覆盖掉了，导致远程连接断开。如果当时没有备份，机房又不在本地，那就只能联系驻场同事去控制台操作了，过程非常痛苦。所以我要特别强调：不管你对配置多熟悉，备份一定要做，而且要在本地保存一份副本。

2.3 交换机侧需要提前确认的事

服务器端的配置能自己控制，但交换机端的配合情况往往事前不知道。银河麒麟SP3部署双网卡绑定，如果选的是mode=1，那交换机端口不需要任何特殊配置，直接把两根网线分别插到交换机任意两个口上就行，这是最简单的场景。但如果你选的是mode=4，那就必须跟网络管理员提前对齐，否则后患无穷。

mode=4用的是802.3ad LACP协议，交换机端口必须加入链路聚合组，并且聚合模式要设置成active（主动协商）或者passive（被动协商），两边只要有一方是active就能协商成功，但大多数网络管理员会直接配置成active。如果交换机端口没配置聚合，服务器端强行起了LACP，结果就是链路在物理层是up的，但协议层一直协商不上来，表现出来就是ping不同、业务不通，而且不是彻底不通，是时通时断，极具迷惑性。

另外不同厂商的交换机叫法不一样，华三叫链路聚合、思科叫Port Channel或EtherChannel、华为叫Eth-Trunk，但底层都是LACP。你跟网络管理员沟通的时候，直接说"帮我把这两个口做成动态LACP聚合"，对方一般都能听懂。

这里分享一个沟通技巧：让网络管理员先把交换机端配好，你再配服务器端。否则你服务器端先配好了，交换机端还没动，这段时间内如果你通过这台服务器远程操作其他机器，那流量会在bond口上产生大量丢包，很容易把自己锁在门外。正确的顺序是：先协调交换机，确认端口配置完成，再动服务器。

3. 核心配置实操：nmcli命令行与ifcfg文件两种写法

3.1 推荐做法：通过nmcli创建bond

银河麒麟V10 SP3默认启用了NetworkManager，所以最稳妥的配置方式就是通过nmcli操作，让NetworkManager自动生成连接配置文件。这种方式的好处是NetworkManager会把bond连接和两个slave连接作为统一的连接对象来管理，重启之后能自动恢复，不太容易出现手工写配置文件导致的遗漏。

先看一下当前系统里已经存在的连接，避免后面创建的连接名冲突。

nmcli con show

确认之后，按下面的顺序执行配置。以bond0作为绑定接口名，主网卡为eth0、备用网卡为eth1为例：

# 创建bond0连接，模式为active-backup，MII轮询间隔100毫秒 nmcli con add type bond ifname bond0 mode active-backup miimon 100 primary eth0 # 给bond0配置IP、网关和DNS nmcli con modify bond-bond0 ipv4.method manual ipv4.addresses 192.168.10.10/24 ipv4.gateway 192.168.10.1 ipv4.dns 223.5.5.5 # 添加两块物理网卡作为bond的成员 nmcli con add type ethernet ifname eth0 master bond0 nmcli con add type ethernet ifname eth1 master bond0 # 启动bond和两个成员连接 nmcli con up bond-bond0 nmcli con up bond-slave-eth0 nmcli con up bond-slave-eth1

需要注意几点。第一，默认生成的连接名是bond-bond0、bond-slave-eth0、bond-slave-eth1这种格式，你也可以用con-name参数重命名，比如nmcli con add type bond ifname bond0 con-name mybond mode active-backup，但是重命名之后up连接时要用新的连接名。第二，IP地址只需要配在bond0上，两个slave成员上不要配任何IP，否则会造成同一网段多条路由的冲突，轻则路由表混乱，重则ARP冲突导致网络中断。第三，mode active-backup模式下primary参数指定了主用网卡，当主用网卡恢复之后，bond会自动把流量切回主用网卡，这个特性在故障恢复场景中很有用，建议配置。

配置完成后可以立刻验证一下：

cat /proc/net/bonding/bond0

这个文件会显示bond0的当前状态，包括当前的活动slave是哪个、MII状态、链路失败次数等，这是后续所有验证操作的起点。

3.2 经典做法：直接改写ifcfg配置文件

如果你所在团队的网络管理习惯是直接维护/etc/sysconfig/network-scripts/下的配置文件，或者项目验收时需要提交配置文件归档，那手工写ifcfg文件的方式更适合你。银河麒麟V10 SP3虽然默认用NetworkManager，但NetworkManager默认配置是可以读取ifcfg文件的（通过ifcfg-rh插件），所以这种做法在SP3上完全可行。

同样以bond0、eth0、eth1为例，需要创建三个配置文件。

第一个是bond0的配置文件/etc/sysconfig/network-scripts/ifcfg-bond0：

DEVICE=bond0 NAME=bond0 TYPE=bond BONDING_MASTER=yes ONBOOT=yes BOOTPROTO=none IPADDR=192.168.10.10 NETMASK=255.255.255.0 GATEWAY=192.168.10.1 DNS1=223.5.5.5 BONDING_OPTS="mode=1 miimon=100 primary=eth0 fail_over_mac=1"

第二个是主网卡eth0的配置文件/etc/sysconfig/network-scripts/ifcfg-eth0：

DEVICE=eth0 NAME=eth0 TYPE=Ethernet ONBOOT=yes BOOTPROTO=none MASTER=bond0 SLAVE=yes

第三个是备用网卡eth1的配置文件，内容跟eth0几乎一样，只把设备名改掉即可。

这里有个非常重要的细节：两个slave网卡的配置里一定不要出现IPADDR、NETMASK、GATEWAY这些参数，IP只放在bond0上。如果某个slave网卡残留了旧IP配置，重启后NetworkManager可能会给这张网卡额外配置一个地址，同时这个地址所在的网段如果跟bond0冲突，系统就会出现两条默认路由，后果就是网络时通时断，这个坑我踩过不止一次。

关于BONDING_OPTS参数，展开解释一下。mode=1是主备模式，miimon=100表示每隔100毫秒轮询一次链路状态，这个值越小切换越快，但也越消耗CPU，100毫秒是推荐值。primary=eth0指定eth0为主用网卡。fail_over_mac=1是个容易被忽略但很关键的参数：它告诉bond在切换后不用固定某一个slave的MAC地址，而是用切换后活跃的那张网卡的MAC地址。如果不加这个参数，bond默认保持第一个加载的slave的MAC地址，这会导致对端交换机和ARP表在某些特殊拓扑下学习不到正确的MAC，造成切换后网络暂时不通。具体机制在踩坑章节里再详细说。

3.3 加载bonding内核模块，确保重启不丢

无论用哪种方式配置，都要确保bonding内核模块被正确加载。NetworkManager在创建bond连接时通常会自动加载bonding模块，但如果你用的是纯配置文件方式，或者遇到某些精简定制的国产系统镜像，模块可能没有自动加载。保险起见，建议把bonding模块写入系统启动加载列表。

echo "bonding" > /etc/modules-load.d/bonding.conf modprobe bonding

加载之后立刻验证：

lsmod | grep bonding

如果输出里有bonding相关信息，说明模块加载成功。注意，如果modprobe执行时报错，可以看看内核版本和模块路径是否匹配，内核模块一般在/lib/modules/$(uname -r)/kernel/drivers/net/bonding/下，部分国产系统的内核编译选项可能没有把bonding编成模块，而是直接编进了内核，这种情况下lsmod可能看不到，但只要/proc/net/bonding/目录存在，就说明bond功能可用。

这个细节很多人不注意，但恰恰是"配置完看似成功、一重启就全部失效"的最常见原因之一。

3.4 两种写法的适用场景对比

很多刚上手的人会纠结到底用nmcli还是手写ifcfg文件，我的建议是分场景决策。为了直观，我把两种方式做了一张对比表。

我最推荐的做法是：单机调试阶段用nmcli快速交付，等确认所有参数都没问题了，再把关键配置导出来归档到版本管理里；如果是批量交付几十台机器，那直接用ifcfg文件模板加Ansible或脚本分发，效率更高。但无论选哪种，都要记住一个原则：不要一个系统里同时对同一张网卡既用nmcli管理又手工改ifcfg文件，两个管理器对同一接口反复接管，最容易导致重启后配置丢失或冲突。

4. 踩坑实录：从"配置成功"到"重启就挂"的完整排查链路

4.1 坑一：bonding模块没加载，bond0默默隐身

这是我在实际项目里遇到频率最高的问题。现象非常典型：配置完bond后一切正常，IP能ping通，cat /proc/net/bonding/bond0也能看到内容。但是执行reboot之后，服务器起来了，bond0这个接口就消失了，网络完全不通。SSH连不上去，控制台看了ip link，只看到物理网卡，没有bond0。

为什么配置时会好？因为配置过程中手动执行过modprobe bonding，模块当时加载了，bond0自然就能工作。但重启之后，没有把bonding模块写入到系统启动加载的模块列表里，systemd不会自动加载这个模块，所以bond0就起不来了。NetworkManager在启动时会尝试创建bond连接，但底层模块缺失，连接创建失败，就表现为bond0消失。

排查和解决都不复杂，但如果没有经验，这个坑能让人在机房耗一整天。解决办法就是前面说的，把bonding写入/etc/modules-load.d/bonding.conf，然后执行modprobe bonding，再重启验证一次。如果你已经出问题了，临时救急的办法是启动后到控制台手动执行modprobe bonding，然后systemctl restart NetworkManager，网络就能恢复，但根本解法还是要把模块加入开机加载。

4.2 坑二：NetworkManager和network双管理冲突

银河麒麟V10 SP3环境里，默认同时存在NetworkManager服务和一个叫network的服务。NetworkManager是系统默认的网络管理服务，而network服务是从SysV时代继承下来的老脚本，作用是通过network-scripts目录下的配置文件来管理网络。这两个服务同时存在时，如果同一张网卡被两边都尝试接管，就会产生冲突。

表现出的现象是：bond配置在文件里看起来完全没问题，重启后ip addr能看到bond0和IP，但就是ping不通网关。用nmcli device status查看，发现bond0的状态是connected，但两个slave网卡的状态变成了unmanaged或者disconnected，说明NetworkManager认为这些接口不在它的管辖区，而network服务又没能把它们正常带起来。

排查的完整思路是这样：先看服务状态，确认到底是哪个服务在报错。

systemctl status NetworkManager systemctl status network

如果看到network服务failed，或者NetworkManager日志里有"interface eth0 is not managed"之类的信息，那基本就是双管理冲突。解决办法是二选一：要么彻底停用network服务，让NetworkManager全部接管；要么关闭NetworkManager对这几张网卡的管理，用传统方式接管。我个人的习惯是保留NetworkManager，因为现代配置和排障工具都对NM更友好。

systemctl disable network systemctl stop network systemctl status NetworkManager

停掉network服务之后再到关键步骤里重新激活bond连接：

nmcli con up bond-bond0 nmcli con up bond-slave-eth0 nmcli con up bond-slave-eth1

这里要特别说明，停用network服务前记得先确认NetworkManager是正常的，否则你把网络服务停了，NM又接管不了，服务器就彻底失联了。稳妥的做法是先在SSH会话里测试重新加载NM连接，确认网络能通，再停用network。

4.3 坑三：slave网卡上的残留MAC和旧配置干扰

这个坑在迁移老机器的场景里特别常见。比如一台机器之前是单网卡直接用eth0的，网卡上可能手动配置过MAC地址，或者做过IP克隆，重启后bond起来了，但通信还是有问题。现象是对端设备能ping通，但过一会儿就掉线，然后又恢复，ARP表忽对忽错，抓包能看到从同一个IP发出来多个不同的MAC地址。

原因是bond的MAC地址继承机制。默认情况下，bond0会使用第一个被加入的slave的MAC地址，并且在运行期间保持不变。如果还有第二个slave，在切换过程中，对端交换机从新活跃的slave端口收到了源MAC为bond0 MAC的帧，但这个MAC地址之前是从另一个端口学习到的，交换机的MAC地址表就会反复震荡。最坏的情况下，对端设备上绑定了基于IP-MAC的访问控制策略，新网卡的MAC不在允许列表里，切换后直接断网。

解决方式有两层。第一层是在BONDING_OPTS里增加fail_over_mac=1，让bond在切换时同步更换MAC为当前活跃网卡的MAC，这样对端交换机始终学习到的是真实活跃端口的MAC，ARP震荡的问题就解决了。第二层是彻底清理掉slave网卡上的HWADDR残留配置，打开ifcfg-eth0和ifcfg-eth1检查有没有HWADDR或MACADDR字段，如果有且值已经不对应物理网卡的真实MAC，直接删掉或改对。

在配置bond之前，建议先用ethtool或者ip link把每张物理网卡的硬件MAC记录下来，方便后面对照验证：

ip link show eth0 ip link show eth1

4.4 重启后起不来的标准排查顺序

把所有坑汇总成一套排查SOP，你以后遇到任何bond起不来的问题，按顺序做一遍基本都能找到原因。这个SOP是我在几次半夜被叫起来的经历里总结出来的，分享出来省得你们走弯路。

# 第一步：看服务状态 systemctl status NetworkManager systemctl status network # 第二步：看bond设备是否存在 ip link show bond0 # 第三步：看bond内部状态 cat /proc/net/bonding/bond0 # 第四步：查内核日志里有没有bond相关报错 dmesg | grep -i bond # 第五步：查NetworkManager日志 journalctl -u NetworkManager --since today # 第六步：看网卡被谁接管 nmcli device status

遇到问题按这个顺序走，一般十分钟内能定位。第一步先确认是哪个网络服务在干活、有没有挂掉，第二步确认bond0这个设备本身是否存在，第三步能看到bond内部成员链路状态和活动状态，第四步和第五步能查到模块加载和连接创建的具体报错，最后一步确认网卡是不是被NetworkManager正常纳管。

特别提醒一个我见过很多次的场景：排障的时候发现nmcli device status里物理网卡显示unmanaged，但NetworkManager服务又是正常的，这时候多半是因为ifcfg文件中设置了NM_CONTROLLED=no，或者系统级的NetworkManager.conf里把接口排除在了管理范围之外。打开/etc/NetworkManager/NetworkManager.conf看一眼，如果有interface-name=eth0这类配置，直接删掉并重启NetworkManager。

5. 验证与日常运维：从重启到故障演练的一整套动作

5.1 重启验证与开机自启确认

配置全部做完之后，最关键的一步就是重启验证。很多人配置完当时ping通了就觉得大功告成，结果第二天到项目现场发现服务器重启过一次后网络不通了，这种事故在项目交付里太常见了。

重启之前，先确认所有相关服务都已经设置了开机自启：

systemctl is-enabled NetworkManager systemctl is-enabled network

理想状态下，NetworkManager是enabled，network是disabled或者masked，不要让两个服务同时enabled。然后执行reboot，等服务器完全起来之后，重新登录，依次检查：

cat /proc/net/bonding/bond0 ip addr show bond0

第一行看当前活跃slave是哪个，第二行确认IP地址真的配在了bond0上。只要这两个输出正常，说明bond已经成功接管了网络。

在这里特别提醒，重启验证一定要在变更窗口内做，不要配置完就急着走。有一次我在远程给客户配bond，配置完一切正常，客户说不用重启了，结果第三天客户重启了服务器，然后就打电话说网络不通。我远程一看，就是没把bonding模块写入modules-load.d。如果在变更时多花十分钟做了一次完整重启验证，后面就不用花几个小时来回沟通了。

5.2 故障演练：拔线测试真实切换时间

双网卡绑定的核心价值在故障切换，所以一定要主动模拟故障验证，不能光看配置。最常见的演练方式就是直接拔掉主用网卡的网线，观察业务是否中断、切换耗时多久、备用网卡是否正常接管。

演练的步骤是这样：

1. 先记录当前bond状态，cat /proc/net/bonding/bond0，看Currently Active Slave显示的是哪个网卡。
2. 从另一台机器持续ping这台服务器的IP，保持ping不断。
3. 物理拔掉主用网卡的网线。
4. 观察ping的丢包情况，以及bond状态里Currently Active Slave是否切换到了备用网卡。
5. 把主用网卡的网线插回去，再观察状态是否自动切回主用网卡。
6. 查看/proproc/net/bonding/bond0里的MII Status和Link Failure Count，确认链路状态恢复正常。

这里要解释一个细节：为什么推荐物理拔线而不是ip link set eth0 down？因为物理拔线模拟的是真实链路故障，能测试到PHY层、驱动层、对端交换机端口状态变化这一整套链路反应。而通过命令down接口虽然也会触发bond切换，但它更多是软件层主动断开，跟真实事故的链路状态感知路径不完全一样。如果只在软层测过，真正发生了网线松动这类物理故障，可能不会触发切换，那就白配置了。

切换时间方面，正常在mode=1 + miimon=100配置下，主备切换应该在1秒级别。如果你发现ping中断了几十秒甚至更久，大概率不是bond切换本身慢了，而是交换机的STP（生成树协议）在做收敛。交换机检测到端口down之后要等STP重新计算，默认可能要30到50秒，这个时间对业务来说是无法接受的。解决办法是让网络管理员把这两个端口配置成边缘端口（edge port）或者开启portfast，跳过STP监听和学习状态，端口一up就能直接转发流量。这个坑很多人会忽略，服务器端调来调去都正常，结果就是切换时间很长，最后发现是交换机端口配置问题。

5.3 吞吐量验证：iperf3实测

做完故障切换验证，还需要验证带宽是否符合预期。对mode=1来说，带宽预期就是单张网卡的速率，因为同一时刻只有一张网卡在工作，你不能指望主备模式叠加带宽。如果你选的是mode=4，那理论上带宽是聚合端口的总和，但具体能跑到多少还取决于流量的哈希分布和会话数。

验证工具我用iPerf3，简单直接。银河麒麟SP3的默认源里不一定有iperf3，没有的话先装一下：

dnf install -y iperf3

服务端在这台绑定了bond的机器上启动：

iperf3 -s

客户端在另一台测试机上运行：

iperf3 -c 192.168.10.10 -t 60 -P 4 -i 10

-P 4表示开4个并发连接，这样在多核环境下能更充分地压满带宽。跑完之后看SUM行里的Transfer和Bitrate，如果速率接近单网卡线速，说明bond工作正常。如果你配的是mode=4，但测出来的速率跟单网卡一样，那大概率是交换机端口没协商好，或者对端只有一块网卡不足以形成多条流，需要多测几个并发连接或者在多台机器上同时打流量。

测试的时候有个小经验：不要只在bond服务器和另一台机器之间对测，最好通过绑定bond的服务器访问多个不同目标，模拟业务流量模式。因为单对单连接在哈希算法下可能始终走同一个slave，负载均衡效果就看不出来，而业务混流之后哈希分布才会体现真正的聚合效果。

5.4 日常巡检命令清单

部署完成只是开始，后续的日常巡检才是保证bond长期稳定运行的关键。我在实际运维中总结了一套巡检命令清单，每次维护窗口或者定期巡检时跑一遍，能提前发现很多潜在问题。

巡检中发现的最典型异常是Link Failure Count持续增长，说明网络链路时有中断。这种问题在物理机房里经常是网线老化、网口松动或者交换机端口故障导致。如果bond切换机制正常，业务上不会有感知，但这个信号意味着底层链路已经不稳定了，需要联系机房排查物理链路，不要等到真正链路完全断开才处理。

除了上面这种被动巡检，我还会加一个主动的内容：每台做了bond的机器，如果业务允许，定期手动做一次主备切换演练。方法很简单，把primary网卡临时down掉再恢复，确认切换正常。这样做的好处是保证备用链路一定处于可用状态。备份网卡最容易出的问题就是长期不用，真到需要切换的时候才发现网线松了、网卡挂了或者端口被交换机封了，如果平时没有演练习惯，到事故发生时才发现备卡不可用，那做bond的意义就完全没有了。把这条写进变更流程或者维护规范里，比任何监控都实在。

最后再分享几条我个人的实操体会

星麒麟SP3上做双网卡绑定，整个过程做下来，我最深的体会是：国产系统在网络管理这块已经跟主流通用系统很接近了，但细节上仍然有不少差异，最大的障碍反而不是系统本身，而是操作者对底层机制的理解不够透。如果你之前只在CentOS、RedHat上玩过bond，换到麒麟上来，建议把所有配置文件从头到尾检查一遍，不要想当然地认为那边能起这边也能起。

我现在的习惯是这样的：所有bond配置文件的改动都走git管理，每台机器的ifcfg-bond0和ifcfg-ethX都放进仓库，改之前先提交一份备份，改完再提交一份diff，这样即使后面有人误操作了，也能快速定位是谁改了什么；系统升级内核之后，第一时间做一次bond重启验证，因为内核升级可能影响bonding模块的行为；凡是做了bond的机器，在维护手册里单独标出来，写清楚bond模式、主备网卡、切换预期时间、交换机端口编号，方便后面接手的人快速了解这台机器的网络拓扑。

最后再提醒一句已经说过的老话：bond解决的是链路冗余问题，解决不了交换机单点故障。如果两台做高可用的物理机接在同一台交换机上，交换机一旦挂掉，整片业务照样全瘫。设备都上架了，该做的物理隔离还是要做，这个原则跟你在哪个系统上配置bond没有关系。