Linux 乙太網繫結驅動程式 HOWTO

最新更新：2011 年 4 月 27 日

初始版本：Thomas Davis <tadavis at lbl.gov>

更正，HA 擴充套件：2000/10/03-15

  • Willy Tarreau <willy at meta-x.org>

  • Constantine Gavrilov <const-g at xpert.com>

  • Chad N. Tindel <ctindel at ieee dot org>

  • Janice Girouard <girouard at us dot ibm dot com>

  • Jay Vosburgh <fubar at us dot ibm dot com>

2005 年 2 月由 Jay Vosburgh 重組和更新 新增 Sysfs 資訊：2006/04/24

  • Mitch Williams <mitch.a.williams at intel.com>

簡介

Linux 繫結驅動程式提供了一種將多個網路介面聚合到單個邏輯“繫結”介面中的方法。繫結介面的行為取決於模式；一般來說，模式提供熱備或負載平衡服務。此外，還可以執行鏈路完整性監控。

繫結驅動程式最初來自 Donald Becker 的 beowulf 補丁，用於核心 2.0。自那以後，它發生了很大變化，來自 extreme-linux 和 beowulf 站點的原始工具將無法與此版本的驅動程式一起使用。

有關驅動程式的新版本、更新的使用者空間工具以及向誰尋求幫助，請關注本文件末尾的連結。

1. 繫結驅動程式安裝

大多數流行的發行版核心都附帶了繫結驅動程式，它已經作為一個模組可用。如果你的發行版沒有，或者你需要從原始碼編譯繫結（例如，從 kernel.org 配置和安裝主線核心），你需要執行以下步驟

1.1 配置並構建帶有繫結的核心

當前版本的繫結驅動程式位於最新核心原始碼的 drivers/net/bonding 子目錄中（可在 https://kernel.linux.club.tw 上獲得）。大多數“自己動手”的使用者都希望使用來自 kernel.org 的最新核心。

使用“make menuconfig”（或“make xconfig”或“make config”）配置核心，然後在“網路裝置支援”部分選擇“繫結驅動程式支援”。建議將驅動程式配置為模組，因為它是目前將引數傳遞給驅動程式或配置多個繫結裝置的唯一方法。

構建並安裝新的核心和模組。

1.2 繫結控制實用程式

建議透過 iproute2 (netlink) 或 sysfs 配置繫結，舊的 ifenslave 控制實用程式已過時。

2. 繫結驅動程式選項

繫結驅動程式的選項在載入時作為引數提供給繫結模組，或者透過 sysfs 指定。

