前言

網口/網卡bond，也就是多個網絡接口綁定成一個邏輯接口的技術（NIC Teaming/Link Aggregation），或者稱為鏈路聚合。

例如，當你有一張兩個10Gps端口的網卡時，若你想將網口的速率翻倍，變為20Gps,便可以考慮在os下將這兩個網口做一個mode=0 或 mode =4 的綁定， 便可以得到一個 速率為20Gps的網絡接口。

下面本文將介紹bond的歷史來源、基本幾種模式，並探討各種模式的原理。

鏈路聚合歷史脈絡

1.發展背景

• 高可用性需求：隨着企業越來越依賴於網絡服務（如數據庫、文件服務器），網絡連接的單點故障變得不可接受。一塊網卡、一條網線或一個交換機端口的故障，就可能導致關鍵業務中斷，造成巨大損失。
• 帶寬增長需求：服務器處理能力快速增長（CPU、內存、磁盤I/O），而網絡帶寬成為了新的瓶頸。在千兆以太網（1Gbps）成為主流的時代，如何突破單塊網卡的速率上限，成為一個迫切問題。

2.早期概念與專有解決方案（1990年代中後期）

在早期，並沒有統一的標準。各大網絡設備廠商，如 Cisco、Nortel、3Com 等，都推出了各自的私有鏈路聚合技術。
例如，Cisco的 EtherChannel、Fast EtherChannel 就是早期的代表。
問題：必須使用同一廠商的交換機和安裝了特定驅動的服務器網卡才能實現捆綁，增加了成本和複雜性。

標準化進程——IEEE 802.3ad的誕生（2000年）

為了解決私有協議帶來的混亂，IEEE（電氣和電子工程師協會）牽頭制定了標準。2000年，IEEE 802.3ad 標準正式發佈。
這個標準定義了 鏈路聚合控制協議（LACP - Link Aggregation Control Protocol），允許支持該標準的任何廠商的交換機與任何支持該標準的服務器網卡進行通信和協商，這是網口bonding技術發展的里程碑。它打破了廠商鎖定，使得跨平台、跨設備的鏈路聚合成為可能。

操作系統內核的集成（2000年代初期）

從硬件/驅動到操作系統：在標準制定之後，需要操作系統層面提供支持來實現bonding功能。

• Linux的引領作用：Linux內核在 2.4.x 版本（2001年左右）​ 開始集成官方的 bonding驅動。這是一個純軟件實現的解決方案，它允許系統管理員將多個物理網卡接口綁定成一個邏輯接口 bond0，並支持多種模式（包括基於802.3ad的模式4）。
• 開源的力量：Linux bonding驅動的出現，讓即使使用廉價普通網卡的用户也能享受到鏈路聚合的好處，只要交換機支持LACP即可。這大大降低了技術門檻，促進了該技術在Web託管、雲計算等領域的普及。
  其他操作系統的跟進：隨後，其他主流服務器操作系統也紛紛內置了類似功能：
• Windows Server​ 在後續版本中加入了名為 NIC Teaming​ 的功能。
• VMware ESXi​ 等虛擬化平台在虛擬交換機層面提供了豐富的負載均衡和故障切換策略。

mode=0 round robin 平衡輪詢策略

進入正題，linux有七種網卡綁定模式：

0. round robin，
1. active-backup
2. load balancing (xor)，
3. fault-tolerance (broadcast)，
4. lacp
5. transmit load balancing，
6. adaptive load balancing。

mode=4在一般企業中用的比較多， mode=1,mode=6 也有部分地位

首先介紹mode=0. mode=0的官方名稱是 平衡輪詢策略

核心原理：在這種模式下，數據包的發送會依次通過每一個被綁定的物理網口。第一個數據包走第一個物理網口，第二個數據包走第二個物理網口，如此循環往復。這種機制旨在最大化地利用所有可用網卡的帶寬，實現網絡流量的負載均衡

其主要目標是進行負載均衡，通過將網絡流量分散到多條鏈路，從而增加有效的網絡帶寬。同時，當一條物理鏈路發生故障時，它能自動將流量切換到其他正常的鏈路上，因此也具備了基本的容錯能力

帶寬效果
理想情況下，總帶寬是所有成員網卡帶寬之和（例如，2個1G網卡綁定後，理論發送帶寬可達2G）
容錯能力
具備鏈路冗餘。當監測到某個網卡的鏈路中斷時，會自動停止向該網卡發送數據，由其他正常網卡接管
交換機需求
通常需要配置支持。需將連接多個物理網口的交換機端口配置為聚合組（如Cisco的EtherChannel、華為的Eth-Trunk），否則可能因MAC地址混亂導致網絡問題

為什麼呢？ 簡單説一下原理：

mode 0下bond所綁定的網口都會被修改成相同的mac地址，如果這些網卡都被接在同一個交換機，那麼交換機的arp表裏這個mac地址對應的端口就有多個，那麼交換機接受到發往這個mac地址的包應該往哪個端口轉發呢？

