鏈路聚合通過聚合多條並行的物理鏈路，對上層協議表現為一條邏輯鏈路，來提高吞吐量和冗余性。常見的鏈路聚合技術有Cisco的Etherchannel
,華為的Eth-trunk 以及 linux bonding 等。鏈路聚合分為動態和靜態兩種，靜態的通過手工配置，動態的通過協議協商。IEEE 規定的鏈路聚合標准
LACP(Link Aggregation Control Protocol)使用的最為廣泛1。
以太網的鏈路帶寬是以10Mbps、100Mbps、1000Mpbs、10Gbps等，速率增長是離散的，鏈路聚合可以線性的增加鏈路帶寬，例如兩交換機之間的流量大於1Gbps小於2Gbps，利用鏈路聚合綁定兩個千兆鏈路可以很好的解決問題；另一種情況，兩交換機之間的流量大約11Gbps,可以利用鏈路綁定一條千兆一條萬兆鏈路嗎？下面的文章就來討論這個問題。
靜態與動態
靜態鏈路聚合:
不需要使用控制協議（i.e 不使用基於網絡的協議），通過手工配置生效，當聚合口組成員端口啟動后，立即生效（成為活動的成員端口）。
動態鏈路聚合：
需要使用鏈路聚合控制協議（LACP）,端口通過配置加鏈路聚合組，但是否生效（被選中成為活動的成員端口）取決於LACP的協商結果。
初見鏈路聚合——一個拓撲實踐
在詳細介紹鏈路聚合之前，先來討論圖1拓撲，初步挖掘一下鏈路聚合技術，這個神奇的拓撲在《MSTP 解決鏈路負載均衡與鏈路檢測》一文中用於討論MSTP 在該拓撲上的適用性，這里面用來討論鏈路聚合依然很合適（它依然能引出很多問題）。
情景：如圖1 所示，link1 是裸光纖鏈路，link2 中間加了百兆收發器。
問：這樣的拓撲能否使用鏈路聚合技術？
答案:是不行的，鏈路聚合技術有很多限制，不同廠商的實現雖然不同，但是仍需要遵循這些限制，如圖1 jieru 的E0/0/2 是一個百兆端口，G0/0/1 是一個千兆端口，二者的物理層實現不一樣，無法聚合，圖1 jieru 上配置e0/0/2與g0/0/1鏈路聚合會報錯。
假設1：將jieru e0/0/2 換成千兆端口(G0/0/2)。
問：圖1 拓撲可否使用鏈路聚合呢？
答案:可以配置成靜態的端口聚合，但是靜態端口聚合可能會導致轉發黑洞。
先來看看link1與link2 有何不同。第一 對應兩台交換機來說，g0/0/1 和g0/0/2 一個是光口，一個是電口，介質不同；第二 link1 實際速率(或者說 工作速率 speed)為1000Mbps,link2 實際速率為100Mbps。
第一，介質不同的兩個端口可以做鏈路聚合嗎？原則上是不行的，但是事實上很多廠商已經實現這一功能2，只要兩條鏈路都是全雙工點對點鏈路就行。
第二，工作速率不同的兩個端口可以做鏈路聚合嗎？動態鏈路聚合（基於LACP）不支持非等速率鏈路聚合,LACP 要求參與聚合的N條平行的鏈路 必須是全雙工點對點端口，並且實際速率相同3；靜態鏈路聚合並沒有找到明確的規范，實際測試是可以聚合工作速率不同的兩端口的。
根據華為的實現，huiju上將G0/0/1 - 2 配置到一個Eth-trunk 中，在huiju上顯示
Eth-trunk 的帶寬為1.1Gbps,實際上鏈路帶寬不一定能到這么大（見下文 負載均衡章節分析）。
而就算靜態鏈路聚合可以很好的解決負載問題，但是依然解決不了圖1 拓撲中潛在的風險，在《MSTP 解決鏈路負載均衡與鏈路檢測》中談到，應用在圖1 中的冗余協議必須要解決對Link2的鏈路檢測問題，才能避免轉發黑洞。靜態配置的鏈路聚合無法感知link2 光纖鏈路故障（不依賴hello消息），故障發生后相當一部分數據幀會被送入無休止的黑洞。
假設2：目前的光纖傳輸技術發展的很快，利用DWDM技術，在單個波長上甚至都能傳輸40Gbps的流量，單條裸光纖使用百兆收發器實在浪費，將圖1 中的百兆收發器改成高端些的光端機，為Link2 提供1Gbps的鏈路帶寬。可以滿足LACP的要求使用動態鏈路聚合技術了。
問1：圖1 使用LACP聚合的link2 還會產生流量轉發黑洞嗎?
答：是不會的，使用LACP聚合的鏈路，會周期性的交換LACPDU,Link2 光纖鏈路故障發生后，LACP 可以感知到，從而將G0/0/2 端口置為非活動狀態，分配給其的會話流量重新分配給G0/0/1 ,因而只會短暫的出現網絡中斷。
**問2：**link2 光纖鏈路故障后，LACP多久才能感知到？
**答：**LACP雙方在協商階段會較頻繁的發送LACPDU,當協商完成確定要聚合的鏈路后，LACP雙方默認Slow Periodic Time模式下，30s發送一次LACPDU,Long Timeout Time 90s;因此LACP 大約需要90s 才能感知到link2 光纖故障。對於有些業務來說90s的時間太長了，可以調整LACP 工作在Fast Periodic Time 模式下（僅當確認業務不繁忙，且端到端延時較小的情況下，不然造成LACP 震盪），1s 交互一次LACPDU ,Short Timeout Time 3s,從而實現故障快速感知切換。
鏈路聚合原理分析
上文已經談到，鏈路聚合分為動態與靜態兩種，靜態模式的鏈路聚合會造成不可預料的問題，在多數情況下建議使用動態模式下的鏈路聚合，使用鏈路聚合控制協議自動去協商、評估、聚合鏈路。這節從最常見的鏈路聚合控制協議（LACP）入手，分析鏈路聚合的原理。
分層模型
在OSI分層參考模型中，鏈路聚合工作數據鏈路層的鏈路聚合子層，MAC子層之上，MAC Client之下。鏈路聚合子層可以聚合多個獨立的鏈路,向MAC Client 提供單一的MAC 接口，見下圖2
Aggregator (聚合器)為鏈路聚合組提供數據傳輸和接收的方法，並向MAC Client 提供單一的MAC 接口，Aggregator包含Frame Collector 和 Frame Distributor，Frame Collector負責從聚合鏈路組中接收數據幀，傳遞給MAC Client,Frame Distributor將從MAC Client 收取的數據幀通過聚合鏈路組傳輸出去，無論是接收還是傳輸數據幀，都必須要避免數據幀亂序或者重復;Aggregator Control 中，LACP 負責與對端系統通過Control Frame 交換信息，協商決定聚合哪些鏈路，以及使能或關閉聚合組，Aggregator Control 通過共享變量實現對Aggregator 的控制。圖示見上圖3 5.
LACPDU
鏈路聚合控制協議（LACP）通過交互LACPDU,為配對雙方協商聚合哪幾條條鏈路、以及協商如何在聚合鏈路上正確的發送與接收數據。LACPDU的格式
LACPDU 通過二層組播發送。LACPDU結構中字段很多，這里先介紹一下什么是“Actor”與“Partner”。
鏈路兩端的LACP參與者，通過組播向鏈路上發送LACPDU，參與者發送LACPDU時，本地系統就稱為“Actor”，遠端系統就稱為“Partner”（換句話說，每個參與者都認為自己是“Actor”,對方是“Partner”）。
LACP狀態機
Receive machine：接收並維護與Partner的狀態;
Periodic Transmission machine：負責周期性的傳送LACPDU,保持聚合狀；
Selection Logic ：負責為端口選擇合適的Aggregator，稱:“端口選擇了Aggregator” 為”selected”;
Mux machine:負責將端口附着到對應的Aggregator（或分離） ，並且負責使能端口接收或轉發數據（或關閉）；
Transmit machine：負責周期性的或按其他狀態機的要求傳輸LACPDU。
當LACP協商開始時，Receive machine 負責與Partner 交換配置信息，當Actor和Partner信息交換完畢后（雙方完全知曉了對方的信息），Selection Logic 依據對應的算法為端口選擇Aggregator,選擇完畢后，Mux machine將處於”selected”狀態的端口附着在其對應的Aggregator上，並使能數據轉發；此后Aggregator便可收取MAC Client 的數據幀，向端口組分發，並且收集端口組轉發來的數據幀，傳遞給 MAC Client；鏈路聚合完成后，Periodic Transmission machine 周期性的傳送LACPDU,Receive machine 接收LACPDU，共同負責保持、維護LACP鏈路聚合組的狀態；Transmit machine 在整個過程中，負責LACPDU的傳輸。
LACPDU的Actor/Partner State
LACP 使用LACPDU 向對端系統傳達自身目前的狀態（Actor State）、自己已知的對端系統的狀態（Patner State）,完成協商過程。
1、協商開始之前，參與者雙方都未收到對方的LACPDU,因此端口狀態為
Active, Aggeration, defaulted
1
Active：表示系統在該鏈路使能了LACP;
Aggeration：表示系統認為該鏈路是“有聚合能力的”；
defaulted：表示系統Receive machine 未獲得”Partner”的LACPDU,因此將Partner的信息置於默認值。
2、協商開始后，參與者雙方收到了對方的LACPDU,獲知了對方的信息，LACP為端口選擇了合適的Aggregator,端口會置於以下狀態通知對方：
Active, Aggeration, Synchronization
1
Synchronization：表示系統認為該鏈路已經加入了聚合組，選擇了合適的aggregator。
3、當參與者雙方的端口都處於2狀態時，說明協商成功，該鏈路可以加入鏈路聚合組，參與者端口會置於以下狀態通知對方：
Activity, Aggregation, Synchronization, Collecting, Distributing
1
Collecting：表示Frame Collector 已經使能，准備接收數據幀；
Distributing：表示Frame Distributor 已經使能，准備分發數據幀。
4、最終參與者雙方都處於3狀態，鏈路聚合完成，開始准備轉發數據幀。
Selection 算法
簡介
Selection 算法或者叫Selection邏輯，是LACP協議中最核心的部分。Selection為端口選擇Aggregator,實際上就是決定哪些端口可以聚合，並形成鏈路聚合組。開始介紹前先了解一下幾個概念：
KEY：每個端口、aggregator 都對應一個key，擁有相同key的一組端口，具有聚合的潛力。端口的key 由端口的速率、雙工狀態、點對點狀態以及管理配置信息等決定，具有相同key的端口才有可能聚合在一起。在推薦的實現中，每個端口對應一個aggregator,該aggregator的key與對應的端口的key相同。
System Identifier:由LACP參與者的MAC地址(one of the ports of the System)和優先級（priority）組成。System Identifier用來決定Master與Salve,優先級值小的系統成為Master,優先級相同，則mac地址值小的成為Master。
LAG ID:譯為，鏈路聚合組標識符。同一鏈路聚合組內的端口的LAG ID 相同。LAG ID由 Actor System Identifier、Actor port key、Partner System Identifier、Partner port key組成。
SElELCTED:當一個端口處於SElELCTED狀態，說明該端口已經選擇了合適的Aggregator，准備下一步准備attach到Aggregator，完成鏈路聚合。
很多LACP的實現中，都需要管理員手動的在每個系統配置待聚合的端口組(如思科的EtherChannel),再由LACP協商決定哪些端口可以聚合。
算法6
每一個待聚合端口組只能產生一個鏈路聚合組，鏈路聚合組中端口的LAG ID 相同，其他端口處於”UNSELECTED（不選擇任何Aggregator）”狀態 ;
Master系統，從待聚合端口組中優先級最高的端口開始選擇，端口選擇KEY與其相同的Aggregator（SELECTED），次優先級的端口如果LAG ID與最高優先級端口相同，則選擇同一個Aggregator,若不同，則置於“UNSELECTED”狀態，執行下一個端口，直到選擇完畢。
Slave系統根據Master的選擇，決定聚合哪些端口。
Master P1-3 屬於待聚合端口組5，且端口的速率等信息相同，因此Key都為401(系統計算),
Slave P1 P3屬於待聚合端口組10，P2 屬於帶聚合端口組5，因此Key不相同。Master上P1-3的priority都為默認值，因此Port id 最小的P1 是最高優先級的端口，P1首先選擇自己對應的aggregator；從圖上可以看到P2的LAG ID (401，401,401，401)與P1 的LAG ID(401,401，12945，12945)不同，因此P2 置於”UNSELECTED”狀態；P3的LAG ID與P1相同，因此P3 選擇與P1 同一個aggregator ;Slave 根據Master 的聚合結果聚合自己的端口。
如圖6，將P2 的Priority改為0，因此P2成為了待聚合端口組中最高優先級端口，P2選擇了自己對應的aggregator,由於P1、P3的LAG ID與P2不同，因此P1、P3置於“UNSELECTED”狀態。
負載均衡與權重
這節討論aggregator如何分發（從鏈路聚合組中選擇一條成員鏈路並轉發）上層協議（MAC Client）的數據幀，如圖3 aggregator 中的Frame Distributor負責分發數據幀，分發需有一定的負載均衡算法， 使數據幀相對均勻的分布在不同的成員鏈路上，達到擴展帶寬的作用。不同的鏈路聚合實現有多種分發負載算法，但每種分發算法最好都不要產生：
給定的會話7 數據幀亂序
數據幀重復
數據幀亂序或者重復都會對接收者造成不良影響，為避免產生着兩種情況，有一個約定俗成的規則，即：所有屬於給定會話的數據幀 必須保證從同一鏈路轉發。 這就要求給定會話無論何時到達Frame Distributor,Frame Distributor需要為其選擇固定的一條鏈路，也就是說選擇算法是”history Independent”,可以為每個會話維護一張轉發端口的對應表，當第一個數據幀選擇鏈路轉發后，后續的數據幀依照轉發表轉發，如此減輕設備的計算負擔。
幾種負載均衡算法
滿足上述規則的負載方式有很多，鏈路聚合可以使用 MAC 、IP、Layer4 port numbers 逐流負載，可以是基於源地址（端口）、目的地址（端口）或者兩種都有8。可以根據不同的拓撲類型選擇不同的負載方法。
Example A 是典型的“多對多”傳輸的場景，SW1 和 SW2 之間的聚合鏈路基於源MAC或目的MAC（src-mac or dst-mac）分發，即可將流量負載在各個成員鏈路;
Example B 多台PC同一台路由器通信，路由器的IP、MAC都只有一個，因此源自PC的流量需使用源MAC 負載，源自路由器的流量需使用目的MAC負載。（SW1 src-mac,SW2 dst-mac);
Example C 假設兩台服務器所有的通信都使用相同的MAC地址，若實現負載，基於IP或MAC的負載方式都不行，可利用高層協議的信息負載，比如Layer4 port numbers。
非等價鏈路聚合？
回到圖1 的問題，LACP為什么不能聚合速率不同的鏈路？端口的Key會依據速率（speed）等信息計算，如果速率不同，端口的Key就會不同，LACP無法聚合。上文說過可以通過靜態的鏈路聚合將速率不同的鏈路聚合起來，但喪失了LACP的特性。目前LACP標准中還不能支持非等價鏈路聚合。
非等價鏈路聚合設想
假設需要帶寬為12Gbps的鏈路，如何適配LACP才能實現呢，這里有個設想：
首先LACP key的計算將端口速率排除在外，這樣不同速率的端口key 的計算值相同，可以聚合在一起。只有這樣是不行的，12Gbps的鏈路需要聚合三條鏈路帶寬分別是10Gbps、1Gbps、1Gbps，以現有的分發負載方式是無法應對不同速率的端口的。可為每個端口維護一個Weight（權重）值，比如10Gpbs端口的weight是10，1Gbps的weight 是 1，Frame Distributor 依據不同的權重將10/12的會話分發到10Gbps的端口，將1/12的會話分發到1Gbps的端口。
這里有個兩個問題，第一 Frame Distributor 不可能預知鏈路的會話數量，該怎樣依據比例分發會話呢？第二 每個會話的流量不同，以會話為粒度負載有可能會造成流量負載不均，甚至擁塞。
為解決這兩個問題，使用基於端口負載的動態的權重也許行得通。下面設想一下方案：
為了獲得更好的負載效果，將權重的基數設為100Mbps，因此10Gbps的原始權重是10000Mpbs/100Mbps=100,1Gbps的原始權重是10；
當一個數據幀到達，獲取當前3個端口的負載量（以Mbps為單位），X=負載量整除100，原始權重減去X等於當前端口權重，數據幀從當前權重最大的端口轉發。
維護一張轉發表，轉發表中是會話的信息與轉發端口的對應表，當一個數據幀到達時，先搜索轉發表，有對應的轉發條目直接轉發，沒有對應的轉發條目則執行上述2轉發規則，計算出端口后，轉發條目維護進轉發表。
這里面端口負載量的計算很有講究，由於會話的流量是動態的，時大時小，因此負載量須是一段時間的平均負載量，時間跨度取大了或取小了都會對實際負載效果造成影響。
實際實現中，轉發表的最大可維持的條目數也有講究。條目數太多，會過度占用設備的內存，並且尋址時間會增加；條目數太少，會影響選擇算法的”history Independent”，同一會話的數據有可能從不同鏈路轉發，造成亂序或幀重復。