模組選項可以作為命令列引數傳遞給 insmod 或 modprobe 命令，但通常在 /etc/modprobe.d/*.conf 配置檔案中指定，或者在特定於發行版的配置檔案中指定（其中一些將在下一節中詳細介紹）。

有關 sysfs 的繫結支援的詳細資訊，請參見下面的“透過 Sysfs 手動配置繫結”部分。

下面列出了可用的繫結驅動程式引數。如果未指定引數，則使用預設值。在最初配置繫結時，建議在單獨的視窗中執行“tail -f /var/log/messages”以監視繫結驅動程式錯誤訊息。

至關重要的是，必須指定 miimon 或 arp_interval 和 arp_ip_target 引數，否則在鏈路故障期間會發生嚴重的網路降級。很少有裝置不支援至少 miimon，因此實際上沒有理由不使用它。

具有文字值的選項將接受文字名稱或（為了向後相容）選項值。例如，“mode=802.3ad”和“mode=4”設定相同的模式。

引數如下

active_slave

指定支援它的模式的新活動從裝置（active-backup、balance-alb 和 balance-tlb）。可能的值是任何當前已從屬介面的名稱，或空字串。如果給出了名稱，則從裝置及其鏈路必須處於 up 狀態才能被選為新的活動從裝置。如果指定了空字串，則當前活動從裝置將被清除，並且會自動選擇新的活動從裝置。

請注意，這隻能透過 sysfs 介面獲得。不存在以此名稱命名的模組引數。

此選項的正常值是當前活動從裝置的名稱，如果沒有活動從裝置或當前模式不使用活動從裝置，則為空字串。

ad_actor_sys_prio

在 AD 系統中，這指定了系統優先順序。允許的範圍是 1 - 65535。如果未指定該值，則預設值為 65535。

此引數僅在 802.3ad 模式下有效，並且可以透過 SysFs 介面獲得。

ad_actor_system

在 AD 系統中，這指定了協議資料包交換 (LACPDUs) 中參與者的 mac 地址。該值不能是多播地址。如果指定了全零 MAC，則繫結將在內部使用繫結本身的 MAC。最好為此 mac 設定本地管理位，但驅動程式不強制執行。如果未給出該值，則系統預設使用主伺服器的 mac 地址作為參與者的系統地址。

此引數僅在 802.3ad 模式下有效，並且可以透過 SysFs 介面獲得。

ad_select

指定要使用的 802.3ad 聚合選擇邏輯。可能的值及其效果是

stable 或 0

活動聚合器由最大聚合頻寬選擇。

只有當活動聚合器的所有從裝置都關閉或活動聚合器沒有從裝置時，才會重新選擇活動聚合器。

這是預設值。

bandwidth 或 1

活動聚合器由最大聚合頻寬選擇。如果發生以下情況，則會發生重新選擇

  • 從裝置已新增到繫結或從繫結中刪除

  • 任何從裝置的鏈路狀態更改

  • 任何從裝置的 802.3ad 關聯狀態更改

  • 繫結的管理狀態更改為 up

count 或 2

活動聚合器由最大埠（從裝置）數選擇。重新選擇的發生方式與上面的“頻寬”設定下描述的相同。

頻寬和計數選擇策略允許在活動聚合器發生部分故障時進行 802.3ad 聚合的故障轉移。這使得具有最高可用性（在頻寬或埠數方面）的聚合器始終處於活動狀態。

此選項已新增到繫結版本 3.4.0 中。

ad_user_port_key

在 AD 系統中，埠金鑰有三個部分，如下所示 -

位

用途

00

雙工

01-05

速度

06-15

使用者定義

這定義了埠金鑰的最高 10 位。這些值可以從 0 到 1023。如果未給出，則系統預設為 0。

此引數僅在 802.3ad 模式下有效，並且可以透過 SysFs 介面獲得。

all_slaves_active

指定是否應刪除（0）或傳遞（1）重複幀（在非活動埠上接收）。

通常，繫結將刪除重複幀（在非活動埠上接收），這對於大多數使用者來說是理想的。但有時允許傳遞重複幀是很好的。

預設值為 0（刪除在非活動埠上接收的重複幀）。

arp_interval

指定 ARP 鏈路監控頻率（以毫秒為單位）。

ARP 監控的工作原理是定期檢查從裝置，以確定它們最近是否已傳送或接收流量（精確的標準取決於繫結模式和從裝置的狀態）。常規流量是透過為 arp_ip_target 選項指定的地址發出的 ARP 探測生成的。

此行為可以透過下面的 arp_validate 選項修改。

如果在以太通道相容模式（模式 0 和 2）中使用 ARP 監控，則應將交換機配置為以均勻的方式跨所有鏈路分配資料包的模式。如果交換機配置為以 XOR 方式分配資料包，則來自 ARP 目標的所有回覆將在同一鏈路上接收，這可能會導致其他組成員失敗。ARP 監控不應與 miimon 結合使用。值為 0 會停用 ARP 監控。預設值為 0。

arp_ip_target

當 arp_interval > 0 時，指定要用作 ARP 監控對等方的 IP 地址。這些是要傳送的 ARP 請求的目標，用於確定到目標的鏈路的執行狀況。以 ddd.ddd.ddd.ddd 格式指定這些值。多個 IP 地址必須用逗號分隔。必須至少給出一個 IP 地址才能使 ARP 監控正常工作。可以指定的最大目標數為 16。預設值為沒有 IP 地址。

ns_ip6_target

當 arp_interval > 0 時，指定要用作 IPv6 監控對等方的 IPv6 地址。這些是要傳送的 NS 請求的目標，用於確定到目標的鏈路的執行狀況。以 ffff:ffff::ffff:ffff 格式指定這些值。多個 IPv6 地址必須用逗號分隔。必須至少給出一個 IPv6 地址才能使 NS/NA 監控正常工作。可以指定的最大目標數為 16。預設值為沒有 IPv6 地址。

arp_validate

指定是否應在支援 arp 監控的任何模式下驗證 ARP 探測和回覆，或者是否應過濾（忽略）非 ARP 流量以進行鏈路監控。

可能的值是

none 或 0

不執行驗證或過濾。

active 或 1

僅對活動從裝置執行驗證。

backup 或 2

僅對備份從裝置執行驗證。

all 或 3

對所有從裝置執行驗證。

filter 或 4

過濾應用於所有從裝置。不執行驗證。

filter_active 或 5

過濾應用於所有從裝置，驗證僅對活動從裝置執行。

filter_backup 或 6

過濾應用於所有從裝置，驗證僅對備份從裝置執行。

驗證

啟用驗證會導致 ARP 監控檢查傳入的 ARP 請求和回覆，並且僅當從裝置接收到相應的 ARP 流量時才認為從裝置處於 up 狀態。

對於活動從裝置，驗證會檢查 ARP 回覆以確認它們是由 arp_ip_target 生成的。由於備份從裝置通常不會接收這些回覆，因此對備份從裝置執行的驗證是在透過活動從裝置傳送的廣播 ARP 請求上進行的。某些交換機或網路配置可能會導致備份從裝置未收到 ARP 請求的情況；在這種情況下，必須停用備份從裝置的驗證。

備份從裝置上 ARP 請求的驗證主要幫助繫結確定哪些從裝置在活動從裝置發生故障時更有可能工作，它實際上並不能保證備份從裝置在被選為下一個活動從裝置時會工作。

驗證在多個繫結主機同時向公共交換機之外的一個或多個目標發出 ARP 的網路配置中很有用。如果交換機和目標之間的鏈路發生故障（但交換機本身沒有發生故障），則多個繫結例項生成的探測流量將欺騙標準 ARP 監控認為鏈路仍然處於 up 狀態。使用驗證可以解決此問題，因為 ARP 監控只會考慮與其自身繫結例項關聯的 ARP 請求和回覆。

過濾

啟用過濾會導致 ARP 監控僅使用傳入的 ARP 資料包來確定鏈路可用性。到達的不是 ARP 的資料包將正常傳遞，但在確定從裝置是否可用時不計數。

過濾的工作原理是僅考慮接收 ARP 資料包（任何 ARP 資料包，無論源或目標如何）來確定從裝置是否已接收到流量以用於鏈路可用性目的。

過濾在大量第三方廣播流量會欺騙標準 ARP 監控認為鏈路仍然處於 up 狀態的網路配置中很有用。使用過濾可以解決此問題，因為僅考慮 ARP 流量用於鏈路可用性目的。

此選項已新增到繫結版本 3.1.0 中。

arp_all_targets

指定為了使 ARP 監控認為從裝置處於 up 狀態，必須可訪問的 arp_ip_targets 的數量。此選項僅影響啟用 arp_validation 的從裝置的 active-backup 模式。

可能的值是

any 或 0

僅當任何 arp_ip_targets 可訪問時才認為從裝置處於 up 狀態

all 或 1

僅當所有 arp_ip_targets 都可訪問時才認為從裝置處於 up 狀態

arp_missed_max

指定為了使介面被 ARP 監控標記為 down 狀態，必須失敗的 arp_interval 監控檢查的數量。

為了提供有序的故障轉移語義，允許備份介面進行額外的監控檢查（即，在被標記為 down 狀態之前，它們必須失敗 arp_missed_max + 1 次）。

預設值為 2，允許的範圍為 1 - 255。

coupled_control

指定 LACP 狀態機的 MUX 在 802.3ad 模式下是否應具有單獨的收集和分發狀態。

這是透過除了現有的耦合控制狀態機之外，還根據 IEEE 802.1AX-2008 5.4.15 實現獨立的控制狀態機來實現的。

預設值為 1。此設定不分離收集和分發狀態，從而將繫結保持在耦合控制狀態。

downdelay

指定檢測到鏈路故障後等待停用從裝置的時間（以毫秒為單位）。此選項僅對 miimon 鏈路監控有效。downdelay 值應為 miimon 值的倍數；如果不是，它將被向下舍入到最接近的倍數。預設值為 0。

fail_over_mac

指定 active-backup 模式是否應在從屬時將所有從裝置設定為相同的 MAC 地址（傳統行為），或者，在啟用時，根據所選策略執行對繫結 MAC 地址的特殊處理。

可能的值是

none 或 0

none 或 0

active 或 1

“active”fail_over_mac 策略指示繫結的 MAC 地址應始終是當前活動從裝置的 MAC 地址。從裝置的 MAC 地址不會更改；相反，繫結的 MAC 地址在故障轉移期間會更改。

此策略對於永遠無法更改其 MAC 地址的裝置，或者對於拒絕傳入具有其自身源 MAC 的廣播（這會干擾 ARP 監控）的裝置很有用。

此策略的缺點是，網路上的每個裝置都必須透過 gratuitous ARP 進行更新，而不是僅更新交換機或一組交換機（如果交換機透過偵聽傳入流量來更新其表，則通常對任何流量（而不僅僅是 ARP 流量）進行此操作），從而採用傳統方法。如果 gratuitous ARP 丟失，則通訊可能會中斷。

當此策略與 mii 監控器結合使用時，在能夠實際傳送和接收之前宣告鏈路 up 狀態的裝置特別容易丟失 gratuitous ARP，並且可能需要適當的 updelay 設定。

follow 或 2

“follow”fail_over_mac 策略會導致正常選擇繫結的 MAC 地址（通常是新增到繫結的第一個從裝置的 MAC 地址）。但是，當從裝置處於備份角色時，不會將第二個和後續從裝置設定為此 MAC 地址；從裝置在故障轉移時（以及以前活動的從裝置接收新活動從裝置的 MAC 地址）使用繫結的 MAC 地址進行程式設計。

此策略對於多埠裝置很有用，這些裝置在多個埠使用相同的 MAC 地址程式設計時會變得混亂或導致效能下降。

預設策略為 none，除非第一個從裝置無法更改其 MAC 地址，在這種情況下，預設情況下會選擇 active 策略。

僅當繫結中不存在從裝置時，才能透過 sysfs 修改此選項。

此選項已新增到繫結版本 3.2.0 中。“follow”策略已新增到繫結版本 3.3.0 中。

lacp_active

指定是否定期傳送 LACPDU 幀的選項。

off 或 0

LACPDU 幀充當“在被告知時說話”。

on 或 1

LACPDU 幀定期沿配置的鏈路傳送。有關更多詳細資訊，請參見 lacp_rate。

預設值為 on。

lacp_rate

指定我們要求鏈路合作伙伴以 802.3ad 模式傳輸 LACPDU 資料包的速率的選項。可能的值是

slow 或 0

請求合作伙伴每 30 秒傳輸一次 LACPDUs

fast 或 1

請求合作伙伴每 1 秒傳輸一次 LACPDUs

預設值為 slow。

max_bonds

指定為此繫結驅動程式例項建立的繫結裝置數。例如，如果 max_bonds 為 3，並且尚未載入繫結驅動程式，則將建立 bond0、bond1 和 bond2。預設值為 1。指定值 0 將載入繫結，但不會建立任何裝置。

miimon

指定 MII 鏈路監控頻率（以毫秒為單位）。這確定了檢查每個從裝置的鏈路狀態以查詢鏈路故障的頻率。值為零會停用 MII 鏈路監控。值 100 是一個好的起點。下面的 use_carrier 選項會影響鏈路狀態的確定方式。有關更多資訊，請參見高可用性部分。如果未設定 arp_interval，則預設值為 100。

min_links

指定在宣告載波之前必須處於活動狀態的最小鏈路數。它類似於 Cisco EtherChannel min-links 功能。這允許設定必須處於 up 狀態（鏈路 up 狀態）的最小成員埠數，然後才能將繫結裝置標記為 up 狀態（載波 on）。這對於更高級別的服務（如群集）希望確保在切換之前至少有最低數量的低頻寬鏈路處於活動狀態的情況很有用。此選項僅影響 802.3ad 模式。

預設值為 0。這將導致在存在活動聚合器時（對於 802.3ad 模式）宣告載波，而不管該聚合器中可用鏈路的數量如何。請注意，由於聚合器在沒有至少一條可用鏈路的情況下無法處於活動狀態，因此將此選項設定為 0 或 1 具有完全相同的效果。

mode

指定繫結策略之一。預設值為 balance-rr（迴圈）。可能的值是

balance-rr 或 0

迴圈策略：按順序從第一個可用從裝置到最後一個可用從裝置傳輸資料包。此模式提供負載平衡和容錯。

active-backup 或 1

活動-備份策略：繫結中只有一個從裝置處於活動狀態。只有在活動從裝置發生故障時，另一個從裝置才會變為活動狀態。繫結的 MAC 地址僅在一個埠（網路介面卡）上外部可見，以避免混淆交換機。

在繫結版本 2.6.2 或更高版本中，當在 active-backup 模式下發生故障轉移時，繫結將在新活動的從裝置上發出一個或多個 gratuitous ARP。為繫結主介面和配置在其上的每個 VLAN 介面發出一個 gratuitous ARP，前提是該介面配置了至少一個 IP 地址。為 VLAN 介面發出的 Gratuitous ARP 帶有適當的 VLAN id 標記。

此模式提供容錯。下面記錄的 primary 選項會影響此模式的行為。

balance-xor 或 2

XOR 策略：基於所選的傳輸雜湊策略進行傳輸。預設策略是一個簡單的 [(源 MAC 地址 XOR 目標 MAC 地址 XOR 資料包型別 ID) 模從裝置計數]。可以透過下面描述的 xmit_hash_policy 選項選擇備用傳輸策略。

此模式提供負載平衡和容錯。

broadcast 或 3

廣播策略：在所有從屬介面上傳輸所有內容。此模式提供容錯。

802.3ad 或 4

IEEE 802.3ad 動態鏈路聚合。建立共享相同速度和雙工設定的聚合組。根據 802.3ad 規範利用活動聚合器中的所有從裝置。

傳出流量的從裝置選擇是根據傳輸雜湊策略完成的，可以透過下面記錄的 xmit_hash_policy 選項從預設的簡單 XOR 策略進行更改。請注意，並非所有傳輸策略都符合 802.3ad，尤其是在 802.3ad 標準的 43.2.4 節中關於資料包錯誤排序要求方面。不同的對等實現對不合規性的容忍度各不相同。

先決條件

1. 用於檢索每個從裝置的速度和雙工的基本驅動程式中的 Ethtool 支援。

2. 支援 IEEE 802.3ad 動態鏈路聚合的交換機。

大多數交換機都需要某種型別的配置才能啟用 802.3ad 模式。

balance-tlb 或 5

自適應傳輸負載平衡：不需要任何特殊交換機支援的通道繫結。

在 tlb_dynamic_lb=1 模式下；傳出流量根據每個從裝置上的當前負載（相對於速度計算）進行分配。

在 tlb_dynamic_lb=0 模式下；基於當前負載的負載平衡被停用，負載僅使用雜湊分佈進行分配。

傳入流量由當前從裝置接收。如果接收從裝置發生故障，則另一個從裝置會接管發生故障的接收從裝置的 MAC 地址。

先決條件

基本驅動程式中的 Ethtool 支援，用於檢索每個從裝置的速度。

balance-alb 或 6

自適應負載平衡：包括 balance-tlb 加上用於 IPV4 流量的接收負載平衡 (rlb)，並且不需要任何特殊交換機支援。接收負載平衡是透過 ARP 協商實現的。繫結驅動程式會攔截本地系統發出的 ARP 回覆，並在其傳輸出去時使用繫結中其中一個從裝置的唯一硬體地址覆蓋源硬體地址，以便不同的對等方為伺服器使用不同的硬體地址。

來自伺服器建立的連線的接收流量也會進行平衡。當本地系統傳送 ARP 請求時，繫結驅動程式會複製並儲存 ARP 資料包中的對等方 IP 資訊。當 ARP 回覆從對等方到達時，將檢索其硬體地址，並且繫結驅動程式會啟動對該對等方的 ARP 回覆，將其分配給繫結中的其中一個從裝置。使用 ARP 協商進行平衡的一個有問題的結果是，每次廣播 ARP 請求時，它都會使用繫結的硬體地址。因此，對等方會學習繫結的硬體地址，並且接收流量的平衡會崩潰到當前從裝置。這可以透過向所有對等方傳送更新（ARP 回覆）以及它們各自分配的硬體地址來處理，以便重新分配流量。當向繫結新增新的從裝置以及重新啟用非活動從裝置時，也會重新分配接收流量。接收負載在繫結中速度最高的從裝置組中按順序（迴圈）分配。

當鏈路重新連線或新的從裝置加入繫結時，透過啟動帶有選定 MAC 地址的 ARP 回覆給每個客戶端，從而在繫結中的所有活動從裝置之間重新分配接收流量。updelay 引數（下面詳細介紹）必須設定為等於或大於交換機的轉發延遲的值，以便傳送給對等方的 ARP 回覆不會被交換機阻止。

先決條件

1. 基本驅動程式中的 Ethtool 支援，用於檢索每個從裝置的速度。

2. 基本驅動程式支援在裝置開啟時設定裝置的硬體地址。這是必需的，以便始終有一個團隊中的從裝置使用繫結硬體地址（curr_active_slave），同時為繫結中的每個從裝置提供唯一的硬體地址。如果 curr_active_slave 發生故障，其硬體地址將與選擇的新 curr_active_slave 交換。

num_grat_arp, num_unsol_na

指定在故障轉移事件後要發出的對等方通知（gratuitous ARP 和 unsolicited IPv6 Neighbor Advertisements）的數量。一旦新從裝置上的鏈路啟動（可能立即），就會在繫結裝置和每個 VLAN 子裝置上傳送對等方通知。如果數字大於 1，則以 peer_notif_delay 指定的速率重複此操作。

有效範圍為 0 - 255；預設值為 1。這些選項僅影響 active-backup 模式。這些選項分別針對繫結版本 3.3.0 和 3.4.0 新增。

從 Linux 3.0 和繫結版本 3.7.1 開始，這些通知由 ipv4 和 ipv6 程式碼生成，並且重複次數無法獨立設定。

packets_per_slave

指定在移動到下一個從裝置之前要透過從裝置傳輸的資料包數。設定為 0 時，將隨機選擇一個從裝置。

有效範圍為 0 - 65535；預設值為 1。此選項僅在 balance-rr 模式下有效。

peer_notif_delay

指定在故障轉移事件後發出每個對等方通知（gratuitous ARP 和 unsolicited IPv6 Neighbor Advertisements）之間的延遲（以毫秒為單位）。此延遲應為 MII 鏈路監控間隔 (miimon) 的倍數。

有效範圍為 0 - 300000。預設值為 0，這意味著與 MII 鏈路監控間隔的值匹配。

prio

從裝置優先順序。數字越大表示優先順序越高。主從裝置具有最高優先順序。此選項也遵循 primary_reselect 規則。

此選項只能透過 netlink 進行配置，並且僅對 active-backup(1)、balance-tlb (5) 和 balance-alb (6) 模式有效。有效值範圍是有符號的 32 位整數。

預設值為 0。

primary

一個字串（eth0、eth2 等），指定哪個從裝置是主裝置。指定的裝置只要可用，就將始終是活動從裝置。只有當主裝置離線時才會使用備用裝置。當一個從裝置優於另一個從裝置時，這很有用，例如，當一個從裝置比另一個從裝置具有更高的吞吐量時。

primary 選項僅對 active-backup(1)、balance-tlb (5) 和 balance-alb (6) 模式有效。

primary_reselect

指定主從裝置的重新選擇策略。這會影響在活動從裝置發生故障或主從裝置恢復時如何選擇主從裝置成為活動從裝置。此選項旨在防止主從裝置和其他從裝置之間出現來回切換。可能的值是

always 或 0（預設）

主從裝置在恢復聯機時成為活動從裝置。

better 或 1

如果主從裝置的速度和雙工優於當前活動從裝置的速度和雙工，則主從裝置在恢復聯機時成為活動從裝置。

failure 或 2

僅噹噹前活動從裝置發生故障且主從裝置處於聯機狀態時，主從裝置才會成為活動從裝置。

在以下兩種情況下，primary_reselect 設定將被忽略

如果沒有從裝置處於活動狀態，則第一個恢復的從裝置將成為活動從裝置。

最初從屬時，主從裝置始終成為活動從裝置。

透過 sysfs 更改 primary_reselect 策略將導致根據新策略立即選擇最佳活動從裝置。根據情況，這可能會或可能不會導致活動從裝置的更改。

此選項已新增到繫結版本 3.6.0 中。

tlb_dynamic_lb

指定是否在 tlb 或 alb 模式下啟用流的動態混排。該值對任何其他模式均無效。

tlb 模式的預設行為是在該間隔內基於負載在從裝置之間混排活動流。這提供了良好的 lb 特性，但可能會導致資料包重新排序。如果重新排序是一個問題，請使用此變數來停用流混排，並且僅依賴於雜湊分佈提供的負載平衡。xmit-hash-policy 可用於選擇設定的適當雜湊。

sysfs 條目可用於更改每個繫結裝置的設定，初始值來自模組引數。僅當繫結裝置處於關閉狀態時，才允許更改 sysfs 條目。

預設值為“1”，表示啟用流混排，而值“0”表示停用它。此選項已新增到繫結驅動程式 3.7.1 中

updelay

指定檢測到鏈路恢復後等待啟用從裝置的時間（以毫秒為單位）。此選項僅對 miimon 鏈路監控有效。updelay 值應為 miimon 值的倍數；如果不是，它將被向下舍入到最接近的倍數。預設值為 0。

use_carrier

指定 miimon 是否應使用 MII 或 ETHTOOL ioctl 與 netif_carrier_ok() 來確定鏈路狀態。MII 或 ETHTOOL ioctl 效率較低，並且在核心中使用了已棄用的呼叫序列。netif_carrier_ok() 依賴於裝置驅動程式來使用 netif_carrier_on/off 維護其狀態；在撰寫本文時，大多數（但並非全部）裝置驅動程式都支援此功能。

如果 bonding 堅持鏈路處於活動狀態，但實際上不應該如此，那麼可能是您的網路裝置驅動程式不支援 netif_carrier_on/off。netif_carrier 的預設狀態是“carrier on”，因此如果驅動程式不支援 netif_carrier，則鏈路將始終顯示為活動狀態。在這種情況下，將 use_carrier 設定為 0 將導致 bonding 恢復為使用 MII / ETHTOOL ioctl 方法來確定鏈路狀態。

值為 1 表示啟用 netif_carrier_ok() 的使用，值為 0 將使用已棄用的 MII / ETHTOOL ioctl。預設值為 1。

xmit_hash_policy

選擇用於 balance-xor、802.3ad 和 tlb 模式下從裝置選擇的傳輸雜湊策略。可能的值包括

layer2

使用硬體 MAC 地址和資料包型別 ID 欄位的異或來生成雜湊。公式為

hash = 源 MAC[5] XOR 目標 MAC[5] XOR 資料包型別 ID slave number = hash 模從裝置計數

此演算法會將所有到特定網路對等方的流量放在同一從裝置上。

此演算法符合 802.3ad 標準。

layer2+3

此策略使用 layer2 和 layer3 協議資訊的組合來生成雜湊。

使用硬體 MAC 地址和 IP 地址的異或來生成雜湊。公式為

hash = 源 MAC[5] XOR 目標 MAC[5] XOR 資料包型別 ID hash = hash XOR 源 IP XOR 目標 IP hash = hash XOR (hash RSHIFT 16) hash = hash XOR (hash RSHIFT 8) 然後將雜湊值對從裝置計數進行模運算。

如果協議是 IPv6，則首先使用 ipv6_addr_hash 對源地址和目標地址進行雜湊處理。

此演算法會將所有到特定網路對等方的流量放在同一從裝置上。對於非 IP 流量，該公式與 layer2 傳輸雜湊策略的公式相同。

此策略旨在提供比單獨 layer2 更平衡的流量分配，尤其是在需要 layer3 閘道器裝置才能到達大多數目標的環境中。

此演算法符合 802.3ad 標準。

layer3+4

此策略在可用時使用上層協議資訊來生成雜湊。這允許到特定網路對等方的流量跨越多個從裝置，但單個連線不會跨越多個從裝置。

未分片的 TCP 和 UDP 資料包的公式為

hash = 源埠，目標埠（如標頭中所示） hash = hash XOR 源 IP XOR 目標 IP hash = hash XOR (hash RSHIFT 16) hash = hash XOR (hash RSHIFT 8) hash = hash RSHIFT 1 然後將雜湊值對從裝置計數進行模運算。

如果協議是 IPv6，則首先使用 ipv6_addr_hash 對源地址和目標地址進行雜湊處理。

對於分片的 TCP 或 UDP 資料包以及所有其他 IPv4 和 IPv6 協議流量，將省略源埠和目標埠資訊。對於非 IP 流量，該公式與 layer2 傳輸雜湊策略的公式相同。

此演算法不完全符合 802.3ad 標準。包含分片和未分片資料包的單個 TCP 或 UDP 會話將看到資料包跨越兩個介面條帶化。這可能會導致亂序交付。大多數流量型別都不會滿足此標準，因為 TCP 很少分片流量，並且大多數 UDP 流量不涉及擴充套件會話。802.3ad 的其他實現可能會或可能不會容忍此不合規行為。

encap2+3

此策略使用與 layer2+3 相同的公式，但它依賴於 skb_flow_dissect 來獲取標頭欄位，如果使用封裝協議，這可能會導致內部標頭的使用。例如，這將提高隧道使用者的效能，因為資料包將根據封裝的流進行分配。

encap3+4

此策略使用與 layer3+4 相同的公式，但它依賴於 skb_flow_dissect 來獲取標頭欄位，如果使用封裝協議，這可能會導致內部標頭的使用。例如，這將提高隧道使用者的效能，因為資料包將根據封裝的流進行分配。

vlan+srcmac

此策略使用非常基本的 vlan ID 和源 mac 雜湊來按 vlan 平衡流量，並在一條鏈路發生故障時進行故障轉移。預期的用例是多個虛擬機器共享的繫結，所有虛擬機器都配置為使用自己的 vlan，以提供類似 lacp 的功能，而無需支援 lacp 的交換硬體。

雜湊公式很簡單

hash = (vlan ID) XOR (源 MAC 供應商) XOR (源 MAC dev)

預設值為 layer2。此選項在 bonding 版本 2.6.3 中新增。在 bonding 的早期版本中，此引數不存在，並且 layer2 策略是唯一的策略。layer2+3 值是為 bonding 版本 3.2.2 新增的。

resend_igmp

指定在故障轉移事件後要發出的 IGMP 成員資格報告的數量。在故障轉移後立即發出一個成員資格報告，後續資料包以每 200 毫秒的間隔傳送。

有效範圍是 0 - 255；預設值為 1。值為 0 可防止 IGMP 成員資格報告響應故障轉移事件而發出。

此選項對於 bonding 模式 balance-rr (0)、active-backup (1)、balance-tlb (5) 和 balance-alb (6) 很有用，在這些模式中，故障轉移可以將 IGMP 流量從一個從裝置切換到另一個從裝置。因此，必須發出新的 IGMP 報告，以使交換機透過新選擇的從裝置轉發傳入的 IGMP 流量。

此選項是為 bonding 版本 3.7.0 新增的。

lp_interval

指定 bonding 驅動程式向每個從裝置的對等交換機發送學習資料包的例項之間的時間間隔（秒）。

有效範圍是 1 - 0x7fffffff；預設值為 1。此選項僅在 balance-tlb 和 balance-alb 模式下有效。

3. 配置 Bonding 裝置

您可以使用發行版的網路初始化指令碼配置 bonding，也可以使用 iproute2 或 sysfs 介面手動配置。發行版通常使用以下三個包之一來建立網路初始化指令碼：initscripts、sysconfig 或 interfaces。這些包的最新版本支援 bonding，而舊版本不支援。

我們將首先描述使用完整或部分支援 bonding 的 initscripts、sysconfig 和 interfaces 版本的發行版的 bonding 配置選項，然後提供有關在沒有網路初始化指令碼支援的情況下啟用 bonding 的資訊（即，initscripts 或 sysconfig 的舊版本）。

如果您不確定您的發行版使用的是 sysconfig、initscripts 還是 interfaces，或者不知道它是否足夠新，請不要擔心。確定這一點非常簡單。

首先，在 /etc/network 目錄中查詢名為 interfaces 的檔案。如果您的系統中存在此檔案，則您的系統使用 interfaces。請參閱使用 Interfaces 支援進行配置。

否則，請發出命令

$ rpm -qf /sbin/ifup

它將響應以“initscripts”或“sysconfig”開頭的文字行，後跟一些數字。這是提供您的網路初始化指令碼的包。

接下來，要確定您的安裝是否支援 bonding，請發出命令

$ grep ifenslave /sbin/ifup

如果這返回任何匹配項，則您的 initscripts 或 sysconfig 支援 bonding。

3.1 使用 Sysconfig 支援進行配置

本節適用於使用帶有 bonding 支援的 sysconfig 版本的發行版，例如，SuSE Linux Enterprise Server 9。

SuSE SLES 9 的網路配置系統確實支援 bonding，但是，在撰寫本文時，YaST 系統配置前端不提供任何使用 bonding 裝置的方法。但是，可以手動管理 bonding 裝置，如下所示。

首先，如果尚未配置從裝置，請配置它們。在 SLES 9 上，最簡單的方法是執行 yast2 sysconfig 配置實用程式。目標是為每個從裝置建立一個 ifcfg-id 檔案。完成此操作的最簡單方法是將裝置配置為 DHCP（這只是為了建立 ifcfg-id 檔案；有關 DHCP 的一些問題，請參見下文）。每個裝置的配置檔名將採用以下形式

ifcfg-id-xx:xx:xx:xx:xx:xx

其中“xx”部分將被裝置的永久 MAC 地址中的數字替換。

建立 ifcfg-id-xx:xx:xx:xx:xx:xx 檔案集後，有必要編輯從裝置的配置檔案（MAC 地址對應於從裝置的 MAC 地址）。在編輯之前，該檔案將包含多行，並且看起來像這樣

BOOTPROTO='dhcp'
STARTMODE='on'
USERCTL='no'
UNIQUE='XNzu.WeZGOGF+4wE'
_nm_name='bus-pci-0001:61:01.0'

將 BOOTPROTO 和 STARTMODE 行更改為以下內容

BOOTPROTO='none'
STARTMODE='off'

不要更改 UNIQUE 或 _nm_name 行。刪除任何其他行（USERCTL 等）。

修改 ifcfg-id-xx:xx:xx:xx:xx:xx 檔案後，就可以為 bonding 裝置本身建立配置檔案了。此檔名為 ifcfg-bondX，其中 X 是要建立的 bonding 裝置的編號，從 0 開始。第一個此類檔案是 ifcfg-bond0，第二個是 ifcfg-bond1，依此類推。sysconfig 網路配置系統將正確啟動 bonding 的多個例項。

ifcfg-bondX 檔案的內容如下

BOOTPROTO="static"
BROADCAST="10.0.2.255"
IPADDR="10.0.2.10"
NETMASK="255.255.0.0"
NETWORK="10.0.2.0"
REMOTE_IPADDR=""
STARTMODE="onboot"
BONDING_MASTER="yes"
BONDING_MODULE_OPTS="mode=active-backup miimon=100"
BONDING_SLAVE0="eth0"
BONDING_SLAVE1="bus-pci-0000:06:08.1"

將示例 BROADCAST、IPADDR、NETMASK 和 NETWORK 值替換為適合您網路的值。

STARTMODE 指定裝置何時聯機。可能的值包括

onboot

裝置在啟動時啟動。如果您不確定，這可能是您想要的。

manual

僅在手動呼叫 ifup 時才啟動裝置。如果您出於某種原因不希望它們在啟動時自動啟動，則可以這樣配置 Bonding 裝置。

hotplug

裝置由熱插拔事件啟動。對於 bonding 裝置，這不是一個有效的選擇。

off 或

裝置配置將被忽略。

ignore

BONDING_MASTER=’yes’ 行表示該裝置是 bonding 主裝置。唯一有用的值是“yes”。

BONDING_MODULE_OPTS 的內容提供給此裝置的 bonding 模組例項。在此處指定 bonding 模式、鏈路監視等的選項。不要包含 max_bonds bonding 引數；如果您有多個 bonding 裝置，這將使配置系統感到困惑。

最後，為每個從裝置提供一個 BONDING_SLAVEn=”從裝置”。其中“n”是一個遞增的值，每個從裝置一個。“從裝置”可以是介面名稱，例如“eth0”，也可以是網路裝置的裝置說明符。介面名稱更容易找到，但如果例如序列中的早期裝置失敗，則 ethN 名稱可能會在啟動時更改。裝置說明符（示例中的 bus-pci-0000:06:08.1）指定物理網路裝置，並且不會更改，除非裝置的匯流排位置更改（例如，它從一個 PCI 插槽移動到另一個 PCI 插槽）。上面的示例出於演示目的使用了每種型別中的一種；大多數配置將為所有從裝置選擇一種或另一種。

修改或建立所有配置檔案後，必須重新啟動網路才能使配置更改生效。這可以透過以下方式完成

# /etc/init.d/network restart

請注意，網路控制指令碼 (/sbin/ifdown) 將刪除 bonding 模組作為網路關閉處理的一部分，因此如果例如模組引數已更改，則無需手動刪除模組。

此外，在撰寫本文時，YaST/YaST2 將不管理 bonding 裝置（它們不會在其網路裝置列表中顯示 bonding 介面）。必須手動編輯配置檔案以更改 bonding 配置。

有關 ifcfg 檔案格式的其他常規選項和詳細資訊，請參見示例 ifcfg 模板檔案

/etc/sysconfig/network/ifcfg.template

請注意，該模板沒有記錄上面描述的各種 BONDING_* 設定，但確實描述了許多其他選項。

3.1.1 將 DHCP 與 Sysconfig 結合使用

在 sysconfig 下，使用 BOOTPROTO=’dhcp’ 配置裝置將導致它查詢 DHCP 以獲取其 IP 地址資訊。在撰寫本文時，這對於 bonding 裝置不起作用；這些指令碼嘗試在新增任何從裝置之前從 DHCP 獲取裝置地址。如果沒有活動的從裝置，則不會將 DHCP 請求傳送到網路。

3.1.2 使用 Sysconfig 配置多個 Bonding

sysconfig 網路初始化系統能夠處理多個 bonding 裝置。所有需要做的就是每個 bonding 例項都有一個適當配置的 ifcfg-bondX 檔案（如上所述）。不要為 bonding 的任何例項指定“max_bonds”引數，因為這會使 sysconfig 感到困惑。如果您需要具有相同引數的多個 bonding 裝置，請建立多個 ifcfg-bondX 檔案。

由於 sysconfig 指令碼在 ifcfg-bondX 檔案中提供 bonding 模組選項，因此無需將它們新增到系統 /etc/modules.d/*.conf 配置檔案中。

3.2 使用 Initscripts 支援進行配置

本節適用於使用帶有 bonding 支援的 initscripts 最新版本的發行版，例如，Red Hat Enterprise Linux 版本 3 或更高版本、Fedora 等。在這些系統上，網路初始化指令碼瞭解 bonding，並且可以配置為控制 bonding 裝置。請注意，initscripts 包的舊版本對 bonding 的支援級別較低；這將在適用時註明。

除非 ethX 裝置配置了 IP 地址，否則這些發行版不會自動載入網路介面卡驅動程式。由於此約束，使用者必須手動為將成為 bondX 鏈路成員的所有物理介面卡配置網路指令碼檔案。網路指令碼檔案位於目錄中

/etc/sysconfig/network-scripts

檔名必須以“ifcfg-eth”為字首，並以介面卡的物理介面卡號為字尾。例如，eth0 的指令碼將命名為 /etc/sysconfig/network-scripts/ifcfg-eth0。將以下文字放入檔案中

DEVICE=eth0
USERCTL=no
ONBOOT=yes
MASTER=bond0
SLAVE=yes
BOOTPROTO=none

DEVICE= 行對於每個 ethX 裝置都會有所不同，並且必須與檔名相對應，即，ifcfg-eth1 必須具有 DEVICE=eth1 的裝置行。MASTER= 行的設定也取決於為您繫結選擇的最終 bonding 介面名稱。與其他網路裝置一樣，這些通常從 0 開始，並且每個裝置遞增 1，即，第一個 bonding 例項是 bond0，第二個是 bond1，依此類推。

接下來，建立一個 bonding 網路指令碼。此指令碼的檔名將是 /etc/sysconfig/network-scripts/ifcfg-bondX，其中 X 是 bond 的編號。對於 bond0，該檔名為“ifcfg-bond0”，對於 bond1，該檔名為“ifcfg-bond1”，依此類推。在該檔案中，放入以下文字

DEVICE=bond0
IPADDR=192.168.1.1
NETMASK=255.255.255.0
NETWORK=192.168.1.0
BROADCAST=192.168.1.255
ONBOOT=yes
BOOTPROTO=none
USERCTL=no

請務必更改特定於網路的行（IPADDR、NETMASK、NETWORK 和 BROADCAST）以匹配您的網路配置。

對於 initscripts 的更高版本，例如 Fedora 7（或更高版本）和 Red Hat Enterprise Linux 版本 5（或更高版本）中找到的版本，可以在 ifcfg-bond0 檔案中指定 bonding 選項，例如，格式為

BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254"

的行將使用指定的選項配置 bond。BONDING_OPTS 中指定的選項與 bonding 模組引數相同，除了在使用低於 8.57 (Fedora 8) 和 8.45.19 (Red Hat Enterprise Linux 5.2) 的 initscripts 版本時，arp_ip_target 欄位除外。使用舊版本時，每個目標都應作為單獨的選項包含，並且應以“+”開頭，以指示應將其新增到查詢目標列表中，例如，

arp_ip_target=+192.168.1.1 arp_ip_target=+192.168.1.2

是指定多個目標的正確語法。透過 BONDING_OPTS 指定選項時，無需編輯 /etc/modprobe.d/*.conf。

對於不支援 BONDING_OPTS 的更舊版本的 initscripts，有必要編輯 /etc/modprobe.d/*.conf（取決於您的發行版）以在啟動 bond0 介面時載入具有所需選項的 bonding 模組。/etc/modprobe.d/*.conf 中的以下行將載入 bonding 模組，並選擇其選項

alias bond0 bonding options bond0 mode=balance-alb miimon=100

將示例引數替換為適合您配置的選項集。

最後以 root 身份執行“/etc/rc.d/init.d/network restart”。這將重新啟動網路子系統，並且您的 bond 鏈路現在應該已啟動並執行。

3.2.1 將 DHCP 與 Initscripts 結合使用

Initscripts 的最新版本（Fedora Core 3 和 Red Hat Enterprise Linux 4 或更高版本提供的版本據報告有效）支援透過 DHCP 將 IP 資訊分配給 bonding 裝置。

要配置 DHCP 的 bonding，請如上所述配置它，除了將行“BOOTPROTO=none”替換為“BOOTPROTO=dhcp”並新增由“TYPE=Bonding”組成的行。請注意，TYPE 值區分大小寫。

3.2.2 使用 Initscripts 配置多個 Bonding

Fedora 7 和 Red Hat Enterprise Linux 5 中包含的 Initscripts 包支援多個 bonding 介面，只需在 ifcfg-bondX 中指定適當的 BONDING_OPTS=，其中 X 是 bond 的編號。此支援需要在核心中支援 sysfs，以及 bonding 驅動程式 3.0.0 或更高版本。其他配置可能不支援此方法來指定多個 bonding 介面；對於這些例項，請參見下面的“手動配置多個 Bonds”部分。

3.3 使用 iproute2 手動配置 Bonding

本節適用於其網路初始化指令碼（sysconfig 或 initscripts 包）不具有 bonding 特定知識的發行版。一個這樣的發行版是 SuSE Linux Enterprise Server 版本 8。

對於這些系統，通用方法是將 bonding 模組引數放入 /etc/modprobe.d/ 中的配置檔案中（如安裝的發行版適當），然後將 modprobe 和/或 ip link 命令新增到系統的全域性 init 指令碼中。全域性 init 指令碼的名稱不同；對於 sysconfig，它是 /etc/init.d/boot.local，對於 initscripts，它是 /etc/rc.d/rc.local。

例如，如果您想建立一個由兩個 e100 裝置（假定為 eth0 和 eth1）組成的簡單 bond，並使其在重新啟動後保持不變，請編輯適當的檔案（/etc/init.d/boot.local 或 /etc/rc.d/rc.local），並新增以下內容

modprobe bonding mode=balance-alb miimon=100
modprobe e100
ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
ip link set eth0 master bond0
ip link set eth1 master bond0

將示例 bonding 模組引數和 bond0 網路配置（IP 地址、網路掩碼等）替換為適合您配置的值。

不幸的是，此方法將不提供對 bond 裝置上 ifup 和 ifdown 指令碼的支援。要重新載入 bonding 配置，需要執行初始化指令碼，例如，

# /etc/init.d/boot.local

或

# /etc/rc.d/rc.local

在這種情況下，可能需要建立一個單獨的指令碼，該指令碼僅初始化 bonding 配置，然後從 boot.local 中呼叫該單獨的指令碼。這允許啟用 bonding，而無需重新執行整個全域性 init 指令碼。

要關閉 bonding 裝置，首先需要將 bonding 裝置本身標記為關閉，然後刪除適當的裝置驅動程式模組。對於上面的示例，您可以執行以下操作

# ifconfig bond0 down
# rmmod bonding
# rmmod e100

同樣，為了方便起見，可能需要建立一個包含這些命令的指令碼。

3.3.1 手動配置多個 Bonds

本節包含有關為那些網路初始化指令碼不支援配置多個 bonds 的系統配置具有不同選項的多個 bonding 裝置的資訊。

如果您需要多個 bonding 裝置，但所有裝置都具有相同的選項，則您可能希望使用上面記錄的“max_bonds”模組引數。

要建立具有不同選項的多個 bonding 裝置，最好使用 sysfs 匯出的 bonding 引數，如下面的部分中所述。

對於沒有 sysfs 支援的 bonding 版本，提供具有不同選項的 bonding 多個例項的唯一方法是多次載入 bonding 驅動程式。請注意，sysconfig 網路初始化指令碼的當前版本會自動處理此問題；如果您的發行版使用這些指令碼，則無需採取特殊操作。如果您不確定您的網路初始化指令碼，請參見上面的配置 Bonding 裝置部分。

要載入模組的多個例項，需要為每個例項指定不同的名稱（模組載入系統要求每個載入的模組，即使是同一模組的多個例項，也具有唯一的名稱）。這可以透過在 /etc/modprobe.d/*.conf 中提供多組 bonding 選項來實現，例如

alias bond0 bonding
options bond0 -o bond0 mode=balance-rr miimon=100

alias bond1 bonding
options bond1 -o bond1 mode=balance-alb miimon=50

將載入 bonding 模組兩次。第一個例項命名為“bond0”，並以 balance-rr 模式建立一個 miimon 為 100 的 bond0 裝置。第二個例項命名為“bond1”，並以 balance-alb 模式建立一個 miimon 為 50 的 bond1 裝置。

在某些情況下（通常使用較舊的發行版），上述操作不起作用，並且第二個 bonding 例項永遠看不到其選項。在這種情況下，可以按如下方式替換第二個選項行

install bond1 /sbin/modprobe --ignore-install bonding -o bond1 \
                             mode=balance-alb miimon=50

對於每個後續例項，可以在 bond1 的位置重複多次指定一個新的唯一名稱。

已經觀察到，某些 Red Hat 提供的核心無法在載入時重新命名模組（“-o bond1”部分）。嘗試將該選項傳遞給 modprobe 將產生“不允許操作”錯誤。這已在某些 Fedora Core 核心上報告，並且已在 RHEL 4 上看到。在出現此問題的核心上，將無法配置具有不同引數的多個 bonds（因為它們是較舊的核心，並且也缺少 sysfs 支援）。

3.4 透過 Sysfs 手動配置 Bonding

從版本 3.0.0 開始，可以透過 sysfs 介面配置通道 Bonding。此介面允許動態配置系統中的所有 bonds，而無需解除安裝模組。它還允許在執行時新增和刪除 bonds。不再需要 ifenslave，但仍然支援它。

使用 sysfs 介面允許您使用具有不同配置的多個 bonds，而無需重新載入模組。它還允許您在使用編譯到核心中的 bonding 時使用多個配置不同的 bonds。

您必須安裝 sysfs 檔案系統才能以這種方式配置 bonding。本文件中的示例假定您使用的是 sysfs 的標準掛載點，例如 /sys。如果您的 sysfs 檔案系統掛載在其他位置，則需要相應地調整示例路徑。

建立和銷燬 Bonds

要新增新的 bond foo

# echo +foo > /sys/class/net/bonding_masters

要刪除現有的 bond bar

# echo -bar > /sys/class/net/bonding_masters

要顯示所有現有的 bonds

# cat /sys/class/net/bonding_masters

注意

由於 sysfs 檔案的大小限制為 4K，如果您的 bonds 超過幾百個，則此列表可能會被截斷。在正常操作條件下不太可能發生這種情況。

新增和刪除 Slaves

可以使用檔案 /sys/class/net/<bond>/bonding/slaves 將介面繫結到 bond。此檔案的語義與 bonding_masters 檔案相同。

要將介面 eth0 繫結到 bond bond0

# ifconfig bond0 up
# echo +eth0 > /sys/class/net/bond0/bonding/slaves

要從 bond bond0 中釋放 slave eth0

# echo -eth0 > /sys/class/net/bond0/bonding/slaves

當介面繫結到 bond 時，將在 sysfs 檔案系統中建立兩者之間的符號連結。在這種情況下，您將獲得 /sys/class/net/bond0/slave_eth0 指向 /sys/class/net/eth0，而 /sys/class/net/eth0/master 指向 /sys/class/net/bond0。

這意味著您可以透過查詢主符號連結來快速判斷介面是否已繫結。因此：# echo -eth0 > /sys/class/net/eth0/master/bonding/slaves 將從其繫結的任何 bond 中釋放 eth0，而不管 bond 介面的名稱如何。

更改 Bond 的配置

可以透過操作位於 /sys/class/net/<bond name>/bonding 中的檔案來單獨配置每個 bond

這些檔案的名稱與本文件中其他地方描述的命令列引數直接對應，並且除了 arp_ip_target 之外，它們接受相同的值。要檢視當前設定，只需 cat 適當的檔案即可。

此處將給出一些示例；有關每個引數的特定使用指南，請參見本文件中的相應部分。

要將 bond0 配置為 balance-alb 模式

# ifconfig bond0 down
# echo 6 > /sys/class/net/bond0/bonding/mode
- or -
# echo balance-alb > /sys/class/net/bond0/bonding/mode

注意

必須先關閉 bond 介面，然後才能更改模式。

要在 bond0 上啟用 MII 監視，間隔為 1 秒

# echo 1000 > /sys/class/net/bond0/bonding/miimon

注意

如果啟用了 ARP 監視，則在啟用 MII 監視時，它將被停用，反之亦然。

要新增 ARP 目標

# echo +192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target
# echo +192.168.0.101 > /sys/class/net/bond0/bonding/arp_ip_target

注意

最多可以指定 16 個目標地址。

要刪除 ARP 目標

# echo -192.168.0.100 > /sys/class/net/bond0/bonding/arp_ip_target

要配置學習資料包傳輸之間的間隔

# echo 12 > /sys/class/net/bond0/bonding/lp_interval

注意

lp_interval 是 bonding 驅動程式向每個從裝置的對等交換機發送學習資料包的例項之間的時間間隔（秒）。預設間隔為 1 秒。

示例配置

我們從 3.3 節中顯示的相同示例開始，使用 sysfs 執行，而不使用 ifenslave。

要建立一個由兩個 e100 裝置（假定為 eth0 和 eth1）組成的簡單 bond，並使其在重新啟動後保持不變，請編輯適當的檔案（/etc/init.d/boot.local 或 /etc/rc.d/rc.local），並新增以下內容

modprobe bonding
modprobe e100
echo balance-alb > /sys/class/net/bond0/bonding/mode
ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
echo 100 > /sys/class/net/bond0/bonding/miimon
echo +eth0 > /sys/class/net/bond0/bonding/slaves
echo +eth1 > /sys/class/net/bond0/bonding/slaves

要新增第二個 bond，其中兩個 e1000 介面處於 active-backup 模式，使用 ARP 監視，請將以下行新增到您的 init 指令碼中

modprobe e1000
echo +bond1 > /sys/class/net/bonding_masters
echo active-backup > /sys/class/net/bond1/bonding/mode
ifconfig bond1 192.168.2.1 netmask 255.255.255.0 up
echo +192.168.2.100 /sys/class/net/bond1/bonding/arp_ip_target
echo 2000 > /sys/class/net/bond1/bonding/arp_interval
echo +eth2 > /sys/class/net/bond1/bonding/slaves
echo +eth3 > /sys/class/net/bond1/bonding/slaves

3.5 使用 Interfaces 支援進行配置

本節適用於使用 /etc/network/interfaces 檔案描述網路介面配置的發行版，最顯著的是 Debian 及其衍生產品。

Debian 上的 ifup 和 ifdown 命令不支援開箱即用的 bonding。應安裝 ifenslave-2.6 包以提供 bonding 支援。安裝後，此包將提供 bond-* 選項以用於 /etc/network/interfaces 中。

請注意，ifenslave-2.6 包將在適當時載入 bonding 模組並使用 ifenslave 命令。

示例配置

在 /etc/network/interfaces 中，以下節將以 active-backup 模式配置 bond0，其中 eth0 和 eth1 作為 slaves

auto bond0
iface bond0 inet dhcp
        bond-slaves eth0 eth1
        bond-mode active-backup
        bond-miimon 100
        bond-primary eth0 eth1

如果上述配置不起作用，您可能有一個系統使用 upstart 進行系統啟動。對於最新的 Ubuntu 版本，這一點尤其正確。/etc/network/interfaces 中的以下節將在這些系統上產生相同的結果

auto bond0
iface bond0 inet dhcp
        bond-slaves none
        bond-mode active-backup
        bond-miimon 100

auto eth0
iface eth0 inet manual
        bond-master bond0
        bond-primary eth0 eth1

auto eth1
iface eth1 inet manual
        bond-master bond0
        bond-primary eth0 eth1

有關 /etc/network/interfaces 中支援的 bond-* 選項的完整列表以及針對您的特定發行版的一些更高階的示例，請參見 /usr/share/doc/ifenslave-2.6 中的檔案。

3.6 覆蓋特殊情況的配置

使用 bonding 驅動程式時，傳輸幀的物理埠通常由 bonding 驅動程式選擇，與使用者或系統管理員無關。輸出埠只是使用所選 bonding 模式的策略選擇的。但是，有時有助於將某些類別的流量定向到某些物理介面上，以實施稍微更復雜的策略。例如，要透過連線到專用網路的繫結介面到達 Web 伺服器，而 eth1 透過公共網路連線，則可能希望使繫結偏向首先透過 eth0 傳送所述流量，僅將 eth1 用作後備，而所有其他流量都可以安全地透過任一介面傳送。可以使用 linux 中固有的流量控制實用程式來實現此類配置。

預設情況下，bonding 驅動程式具有多佇列感知能力，並且在驅動程式初始化時建立 16 個佇列（有關詳細資訊，請參見 多佇列網路裝置支援 HOWTO）。如果需要更多或更少的佇列，可以使用模組引數 tx_queues 來更改此值。沒有可用的 sysfs 引數，因為分配是在模組初始化時完成的。

/proc/net/bonding/bondX 檔案的輸出已更改，因此現在為每個 slave 列印輸出佇列 ID

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:1a:a0:12:8f:cb
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Link Failure Count: 0
Permanent HW addr: 00:1a:a0:12:8f:cc
Slave queue ID: 2

可以使用命令設定 slave 的 queue_id

# echo "eth1:2" > /sys/class/net/bond0/bonding/queue_id

任何需要設定 queue_id 的介面都應使用多個像上面這樣的呼叫來設定它，直到為所有介面設定了適當的優先順序。在允許透過 initscripts 進行配置的發行版上，可以將多個“queue_id”引數新增到 BONDING_OPTS 以設定所有需要的 slave 佇列。

這些佇列 id 可以與 tc 實用程式結合使用，以配置多佇列 qdisc 和過濾器，以使某些流量偏向在某些 slave 裝置上傳輸。例如，假設我們希望在上述配置中強制所有繫結到 192.168.1.100 的流量使用 bond 中的 eth1 作為其輸出裝置。以下命令將完成此操作

# tc qdisc add dev bond0 handle 1 root multiq

# tc filter add dev bond0 protocol ip parent 1: prio 1 u32 match ip \
        dst 192.168.1.100 action skbedit queue_mapping 2

這些命令告訴核心將多佇列佇列規則附加到 bond0 介面並過濾排隊到它的流量，以便具有 dst ip 為 192.168.1.100 的資料包將其輸出佇列對映值覆蓋為 2。然後將此值傳遞到驅動程式中，導致覆蓋正常的輸出路徑選擇策略，而是選擇對映到 eth1 的 qid 2。

請注意，qid 值從 1 開始。Qid 0 保留用於啟動驅動程式，以便應進行正常的輸出策略選擇。簡單地將 slave 的 qid 保留為 0 的一個好處是現在存在的 bonding 驅動程式中的多佇列感知能力。此感知能力允許將 tc 過濾器放置在 slave 裝置以及 bond 裝置上，並且 bonding 驅動程式將僅充當選擇 slave 裝置上輸出佇列的直通，而不是輸出埠選擇。

此功能首次出現在 bonding 驅動程式 3.7.0 版本中，並且對輸出 slave 選擇的支援僅限於輪詢和主動/備份模式。

3.7 以更安全的方式配置 802.3ad 模式的 LACP

使用 802.3ad bonding 模式時，Actor（主機）和 Partner（交換機）會交換 LACPDUs。這些 LACPDUs 無法被嗅探，因為它們的目標是鏈路本地 mac 地址（交換機/網橋不應轉發）。但是，大多數值都很容易預測，或者只是機器的 MAC 地址（同一 L2 中的所有其他主機都知道）。這意味著 L2 域中的其他機器可以從其他主機欺騙 LACPDU 資料包到交換機，並可能透過（從交換機的角度來看）加入另一臺機器的聚合來造成混亂，從而接收該主機的部分傳入流量和/或欺騙來自該機器本身的流量（甚至可能成功終止部分流）。雖然這不太可能發生，但可以透過簡單地配置幾個 bonding 引數來避免這種可能性。

  1. ad_actor_system：您可以設定一個隨機 mac 地址，用於這些 LACPDU 交換。該值不能為 NULL 或 Multicast。最好設定 local-admin 位。以下 shell 程式碼生成如上所述的隨機 mac 地址

    # sys_mac_addr=$(printf '%02x:%02x:%02x:%02x:%02x:%02x' \
                         $(( (RANDOM & 0xFE) | 0x02 )) \
                         $(( RANDOM & 0xFF )) \
                         $(( RANDOM & 0xFF )) \
                         $(( RANDOM & 0xFF )) \
                         $(( RANDOM & 0xFF )) \
                         $(( RANDOM & 0xFF )))
# echo $sys_mac_addr > /sys/class/net/bond0/bonding/ad_actor_system

  2. ad_actor_sys_prio：隨機化系統優先順序。預設值為 65535，但系統可以取值 1 - 65535。以下 shell 程式碼生成隨機優先順序並進行設定

    # sys_prio=$(( 1 + RANDOM + RANDOM ))
# echo $sys_prio > /sys/class/net/bond0/bonding/ad_actor_sys_prio

  3. ad_user_port_key：使用埠金鑰的使用者部分。預設值保持為空。這些是埠金鑰的上位 10 位，取值範圍為 0 - 1023。以下 shell 程式碼生成這 10 位並進行設定

    # usr_port_key=$(( RANDOM & 0x3FF ))
# echo $usr_port_key > /sys/class/net/bond0/bonding/ad_user_port_key

4 查詢 Bonding 配置

4.1 Bonding 配置

每個 bonding 裝置在 /proc/net/bonding 目錄中都有一個只讀檔案。檔案內容包括 bonding 配置、選項和每個 slave 狀態的資訊。

例如，在以 mode=0 和 miimon=1000 引數載入驅動程式後，/proc/net/bonding/bond0 的內容通常如下所示

Ethernet Channel Bonding Driver: 2.6.1 (October 29, 2004)
Bonding Mode: load balancing (round-robin)
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 1000
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth1
MII Status: up
Link Failure Count: 1

Slave Interface: eth0
MII Status: up
Link Failure Count: 1

確切的格式和內容將根據 bonding 配置、狀態和 bonding 驅動程式的版本而變化。

4.2 網路配置

可以使用 ifconfig 命令檢查網路配置。Bonding 裝置將設定 MASTER 標誌；Bonding slave 裝置將設定 SLAVE 標誌。ifconfig 輸出不包含有關哪些 slave 與哪些 master 相關聯的資訊。

在下面的示例中，bond0 介面是 master (MASTER)，而 eth0 和 eth1 是 slave (SLAVE)。請注意，除了 TLB 和 ALB 之外，bond0 的所有 slave 都具有與 bond0 相同的 MAC 地址 (HWaddr)，TLB 和 ALB 要求每個 slave 具有唯一的 MAC 地址

# /sbin/ifconfig
bond0     Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          inet addr:XXX.XXX.XXX.YYY  Bcast:XXX.XXX.XXX.255  Mask:255.255.252.0
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:7224794 errors:0 dropped:0 overruns:0 frame:0
          TX packets:3286647 errors:1 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:0

eth0      Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:3573025 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1643167 errors:1 dropped:0 overruns:1 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:10 Base address:0x1080

eth1      Link encap:Ethernet  HWaddr 00:C0:F0:1F:37:B4
          UP BROADCAST RUNNING SLAVE MULTICAST  MTU:1500  Metric:1
          RX packets:3651769 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1643480 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          Interrupt:9 Base address:0x1400

5. 交換機配置

對於本節，“交換機”是指 bonding 裝置直接連線到的任何系統（即，電纜的另一端插入的位置）。這可以是實際的專用交換機裝置，也可以是另一個常規系統（例如，執行 Linux 的另一臺計算機）。

active-backup、balance-tlb 和 balance-alb 模式不需要任何特定的交換機配置。

802.3ad 模式要求交換機將適當的埠配置為 802.3ad 聚合。用於配置此方法的具體方法因交換機而異，但例如，Cisco 3550 系列交換機要求首先將適當的埠分組到單個 etherchannel 例項中，然後將該 etherchannel 設定為“lacp”模式以啟用 802.3ad（而不是標準的 EtherChannel）。

balance-rr、balance-xor 和 broadcast 模式通常要求交換機將適當的埠分組在一起。這種組的命名法因交換機而異，它可以稱為“etherchannel”（如上面的 Cisco 示例中所示）、“trunk group”或其他類似的變體。對於這些模式，每個交換機還將具有其自己的用於交換機傳輸策略的配置選項。典型選擇包括 MAC 或 IP 地址的 XOR。兩個對等方的傳輸策略不需要匹配。對於這三種模式，bonding 模式實際上為 EtherChannel 組選擇了一種傳輸策略；所有三種模式都將與另一個 EtherChannel 組互操作。

6. 802.1q VLAN 支援

可以使用 8021q 驅動程式在 bonding 介面上配置 VLAN 裝置。但是，預設情況下，只有來自 8021q 驅動程式並透過 bonding 的資料包才會被標記。自生成的資料包，例如 bonding 的學習資料包或由 ALB 模式或 ARP 監視機制生成的 ARP 資料包，由 bonding 本身在內部標記。因此，bonding 必須“學習”在其之上配置的 VLAN ID，並使用這些 ID 標記自生成的資料包。

出於簡單性的考慮，並且為了支援可以使用 VLAN 硬體加速解除安裝的介面卡的使用，bonding 介面宣告自身具有完全的硬體解除安裝能力，它會收到 add_vid/kill_vid 通知以收集必要的資訊，並將這些操作傳播到 slave。對於混合介面卡型別，應透過不具備解除安裝能力的介面卡的硬體加速標記資料包將由 bonding 驅動程式“取消加速”，以便 VLAN 標籤位於常規位置。

VLAN 介面必須僅在 enslave 至少一個 slave 後新增到 bonding 介面之上。在新增第一個 slave 之前，bonding 介面的硬體地址為 00:00:00:00:00:00。如果在第一次 enslave 之前建立了 VLAN 介面，它將選擇全零硬體地址。一旦第一個 slave 連線到 bond，bond 裝置本身將選擇 slave 的硬體地址，然後該地址可用於 VLAN 裝置。

另請注意，如果從仍然在其上具有一個或多個 VLAN 介面的 bond 中釋放所有 slave，則可能會發生類似的問題。新增新的 slave 時，bonding 介面將從第一個 slave 獲取其硬體地址，該地址可能與 VLAN 介面的硬體地址不匹配（VLAN 介面的硬體地址最終是從較早的 slave 複製的）。

有兩種方法可以確保 VLAN 裝置在從 bonding 介面中刪除所有 slave 時以正確的硬體地址執行

  1. 刪除所有 VLAN 介面，然後重新建立它們

2. 設定 bonding 介面的硬體地址，使其與 VLAN 介面的硬體地址匹配。

請注意，更改 VLAN 介面的 HW 地址會將底層裝置（即 bonding 介面）設定為混雜模式，這可能不是您想要的。

8. 潛在的故障源

8.1 路由冒險

配置 bonding 時，重要的是 slave 裝置沒有覆蓋 master 路由的路由（或者，通常根本沒有路由）。例如，假設 bonding 裝置 bond0 有兩個 slave，eth0 和 eth1，並且路由表如下所示

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 eth0
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 eth1
10.0.0.0        0.0.0.0         255.255.0.0     U        40 0          0 bond0
127.0.0.0       0.0.0.0         255.0.0.0       U        40 0          0 lo

此路由配置可能會更新驅動程式中的接收/傳輸時間（ARP 監視器需要），但可能會繞過 bonding 驅動程式（因為在這種情況下，到網路 10 上另一臺主機的傳出流量將在 bond0 之前使用 eth0 或 eth1）。

ARP 監視器（和 ARP 本身）可能會對此配置感到困惑，因為 ARP 請求（由 ARP 監視器生成）將在一個介面 (bond0) 上傳送，但相應的回覆將到達不同的介面 (eth0)。對於 ARP 而言，此回覆看起來像是未經請求的 ARP 回覆（因為 ARP 基於介面匹配回覆），因此會被丟棄。MII 監視器不受路由表狀態的影響。

此處的解決方案很簡單，就是確保 slave 沒有自己的路由，如果由於某種原因必須這樣做，則這些路由不會覆蓋其 master 的路由。通常應該是這種情況，但不尋常的配置或錯誤的或自動的靜態路由新增可能會導致問題。

8.2 乙太網裝置重新命名

在網路配置指令碼不將物理裝置直接與網路介面名稱關聯的系統上（因此相同的物理裝置始終具有相同的“ethX”名稱），可能需要在 /etc/modprobe.d/ 中的配置檔案中新增一些特殊邏輯。

例如，給定包含以下內容的 modules.conf

alias bond0 bonding
options bond0 mode=some-mode miimon=50
alias eth0 tg3
alias eth1 tg3
alias eth2 e1000
alias eth3 e1000

如果 eth0 和 eth1 都不是 bond0 的 slave，則當 bond0 介面啟動時，裝置最終可能會重新排序。發生這種情況是因為首先載入 bonding，然後接下來載入其 slave 裝置的驅動程式。由於未載入其他驅動程式，因此當 e1000 驅動程式載入時，它將為其裝置接收 eth0 和 eth1，但 bonding 配置會嘗試 enslave eth2 和 eth3（稍後可能會分配給 tg3 裝置）。

新增以下內容

add above bonding e1000 tg3

會導致 modprobe 在載入 bonding 時按順序載入 e1000，然後載入 tg3。此命令已在 modules.conf 手冊頁中完全記錄。

在使用 modprobe 的系統上，可能會出現等效的問題。在這種情況下，可以將以下內容新增到 /etc/modprobe.d/ 中的配置檔案中，如

softdep bonding pre: tg3 e1000

這將在載入 bonding 模組之前載入 tg3 和 e1000 模組。有關此內容的完整文件，請參見 modprobe.d 和 modprobe 手冊頁。

9. SNMP 代理

如果執行 SNMP 代理，則應在任何參與 bond 的網路驅動程式之前載入 bonding 驅動程式。此要求是因為介面索引 (ipAdEntIfIndex) 與使用給定 IP 地址找到的第一個介面相關聯。也就是說，每個 IP 地址只有一個 ipAdEntIfIndex。例如，如果 eth0 和 eth1 是 bond0 的 slave，並且 eth0 的驅動程式在 bonding 驅動程式之前載入，則 IP 地址的介面將與 eth0 介面相關聯。此配置如下所示，IP 地址 192.168.1.1 的介面索引為 2，該索引指向 ifDescr 表 (ifDescr.2) 中的 eth0。

interfaces.ifTable.ifEntry.ifDescr.1 = lo
interfaces.ifTable.ifEntry.ifDescr.2 = eth0
interfaces.ifTable.ifEntry.ifDescr.3 = eth1
interfaces.ifTable.ifEntry.ifDescr.4 = eth2
interfaces.ifTable.ifEntry.ifDescr.5 = eth3
interfaces.ifTable.ifEntry.ifDescr.6 = bond0
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 5
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 4
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1

透過在任何參與 bond 的網路驅動程式之前載入 bonding 驅動程式，可以避免此問題。以下是首先載入 bonding 驅動程式的示例，IP 地址 192.168.1.1 與 ifDescr.2 正確關聯。

interfaces.ifTable.ifEntry.ifDescr.1 = lo interfaces.ifTable.ifEntry.ifDescr.2 = bond0 interfaces.ifTable.ifEntry.ifDescr.3 = eth0 interfaces.ifTable.ifEntry.ifDescr.4 = eth1 interfaces.ifTable.ifEntry.ifDescr.5 = eth2 interfaces.ifTable.ifEntry.ifDescr.6 = eth3 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.10.10.10 = 6 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.192.168.1.1 = 2 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.10.74.20.94 = 5 ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 = 1

雖然某些發行版可能不會在 ifDescr 中報告介面名稱，但 IP 地址和 IfIndex 之間的關聯仍然存在，並且 SNMP 函式（例如 Interface_Scan_Next）將報告該關聯。

10. 混雜模式

執行網路監視工具（例如 tcpdump）時，通常會在裝置上啟用混雜模式，以便可以看到所有流量（而不是僅看到目標為主機的流量）。bonding 驅動程式處理 bonding master 裝置（例如 bond0）的混雜模式更改，並將設定傳播到 slave 裝置。

對於 balance-rr、balance-xor、broadcast 和 802.3ad 模式，混雜模式設定將傳播到所有 slave。

對於 active-backup、balance-tlb 和 balance-alb 模式，混雜模式設定僅傳播到活動 slave。

對於 balance-tlb 模式，活動 slave 是當前接收入站流量的 slave。

對於 balance-alb 模式，活動 slave 是用作“主要”的 slave。此 slave 用於特定於模式的控制流量，用於傳送到未分配的對等方或負載不平衡的情況。

對於 active-backup、balance-tlb 和 balance-alb 模式，當活動 slave 更改時（例如，由於鏈路故障），混雜設定將傳播到新的活動 slave。

11. 配置 Bonding 以實現高可用性

高可用性是指透過在主機與世界其他地方之間具有冗餘或備份裝置、鏈路或交換機來提供最大網路可用性的配置。目標是提供網路連線的最大可用性（即網路始終正常工作），即使其他配置可以提供更高的吞吐量。

11.1 單個交換機拓撲中的高可用性

如果兩臺主機（或主機和單個交換機）透過多個物理鏈路直接連線，則最佳化最大頻寬不會導致可用性降低。在這種情況下，只有一個交換機（或對等方），因此如果它發生故障，則沒有可故障轉移的替代訪問方式。此外，bonding 負載平衡模式支援對其成員的鏈路監視，因此如果單個鏈路發生故障，負載將在其餘裝置之間重新平衡。

有關使用一個對等裝置配置 bonding 的資訊，請參見第 12 節“配置 Bonding 以實現最大吞吐量”。

11.2 多個交換機拓撲中的高可用性

對於多個交換機，bonding 和網路的配置會發生巨大變化。在多個交換機拓撲中，網路可用性和可用頻寬之間存在權衡。

以下是一個示例網路，配置為最大程度地提高網路的可用性

      |                                     |
      |port3                           port3|
+-----+----+                          +-----+----+
|          |port2       ISL      port2|          |
| switch A +--------------------------+ switch B |
|          |                          |          |
+-----+----+                          +-----++---+
      |port1                           port1|
      |             +-------+               |
      +-------------+ host1 +---------------+
               eth0 +-------+ eth1

在此配置中，兩個交換機之間存在鏈路（ISL 或交換機間鏈路），並且有多個埠連線到外部世界（每個交換機上的“port3”）。沒有技術原因不能將其擴充套件到第三個交換機。

11.2.1 多個交換機拓撲的 HA Bonding 模式選擇

在上述示例之類的拓撲中，在最佳化可用性時，active-backup 和 broadcast 模式是唯一有用的 bonding 模式；其他模式要求所有鏈路在同一對等方上終止才能合理執行。

active-backup

這通常是首選模式，尤其是當交換機具有 ISL 並且執行良好時。如果網路配置使得一個交換機專門用作備份交換機（例如，容量較低、成本較高），則可以使用 primary 選項來確保首選鏈路始終在其可用時使用。

broadcast

此模式實際上是一種特殊用途模式，僅適用於非常特定的需求。例如，如果兩個交換機未連線（沒有 ISL），並且它們之外的網路完全獨立。在這種情況下，如果需要某些特定單向流量到達兩個獨立的網路，則 broadcast 模式可能適用。

12. 配置 Bonding 以實現最大吞吐量

12.1 單個交換機拓撲中吞吐量最大化

在單個交換機配置中，最大程度地提高吞吐量的最佳方法取決於應用程式和網路環境。各種負載平衡模式在不同的環境中各有優缺點，如下詳述。

對於此討論，我們將拓撲分解為兩類。根據大多數流量的目的地，我們將它們分為“閘道器”或“本地”配置。

在閘道器配置中，“交換機”主要用作路由器，並且大多數流量透過此路由器到達其他網路。一個例子如下所示

+----------+                     +----------+
|          |eth0            port1|          | to other networks
| Host A   +---------------------+ router   +------------------->
|          +---------------------+          | Hosts B and C are out
|          |eth1            port2|          | here somewhere
+----------+                     +----------+

路由器可以是專用路由器裝置，也可以是充當閘道器的另一臺主機。對於我們的討論，重要的一點是來自主機 A 的大多數流量將在到達其最終目的地之前透過路由器到達某個其他網路。

在閘道器網路配置中，儘管主機 A 可能會與許多其他系統通訊，但其所有流量都將透過本地網路上的另一個對等方（路由器）傳送和接收。

請注意，對於配置 bonding 而言，透過多個物理鏈路直接連線的兩個系統的情況與閘道器配置相同。在這種情況下，所有流量都將定向到“閘道器”本身，而不是閘道器之外的某個其他網路。

在本地配置中，“交換機”主要用作交換機，並且大多數流量透過此交換機到達同一網路上的其他站點。一個例子如下所示

+----------+            +----------+       +--------+
|          |eth0   port1|          +-------+ Host B |
|  Host A  +------------+  switch  |port3  +--------+
|          +------------+          |                  +--------+
|          |eth1   port2|          +------------------+ Host C |
+----------+            +----------+port4             +--------+

同樣，交換機可以是專用交換機裝置，也可以是充當閘道器的另一臺主機。對於我們的討論，重要的一點是來自主機 A 的大多數流量的目標是同一本地網路上的其他主機（在上面的示例中為主機 B 和主機 C）。

總而言之，在閘道器配置中，與 bonding 裝置的流量將與網路上同一 MAC 級別的對等方（閘道器本身，即路由器）進行互動，而無論其最終目的地如何。在本地配置中，流量直接與最終目的地之間流動，因此，每個目的地（主機 B，主機 C）將由其各自的 MAC 地址直接定址。

閘道器和本地網路配置之間的這種區別很重要，因為許多可用的負載平衡模式都使用本地網路源和目的地的 MAC 地址來制定負載平衡決策。下面描述了每種模式的行為。

12.1.1 單個交換機拓撲的 MT Bonding 模式選擇

此配置最容易設定和理解，但您必須確定哪種 bonding 模式最適合您的需求。下面詳細介紹了每種模式的權衡

balance-rr

此模式是唯一允許單個 TCP/IP 連線跨多個介面條帶化流量的模式。因此，它是唯一允許單個 TCP/IP 流利用超過一個介面吞吐量的模式。但是，這是有代價的：條帶化通常會導致對等系統接收無序的資料包，從而導致 TCP/IP 的擁塞控制系統啟動，通常透過重新傳輸段。

可以透過更改 net.ipv4.tcp_reordering sysctl 引數來調整 TCP/IP 的擁塞限制。通常預設值為 3。但請記住，當 TCP 堆疊檢測到重新排序時，它可以自動增加此值。

請注意，將以無序方式傳遞的資料包的分數差異很大，並且不可能為零。重新排序的級別取決於多種因素，包括網路介面、交換機和配置的拓撲。一般來說，高速網絡卡會產生更多的重新排序（由於資料包合併等因素），並且“多對多”拓撲將以高於“多慢對一快”配置的速率重新排序。

許多交換機不支援任何對流量進行條帶化的模式（而是根據 IP 或 MAC 級別地址選擇埠）；對於這些裝置，透過交換機流向 balance-rr bond 的特定連線的流量將不會利用大於一個介面的頻寬。

如果您正在使用 TCP/IP 以外的協議（例如 UDP），並且您的應用程式可以容忍無序傳遞，則此模式可以允許隨介面新增到 bond 而線性擴充套件的單流資料報效能。

此模式要求交換機將適當的埠配置為“etherchannel”或“trunking”。

active-backup

在此網路拓撲中，active-backup 模式沒有太多優勢，因為非活動備份裝置都連線到與主裝置相同的對等方。在這種情況下，負載平衡模式（具有鏈路監視）將提供相同級別的網路可用性，但具有增加的可用頻寬。從好的方面來說，active-backup 模式不需要交換機的任何配置，因此如果可用硬體不支援任何負載平衡模式，則它可能具有價值。

balance-xor

此模式將限制流量，以便目標為特定對等方的資料包始終透過同一介面傳送。由於目的地由所涉及的 MAC 地址確定，因此此模式最適合“本地”網路配置（如上所述），所有目的地都在同一本地網路上。如果您的所有流量都透過單個路由器傳遞（即，如上所述的“閘道器”網路配置），則此模式可能不是最佳選擇。

與 balance-rr 一樣，交換機埠需要配置為“etherchannel”或“trunking”。

broadcast

與 active-backup 一樣，在此型別的網路拓撲中，此模式沒有太多優勢。

802.3ad

對於此類網路拓撲，此模式可能是一個不錯的選擇。802.3ad 模式是 IEEE 標準，因此所有實現 802.3ad 的對等方都應該很好地互操作。802.3ad 協議包括聚合的自動配置，因此只需要對交換機進行最少的手動配置（通常僅指定某些裝置可用於 802.3ad）。802.3ad 標準還規定幀必須按順序（在某些限制範圍內）傳遞，因此通常單個連線不會看到資料包的錯誤排序。802.3ad 模式確實有一些缺點：該標準規定聚合中的所有裝置都以相同的速度和雙工模式執行。此外，與除 balance-rr 之外的所有 bonding 負載平衡模式一樣，沒有單個連線能夠利用超過單個介面的頻寬。

此外，linux bonding 802.3ad 實現按對等方分配流量（使用 MAC 地址和資料包型別 ID 的 XOR），因此在“閘道器”配置中，所有傳出流量通常將使用同一裝置。傳入流量也可能最終出現在單個裝置上，但這取決於對等方的 802.3ad 實現的平衡策略。在“本地”配置中，流量將在 bond 中的裝置之間分配。

最後，802.3ad 模式要求使用 MII 監視器，因此，在此模式下無法使用 ARP 監視器。

balance-tlb

balance-tlb 模式按對等方平衡傳出流量。由於平衡是根據 MAC 地址完成的，因此在“閘道器”配置中（如上所述），此模式將透過單個裝置傳送所有流量。但是，在“本地”網路配置中，此模式以一種模糊智慧的方式（不是像 balance-xor 或 802.3ad 模式中的簡單 XOR）跨裝置平衡多個本地網路對等方，因此在數學上不幸的 MAC 地址（即，XOR 為相同值的 MAC 地址）不會全部“聚集”在單個介面上。

與 802.3ad 不同，介面可以具有不同的速度，並且不需要特殊的交換機配置。缺點是，在這種模式下，所有傳入的流量都透過單個介面到達，這種模式需要從屬介面的網路裝置驅動程式中提供一定的 ethtool 支援，並且 ARP 監視器不可用。

balance-alb

這種模式包含了 balance-tlb 的所有功能，甚至更多。它具有 balance-tlb 的所有特性（和限制），並且還將平衡來自本地網路對等方的傳入流量（如上面的“繫結模組選項”部分所述）。

這種模式的唯一額外缺點是，網路裝置驅動程式必須支援在裝置開啟時更改硬體地址。

12.2 多交換機拓撲中的最大吞吐量

當多個交換機配置為並行，作為兩個或多個系統之間的隔離網路的一部分時，可以使用多個交換機來最佳化吞吐量，例如

              +-----------+
              |  Host A   |
              +-+---+---+-+
                |   |   |
       +--------+   |   +---------+
       |            |             |
+------+---+  +-----+----+  +-----+----+
| Switch A |  | Switch B |  | Switch C |
+------+---+  +-----+----+  +-----+----+
       |            |             |
       +--------+   |   +---------+
                |   |   |
              +-+---+---+-+
              |  Host B   |
              +-----------+

在此配置中，交換機彼此隔離。採用這種拓撲結構的一個原因是，對於具有許多主機的隔離網路（例如，配置為高效能的叢集），使用多個較小的交換機可能比單個較大的交換機更具成本效益，例如，在具有 24 個主機的網路上，三個 24 埠交換機可能比單個 72 埠交換機便宜得多。

如果需要訪問網路之外的內容，則可以為主機配備連線到外部網路的額外網路裝置；然後，該主機還可以充當閘道器。

12.2.1 多交換機拓撲的 MT 繫結模式選擇

在實際應用中，此型別配置中通常採用的繫結模式是 balance-rr。 歷史上，在這種網路配置中，通常由於網路介面卡不進行任何型別的包合併（透過使用 NAPI，或者因為裝置本身直到收到一定數量的包才生成中斷）而減輕了亂序包傳遞的常見警告。 以這種方式使用時，balance-rr 模式允許兩個主機之間的單個連線有效地利用大於一個介面的頻寬。

13. 交換機行為問題

13.2 重複的傳入資料包

注意：從 3.0.2 版開始，繫結驅動程式具有抑制重複資料包的邏輯，這應在很大程度上消除此問題。 以下描述僅供參考。

觀察到當首次使用繫結裝置或在一段時間空閒後，會出現短暫的重複流量突發並不罕見。 透過向網路上的某個其他主機發出“ping”來最容易觀察到這一點，並注意到來自 ping 標誌重複的輸出（通常每個從屬裝置一個）。

例如，在具有五個從屬裝置並且全部連線到一個交換機的活動-備份模式的繫結中，輸出可能如下所示

# ping -n 10.0.4.2
PING 10.0.4.2 (10.0.4.2) from 10.0.3.10 : 56(84) bytes of data.
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.7 ms
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=1 ttl=64 time=13.8 ms (DUP!)
64 bytes from 10.0.4.2: icmp_seq=2 ttl=64 time=0.216 ms
64 bytes from 10.0.4.2: icmp_seq=3 ttl=64 time=0.267 ms
64 bytes from 10.0.4.2: icmp_seq=4 ttl=64 time=0.222 ms

這不是由於繫結驅動程式中的錯誤，而是許多交換機如何更新其 MAC 轉發表的副作用。 最初，交換機不會將資料包中的 MAC 地址與特定的交換機埠相關聯，因此可能會將流量傳送到所有埠，直到其 MAC 轉發表更新為止。 由於連線到繫結的介面可能會佔用單個交換機上的多個埠，因此當交換機（暫時）將流量泛洪到所有埠時，繫結裝置會收到同一資料包的多個副本（每個從屬裝置一個）。

重複的資料包行為取決於交換機，某些交換機表現出這種行為，而有些則沒有。 在顯示此行為的交換機上，可以透過清除 MAC 轉發表來誘導此行為（在大多數 Cisco 交換機上，特權命令“clear mac address-table dynamic”將完成此操作）。

14. 硬體特定注意事項

本節包含有關在特定硬體平臺上配置繫結或將繫結與特定交換機或其他裝置連線的其他資訊。

14.1 IBM BladeCenter

這適用於 JS20 和類似的系統。

在 JS20 刀鋒伺服器上，繫結驅動程式僅支援 balance-rr、active-backup、balance-tlb 和 balance-alb 模式。 這主要是由於 BladeCenter 內部的網路拓撲，詳見下文。

JS20 網路介面卡資訊

所有 JS20 都帶有兩個整合在主機板上的 Broadcom 千兆乙太網埠（在 IBM 術語中，“主機板”）。 在 BladeCenter 機箱中，所有 JS20 刀鋒伺服器的 eth0 埠都硬連線到 I/O 模組 #1；同樣，所有 eth1 埠都連線到 I/O 模組 #2。 可以在 JS20 上安裝一個附加的 Broadcom 子卡，以提供另外兩個千兆乙太網埠。 這些埠 eth2 和 eth3 分別連線到 I/O 模組 3 和 4。

每個 I/O 模組都可以包含交換機或直通模組（允許埠直接連線到外部交換機）。 某些繫結模式需要特定的 BladeCenter 內部網路拓撲才能執行； 詳細資訊如下。

有關更多特定於 BladeCenter 的網路資訊，請參見兩個 IBM 紅皮書 (www.ibm.com/redbooks)

  • “IBM eServer BladeCenter 網路選項”

  • “IBM eServer BladeCenter 第 2-7 層網路交換”

BladeCenter 網路配置

由於 BladeCenter 可以透過多種方式進行配置，因此本討論將僅限於描述基本配置。

通常，乙太網交換機模組 (ESM) 用於 I/O 模組 1 和 2。在這種配置中，JS20 的 eth0 和 eth1 埠將連線到不同的內部交換機（在相應的 I/O 模組中）。

直通模組（OPM 或 CPM，光纖或銅纜直通模組）將 I/O 模組直接連線到外部交換機。 透過在 I/O 模組 #1 和 #2 中使用 PM，JS20 的 eth0 和 eth1 介面可以重定向到外部世界並連線到公共外部交換機。

根據 ESM 和 PM 的組合，網路對於繫結而言將顯示為單交換機拓撲（所有 PM）或多交換機拓撲（一個或多個 ESM，零個或多個 PM）。 也可以將 ESM 連線在一起，從而形成與上述“多交換機拓撲中的高可用性”中的示例非常相似的配置。

特定模式的要求

balance-rr 模式要求對繫結中的裝置使用直通模組，所有模組都連線到公共外部交換機。 與 balance-rr 常用方法一樣，該交換機必須在適當的埠上配置為“etherchannel”或“trunking”。

balance-alb 和 balance-tlb 模式可以與交換機模組或直通模組（或兩者的混合）一起使用。 這些模式的唯一特定要求是所有網路介面都必須能夠訪問透過繫結裝置傳送的流量的所有目的地（即，網路必須在 BladeCenter 外部的某個點匯聚）。

active-backup 模式沒有其他要求。

其他注意事項

LAN 上的序列 (SoL) 鏈路僅透過主乙太網 (eth0) 建立，因此，任何與 eth0 的鏈路丟失都將導致丟失 SoL 連線。 它不會與其他網路流量一起故障轉移，因為 SoL 系統超出了繫結驅動程式的控制範圍。

在交換機（內部乙太網交換機模組或外部交換機）上停用生成樹可能有助於避免使用繫結時的故障轉移延遲問題。

15. 常見問題解答

1. 它是否是 SMP 安全的？

是。 舊的 2.0.xx 通道繫結補丁不是 SMP 安全的。 新驅動程式從一開始就被設計為 SMP 安全的。

2. 什麼型別的卡可以與它一起使用？

任何乙太網型別的卡（您甚至可以混合使用卡 - 例如 Intel EtherExpress PRO/100 和 3com 3c905b）。 對於大多數模式，裝置的速度不必相同。

從 3.2.1 版開始，繫結還支援活動-備份模式下的 Infiniband 從屬裝置。

3. 我可以擁有多少個繫結裝置？

沒有限制。

4. 一個繫結裝置可以有多少個從屬裝置？

這僅受 Linux 支援的網路介面數量和/或您可以在系統中放置的網絡卡數量的限制。

6. 繫結可以用於高可用性嗎？

是的。 有關詳細資訊，請參見高可用性部分。

7. 它與哪些交換機/系統配合使用？

此問題的完整答案取決於所需的模式。

在基本平衡模式（balance-rr 和 balance-xor）中，它可以與支援 etherchannel（也稱為 trunking）的任何系統配合使用。 大多數當前可用的託管交換機都具有此類支援，許多非託管交換機也具有此類支援。

高階平衡模式（balance-tlb 和 balance-alb）沒有特殊的交換機要求，但是確實需要支援特定功能的裝置驅動程式（如上面的模組引數下的相應部分中所述）。

在 802.3ad 模式下，它可以與支援 IEEE 802.3ad 動態鏈路聚合的系統配合使用。 當前可用的大多數託管交換機和許多非託管交換機都支援 802.3ad。

active-backup 模式應與任何第 II 層交換機一起使用。

8. 繫結裝置從何處獲取其 MAC 地址？

當使用具有固定 MAC 地址的從屬裝置時，或者當啟用了 fail_over_mac 選項時，繫結裝置的 MAC 地址是活動從屬裝置的 MAC 地址。

對於其他配置，如果未顯式配置（使用 ifconfig 或 ip link），則繫結裝置的 MAC 地址取自其第一個從屬裝置。 然後，此 MAC 地址將傳遞給所有後續從屬裝置，並保持永續性（即使移除了第一個從屬裝置），直到繫結裝置被關閉或重新配置。

如果您希望更改 MAC 地址，則可以使用 ifconfig 或 ip link 設定它

# ifconfig bond0 hw ether 00:11:22:33:44:55

# ip link set bond0 address 66:77:88:99:aa:bb

也可以透過關閉/啟動裝置然後更改其從屬裝置（或其順序）來更改 MAC 地址

# ifconfig bond0 down ; modprobe -r bonding
# ifconfig bond0 .... up
# ifenslave bond0 eth...

此方法將自動從新增的下一個從屬裝置獲取地址。

要恢復從屬裝置的 MAC 地址，您需要將它們從繫結中分離 (ifenslave -d bond0 eth0)。 然後，繫結驅動程式將恢復從屬裝置在被從屬之前所具有的 MAC 地址。

9. 哪些繫結模式支援本機 XDP？

  • balance-rr (0)

  • active-backup (1)

  • balance-xor (2)

  • 802.3ad (4)

請注意，vlan+srcmac 雜湊策略不支援本機 XDP。 對於其他繫結模式，必須以通用模式載入 XDP 程式。