M-LAG（Multichassis Link Aggregation Group）即跨裝置鏈路聚合組，是一種實現跨裝置鏈路聚合的機制，如下圖所示，將SwitchA和SwitchB透過peer-link鏈路連線並以同一個狀態和Switch進行鏈路聚合協商，從而把鏈路可靠性從單板級提高到了裝置級。
M-LAG除了具備增加頻寬、提高鏈路可靠性、負載分擔的優勢外，還具備以下優勢：
更高的可靠性：把鏈路可靠性從單板級提高到了裝置級。
簡化組網及配置：可以將M-LAG理解為一種橫向虛擬化技術，將雙歸接入的兩臺裝置在邏輯上虛擬成一臺裝置。M-LAG本身提供了一個沒有環路的二層拓撲同時實現冗餘備份，極大的簡化了組網及配置。
獨立升級：兩臺裝置可以分別進行升級，保證有一臺裝置正常工作即可，對正在執行的業務幾乎沒有影響。
M-LAG的基本概念
如下圖所示，使用者側裝置Switch（可以是交換機或主機）透過M-LAG機制與另外兩臺裝置（SwitchA和SwitchB）進行跨裝置鏈路聚合，共同組成一個雙活系統。這樣可以實現SwitchA和SwitchB共同進行流量轉發的功能，保證網路的可靠性。
M-LAG涉及的相關概念，如下表所示。
概念
說明
DFS Group
動態交換服務組DFSGroup（DynamicFabricServiceGroup），主要用於部署M-LAG裝置之間的配對。
M-LAG雙歸裝置之間的介面狀態，表項等資訊同步需要依賴DFS Group協議進行同步。
DFS主裝置
部署M-LAG且狀態為主的裝置，通常也稱為M-LAG主裝置。
DFS備裝置
部署M-LAG且狀態為備的裝置，通常也稱為M-LAG備裝置。
說明：
DFS Group的角色區分為主和備，正常情況下，主裝置和備裝置同時進行業務流量的轉發，轉發行為沒有區別，僅在故障場景下，主備裝置的行為會有差別。
雙主檢測鏈路
雙主檢測鏈路，又稱為心跳鏈路，是一條三層互通鏈路，用於M-LAG主備裝置間傳送雙主檢測報文。用於檢查是否出現雙主的情況。
雙主檢測鏈路可以透過外部網路承載，也可以單獨配置一條三層可達的鏈路來作為雙主檢測鏈路。
peer-link鏈路
peer-link鏈路是一條直連鏈路且必須做鏈路聚合，用於交換協商報文及傳輸部分流量。
peer-link介面
peer-link鏈路兩端直連的介面均為peer-link介面。介面配置為peer-link介面後，該介面上不能再配置其它業務。
HB DFS主裝置
透過心跳鏈路來協商的狀態為主的裝置。
HB DFS備裝置
透過心跳鏈路來協商的狀態為備的裝置。
說明：
在正常情況下，HB DFS主備狀態對M-LAG的轉發行為不會產生影響，僅用於二次故障恢復場景下，在原DFS主裝置或備裝置故障恢復且peer-link鏈路仍然故障時，觸發HB DFS狀態為備的裝置上相應埠Error-Down，避免M-LAG裝置在雙主情況下出現的流量異常。
M-LAG成員介面
M-LAG主備裝置上連線使用者側主機（或交換裝置）的Eth-Trunk介面。
M-LAG成員介面角色也區分主和備，與對端同步成員口資訊時，狀態由Down先變為Up的M-LAG成員介面成為主M-LAG成員口，對端對應的M-LAG成員口為備。
說明：
僅在M-LAG接入組播場景下，M-LAG成員介面的主備角色存在轉發行為差異。
M-LAG協議互動原理
如下圖所示，M-LAG的建立過程有如下幾個步驟：
DFS Group配對
當裝置完成M-LAG配置後，裝置首先透過peer-link鏈路傳送DFS Group的Hello報文。當裝置收到對端的Hello報文後，會判斷報文中攜帶的DFS Group編號是否和本端相同，如果兩臺裝置的DFS Group編號相同，則兩臺裝置DFS Group配對成功。
DFS Group協商主備
配對成功後，兩臺裝置會向對端傳送DFS Group的裝置資訊報文，裝置根據報文中攜帶的DFS Group優先順序以及系統MAC地址確定出DFS Group的主備狀態。
以SwitchB為例，當SwitchB收到SwitchA傳送的報文時，SwitchB會檢視並記錄對端資訊，然後比較DFS Group的優先順序，如果SwitchA的DFS Group優先順序高於本端的DFS Group優先順序，則確定SwitchA為DFS主裝置，SwitchB為DFS備裝置。如果SwitchA和SwitchB的DFS Group優先順序相同，比較兩臺裝置的MAC地址，確定MAC地址小的一端為DFS主裝置。
M-LAG成員介面協商主備
在DFS Group協商出主備狀態後，M-LAG的兩臺裝置會透過peer-link鏈路傳送M-LAG裝置資訊報文，報文中攜帶了M-LAG成員介面的配置資訊。在成員口資訊同步完成後，確定M-LAG成員介面的主備狀態。
與對端同步成員口資訊時，狀態由Down先變為Up的M-LAG成員介面成為主M-LAG成員口，對端對應的M-LAG成員口為備，且主備狀態預設不回切，即：當M-LAG成員介面狀態為主的裝置故障恢復後，先前由備狀態升級為主狀態的介面仍保持主狀態，恢復故障的M-LAG成員介面狀態為備。
雙主檢測
協商出M-LAG主備後，兩臺裝置之間會透過雙主檢測鏈路按照1s的週期傳送M-LAG雙主檢測報文，一旦裝置感知peer-link故障，會按照100ms的週期傳送三個雙主檢測鏈路報文，加速檢測。當兩臺裝置均能夠收到對端傳送的報文時，雙活系統即開始正常的工作。
M-LAG同步資訊
正常工作後，兩臺裝置之間會透過peer-link鏈路傳送M-LAG同步報文實時同步對端的資訊，M-LAG同步報文中主要包括MAC表項、ARP以及STP等，併發送M-LAG成員埠的狀態，這樣任意一臺裝置故障都不會影響流量的轉發，保證正常的業務不會中斷。
M-LAG防環機制
如下圖所示，從接入裝置或網路側到達M-LAG配對裝置的單播流量，會優先從本地轉發出去，peer-link鏈路一般情況下不用來轉發資料流量。當流量透過peer-link鏈路廣播到對端M-LAG裝置，在peer-link鏈路與M-LAG成員口之間設定單方向的流量隔離，即從peer-link口進來的流量不會再從M-LAG口轉發出去，所以不會形成環路，這就是M-LAG單向隔離機制。
單向隔離機制生效前提
當M-LAG兩臺裝置協商出M-LAG主備後，系統透過M-LAG同步報文判斷接入裝置是否雙活接入：
若接入裝置雙活接入M-LAG系統，則M-LAG兩臺裝置下發對應M-LAG成員口的單向隔離配置，來隔離由peer-link口發往M-LAG成員口的流量。
說明：
M-LAG防環機制中的單向隔離對二層（包括單播、組播、廣播）流量生效，三層組播流量生效，三層單播流量不生效。
若接入裝置單歸接入M-LAG系統，則M-LAG系統不會下發對應M-LAG成員口的單向隔離配置。
單向隔離機制實現原理
如下圖所示，在裝置雙活接入M-LAG場景下，裝置會預設按下列順序下發全域性ACL配置：
Rule1：允許透過源埠為peer-link介面，目的埠為M-LAG成員口的三層單播報文；
Rule2：拒絕透過源埠為peer-link介面，目的埠為M-LAG成員口的所有報文；
當M-LAG裝置感知到本端的M-LAG成員口狀態為Down時，會透過peer-link傳送M-LAG同步報文，通知對端裝置撤銷自動下發的相應的M-LAG成員埠的單向隔離ACL規則組。
M-LAG配置一致性檢查
M-LAG運用於企業網中時，面臨一個突出的問題：部署企業網資料中心時，透過手工配置、人工比對來保證每一個M-LAG系統兩端裝置的配置一致性，不僅處理效率低下，更多的是帶來諸多潛在的誤配置風險。
為了解決上述問題，華為公司提出了M-LAG配置一致性檢查的解決方案。該解決方案中，透過M-LAG機制自帶的配置一致性檢查功能，去訂閱M-LAG系統兩端裝置的各模組配置。透過檢查功能返回的比對結果，及時地調整M-LAG兩端裝置的配置部署，防止組網成環或者資料丟包等問題發生。
M-LAG配置一致性檢查將裝置配置分為兩類，分別為關鍵配置（Type 1）和一般配置（Type 2）。根據對關鍵配置檢查不一致時的處理方式，M-LAG一致性又分為嚴格模式（strict）和鬆散模式（loose）。
關鍵配置（Type 1）：如果在M-LAG系統兩端裝置不一致，會導致成環、狀態正常但長時間丟包等問題。
嚴格模式下，如果M-LAG兩端裝置存在Type 1配置不一致，會導致M-LAG備裝置上成員口處於ERROR DOWN狀態，且觸發裝置對Type 1型別配置檢查不一致的告警。
鬆散模式下，如果M-LAG兩端裝置存在Type 1配置不一致，則會觸發裝置對兩種型別配置檢查不一致的告警。
一般配置（Type 2）：如果在M-LAG系統兩端裝置不一致，可能會導致M-LAG執行狀態異常。與Type 1型別的配置相比較而言，Type 2型別的配置問題更容易被發現，對組網環境的影響也相對較小。
無論處於何種模式，如果M-LAG兩端裝置存在以下Type 2配置不一致，只會觸發裝置對兩種型別配置檢查不一致的告警。
M-LAG正常工作場景流量轉發
單播流量轉發
單播流量轉發包括二層已知單播轉發和三層單播轉發。如下圖所示，M-LAG雙活系統在接入裝置雙歸接入場景下的已知單播流量轉發：
對於南北向單播流量，在M-LAG接入側，M-LAG的成員裝置接收到接入裝置透過鏈路捆綁負載分擔傳送的流量後，共同進行流量轉發。到達M-LAG主備裝置發往網路側的流量則根據路由錶轉發流量。
對於東西向單播流量，在全部組建M-LAG，沒有孤立埠的場景下，二層流量透過M-LAG本地優先轉發，三層流量透過雙活閘道器轉發，都不經過peer-Link鏈路，直接由M-LAG主備裝置轉發至對應成員口。
組播流量轉發
M-LAG接入二層網路
M-LAG上行接入二層網路，那麼二層網路必須要保證發往M-LAG的流量只有一份，否則會有成環的風險。如下圖所示，假設右側M-LAG上行介面被STP協議阻塞：
在ServerB作為組播源、ServerA作為組播組成員時，M-LAG主備都可以轉發組播流量，在網路側只引流一份流量的情況下，接收到流量的裝置直接轉發到本地的M-LAG成員口
在ServerA作為組播源、ServerB作為組播組成員時，組播源的流量透過負載分擔傳送至M-LAG主備裝置，由於右端M-LAG裝置的上行介面被阻塞，那麼右端裝置的組播出介面指向peer-link鏈路。
如果本地M-LAG成員口故障，則組播流量如下圖所示會從peer-link繞行，轉發至M-LAG系統另一臺裝置的成員口進行轉發。
M-LAG接入三層網路
M-LAG上行接入三層網路，M-LAG系統成員裝置需要支援二三層組播混跑。如下圖所示，M-LAG雙活系統在接入裝置雙歸接入場景下的組播流量轉發：
在ServerB作為組播源、ServerA作為組播組成員時，M-LAG主備裝置都從組播源引流，且按照以下規則由M-LAG主備裝置在本地查詢組播表後將流量負載分擔轉發至組播組成員：
若組播組地址最後一位為奇數（例如225。1。1。1或FF1E：：1、FF1E：：B），則由M-LAG成員口狀態為主的裝置轉發至組播組成員；
若組播組地址最後一位為偶數（例如225。1。1。2或FF1E：：2、FF1E：：A），則由M-LAG成員口狀態為備的裝置轉發至組播組成員；
在ServerA作為組播源、ServerB作為組播組成員，且M-LAG裝置無下掛其他組播組成員時，組播源發出的流量負載分擔到M-LAG系統主備裝置，收到流量後在本地查詢組播表將報文傳送出去。
區別於單播流量，M-LAG系統在轉發組播流量時需要在M-LAG兩臺裝置間配置一條獨立三層鏈路。因為在故障場景下，可能出現網路側只有單鏈路上行，此時M-LAG主備裝置間部署一條獨立的單獨L3鏈路可以用來傳輸組播報文。如下圖所示，在網路側鏈路連線M-LAG備裝置場景下，由peer-link介面轉發的組播報文由於單向隔離無法轉發至指定的M-LAG成員口，組播地址最後一位為奇數的組播報文是無法透過peer-link鏈路繞行至M-LAG成員口狀態為主的裝置，只能由獨立三層鏈路轉發至該裝置。
廣播流量轉發
M-LAG接入二層網路
M-LAG上行接入二層網路，那麼二層網路必須要保證發往M-LAG的流量只有一份，否則會有成環的風險。此處以M-LAG主裝置的轉發為例，如下圖所示，假設右側M-LAG上行介面被STP協議阻塞，M-LAG主裝置收到廣播流量後向各個下一跳轉發，當流量到達M-LAG備裝置時，由於peer-link與M-LAG成員介面存在單向隔離機制，到達備裝置的流量不會向S-1轉發。
M-LAG接入三層網路
以M-LAG備裝置的轉發為例，如下圖所示，M-LAG備裝置收到廣播流量後向各個下一跳轉發，當流量到達M-LAG主裝置時，由於peer-link與M-LAG成員介面存在單向隔離機制，到達主裝置的流量不會向S-1轉發。
M-LAG故障場景流量轉發
上行鏈路故障
如下圖所示，M-LAG接入普通乙太網場景，由於M-LAG主裝置的上行鏈路故障，透過M-LAG主裝置的流量均經過peer-link鏈路進行轉發。
當故障的上行鏈路恰好為雙主檢測鏈路，此時對於M-LAG正常工作沒有影響。一旦peer-link也發生故障，M-LAG出現雙主衝突，雙主檢測又無法進行，則會出現丟包現象。
M-LAG接入三層網路場景下，需要在M-LAG主備裝置間配置直連三層鏈路，使得到達Master裝置的上行流量透過三層逃生鏈路到達Backup裝置。
下行鏈路故障
當下行M-LAG成員口故障時，DFS Group主備狀態不會變化，但如果故障M-LAG成員口狀態為主，則備M-LAG成員口狀態由備升主，流量切換到該鏈路上進行轉發。發生故障的M-LAG成員口所在的鏈路狀態變為Down，雙歸場景變為單歸場景。
在M-LAG主成員口故障的同時，主裝置學習到的S-1側MAC不會被清除，直接重新整理MAC表的出埠指向peer-link口，實現流量快速切換，避免未知單播泛洪。
在故障M-LAG成員口恢復後，MAC表的出埠從peer-link指向M-LAG成員口，實現流量快速切換，避免未知單播泛洪。同時，為避免M-LAG主備成員狀態切換造成的某些協議振盪，裝置支援M-LAG成員口狀態不再回切，即由備升主的M-LAG成員口狀態仍為主，原主M-LAG成員口在故障恢復後狀態為備。
M-LAG裝置故障
M-LAG主裝置故障，M-LAG備裝置將升級為主，其裝置側Eth-Trunk鏈路狀態仍為Up，流量轉發狀態不變，繼續轉發流量。M-LAG主裝置側Eth-Trunk鏈路狀態變為Down，雙歸場景變為單歸場景。
如果是M-LAG備裝置發生故障，M-LAG的主備狀態不會發生變化，M-LAG備裝置側Eth-Trunk鏈路狀態變為Down。M-LAG主裝置側Eth-Trunk鏈路狀態仍為Up，流量轉發狀態不變，繼續轉發流量，雙歸場景變為單歸場景。
M-LAG裝置故障恢復時，peer-link先UP，DFS狀態重新協商，M-LAG成員口恢復UP，流量恢復負載分擔。M-LAG主裝置恢復後設備狀態仍然為主，M-LAG備裝置恢復後設備狀態仍然為備。
心跳鏈路故障
心跳鏈路是用來處理peer-link故障時檢測M-LAG系統是否是雙主，若心跳鏈路承載三層網路的業務，心跳故障對裝置流量轉發會有影響。若心跳鏈路承載二層業務或不承載三層業務，心跳故障對裝置流量轉發無影響。兩種情況都會產生心跳故障告警。心跳鏈路故障恢復後，產生心跳故障恢復告警。
peer-link故障
預設情況下，M-LAG應用在普通乙太網絡、VXLAN網路或IP網路的雙歸接入，peer-link故障但雙主檢測心跳狀態正常時，會觸發M-LAG備裝置上除邏輯埠、管理網口、peer-link介面和堆疊口以外的其他介面處於Error-Down狀態。
peer-link故障恢復時，處於Error Down狀態的M-LAG介面預設將在240s後自動恢復為Up狀態，處於Error Down狀態的其它介面將立即自動恢復為Up狀態。
M-LAG二次故障（peer-link故障+M-LAG裝置故障）
如下圖中2所示，在M-LAG應用於雙歸接入時，當peer-link故障但雙主檢測心跳狀態正常會觸發DFS備裝置上某些埠處於Error-Down狀態，此時DFS狀態為主的裝置繼續工作。在該場景的基礎上，若DFS狀態為主的裝置由於斷電、主控板損壞、整機故障重啟等其他故障導致主裝置不能工作時，由下圖中3所示，此時M-LAG主備裝置皆不能正常轉發流量。
在該場景下，可以藉助M-LAG二次故障增強功能來實現該故障場景下業務不中斷的可靠性要求。在上述場景基礎下，若M-LAG已使能二次故障增強功能，則DFS狀態為備的裝置會藉助M-LAG雙主檢測機制感知到DFS主裝置故障（在一定週期內接收不到任何的M-LAG雙主檢測心跳報文）後，將升級為DFS主裝置並恢復裝置上處於ERROR DOWN狀態的埠為Up狀態，繼續轉發流量。
若原DFS狀態為主的裝置故障恢復後但peer-link故障仍故障時：
若配置LACP M-LAG的系統ID在一定時間內切換為本裝置的LACP系統ID，則在LACP協商時接入側僅選擇上行鏈路中的一條鏈路為活動鏈路，實際流量轉發正常。
若配置LACP M-LAG的系統ID為預設情況，即系統ID不回切，M-LAG兩臺裝置均使用同一系統ID來與接入側裝置協商，鏈路均能被選中成為活動鏈路。該場景下，由於peer-link鏈路仍然故障，M-LAG兩端無法同步對端的優先順序、系統MAC等資訊，形成M-LAG兩臺裝置雙主的情況，可能導致流量異常。此時，如下圖所示，可以藉助心跳鏈路報文中攜帶必要的DFS Group協商主備的必要資訊（如DFS Group優先順序、系統MAC等）來協商M-LAG兩臺裝置的HB DFS主備資訊，觸發HB DFS狀態為備的裝置上某些埠處於ERROR DOWN狀態，HB DFS狀態為主的裝置繼續工作。