一個mac地址對應多個端口肯定使交換機迷惑了。所以 mode0下的bond如果連接到交換機，交換機這幾個端口應該採取聚合方式，因為交換機做了聚合後，聚合下的幾個端口被視為一個邏輯組.

服務器視角：             交換機視角：
eth0 (MAC: AA:AA:AA:AA:AA:AA)  ←→  端口1 (邏輯組1)
eth1 (MAC: AA:AA:AA:AA:AA:AA)  ←→  端口2 (邏輯組1)
      ↓                             ↓
bond0 (MAC: AA:AA:AA:AA:AA:AA) ←→ 端口組1 (MAC: AA:AA:AA:AA:AA:AA)

以linux下nmcli設置為例，設置命令如下：

# 創建bond0
nmcli connection add type bond con-name bond0 ifname bond0 mode 0

# 添加網口
sudo nmcli connection add type bond-slave  ifname eth0 master bond0
sudo nmcli connection add type bond-slave  ifname eth1 master bond0


# 設置網關和DNS（可選）
sudo nmcli connection modify bond0 ipv4.gateway "192.168.1.1"
sudo nmcli connection modify bond0 ipv4.dns "8.8.8.8,8.8.4.4"
sudo nmcli connection modify bond0 ipv4.method manual

# 使網口up
nmcli connection  up  bond-slave-網口1名稱
nmcli connection  up  bond-slave-網口2名稱
nmcli connection  up  bond0

交換機設置不再贅述，各家交換機命令都不太一致。 nmcli 設置其他模式的mode，只需要將 下面的 mode 0, 改成mode 其他就行，例如 mode 1 , mode 4

nmcli connection add type bond con-name bond0 ifname bond0 mode 0

mode=1 active-backup 主備策略

特點：只有一個設備處於活動狀態，當一個宕掉另一個馬上由備份轉換為主設備。

此模式只提供了容錯能力；由此可見此算法的優點是可以提供高網絡連接的可用性。

但是它的資源利用率較低，只有一個接口處於工作狀態，在有 N 個網絡接口的情況下，資源利用率為1/N

正常狀態：
主網口(eth0) → 活躍狀態，處理所有網絡流量
備網口(eth1) → 待命狀態，監控鏈路但不傳輸數據

故障狀態（主網口故障）：
主網口(eth0) → 故障，停止工作
備網口(eth1) → 立即接管，成為新的活躍網口

mode=2 Balance-XOR 異或平衡模式

Mode=2​ 稱為異或平衡模式，是一種基於哈希算法的負載均衡方式。

缺省的策略是：
發送端口選擇 = (源MAC XOR 目標MAC) % 從端口數量

假設：
- 源MAC: 11:22:33:44:55:66
- 目標MAC: AA:BB:CC:DD:EE:FF
- 端口數量: 2

計算：
哈希值 = 0x112233445566 XOR 0xAABBCCDDEEFF = 0xBB99FF99BB99
端口索引 = 0xBB99FF99BB99 % 2 = 1 (如果結果為1)

結果：這個會話的所有數據包都通過端口1發送

這種策略也叫layer2 哈希策略，在這種策略下

• 如果主機A與多個不同主機通信 → 流量會分佈到不同端口（有負載均衡）
• 如果主機A只與1台主機B通信 → 所有流量走同一個端口（無負載均衡）

那麼如何解決主機A只與1台主機B帶來的無負載均衡問題呢？

我們需要策略改成 layer3+4

layer3+4是 基於IP和端口的哈希

哈希輸入：源IP + 目標IP + 源端口 + 目標端口

linux下設置如下：

echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy

# 哈希輸入：IP地址 + 端口號
hash = (源IP ^ 目標IP) ^ (源端口 ^ 目標端口)

# 即使同一對主機，不同連接走不同路徑：
連接1: A(IP1:5000) → B(IP2:80)   → 端口0
連接2: A(IP1:5001) → B(IP2:80)   → 端口1  # 不同端口！
連接3: A(IP1:5002) → B(IP2:443)  → 端口0
連接4: A(IP1:5003) → B(IP2:443)  → 端口1

這就更細顆粒度解決了 layer2 策略帶來的單目標通信無負載均衡的問題。

與mode=0的對比如下：

mode=3 Broadcast 廣播模式

mode=3 稱為廣播模式，是所有綁定模式中最特殊的一種，以可靠性為最高優先級。

數據包發送流程：
應用數據 → bond0 → 同時從所有活動從端口發送

發送示例：
數據包P → 同時通過 eth0 和 eth1 發送
        ↗ eth0 → 網絡路徑1 → 目標設備
數據包P 
        ↘ eth1 → 網絡路徑2 → 目標設備

接收示例：
目標設備回覆 → 可能通過 eth0 或 eth1 接收

這種策略帶來100% 數據冗餘，以及可靠的數據傳輸，只適用於極端可靠性要求的特殊場景

mode=4 (802.3ad/LACP) 動態鏈路聚合

Mode=4​稱為動態鏈路聚合或LACP模式，是企業環境中最常用、最標準的綁定模式。

