看過了紅寶書之前的之前的部分，相信大家對數據中心網絡虛擬化技術有了一些基本的認識。本文所要討論的M-LAG技術是一種跨設備的鏈路聚合技術，主要的應用場景是雙歸接入場景。

我們先簡單總結一下之前的內容，在服務器跨核心層二層互訪模型中，核心層與接入層設備有兩個問題是必須要解決的，一是拓撲無環路，二是多路徑轉發。但是傳統以太網通過xSTP破環無法做到多路徑轉發，於是產生了以下兩種解決的思路：

思路一：控制平面虛擬化（堆疊/VSS/IRF&SVF/FEX/IRF3）

控制平面虛擬化的思想是將核心層虛擬成一臺邏輯設備，通過鏈路聚合使此邏輯設備與每個接入層物理或邏輯節點設備均只通過一條邏輯鏈路連接，將整個網絡邏輯拓撲變成一個無環的樹狀連接結構，從而滿足無環與多路徑轉發的需求。

控制平面虛擬化解決了二層網絡無環和多路徑問題，但是其技術本身也存在一些問題：

1. 擴展性受限，受到Master設備性能限制。

2. 可靠性問題，控制平面完全耦合，控制面故障可能導致整個系統故障。

3. 維護麻煩，無法進行獨立設備升級。升級時由於控制面完全耦合，業務中斷時間較長。無損升級（ISSU）的方案操作起來非常麻煩。

思路二：數據平面虛擬化（TRILL/FP&Nvo3）

數據平面虛擬化即在原本的以太網絡上引入一套新的尋址機制（新的尋址標識或者借助IP轉發機制）來解決二層多路徑問題。對接入層以下的設備來說，整個中間系統被虛擬成了一臺框式交換機，原始報文進入這個中間系統，不關心在其中做了什麽處理，只需要知道報文會原封不動的從另外一端出來，就如同兩臺服務器被連到了一臺二層交換機上，而在二層交換機內部，可以通過各種方式來實現多路徑轉發。

這類技術解決了網絡側多路徑轉發和破環問題，並且大多利用了路由的機制，解決了擴展性的問題，同時故障影響範圍也較小。但是其接入側的多路徑問題還是無法解決。比如上圖中，無論接入交換機雙歸接入，還是服務器直接雙歸接入，還是需要借助二層破環協議（例如xSTP）進行破環，無法做到多路徑轉發。

於是我們想到，何不將堆疊/SVF的機制引入到TRILL/VXLAN網絡中，為其接入側多路徑轉發服務。

這樣，一種跨設備鏈路聚合技術M-LAG（Multichassis Link Aggregation Group）產生了。

M-LAG技術的基本思想是，讓兩臺接入交換機以同一個狀態和被接入的設備進行鏈路聚合協商，在被接入的設備看來，就如同和一臺設備建立了鏈路聚合關系。其邏輯拓撲就如同上圖右側所示。

M-LAG技術本質上還是控制平面虛擬化技術，但是和堆疊/SVF技術不同的是，由於M-LAG的目的僅僅是在鏈路聚合協商時，對外表現出同樣的狀態，所以不需要像堆疊，SVF那樣同步設備上所有的信息，只需要同步接口和表項相關的一些內容。這樣，控制面耦合程度相比堆疊/SVF來說，會小很多。

這樣，堆疊/SVF技術的一些缺陷在M-LAG上也會緩解很多，比如上面我們說過的堆疊/SVF的三個主要的問題：

1. 擴展性問題：M-LAG技術並沒有解決擴展性問題，但是其主要目的是為了解決接入側多路徑問題，在數據中心網絡中一般會配合路由或者一些大二層技術。所以擴展性並非其需要考慮的問題。

2. 可靠性問題：M-LAG需要同步的僅僅是協議面的一些內容，並不需要同步所有的設備狀態，理論可靠性相對堆疊/SVF更加好。

3. M-LAG兩臺設備可以進行獨立升級。僅協議面耦合，中斷時間較短。

• M-LAG：跨設備鏈路聚合組，是一種實現跨設備鏈路聚合的機制，能夠實現多臺設備間的鏈路聚合，從而把鏈路可靠性從單板級提高到了設備級，組成雙活系統。

