深入理解 Linux Bond：原理与实践

GrissomFI2025年01月20日约 18 分钟

深入理解 Linux Bond：原理与实践

1. 引言

1.1 什么是 Linux Bond

Linux Bond 是一种将多个物理网络接口（NIC）绑定为一个逻辑接口的技术，用于提升网络的性能和可靠性。通过 Bond 技术，多个网卡协同工作，实现更高的带宽聚合、网络冗余以及负载均衡等功能。简单来说，Bond 类似于将多条普通道路整合成一条多车道的高速公路，既能大幅提升通行能力，又能在某条道路发生问题时迅速切换到其他道路，保障网络的连续性。

1.2 Bond 的历史背景和技术来源

• 技术背景：Linux Bond 技术源于高可用性网络设计需求，最早被用于服务器集群和数据中心环境中，以实现网络冗余和负载均衡。
• 内核支持：从 Linux 2.4 内核开始，Linux Bonding 模块作为内核功能正式推出，逐渐演化为现代网络冗余解决方案的核心组件之一。

1.3 核心功能

1. 带宽聚合：通过将多张网卡合并为一个逻辑接口，提供更高的总传输速率。
2. 网络冗余：即使某条链路或某张网卡发生故障，剩余的网卡仍能正常工作，确保网络服务不中断。
3. 负载均衡：智能分配网络流量到多个物理网卡，实现更高效的网络资源利用。

1.4 典型应用场景

1. 高可用性：

• 在关键业务场景中，主网卡出现故障时，备用网卡能自动接管，避免因网络中断导致服务不可用。
• 例如数据库服务器的主备链路切换。

2. 负载均衡：

• 将网络流量均衡分布到多个网卡，避免单一网卡成为性能瓶颈。
• 适用于高流量场景，如 Web 服务器或文件共享服务。

3. 网络冗余：

• 在云计算或虚拟化环境中，为虚拟机或容器提供稳定且可靠的网络连接。

2. Linux Bond 的工作原理

2.1 Bond 的架构

Linux Bonding 的架构分为逻辑层和物理层：

+---------------------+                     
|     Applications    |                     
+---------------------+                     
           |                                 
           v                                 
+---------------------+                     
|   Network Stack     |                     
+---------------------+                     
           |                                 
           v                                 
+---------------------+                     
|  Bond Device (bond0)|                     
+---------------------+                     
           |                                 
  +--------+--------+                       
  |                 |                       
  v                 v                       
+------+         +------+                   
| eth0 |         | eth1 |                   
+------+         +------+                   
  |                 |                       
  v                 v                       
+-------------------------+                 
|      Network Switch      |                
+-------------------------+

• 逻辑层：Bond 设备（如 bond0）是一个虚拟的网络接口，对上层应用透明。它对外表现为一个普通的网络设备，上层协议栈和应用无需感知其下的从属设备。
• 物理层：多个物理网卡（如 eth0、eth1）作为从属设备（Slave）绑定到 Bond 设备。Bond 设备负责管理这些从属设备，并根据配置的模式决定如何分配流量。

数据流转：

• 收包路径：从属设备接收到的包会通过 bonding 模块传递到 Bond 设备，再交给上层协议栈。
• 发包路径：Bond 设备根据模式和策略将数据包分发到合适的从属设备。

链路检测：

• MII 检测：通过定时发送 MII 信号确认网卡的链路状态。
• ARP 检测：通过发送 ARP 包检测网络通路的连通性。

2.2 Bond 的模式（Mode）概述

