Linux LACP 綑綁：設定、驗證與疑難排解

Linux LACP 綑綁技術可將多個乙太網路介面整合為單一邏輯鏈路，提供更高的總合頻寬，並在實體網卡之間實現自動故障轉移。此技術採用 IEEE 802.3ad 標準，由雙方（伺服器與交換器）協商決定哪些鏈路處於活躍狀態，以及流量如何分配。 本文將探討 LACP 的實際運作原理、何時應優先選用它而非其他 Linux 綑綁模式、如何在現代 Linux 伺服器上進行設定，以及如何驗證其運作狀態。

何謂鏈路聚合與 LACP？

鏈路聚合（Link aggregation）是將多個實體網路連線整合為單一邏輯通道的技術。其主要目的有二：提升鏈路群組的總可用頻寬，並在任何單一成員鏈路發生故障時提供自動故障轉移。

LACP（鏈路聚合控制協定）是 IEEE 802.3ad 標準所定義的動態鏈路聚合版本。與其依賴兩端的靜態配置，LACP 會在伺服器與交換機之間交換稱為 LACPDU 的控制封包。 雙方會協商哪些鏈路加入聚合，監控各鏈路的運作狀態，並根據狀況變化將成員加入或移出群組。

在 Linux 環境中，LACP 作為核心 bonding 驅動程式的模式 4（802.3ad）運行。該驅動程式會建立一個邏輯介面（通常 bond0) 來持有 IP 位址，而如 eth0 和 eth1 等物理介面則成為該綁定組的從屬成員。從作業系統的角度來看，僅存在一個網路介面；但從線路層面來看，則存在多個並行的乙太網路鏈路。

以下是 LACP 明確不做、但人們常有的幾項期待：

• 單一 TCP 連線仍僅透過一條實體鏈路傳輸。LACP 負責流量平衡，而非單一流量內的封包平衡。兩條綁定在一起的 1 GbE 鏈路，並不會讓單次下載速度超過 1 Gbps。
• LACP 需要支援 802.3ad 的交換器。若對接未受管或不支援 LACP 的交換器，將無法建立綁定。
• 所有成員鏈路必須以相同的速度和雙工模式運行。您無法將 1 GbE 埠與 10 GbE 埠進行綁定。

Linux 綁定模式：何時使用 LACP

Linux 綁定驅動程式支援七種模式。大多數生產環境部署僅採用其中三種。

模式 1：主動-備援

其中一個成員介面處於活躍狀態，其餘則處於閒置狀態。若活躍介面發生故障，另一介面將在數百毫秒內接管。此模式無需交換機配置，因此當交換機不在您的控制範圍內或不支援 802.3ad 時，這是最佳選擇。您將獲得冗餘性，但不會獲得額外的頻寬。

模式 4：802.3ad (LACP)

所有成員皆負責傳輸流量。綁定驅動程式與交換機透過 LACP 協商活躍成員集並偵測故障。出站流量會根據您設定的雜湊策略在成員間進行負載平衡。當您希望為多流量工作負載同時具備冗餘與額外頻寬時，這便是專用伺服器連接至受管交換機的標準選擇。

模式 6：balance-alb

雙向自適應負載平衡，無需交換機支援。驅動程式會攔截 ARP 回應以重寫 MAC 位址並分發傳入流量。此模式雖能運作，但相較於 LACP 較為脆弱。僅在確實無法配置交換機端時才應使用。

決策規則：

• 無管理型交換機，或僅需故障轉移：模式 1 (主動-備援)。
• 使用管理型交換機、多重流量，且需同時具備頻寬與冗餘：模式 4（LACP）。
• 無法使用管理型交換機，但需雙向負載平衡：模式 6（balance-alb）。

模式 0（平衡-RR）、2（平衡-XOR）、3（廣播）和 5（平衡-TLB）雖存在，但在現代硬體上極少是正確的選擇。除非有特定理由，否則請選擇模式 1 或模式 4。

在 Linux 上設定 LACP 綁定

在現代的 Ubuntu 和 Debian 系統上，LACP 是透過 netplan 進行設定。在 RHEL、CentOS Stream、AlmaLinux 和 Rocky Linux 上，請透過 NetworkManager 設定 nmcli 或直接編輯底層的連線設定檔。

Netplan（Ubuntu、Debian）

將以下內容放入 /etc/netplan/01-lacp.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    eth0:
      dhcp4: no
    eth1:
      dhcp4: no
  bonds:
    bond0:
      interfaces: [eth0, eth1]
      addresses: [10.0.0.5/24]
      gateway4: 10.0.0.1
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        mii-monitor-interval: 100
        transmit-hash-policy: layer3+4

然後使用 netplan apply。關鍵參數：

