Linux 多網卡綁定
網卡綁定 mode 共有七種 (0~6) bond0、bond1、bond2、bond3、bond4、bond5、bond6
常用的有三種
七種 bond 模式說明：
第一種模式：mode=0 ，即：(balance-rr) Round-robin policy（平衡掄循環策略）
特點：傳輸數據包順序是依次傳輸（即：第1個包走 eth0，下一個包就走 eth1…. 一直循環下去，直到最后一個傳輸完畢），此模式提供負載平衡和容錯能力；但是我們知道如果一個連接或者會話的數據包從不同的接口發出的話，中途再經過不同的鏈路，在客戶端很有可能會出現數據包無序到達的問題，而無序到達的數據包需要重新要求被發送，這樣網絡的吞吐量就會下降
第二種模式：mode=1，即： (active-backup) Active-backup policy（主-備份策略）
特點：只有一個設備處於活動狀態，當一個宕掉另一個馬上由備份轉換為主設備。mac 地址是外部可見得，從外面看來，bond 的 MAC 地址是唯一的，以避免 switch (交換機) 發生混亂。此模式只提供了容錯能力；由此可見此算法的優點是可以提供高網絡連接的可用性，但是它的資源利用率較低，只有一個接口處於工作狀態，在有 N 個網絡接口的情況下，資源利用率為 1/N
第三種模式：mode=2，即：(balance-xor) XOR policy（平衡策略）
特點：基於指定的傳輸 HASH 策略傳輸數據包。缺省的策略是：(源 MAC 地址 XOR 目標 MAC地址) % slave 數量。其他的傳輸策略可以通過 xmit_hash_policy 選項指定，此模式提供負載平衡和容錯能力
第四種模式：mode=3，即：broadcast（廣播策略）
特點：在每個 slave 接口上傳輸每個數據包，此模式提供了容錯能力
第五種模式：mode=4，即：(802.3ad) IEEE 802.3ad Dynamic link aggregation（IEEE 802.3ad 動態鏈接聚合）
特點：創建一個聚合組，它們共享同樣的速率和雙工設定。根據 802.3ad 規范將多個 slave 工作在同一個激活的聚合體下
外出流量的 slave 選舉是基於傳輸hash策略，該策略可以通過 xmit_hash_policy 選項從缺省的 XOR 策略改變到其他策略。需要注意的是並不是所有的傳輸策略都是 802.3ad 適應的
必要條件：
條件1：ethtool 支持獲取每個 slave 的速率和雙工設定
條件2：switch 支持 IEEE 802.3ad Dynamic link aggregation
條件3：大多數 switch 需要經過特定配置才能支持 802.3ad 模式
第六種模式：mode=5，即：(balance-tlb) Adaptive transmit load balancing（適配器傳輸負載均衡）
特點：不需要任何特別的switch(交換機)支持的通道 bonding。在每個 slave 上根據當前的負載（根據速度計算）分配外出流量。如果正在接受數據的slave出故障了，另一個 slave 接管失敗的 slave 的 MAC 地址
該模式的必要條件：ethtool 支持獲取每個 slave 的速率
第七種模式：mode=6，即：(balance-alb) Adaptive load balancing（適配器適應性負載均衡）
特點：該模式包含了 balance-tlb 模式，同時加上針對 IPV4 流量的接收負載均衡 (receive load balance, rlb)，而且不需要任何 switch 的支持。接收負載均衡是通過 ARP 協商實現的。bonding驅動截獲本機發送的 ARP 應答，並把源硬件地址改寫為 bond 中某個 slave 的唯一硬件地址，從而使得不同的對端使用不同的硬件地址進行通信
來自服務器端的接收流量也會被均衡。當本機發送 ARP 請求時，bonding 驅動把對端的 IP 信息從 ARP 包中復制並保存下來。當 ARP 應答從對端到達時，bonding 驅動把它的硬件地址提取出來，並發起一個 ARP 應答給 bond 中的某個 slave。使用ARP協商進行負載均衡的一個問題是：每次廣播 ARP 請求時都會使用 bond 的硬件地址，因此對端學習到這個硬件地址后，接收流量將會全部流向當前的 slave。這個問題可以通過給所有的對端發送更新 （ARP 應答）來解決，應答中包含他們獨一無二的硬件地址，從而導致流量重新分布。當新的 slave 加入到 bond 中時，或者某個未激活的 slave 重新 激活時，接收流量也要重新分布。接收的負載被順序地分布（round robin）在 bond 中最高速的 slave 上
當某個鏈路被重新接上，或者一個新的 slave 加入到 bond 中，接收流量在所有當前激活的 slave 中全部重新分配，通過使用指定的 MAC 地址給每個 client 發起 ARP 應答。下面介紹的 updelay 參數必須被設置為某個大於等於 switch 轉發延時的值，從而保證發往對端的 ARP 應答 不會被switch(交換機)阻截。
必要條件：
條件1：ethtool 支持獲取每個 slave 的速率；
條件2：底層驅動支持設置某個設備的硬件地址，從而使得總是有個 slave (curr_active_slave) 使用 bond 的硬件地址，同時保證每個 bond 中的 slave 都有一個唯一的硬件地址。如果 curr_active_slave 出故障，它的硬件地址將會被新選出來的 curr_active_slave 接管
其實mod=6與mod=0的區別：mod=6，先把 eth0 流量占滿，再占 eth1，….ethX；而 mod=0 的話，會發現2個口的流量都很穩定，基本一樣的帶寬。而 mode=6，會發現第一個口流量很高，第2個口只占了小部分流量
此文以 mode=6 為例
第一步，為虛擬機添加兩塊萬兆網卡
第二步創建一塊虛擬網卡 bond0
第三步為 ens224 和 ens256 兩塊網卡創建配置文件並將兩塊網卡作為 bond0 網卡的 slave
第四步重載並激活 bond0 網卡
然后查看 bond0 網卡的帶寬
查看 bond0 網卡的 ip 地址和兩塊物理網卡的狀態
查看 bond0 的詳細信息
最后我們通過模擬網卡故障查看流量通過狀態 (即斷開當前活躍的 slave)
用同一網段的主機去 ping bond0 的 IP 地址，同時 Stream8-clone1 端進行抓包分析
一共 ping 了四次，通過 tcpdump 也抓到了四對 request 和 reply