前面提到的mode0 1 2 3，都沒有用到IEEE 802.3ad/LACP 協議，是Linux bonding驅動自有的實現。所以Mode=4代表了更現代、更標準的網絡聚合方案

工作原理如下：

1. 協議握手
雙方聲明支持LACP聚合能力
交換系統ID、端口能力、MAC地址等參數

服務器網口 → 發送LACP報文 → 交換機
交換機 → 響應LACP報文 → 服務器

2. 動態聚合建立

# 交換機端創建邏輯聚合端口
交換機: 創建 Port-channel1
↓
# 將兼容的物理端口加入聚合組
端口1 → 加入 Port-channel1
端口2 → 加入 Port-channel1
↓
# 分配聚合組ID
Aggregator ID = 1

3. 智能流量分配

基於哈希算法分配流量：
會話1: IP_A:端口X → IP_B:端口Y → 走 eth0
會話2: IP_A:端口Z → IP_B:端口Y → 走 eth1
同一會話的所有數據包保證走同一路徑

4. 實時監控與故障切換

# 持續保活檢測：
- 每1秒交換LACP保活報文
- 鏈路故障時自動移除故障端口
- 剩餘端口繼續承載流量
- 鏈路恢復後自動重新加入

同樣的，mode=4 的哈希策略默認是layer=2。

這裏額外説一下部分人為什麼兩張網卡對聯，測試iperf bond4速率的時候只能達到單倍速率，就是因為使用了默認的哈希策略，layer=2

# 假設：
機器A MAC: AA:AA:AA:AA:AA:AA
機器B MAC: BB:BB:BB:BB:BB:BB

# layer2哈希計算：
hash = MAC_A XOR MAC_B = 固定值
端口選擇 = hash % 2 = 總是選擇同一個端口

# 結果：所有流量都走同一路徑

如果用上layer3+4， 情況如下：
就因為iperf 使用-P 參數多線程打流，每個線程都會開一個新的端口，所以layer3+4 基於IP和端口的哈希，才能夠符合ipef多線程打流時候的要求，bond的速率也才能達到雙倍的速率。

連接1: A:5000 → B:80 → 哈希值1 → 端口0
連接2: A:5001 → B:80 → 哈希值2 → 端口1 ✅
連接3: A:5002 → B:443 → 哈希值3 → 端口0
連接4: A:5003 → B:443 → 哈希值4 → 端口1 ✅

修改哈希策略命令：

# 修改命令：
echo layer3+4 > /sys/class/net/bond0/bonding/xmit_hash_policy

各家交換機配置LACP命令都不太相同，具體可參考説明書。

總之，大多數場景都建議使用layer3+4，可以獲得更細粒度的負載均衡，特別適合現代的多連接應用環境

mode=5 (Balance-TLB) 自適應發送負載均衡

Mode=5​ 稱為自適應發送負載均衡，是一種智能的發送方向負載均衡方案。

# 1. 實時負載監控
持續監控：eth0的TX隊列長度、eth1的TX隊列長度...

# 2. 動態端口選擇
新連接到來 → 檢查各端口當前負載 → 選擇負載最低的端口

# 3. 會話保持
同一連接的所有數據包保持走同一端口（保證順序）

若是兩個網口綁定mode=5

發送方向（出口）：可以達到雙倍速率

接收方向（入口）：只能達到單倍速率

所以mode=5只適合出口流量為主的應用，例如文件下載服務器等。

Mode=6 (Balance-ALB) 自適應負載

Mode=6​ 稱為自適應負載均衡，是Mode=5的升級版，實現了雙向（發送+接收）負載均衡。

雙向負載均衡機制：

發送方向（同Mode=5）：基於實時負載智能分配


接收方向（新增）：通過ARP協商實現接收負載均衡
ARP協商 → 客户端學習不同MAC地址 → 接收流量分佈到多個端口

接受負載均衡使用了ARP協商機制，具體例子如下：

# 1. 客户端ARP查詢bond0的IP地址
客户端: "誰有192.168.1.100的MAC地址？"

# 2. Mode=6響應策略：
- 第一個ARP請求 → 回覆eth0的MAC地址
- 第二個ARP請求 → 回覆eth1的MAC地址  
- 後續請求 → 輪詢回覆不同端口的MAC地址

# 3. 客户端學習結果：
客户端1: 認為192.168.1.100的MAC是eth0的地址
客户端2: 認為192.168.1.100的MAC是eth1的地址


客户端A → 認為服務器MAC是eth0的地址 → 發送到eth0
客户端B → 認為服務器MAC是eth1的地址 → 發送到eth1
客户端C → 認為服務器MAC是eth0的地址 → 發送到eth0

結果：接收流量均衡分佈到多個端口 ✅

優點：

• 發送和接收方向都能利用多鏈路帶寬
• 無需配置交換機
• 自動適應流量模式變化

缺點：

• ARP協商和MAC地址管理有一定開銷
• 比Mode=4的性能稍差
• 某些網絡設備可能不兼容這種ARP行為

當企業有LACP交換機時，還是Mode=4為最優配置。

總結

沒有"最好"的模式，只有"最適合"當前環境和需求的模式！