模式编号	模式名称	描述	适用场景
Mode 0	`balance-rr`	轮询负载均衡，数据包依次从每个从属设备发送，接收方向使用所有从属设备。	高吞吐量场景，要求交换机支持。
Mode 1	`active-backup`	主备模式，只有一个从属设备处于活动状态，其他设备作为备份。	高可用性场景，如金融交易系统。
Mode 2	`balance-xor`	基于 XOR 的负载均衡，根据源/目的 `MAC` 地址或 `IP` 地址哈希分配流量。	负载均衡场景，需要交换机支持。
Mode 3	`broadcast`	广播模式，所有数据包通过所有从属设备发送，接收路径由上层决定。	特殊场景，如网络监控、广播应用。
Mode 4	`802.3ad (LACP)`	动态链路聚合，需要交换机支持 `LACP` 协议，支持负载均衡和故障转移。	高性能场景，如数据中心、文件服务器。
Mode 5	`balance-tlb`	适配器传输负载均衡，根据当前负载动态调整发送流量分配，接收方向由 ARP 响应负载均衡决定。	单向负载均衡场景，无需交换机支持。
Mode 6	`balance-alb`	适配器适应性负载均衡，支持接收和发送流量的动态负载均衡，接收方向通过 ARP 协商动态调整。	负载均衡场景，无需交换机支持。

2.3 Bond 各模式详细技术点说明

2.3.1 Mode 0: balance-rr

2.3.1.1 工作原理

• 使用轮询机制，将数据包依次通过每个从属设备发送。
• 接收方向的行为取决于交换机的配置。对于 Mode 0，交换机需要配置为将接收流量均匀分配到所有链路，从属设备共同接收数据包。

2.3.1.2 关键技术点

1. 流量分配：

• 数据包按顺序分配到各设备。
• 可能导致数据包乱序，特别是在多路径的网络环境下。

2. 交换机支持要求：

• 需要交换机支持，并配置聚合组（Link Aggregation Group, LAG）。

3. 优势：

• 提供高吞吐量。
• 简单的轮询机制实现负载均衡。

4. 限制：

• 对应用层需要严格包顺序的协议（如某些实时协议）可能不友好。
• 可能增加交换机负载。

5. 适用场景：

• 高吞吐量场景，如大文件传输和视频流服务。

6. 配置关键点：

• 交换机需要启用静态链路聚合。
• 配置时注意 MTU 和链路稳定性。

7. 性能表现：

• 在高带宽场景下性能优秀，但在延迟敏感场景下需谨慎。Mode 0 可能导致数据包乱序，影响实时应用的性能。

8. 容错能力：

• 支持从属设备故障检测并自动切换，但在故障前可能存在乱序数据包。

2.3.2 Mode 1: active-backup

2.3.2.1 工作原理

• 主备模式：只有一个从属设备处于活动状态，其他设备作为备份。不同标准（如 IEEE 802.3ad）中的 Active-Backup 模式实现细节可能有所不同，用户在配置时需注意。
• 故障发生时，自动切换到备份设备。

2.3.2.2 关键技术点

1. 流量分配：

• 所有流量均通过活动设备，备份设备不参与正常流量。

2. 交换机支持要求：

• 不需要交换机支持，适合任意网络环境。

3. 优势：

• 高可靠性，简单实现冗余。
• 对应用层完全透明。

4. 限制：

• 不能实现负载均衡。

5. 适用场景：

• 高可用性要求场景，如金融交易、数据库系统。

6. 配置关键点：

• 确保备份设备状态可用。
• 配置链路监控（如 MII 或 ARP）以快速故障检测。

7. 性能表现：

• 由于单设备传输，吞吐量有限。

8. 容错能力：

• 故障切换时间取决于监控机制和系统配置。

2.3.3 Mode 2: balance-xor

2.3.3.1 工作原理

• 流量分配规则基于 XOR 哈希算法，通常依据源/目的 MAC 地址或 IP 地址的组合进行哈希计算，确保同一数据流的流量固定分配到同一个从属设备。

2.3.3.2 关键技术点

1. 流量分配：

• 同一流的流量固定分配到一个从属设备，避免数据包乱序。

2. 交换机支持要求：

• 需要交换机支持静态链路聚合（Static LAG）。

3. 优势：

