linux网络绑定常用模式有balance-rr（mode=0）、active-backup（mode=1）、802.3ad（mode=4）；选择应基于带宽需求与高可用性要求。1. balance-rr适用于需带宽叠加且交换机支持链路聚合的场景，但可能引发数据包乱序；2. active-backup适合仅需高可用性的环境，主备切换无感知，配置简单；3. 802.3ad适用于需同时实现负载均衡与冗余的环境，但依赖交换机支持lacp协议。配置时优先考虑系统稳定性与网络基础设施能力，若仅为防止单点故障，推荐使用active-backup模式。
Linux系统在处理多网络接口时，提供了极大的灵活性，无论是为了提升吞吐量、隔离不同业务流量，还是为了实现网络链路的高可用性。其中，网络绑定（Bonding）技术是确保服务不中断的关键，它能将多个物理网卡逻辑上捆绑成一个，一旦其中一条链路出现故障，系统能自动切换到健康的链路，几乎不影响上层应用，这对于需要高可用性的服务器环境来说，简直是救命稻草。
解决方案
在Linux环境中配置多网络接口，特别是涉及网络绑定和故障切换，核心思路是将多个物理网卡（或虚拟网卡）逻辑上组合成一个单一的接口。这不仅仅是为了增加带宽，更重要的是为了实现冗余和高可用性。我个人在处理这类需求时，通常会优先考虑
bonding模块，因为它足够成熟且功能强大。
首先，你需要确保系统支持
bonding模块，通常现代Linux发行版都内置了。如果不在，
modprobe bonding可以加载它。接着，关键在于创建和配置
bond接口以及其成员接口。
配置流程大致是这样：
-
确定绑定模式： 这很关键，不同的模式决定了你的网络行为。比如，我最常用的是
active-backup
模式，它能提供完美的故障切换，一个网卡挂了，另一个立刻顶上，IP地址和MAC地址都不变，上层应用根本感知不到链路中断。如果是需要更高吞吐量，并且交换机支持LACP，那802.3ad
（LACP）就是首选，它能将多个链路的带宽聚合起来。 -
配置主
bond
接口： 创建一个ifcfg-bondX
文件（例如ifcfg-bond0
），定义这个逻辑接口的IP地址、网络掩码、网关，以及最重要的BONDING_OPTS
，这里面包含了你选择的绑定模式和一些关键参数，比如miimon
（用于链路监控的毫秒间隔）。 -
配置成员接口： 为每个物理网卡（例如
eth0
,eth1
）创建一个ifcfg-ethX
文件。这些文件不再配置IP地址，而是将它们指定为bond
接口的成员。你需要设置MASTER=bond0
和SLAVE=yes
。 -
应用配置： 重启网络服务（例如
systemctl restart network
或nmcli connection reload
），或者直接使用ifup
命令激活新的接口配置。
这个过程，说实话，一开始可能有点绕，但一旦你理解了
MASTER和
SLAVE的关系，以及
BONDING_OPTS里那些参数的含义，就会发现它其实非常直观。我通常会把
miimon设置得小一点，比如100毫秒，这样故障检测和切换能更快。
Linux网络绑定（Bonding）有哪些常用模式？如何选择合适的模式？
谈到Linux的网络绑定模式，这真是一个选择的艺术，因为它直接决定了你的网络性能和容错能力。我个人觉得，理解这些模式的内在逻辑比死记硬背配置更重要。最常用的模式无外乎以下几种，每种都有其独特的应用场景：
-
mode=0
(balance-rr，轮询策略)：- 特点： 数据包在所有可用端口上依次发送，实现了负载均衡。
- 适用场景： 对带宽需求高，且需要最大化吞吐量的环境。它能将多个链路的带宽叠加，但要求交换机支持链路聚合，并且通常需要配置相同的MAC地址。
- 个人看法： 这种模式在理论上很美，但实际部署时要小心，因为包的顺序可能会乱，对于一些对顺序敏感的应用，可能不是最佳选择。
-
mode=1
(active-backup，主备策略)：- 特点： 只有一个接口处于活动状态，负责所有流量。当活动接口发生故障时，另一个备用接口会立即接管。
- 适用场景： 这是我最常用、也是最推荐的模式，尤其是在只需要高可用性而不需要带宽叠加的场景。例如，数据库服务器、Web服务器，它们更看重的是服务的连续性，而不是极致的带宽。
- 个人看法： 它的优点是配置简单，对交换机没有特殊要求，而且故障切换非常平滑，几乎无感。缺点是带宽无法叠加，始终只有一条链路在工作。但对于很多关键业务来说，稳定性远比那点额外的带宽重要。
-
mode=4
(802.3ad，动态链路聚合，LACP)：- 特点： 动态创建聚合组，根据交换机和网卡之间的LACP协议协商，实现智能的负载均衡。它能聚合多个链路的带宽，并提供故障冗余。
- 适用场景： 需要同时具备高带宽和高可用性的场景，例如虚拟化宿主机、存储网络。
- 个人看法： 这是最“高级”的模式，因为它不仅能负载均衡，还能检测链路故障。但它要求你的交换机必须支持802.3ad（LACP），并且需要正确配置。如果交换机不支持或者配置不当，反而可能带来问题。我通常会在确定交换机能力后才会考虑这种模式。
如何选择？ 这真的取决于你的核心需求。如果只是为了防止网线被踢掉或者网卡坏了导致服务中断，
active-backup模式是你的最佳拍档，简单、可靠。如果你的应用是数据密集型，需要榨干每一丝带宽，并且你的网络基础设施（交换机）也足够现代化，那么
802.3ad会是更好的选择。至于
balance-rr，我用得相对较少，因为它对包顺序的潜在影响让我有点顾虑。
在Linux中如何配置网络接口绑定（Bonding）以实现高可用性？
实现高可用性，我通常会选择
active-backup模式（
mode=1）。这个模式的配置相对直接，而且效果可靠。这里我以CentOS/RHEL系列系统为例，使用
ifcfg文件进行配置，这是我个人觉得最稳妥的方式。
假设我们有两块物理网卡
eth0和
eth1，希望将它们绑定成
bond0，并配置IP地址
192.168.1.100。
-
创建或修改
ifcfg-bond0
文件：# 编辑 /etc/sysconfig/network-scripts/ifcfg-bond0 TYPE=Bond DEVICE=bond0 NAME=bond0 BOOTPROTO=static IPADDR=192.168.1.100 NETMASK=255.255.255.0 GATEWAY=192.168.1.1 ONBOOT=yes # 核心配置：mode=1 (active-backup) 和 miimon (链路监控间隔) BONDING_OPTS="mode=1 miimon=100"
这里
miimon=100
表示每100毫秒检查一次链路状态。这个值可以根据需求调整，但太小可能增加CPU开销，太大则会延长故障检测时间。 -
创建或修改
ifcfg-eth0
文件：# 编辑 /etc/sysconfig/network-scripts/ifcfg-eth0 TYPE=Ethernet DEVICE=eth0 NAME=eth0 ONBOOT=yes MASTER=bond0 SLAVE=yes # 不再配置IP地址，因为它现在是bond0的从属 BOOTPROTO=none
-
创建或修改
ifcfg-eth1
文件：# 编辑 /etc/sysconfig/network-scripts/ifcfg-eth1 TYPE=Ethernet DEVICE=eth1 NAME=eth1 ONBOOT=yes MASTER=bond0 SLAVE=yes BOOTPROTO=none
-
确保
bonding
模块已加载： 通常，如果你在ifcfg-bond0
中配置了TYPE=Bond
，系统会自动加载。但为了保险起见，可以手动检查或添加到模块加载配置中：lsmod | grep bonding # 如果没有输出，可以尝试手动加载 modprobe bonding # 为了开机自动加载，可以将 bonding 加入 /etc/modules-load.d/bonding.conf echo "bonding" > /etc/modules-load.d/bonding.conf
-
重启网络服务：
systemctl restart network # 或者对于使用NetworkManager的系统 nmcli connection reload nmcli connection up bond0
我个人更倾向于
systemctl restart network
，它会重新加载所有配置，虽然可能导致短暂的网络中断，但在配置变更时更彻底。
这样配置完成后，
bond0就会以
active-backup模式运行，
eth0和
eth1中会有一个作为主链路，另一个作为备用链路。当主链路出现问题时，
bond0会自动将流量切换到备用链路，确保网络连接的持续性。
网络故障切换（Failover）后，如何验证Linux Bond状态和链路恢复？
配置好了网络绑定，最让人安心的莫过于能够验证它确实在按预期工作，尤其是在故障发生和恢复之后。我通常会通过几个简单的命令来检查
bond接口的状态，这比看日志文件要直观得多。
-
查看Bond接口的详细状态： 这是我验证
bond
状态的首选命令，它会显示当前哪个接口是活动的，哪些是备用的，以及它们的链路状态。cat /proc/net/bonding/bond0
输出示例：
Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth0 MII Status: up MII Polling Interval (ms): 100 Up Delay (ms): 0 Down Delay (ms): 0 Slave Interface: eth0 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:11:22:33:44:55 Slave queue ID: 0 Slave Interface: eth1 MII Status: up Link Failure Count: 0 Permanent HW addr: 00:11:22:33:44:66 Slave queue ID: 0
这里，
Currently Active Slave: eth0
清楚地表明eth0
是当前活动接口。如果我拔掉eth0
的网线，再次执行这个命令，你会看到Currently Active Slave
会变成eth1
，同时eth0
的MII Status
会变为down
。这就是故障切换成功的标志。 -
检查IP地址和链路状态： 虽然
cat /proc/net/bonding/bond0
已经很详细了，但ip addr show bond0
和ip link show bond0
可以快速确认bond0
接口本身的IP地址是否还在，以及其整体链路是否为UP。ip addr show bond0 ip link show bond0
即使底层物理链路切换了，
bond0
的IP地址和MAC地址都应该保持不变，这是active-backup
模式的关键优势。 -
观察物理接口状态（辅助验证）：
ethtool
命令可以深入查看每个物理网卡的链路状态，这在排查问题时很有用。ethtool eth0 ethtool eth1
在输出中查找
Link detected: yes
或no
。当你模拟故障（比如拔掉网线）时，你会看到对应的物理网卡Link detected
状态会变为no
，而bond0
的活动接口会自动切换。当重新插上网线后，Link detected
会再次变为yes
，bond0
也会根据配置（如果有fail_over_mac
或primary
参数）选择是否切换回主链路。
我通常会做个小实验来验证：
- 先用
ping
命令持续ping一个外部IP地址（比如网关）。 - 然后，物理拔掉当前活动接口的网线。
- 观察
ping
命令的输出，你会看到短暂的丢包（通常只有几秒钟，取决于miimon
设置），然后ping
会恢复正常。 - 同时，通过
cat /proc/net/bonding/bond0
验证活动接口已经切换。 - 最后，重新插上网线，观察
bond0
是否切换回原主接口（如果配置了primary
参数），或者保持在备
用接口上。
用接口上。这个验证过程能让你对Linux网络绑定的健壮性有更直观的认识，也能帮助你在实际部署中更有信心。