• M-LAG主/備設備：和堆疊/SVF一樣，M-LAG也會選取主/備設備，但是正常情況下，主/備設備轉發行為沒有區別，僅在故障場景下，主備設備的行為會有差別，在後面故障場景中我們會講到。

• Dfs-group：動態交換服務組協議，M-LAG雙歸設備之間的接口狀態，表項等信息同步需要依賴Dfs-group協議進行同步。

• Peer-link：部署M-LAG的兩臺設備之間必須存在的一條直連鏈路，且該鏈路必須為鏈路聚合且配置為peer-link。peer-link鏈路是一條二層鏈路，用於協商報文的交互及部分流量的傳輸。接口配置為peer-link接口後，該接口上不能再配置其它業務。

• Keepalive Link：心跳鏈路，承載心跳數據包，主要作用是進行雙主檢測。需要註意的是，keepalive鏈路和peer-link是不同的兩條鏈路，其作用也不一樣。正常情況下，keepalive鏈路不會參與M-LAG的任何轉發行為，只在故障場景下，用於檢查是否出現雙主的情況。keepalive鏈路可以通過外部網絡承載（比如，如果M-LAG上行接入IP網絡，那麽兩臺雙歸設備通過IP網絡可以互通，那麽互通的鏈路就可以作為keepalive）。也可以單獨配置一條三層可達的鏈路來作為keepalive鏈路（比如通過管理口）。

• M-LAG成員口：雙歸接入的接口，兩個M-LAG成員口的狀態需要進行同步。

• 單歸設備：如圖，單歸設備僅連接到M-LAG雙歸設備中的一臺。如果部署M-LAG，單歸設備是極為不推薦的。

一、M-LAG建立過程

M-LAG建立過程主要有以下幾步：

1. M-LAG兩端的設備配置完成後，會進行配對。兩邊設備會在Peer-link上定期發送Hello報文，Hello報文中攜帶了自己的DFS Group ID、協議版本號、系統MAC等信息。

2. 收到對端的Hello報文後，會判斷DFS Group ID是否相同，如果相同，則配對成功。

3. 配對成功後，會選舉主/備設備，根據優先級選舉，優先級高為主。如果優先級一樣則比較系統MAC，小的為主。缺省情況下，優先級為100，可以通過手動配置修改。

4. 配對成功之後，設備間會發送同步報文進行信息同步，需要同步的信息包括設備名、系統MAC、軟件版本、M-LAG狀態、STP BPDU信息、MAC、ARP、IGMP表項等。

5. 設備配對成功後，會通過keepalive鏈路發送心跳。心跳主要是用於在peer-link故障時，雙主檢測使用。

二、M-LAG協議報文

M-LAG協議報文如圖所示，上面說過，協議報文（HELLO或者同步報文）都是在peer-link上承載的，而peer-link是一個二層鏈路，所以協議報文也是封裝在普通的以太報文中的，最外層的以太頭中，源MAC為自身設備的MAC地址，目的MAC為組播MAC地址，VLAN則是用的保留VLAN。

外層以太頭部內，封裝了一層自定義的消息頭部。自定義消息頭部中主要包含以下信息：

• Version：協議版本號，用於標識雙歸設備所運行的M-LAG版本。

• Message Type：報文類型，標識該報文為那種類型的報文，HELLO或者同步報文。

• Node：設備節點編號。

• Slot：槽位號，標識需要接收消息的槽位號，如果盒式設備，則為堆疊ID。

• Serial Number：協議序列號，用於增加可靠性。

自定義消息頭部裏面，就是正常的報文數據，包含了需要交互或者同步的信息。比如HELLO報文的DATA中會包含Dfs-group ID、優先級、設備MAC地址等信息。而同步報文DATA中會包含一些表項和狀態信息。

三、M-LAG同步原理

M-LAG作為一個邏輯的鏈路聚合組，雙歸設備兩端的表項需要保持一致，所以需要在M-LAG兩端同步表項，否則可能導致流量異常。需要保持一致的表項主要有：