• 提供良好的负载均衡效果。
• 避免数据包乱序。

4. 限制：

• 流量分布依赖哈希规则，不均匀流量可能导致某设备过载。

5. 适用场景：

• 流量均匀分布的场景，如多客户端访问服务器。

6. 配置关键点：

• 配置交换机和 Bond 的哈希规则一致。

7. 性能表现：

• 在网络稳定且流量分布均匀时性能优异。

8. 容错能力：

• 支持从属设备故障检测和动态切换。

2.3.4 Mode 3: broadcast

2.3.4.1 工作原理

• 数据包通过所有从属设备发送，接收路径由上层决定。

此模式主要用于特殊场景（如网络监控或广播应用），不适用于常规流量，可能导致带宽浪费和广播风暴。

2.3.4.2 关键技术点

1. 流量分配：

• 每个数据包都复制到所有从属设备。

2. 交换机支持要求：

• 不需要特殊配置，适用于普通网络环境。

3. 优势：

• 数据传输完全冗余，可靠性极高。

4. 限制：

• 网络带宽浪费严重。
• 不适合常规业务，可能导致广播风暴。

5. 适用场景：

• 网络冗余传输，如容灾系统或广播应用。

6. 配置关键点：

• 确保网络链路和交换机能处理高流量负载。

7. 性能表现：

• 可靠性高，但带宽利用率低。

8. 容错能力：

• 所有从属设备故障才能导致链路中断。

2.3.5 Mode 4: 802.3ad (LACP)

2.3.5.1 工作原理

• 基于 LACP 协议动态聚合链路，实现负载均衡和故障转移。

LACP（Link Aggregation Control Protocol）是一种用于链路聚合的协议，属于IEEE 802.1AX标准。它允许将多个物理网络接口聚合为一个逻辑接口，以增加带宽和提供冗余。

2.3.5.2 关键技术点

1. 流量分配：

• 负载均衡通过 LACP 规则动态分配。

2. 交换机支持要求：

• 需要交换机支持并启用 LACP。对于其他模式（如 Mode 0 和 Mode 2），交换机也需要配置静态链路聚合组（Static LAG）。

3. 优势：

• 动态负载均衡，自动适应链路状态。
• 提供高性能和高可靠性。

4. 限制：

• 配置复杂，依赖交换机支持。

5. 适用场景：

• 数据中心、高带宽服务器。

6. 配置关键点：

• 配置交换机和 Bond 的 LACP 参数一致。

7. 性能表现：

• 多链路场景下性能极佳。

8. 容错能力：

• 自动检测链路故障并动态调整流量。

2.3.6 Mode 5: balance-tlb

2.3.6.1 工作原理

• 动态调整发送方向流量分配，接收方向通过 ARP 响应负载均衡。

2.3.6.2 关键技术点

1. 流量分配：

• 根据从属设备的实时负载分配发送流量。

2. 交换机支持要求：

• 不需要特殊支持。

3. 优势：

• 不依赖交换机，部署简单。
• 发送流量动态均衡。

4. 限制：

• 接收流量未优化。

5. 适用场景：

• 无法修改交换机配置的环境。

6. 配置关键点：

• 确保 ARP 响应能正确反映链路状态。

7. 性能表现：

• 动态性强，适合小型场景。

8. 容错能力：

• 支持动态切换，但接收方向可能受限。

2.3.7 Mode 6: balance-alb

2.3.7.1 工作原理

• 动态负载均衡发送和接收流量。在接收方向，通过修改 ARP 响应的源 MAC 地址，动态调整接收路径，确保接收流量均匀分布到所有从属设备。

2.3.7.2 关键技术点

1. 流量分配：

• 发送和接收流量均支持动态负载均衡。

2. 交换机支持要求：

• 不需要特殊支持。

3. 优势：

• 提供双向动态负载均衡。
• 自动适应流量变化。

4. 限制：

• 对某些网络拓扑的兼容性需测试。