• mode: 802.3ad 啟用 LACP。
• lacp-rate: fast 每秒發送 LACPDU，而非預設的 30 秒。必須與交換機設定相符。
• mii-monitor-interval: 100 每 100 毫秒輪詢一次鏈路狀態。
• transmit-hash-policy: layer3+4 根據來源/目的地 IP 位址及 TCP/UDP 埠號分配流量。此設定能比預設 layer2 策略能提供更佳的負載平衡效果。

NetworkManager (RHEL、AlmaLinux、Rocky)

nmcli con add type bond ifname bond0 con-name bond0 \
  bond.options "mode=802.3ad,miimon=100,lacp_rate=fast,xmit_hash_policy=layer3+4"
nmcli con add type ethernet ifname eth0 master bond0
nmcli con add type ethernet ifname eth1 master bond0
nmcli con mod bond0 ipv4.addresses 10.0.0.5/24 ipv4.gateway 10.0.0.1 ipv4.method manual
nmcli con up bond0

交換機端

交換機需要一個設定為 LACP 主動模式的 LAG 群組（通常稱為埠通道），其成員埠數量須與綁定埠相同。 確切的語法因廠商而異，但要求是相同的：埠必須位於同一 VLAN 中，設定為相同的速度和雙工模式，並且至少在一側啟用 LACP 主動模式。兩側皆啟用主動模式是最安全的設定。

在 Cisco IOS 上：

interface range gigabitethernet0/1 - 2
 channel-group 1 mode active
 channel-protocol lacp

在 Aruba/ProCurve 上：

trunk 1-2 trk1 lacp

交換機上的 lacp_rate 設定必須與主機端一致。此處設定不符是 LACP 最常見的配置錯誤之一，會導致每 30 秒發生間歇性連線擺動。

驗證與排除 LACP 故障

在 Linux 端檢查綁定鏈路的即時狀態：

cat /proc/net/bonding/bond0

輸出結果中需注意以下四點：

1. Bonding Mode: IEEE 802.3ad Dynamic link aggregation 確認模式 4 已載入。
2. 每個從屬介面均以 MII Status: up ， link failure count: 0.
3. 每個從屬介面皆顯示 Partner Mac Address 。此處全為零表示交換機完全未傳送 LACP 封包，原因可能是該埠未位於 LACP 活躍的 LAG 中，或是纜線插錯埠。
4. Aggregator ID 在每個成員上都相同。ID 不同表示成員實際上並未組合，而是獨立運作。

驗證頻寬是否被使用的最快速方法，是執行 iperf3 並使用多個並行資料流（iperf3 -P 8) 從另一台主機執行 iperf3。若總吞吐量超過單一鏈路的容量，表示 LACP 正在正確地進行負載平衡。單一串流測試顯示單一鏈路的速率，屬於預期行為，並非錯誤。

最常見的 LACP 問題及其成因：

• 夥伴 MAC 位元組全為零：表示交換機埠未處於 LACP 活躍的 LAG 中，或纜線接錯。
• 綁定成功但吞吐量卡在單一鏈路上：哈希策略可能預設為 layer2，該設定僅根據目的 MAC 進行雜湊。請切換至 layer3+4.
• 每 30 秒間歇性閃爍： lacp_rate 主機與交換機設定不匹配。
• 其中一個從屬埠運作正常，但另一個從未傳輸流量：傳輸速率/雙工模式不匹配，或交換機端面的埠未位於同一個 LAG 群組中。

當 LACP 並非最佳解決方案時

LACP 旨在解決特定問題：將單一主機與單一交換機（或單一交換機堆疊）之間的多條鏈路進行聚合，以實現冗餘與按流量分配的頻寬。但在某些情境下，它並非最佳解決方案。

若您僅需冗餘功能，且交換機不支援 802.3ad 標準，請改用模式 1（主動-備用）。此模式適用於任何設備。

若需跨兩個獨立交換器進行機箱級冗餘，標準 LACP 無法串聯兩個互不相關的交換器。 此時您需要使用多機箱鏈路聚合（MLAG），讓兩台交換機以單一邏輯 LACP 夥伴的身分呈現。多數企業級交換機廠商皆以自有名稱實現此功能：例如 Cisco vPC、Arista MLAG、Juniper MC-LAG。

若需單一流量超過單一鏈路的頻寬，LACP 無法達成此目標。解決方案包括使用更快的實體鏈路（將 2 條 10 GbE 替換為 1 條 25 GbE 或 1 條 40 GbE），或是改用完全不同的技術。 SR-IOV 透過為每台虛擬機器提供硬體加速的虛擬網路介面卡，為虛擬機器提供接近線速的單一流量效能，但它解決的是不同的問題，且有其自身的限制。這將是另一篇文章的討論主題。

對於處理大量並發連線的多數專用伺服器與託管伺服器而言，LACP 仍是標準解決方案。兩條綁定後的 10 GbE 鏈路搭配 layer3+4 散列技術，不僅能輕鬆處理橫跨多條流量流的 18+ Gbps 總流量，還能承受網卡或纜線故障，且不會丟失任何封包。