• MAC表

• ARP表

• 二三層組播轉發表

• DHCP Snooping表

• LACP System ID

• STP全局和端口的一些配置

• 其他一些表項如ACL等

表項會封裝在同步報文的DATA部分，DATA按照TLV格式封裝，方便擴展。以同步ARP表項為例：

TLV的內容包含收到ARP的源M-LAG ID，以及原始的ARP報文。之所以帶原始的ARP報文是因為對於原始的ARP報文，不管什麽版本的設備處理模式都是相同的。更容易實現版本之間的兼容性。除ARP之外，IGMP等協議相關的表項也都是以原始報文同步，對端收到原始報文後會根據報文信息同步為自身的表項。

四、M-LAG協議兼容性原理

之前說過，M-LAG的一大優勢就是支持逐臺升級，為維護帶來了便利。對於控制平面需要進行同步的這類協議來說，逐臺升級過程中，必然會出現兩端協議版本不一致的情況，那麽必須保證協議的兼容性。

M-LAG保證協議兼容性主要有以下一些方法：

1. M-LAG HELLO報文中會協議協議的版本號，這個版本號並不隨設備版本升級而變化，如果設備升級前後涉及M-LAG的功能（如MAC、ARP等）沒有變化，版本號不會變化。如果功能有變化，M-LAG版本號才會變化。

2. M-LAG設備在獲取到對面的版本號後，如果自身版本較高，則會兼容處理老版本發送過來的報文，並且會以老版本的的方式和對方設備進行交互。

3. 上面我們說過，在進行表項信息同步時，M-LAG設備會將原始報文同步給對方。這樣也保證了協議兼容性。以ARP表項為例，ARP協議是一個非常穩定的協議，各個版本對於ARP報文的處理幾乎沒有差別，所以將原始ARP報文發給對面，幾乎不會因為版本原因導致對端設備無法處理。

下面用一個例子來說明一下逐臺升級過程中的協議兼容性問題。

如圖所示，SwitchA和SwitchB組成一個M-LAG系統。版本均為V1R5C10，現在要將兩臺設備升級為V2R1C00版本。由於V2R1C00版本新增了一個同步LACP SystemID的功能，在V1R5C10版本，兩端設備LACP System ID必須手動配置為一致，而在V2R1C00版本中，主設備會將自己的LACP SystemID封裝在同步報文中，備設備收到後，會使用該System ID替換自己的SystemID，防止了手動配置錯誤的情況發生。那麽升級過程如下：

1. SwtichB換包重啟，M-LAG由雙歸變成單歸，SwitchA獨立承擔報文轉發。

2. SwitchB升級完成後，以V2R1C00版本啟動，發送HELLO報文重新配對。由於新增了一個功能，SwitchB發送的HELLO報文中新增了TLV（這裏以新增TLV為例，實際新增功能並不一定會在HELLO報文中新增TLV），SwtichA收到SwitchB的報文後，只處理可以識別的TLV。

3. SwitchB收到SwitchA發送的HELLO報文後，發送HELLO報文中攜帶的版本號比自己低，於是不會校驗是否有該新增的TLV，兩者可以正常協商（新增的TLV功能暫時不生效）。

4. 協商完成後，SwitchB開始發送LACP System ID的同步報文，這是一個新增的報文類型。SwtichA是仍然是老版本，不會處理，直接忽略。SwitchB接收不到SwitchA發送的同步LACP SystemID的報文，也不會有任何處理。兩設備繼續保持手動配置System ID狀態，LACP功能也就繼續保持以前的工作狀態。

5. 開始升級SwtichA，同之前類似，雙歸切換為單歸。

6. SwitchA升級完，最終兩邊版本一致。此時兩臺設備可以交互LACP System ID的同步報文，此時可以將之前手工配置的System ID刪除，全部切換完自動協商形式。

一、正常轉發流程

1：CE側訪問網絡側單播流程

CE側單播訪問網絡側時，無論單歸或是雙歸均為正常轉發流程，雙歸設備會正常通過鏈路聚合將流量哈希到兩條鏈路上。

2：CE側單播互訪流程