5. 适用场景：

• 无交换机支持且需要高效负载均衡的场景。

6. 配置关键点：

• 配置正确的 ARP 协商参数。

7. 性能表现：

• 在复杂网络中表现良好。

8. 容错能力：

• 动态切换性能优异，支持接收和发送流量的平滑调整。

3 Linux Bond 内核模块实现概述

以下是 Bond 内核模块的底层实现细节。

3.1 Bond 驱动的核心结构与框架

3.1.1 核心数据结构

1. struct net_device：描述 Bond 设备的网络接口，负责与内核网络栈交互。
2. struct bonding：

• Bond 的私有数据结构，存储 Bond 配置、状态及从属设备列表。
• 包含链路检测相关参数（如 miimon 和 arp_interval）和从属设备链表 slave_list。

3. struct slave：描述从属设备，存储其链路状态、统计数据和特定配置。

3.1.2 核心功能路径

1. 初始化：

• bond_create：分配并初始化 Bond 设备。
• bond_setup：设置默认参数（如模式、链路检测方法）。

2. 发送路径：

• bond_start_xmit：选择从属设备并发送数据包。

3. 接收路径：

• bond_handle_frame：处理接收到的数据包，视模式而定可能调整路径。

4. 状态更新：

• 定期检测链路状态，更新从属设备的状态信息。

3.2 链路监控机制

3.2.1 检测方法

1. MII 检测：

• 使用 ethtool 接口定期查询物理链路状态。
• 实现：bond_mii_monitor 定时器定期触发状态检查。

2. ARP 检测：

• 构造 ARP 请求发送到目标 IP，分析 ARP 响应确定链路可达性。ARP 监控需要配置 arp_ip_target 参数，指定目标 IP 地址。在 IPv6 环境中，可以使用 ICMP echo 请求进行链路监控。
• 常用于动态路由环境。

3. 定时器机制：

• 内核定时器触发监控函数，例如 bond_mii_monitor_timer，周期性更新链路状态。

3.3 负载均衡与数据分发机制

3.3.1 发送路径

• bond_start_xmit：发送数据包时，根据当前模式选择合适的从属设备。
• 负载分配策略：

• Mode 0：轮询所有从属设备。
• Mode 2：基于 XOR 哈希算法分配（源/目的 MAC 地址或 IP 地址组合）。
• Mode 4：LACP 协商后动态分配。
• Mode 6：根据从属设备负载动态调整。

3.3.2 接收路径

• 对于 Mode 6，拦截 ARP 包，动态调整接收方向的流量分配。
• 接收包的处理通常基于上层协议栈，由内核自动调度。

3.4 从属设备的管理

3.4.1 绑定与解绑

1. 绑定：

• bond_enslave：将从属设备添加到 Bond。
• 检查从属设备的兼容性（如设备类型和驱动支持）。注意并非所有网络驱动都支持所有 Bonding 模式，用户在配置前应检查驱动兼容性。

2. 解绑：

• bond_release：移除从属设备并释放资源。

3.4.2 状态管理

• 每个从属设备维护独立的链路状态（BOND_LINK_UP 或 BOND_LINK_DOWN）。
• 故障时，从属设备自动标记为不可用，并从负载均衡中移除。

3.5 故障恢复与容错机制

3.5.1 故障检测

• 链路故障通过 MII 或 ARP 检测。
• 状态更新通过 bond_change_active_slave 切换活动设备。

3.5.2 故障恢复

• 链路恢复后，重新将从属设备加入负载均衡。
• Mode 1（active-backup）下，快速切换到备份设备以保证服务连续性。

3.6 多队列与性能优化

3.6.1 多队列支持

• Bond 设备通过 struct netdev_queue 管理多队列，支持高性能场景。
• 结合 RSS（Receive Side Scaling）优化多核性能。

3.6.2 软中断机制

• 使用 RPS（Receive Packet Steering）将接收流量分配到特定 CPU，减少 CPU 竞争。

3.6.3 CPU 亲和性

• 中断和流量处理的 CPU 绑定策略，提高数据包处理效率。

3.7 用户空间交互与配置

3.7.1 工具支持

• ip link 和 ifenslave 提供用户空间的设备绑定和参数配置。
• /proc/net/bonding/<bond_name> 提供状态和统计信息。

3.7.2 参数管理

• 模块加载参数：

• mode：设置 Bond 工作模式。
• miimon：链路检测间隔。

• 动态参数：

• 使用 netlink 动态更新设备配置。

4. 动手实践：配置 Linux Bond Mode 6

以下是配置和验证 Linux Bond Mode 6的详细步骤，同时包括对 Bond 状态的监控方法。

4.1 环境准备

4.1.1 系统要求

• 确保系统支持 Bonding 模块（大多数现代 Linux 内核默认支持）。
• 至少两块网卡可用作为从属设备。

4.1.2 确认内核模块

• 检查 bonding 模块是否加载：
```
lsmod | grep bonding
```
• 如果未加载，手动加载模块：
```
sudo modprobe bonding
```

4.2 配置 Bond 接口

4.2.1 创建 Bond 设备

•

sudo vi /etc/sysconfig/network-scripts/ifcfg-bond0

1. 编辑 bond0 的配置文件：

•

DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_OPTS="mode=6 miimon=100"
BOOTPROTO=none
IPADDR=192.168.1.100
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
ONBOOT=yes

2. 配置内容如下：

4.2.2 配置从属网卡

•

sudo vi /etc/sysconfig/network-scripts/ifcfg-eth1

1. 为从属网卡（如 eth1 和 eth2）分别创建配置文件：

•

DEVICE=eth1
NAME=eth1
MASTER=bond0
SLAVE=yes
BOOTPROTO=none
ONBOOT=yes

2. eth1 的配置内容：

•

sudo vi /etc/sysconfig/network-scripts/ifcfg-eth2

3. 类似地配置 eth2：

配置内容与 eth1 一致，仅修改 DEVICE=eth2。

4.2.3 重启网络服务

• 重启网络服务：
```
sudo systemctl restart network
```
• 验证 Bond 设备是否生效：
```
ip addr show bond0
```

4.3 验证 Bond 配置

4.3.1 查看 Bond 状态

•
```
cat /proc/net/bonding/bond0
```

1. 检查 /proc/net/bonding/bond0：

•

• 模式：mode=6 (balance-alb)。
• 从属设备：确保 eth1 和 eth2 均存在。
• 链路状态：从属设备应为 up。

2. 验证以下内容：

4.3.2 流量验证

1. 发送方向负载均衡：

• 使用 iperf 或 ping 从不同客户端发送流量到 bond0。

• 检查从属设备的发送流量：

watch -n 1 cat /sys/class/net/eth1/statistics/tx_bytes
watch -n 1 cat /sys/class/net/eth2/statistics/tx_bytes

• 验证负载是否均匀分布。

2. 接收方向负载均衡：

• 使用 arp 检查目标设备的接收路径：
```
arp -a
```
• 验证接收方向是否动态调整。

4.4 故障测试

4.4.1 模拟链路故障

• 禁用 eth1：
```
sudo ip link set eth1 down
```
• 检查 /proc/net/bonding/bond0，验证 Bond 是否自动将流量切换到 eth2。

注意交换机的链路聚合组配置，避免交换机因链路抖动而禁用端口。

4.4.2 恢复链路

• 启用 eth1：
```
sudo ip link set eth1 up
```
• 再次检查 /proc/net/bonding/bond0，验证 eth1 状态是否恢复。

4.5 Bond 状态监控

4.5.1 查看 Bond 信息

•
```
cat /proc/net/bonding/bond0
```

1. 查看 Bond 设备的详细状态：

•