CE1訪問CE2時，由於SwitchA上會學習到CE2的MAC表項，可以正常轉發給CE2。

CE2訪問CE1時，CE2首先會進行哈希，如果流量被哈希到SwtichA一側，由於SwitchA上會學習到CE1的MAC表項，可以正常轉發給CE1。如果流量被哈希到SwitchB一側，由於SwitchA會將表項同步給SwitchB，SwitchB會從peer-link口學習到CE1的MAC表項（也就是SwitchB上CE1的MAC表項出接口為peer-link口），於是SwitchB會將流量通過peer-link口發給SwitchA，同理，SwitchA將流量轉發給CE1。

3：組播/廣播/未知單播流程

這裏以CE2發送廣播流量為例，廣播流量會在M-LAG兩條鏈路上進行廣播，到達SwitchA和SwitchB後，會繼續向其他CE和網絡側進行廣播。需要註意的是，由於peer-link是加入所有VLAN的的，所以廣播流量必然也會在peer-link上廣播。這裏，SwitchB將廣播流量通過peer-link發送給SwitchA後（SwitchA也會廣播給SwitchB，原理一致，這裏不贅述了），廣播流量不會從SwitchA的MLAG成員口再發送給CE2，這樣就防止了環路的發生。peer-link自身有一個端口隔離的機制：所有從peer-link口接到的:流量不會從M-LAG雙歸成員口再發送出去。

4：網絡側流量模型

網絡側協議根據協議不同，原理會略有不同，這裏我們簡單說一下，後面典型應用場景中會詳細說明：

l xSTP：M-LAG雙歸設備會協商成同一個STP的根橋，也就是說在STP看來，SwitchA和SwitchB是一個STP根橋。

l TRILL/VXLAN：M-LAG會通過同一個標識（虛擬nickname/虛擬VETP）對外協商，網絡側設備會將雙歸設備作為一臺設備進行協商。流量會通過TRILL/VXLAN協議的機制進行，實現負載分擔。

l IP網絡：正常路由協商，如果鏈路狀態一致，則為ECMP。

網絡側無論將流量發給雙歸設備中的哪一臺設備，流量是單播或者廣播，其原理和CE側的原理是一致的，仍然是單播正常轉發，廣播做端口隔離。

二、故障場景

1：M-LAG成員口故障

如果M-LAG某成員口故障，網絡側流量會通過peer-link發送給另外一臺設備，所有流量均由另外一臺設備轉發，具體過程如下：

1. SwitchB的M-LAG成員口故障，網絡側不感知，流量依然會發送給雙歸設備。

2. 由於M-LAG成員口故障，SwtichB將CE對應的MAC表項清除。此時，M-LAG系統會觸發一次MAC表項同步的過程，SwitchA將CE的MAC表項同步給SwitchB，出接口為peer-link口。

3. 由於成員口故障，雙歸變成單歸，端口隔離機制會放開。

4. SwitchB收到網絡側訪問CE的流量後，查找MAC表項，會通過peer-link將流量交給SwitchA轉發給CE。

5. 故障恢復後，M-LAG成員口UP也會觸發一次M-LAG系統的MAC表項同步過程，SwtichB上CE的MAC表項恢復正常情況下的出接口。流量正常轉發。

2：peer-link故障

如果一旦peer-link故障，則兩臺設備不能同時轉發流量，如果同時轉發流量會導致廣播風暴，MAC漂移等一系列問題，所以必須只讓一臺設備轉發，具體方法如下：

1. 雙歸設備一旦感知peer-link口down，即立刻發起一次雙主檢測過程，通過Keepalive鏈路進行雙主檢測。如果在一定時間內未收到對端發來的Keepalive報文，則認為對端設備故障。如果收到對端發來的Keepalive報文，則判定peer-link故障。

2. 判定peer-link故障後，M-LAG備設備會將自己除了peer-link接口、堆疊口、和管理網口之外的所有物理接口Error-dwon。此時，所有流量都只會通過M-LAG主設備進行轉發。