Ethernet Channel Bonding Driver: v3.7.1
Bonding Mode: adaptive load balancing
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Slave Interface: eth1
   MII Status: up
   Link Failure Count: 0
   Permanent HW addr: 00:1a:2b:3c:4d:5e
Slave Interface: eth2
   MII Status: up
   Link Failure Count: 0
   Permanent HW addr: 00:1a:2b:3c:4d:5f

2. 输出示例：

4.5.2 使用网络监控工具

• iftop：实时监控网络流量：
```
sudo iftop -i bond0
```

5 日志与问题排查

本章节汇总了 Linux Bonding 配置和运行中常见的问题及解决方法。

5.1 查看常见错误信息

1. 查看内核日志

• 使用 dmesg 查看内核日志中与 Bonding 相关的内容：
```
dmesg | grep bonding
```
• 使用 journalctl 查看系统日志中的 Bonding 信息：
```
journalctl -k | grep bonding
```

2. 查看 Bond 设备状态

• 检查 Bond 设备的详细信息：
```
cat /proc/net/bonding/bond0
```
• 确认模式、从属设备列表、链路状态等是否正常。

3. 验证从属设备状态

• 查看从属设备的当前绑定和链路状态：
```
ip addr show eth1
ip addr show eth2
```
• 检查网卡物理连接状态：
```
ethtool eth1
ethtool eth2
```

5.2 常见问题与解决方法

5.2.1 Bond 接口无法启动

• 原因:

• 配置文件语法错误：ifcfg-bond0 或从属设备的配置文件中可能存在语法错误（如缺少引号、拼写错误等）。
• 参数冲突：Bonding 配置参数（如 mode、miimon 等）可能与其他网络配置冲突，导致 Bond 接口无法正常启动。
• 网络服务未正确重启：修改配置文件后，网络服务可能未正确重启，导致配置未生效。

• 解决方法

1. 检查配置文件语法：

• 使用文本编辑器打开 /etc/sysconfig/network-scripts/ifcfg-bond0 和从属设备的配置文件（如 ifcfg-eth1、ifcfg-eth2），确保语法正确。

• 示例：

DEVICE=bond0
TYPE=Bond
BONDING_OPTS="mode=4 miimon=100"
BOOTPROTO=none
ONBOOT=yes

• 确保每行配置正确无误，避免拼写错误或缺少引号。

2. 检查参数冲突：

• 确保 Bonding 配置参数（如 mode、miimon 等）与其他网络配置不冲突。
• 例如，检查 BONDING_OPTS 中的参数是否与从属设备的配置冲突。

3. 重启网络服务：

• 使用以下命令重启网络服务，确保配置生效：
```
sudo systemctl restart network
```
• 如果问题仍然存在，可以尝试重启系统。

5.2.2 从属设备无法绑定

• 原因

• 驱动不支持 Bonding：从属设备的网络驱动可能不支持 Bonding 功能。
• 设备已被其他配置占用：从属设备可能已被其他网络配置（如桥接、VLAN 等）占用，导致无法绑定到 Bond 接口。
• 硬件或连接问题：从属设备的硬件故障或物理连接问题可能导致绑定失败。

• 解决方法

1. 检查驱动支持：

• 使用 ethtool 检查从属设备的驱动是否支持 Bonding：
```
ethtool -i eth1
```
• 确保驱动支持 Bonding 功能。如果不支持，可能需要更新驱动或更换网卡。

2. 检查设备占用情况：

• 使用 ip link 检查从属设备是否已被其他配置占用：
```
ip link show eth1
```

• 如果设备已被占用，解除绑定后再重新绑定到 Bond 接口：

sudo ip link set dev eth1 nomaster
sudo ip link set dev eth1 master bond0

3. 检查硬件和连接：

• 使用 ethtool 检查从属设备的物理连接状态：
```
ethtool eth1
```
• 确保设备物理连接正常，无硬件故障。

4. 查看日志：

• 使用 dmesg 或 journalctl 查看内核日志，检查是否有与从属设备绑定相关的错误信息：
```
dmesg | grep bonding
journalctl -k | grep bonding
```

5. 确认 Bonding 模块已加载：

• 使用 lsmod 检查 Bonding 模块是否已加载：
```
lsmod | grep bonding
```
• 如果未加载，手动加载 Bonding 模块：
```
sudo modprobe bonding
```

5.3 常见内核错误日志及解决方法

以下是配置 Linux Bond 时可能遇到的内核错误日志信息及其含义：

5.3.1 "No suitable device found for this operation"

• 原因：尝试绑定的网卡设备不支持 Bonding，或者网卡已被绑定到其他设备。
• 解决方法：

1. 确认网卡是否支持 Bonding：
```
ethtool -i ethX
```
2. 检查网卡是否已被其他设备占用：
```
ip addr show ethX
```

3. 解除绑定后重新操作：

sudo ip link set dev ethX nomaster

5.3.2 "MII status is DOWN for slave interface"

• 原因：从属设备链路检测失败，物理链路可能断开或配置不当。
• 解决方法：

1. 检查物理连接是否正常：
```
ethtool ethX
```

2. 确认 miimon 参数配置正确（如 miimon=100）：

grep BONDING_OPTS /etc/sysconfig/network-scripts/ifcfg-bond0

3. 检查交换机端口状态，确保交换机正确配置。

5.3.3 "Failed to set MAC address for bond interface"

• 原因：Bond 接口未能设置 MAC 地址，通常是从属设备的 MAC 地址冲突或配置问题。
• 解决方法：

1. 检查从属设备的 MAC 地址是否正常：
```
ip link show ethX
```

2. 重置从属设备的配置，确保未配置静态 MAC 地址：

sudo ip link set dev ethX address <new_mac_address>

5.3.4 "Link failure detected on slave interface"

• 原因：从属设备链路故障。
• 解决方法：

1. 确认网卡连接状态：
```
ethtool ethX
```
2. 检查链路检测方式（如 ARP 或 MII）是否配置正确。
3. 确保交换机端口未被禁用或关闭。

5.3.5 "Invalid bonding mode specified"

• 原因：配置文件中指定了错误或不支持的 Bonding 模式。
• 解决方法：

1. 验证配置文件中 mode 参数的值：

grep BONDING_OPTS /etc/sysconfig/network-scripts/ifcfg-bond0

2. 检查是否输入了有效模式（0-6），例如：
```
BONDING_OPTS="mode=6 miimon=100"
```
3. 重启网络服务后再检查日志：
```
sudo systemctl restart network
```

5.3.6 "Unable to add slave interface: Operation not supported"

• 原因：从属设备无法绑定到 Bond，可能是设备驱动不支持 Bonding。
• 解决方法：

1. 确认设备驱动支持 Bonding：
```
ethtool -i ethX
```
2. 检查 Bonding 模块是否正常加载：
```
lsmod | grep bonding
```
3. 如果未加载，手动加载：
```
sudo modprobe bonding
```

5.3.7 "Primary slave interface not available"

• 原因：配置了 primary 参数，但指定的从属设备不可用。
• 解决方法：

1. 检查 primary 参数配置：

grep primary /etc/sysconfig/network-scripts/ifcfg-bond0

2. 确保指定的从属设备已正常连接：
```
ip addr show ethX
```

5.3.8 "ARP monitoring failed on slave interface"

• 原因：ARP 检测未能正常工作，目标 IP 地址不可达。
• 解决方法：

1. 确保 arp_ip_target 配置了有效的目标 IP 地址：

BONDING_OPTS="mode=6 arp_interval=100 arp_ip_target=192.168.1.1"

2. 测试目标 IP 的连通性：
```
ping -c 3 192.168.1.1
```
3. 检查是否存在路由配置问题或防火墙阻断。