3. peer-link故障恢復後，peer-link接口UP，M-LAG系統重新協商。協商完成後，為了保證M-LAG的端口隔離機制生效，網絡側協議收斂完畢，並不立即將備設備上Error-down的端口恢復，而是會有一個延時時間（一般為2分鐘，如果是M-LAG雙歸接入到SVF系統則為5分鐘）。

這裏大家可以看到，如果peer-link故障，由於備設備接口被Error-down，單歸到備設備的CE設備（如圖中CE3）將無法訪問網絡側，也無法收到網絡側的流量。這就是為什麽我們在一開始說，單歸的組網是非常不推薦的。

這裏還需要說明的是：如果使用框式設備組成M-LAG系統，最好是將peer-link接口和M-LAG成員口部署在不同單板上。因為如果部署在同一塊單板上，則如果單板故障，則peer-link和M-LAG成員口同時故障，這時，如果故障的為主設備，則備設備自動Error-down物理端口，此時，發送到雙歸設備的流量會被丟棄。

3：設備故障場景

設備故障處理流程和peer-link故障基本一致，首先設備感知peer-link接口down，進行雙主檢測，檢測肯定檢測不到，於是判定設備故障。既然設備都故障了，自然也轉發不了，如果我是M-LAG主設備，那我啥也不用做，繼續轉發。如果我是M-LAG備設備，那我自然就升主了，然後依然繼續轉發。等故障恢復了，感知peer-link口up，就再進行M-LAG協商。同理，為了給網絡側協議收斂的時間，以及M-LAG本身的一些機制準備，還是會有一個延時的時間，在延時時間內，依然還是只有一臺設備進行轉發。

4：上行鏈路故障

一般情況下，上行鏈路故障並不會影響M-LAG系統的轉發，如圖SwitchA上行鏈路雖然故障，但是網絡側的轉發相關表項會通過SwitchB通過peer-link同步給SwitchA，SwitchA可以將訪問網絡側的流量發送給SwitchB進行轉發。而網絡側發送給CE側的流量由於接口故障，自然也不會發送給SwitchA處理。

但是如果故障的接口正好是Keepalive鏈路接口，就有問題了。此時，由於Keepalive鏈路故障，設備雙主檢測後均認為對方設備故障。此時出現雙主情況，CE發送給SwitchA的流量會因為沒有上行出接口而被丟棄。

針對這個問題，我們主要有兩種方法解決：

1. 用管理口作為Keepalive鏈路。

2. 配置Monitor-link功能，將M-LAG成員口和上行口關聯起來，一旦上行鏈路故障了，會聯動M-LAG成員口故障，這樣就防止了流量丟失。

二：服務器通過M-LAG雙歸接入

Server雙歸接入M-LAG的場景下，Server只需要支持負載分擔模式的雙網卡即可。將雙網卡綁定為Eth-Trunk，建議通過LACP協議和M-LAG進行對接。

如果服務器的網卡只能支持主備模式，通過M-LAG接入的時候必須要通過LACP進行協商。這樣服務器發出的流量只從主鏈路進行轉發，這裏假設左側鏈路為主鏈路。那麽所有的流量都會通過SwitchA進行轉發，而SwitchA會將Server對應的MAC表項通過peer-link同步給SwitchB，出接口為peer-link口。這樣，當SwitchB收到發往Server的流量後，會通過peer-link發送給SwitchA，這時Server相當於是單歸接入。

網卡主備模式服務器能否通過M-LAG接入還取決於服務器的能力，這裏還是推薦網卡負載分擔模式進行接入。

二：M-LAG雙歸接入隧道類協議

前面我們說過，數據平面虛擬化協議大多數是采用了隧道封裝，M-LAG雙歸接入此類網絡的原理基本是一致的。目前CE系列交換機支持M-LAG接入TRILL和VXLAN。

這類場景的實現方式都是將雙歸設備虛擬成一臺設備和網絡側交互。對於TRILL網絡，兩臺設備會通過peer-link協商或者手工配置一個虛擬nickname，在向外發送Hello報文時，封裝這個虛擬的nickname，這樣網絡側設備會認為和同一臺設備建立了TRILL鄰居，這樣所有到Server的路由都會指向這個虛擬nickname。

對於VXLAN網絡，設備會虛擬出一個VTEP，無論是手工建立隧道還是通過MPBGP自動建立的方式，SwitchA和SwitchB均用這個虛擬的VTEP的IP和外界建立VXLAN隧道。

這樣在接入側看來，通過一個Eth-Trunk和一臺設備建立了連接，在網絡側看來，是和一臺設備建立了TRILL鄰居/VXLAN隧道。下面以TRILL網絡為例，描述一下報文轉發過程。

1. SwitchA和SwitchB正常和TRILL網絡側設備建立鄰居關系，註意，TRILL建立鄰居是通過ISIS的機制，HELLO報文中並不發布nickname信息，所以不會出現nickname沖突的情況。

2. SwitchA和SwitchB通過LSP報文像TRILL網絡側發布攜帶虛擬nickname的路由信息。註意，這裏如果TRILL網絡側裏也有一臺設備的nickname和虛擬nickname一致，會出現nickname沖突的情況。

3. 用戶側報文到達雙歸設備後，查詢雙歸設備的MAC表項，發現MAC表項出接口為TRILL的Egress節點，於是對報文進行TRILL封裝，封裝的ingress nickname為虛擬nickname。

4. TRILL網絡側報文在發往用戶側時，由於雙歸設備同時發布了虛擬nickname的路由信息，所以在TRILL網絡側設備看來，雙歸RB是ECMP的等價下一跳，於是封裝的Egress nickname為虛擬nickname。

三：M-LAG雙歸接入IP網絡

M-LAG雙歸接入到IP網絡時，雙歸設備就成了二層網絡和三層網絡的分界點。也就是承擔了網關的作用。由於是兩臺設備做網關，那麽他們對用戶側展示的必須是相同的網關IP和MAC。這裏就要借用VRRP的機制，在SwitchA和SwitchB上配置虛擬的IP和MAC。但是要註意的是，這裏VRRP並不是主備，如果是主備，那就不能負載分擔了。所以我們通過一些機制，屏蔽了VRRP的協議報文，讓VRRP組工作在雙主的狀態下，僅僅借用VRRP的虛擬IP和MAC的機制。

這裏L1和L2接口可以配置成VLANIF或者三層路由接口均可以，SwitchA和SwitchB正常和網絡側建立路由鄰居關系，發布路由時，由於L1和L2網段相同，SwitchA和SwitchB會發布相同網段的路由，這樣在網絡側看來，SwitchA和SwitchB是ECMP的兩個等價下一跳。

四：M-LAG和STP網絡對接

M-LAG雙歸接入STP網絡的場景不太常見，一般可能某些STP網絡不太方便進行調整時，需要和M-LAG進行對接。

M-LAG和STP對接的原理和雙歸接入隧道類協議類似，也是將雙歸設備模擬成STP的一個邏輯節點。這樣網絡側在進行STP協商時，會將雙歸設備看做STP的一個節點。有兩種方法可以將雙歸設備模擬成一個STP節點：

1. 手動配置雙歸設備為STP網絡的根橋。

2. 通過配置VSTP協議，VSTP協議的作用是在雙歸設備之間同步STP的協議狀態，讓兩臺設備以同一個狀態對外進行STP協商。

五：多級M-LAG互聯

在網絡規模較大的情況下，可以在核心層，匯聚層和接入層部署多個M-LAG來保證各層網絡之間的鏈路都可以形成負載分擔，保證了鏈路的可靠性。

多級M-LAG其實本質上並沒有什麽區別，因為所有M-LAG之間都可以看做是通過一個Eth-Trunk連接。比如對於SwitchA和SwitchB來說，往上運行了一個M-LAG連接了一個Eth-Trunk接口，往下也同理。

但是這裏要提一下的是，這種情況下，就不能通過手動配置根橋的方式來進行STP破環了，因為有多級M-LAG，如果配置某M-LAG的雙歸設備為根橋，那其他設備必然就不能運行了。所以多級M-LAG互聯方式必須要部署VSTP協議來同步M-LAG雙歸設備之間STP狀態信息。

數據中心交換機橫向虛擬化集群漫談