成人免费xxxxx在线视频软件_久久精品久久久_亚洲国产精品久久久_天天色天天色_亚洲人成一区_欧美一级欧美三级在线观看

VXLAN與EVPN的結合使用

網絡 通信技術
本文我們來看一個EVPN應用的變化,將EVPN的控制層與VXLAN結合。

EVPN是近幾年最熱門的網絡技術之一。如果你還沒聽過EVPN,你的網絡技能可能已經落伍了,趕緊看看之前的《EVPN簡介》吧!EVPN全稱是Ethernet VPN,從名字上看是一個L2 VPN的實現。實際上在最開始提出時,也是用作L2 VPN,號稱是next generation L2 VPN,對原有的VPLS(Virtual Private LAN Service)進行改進。所以最開始的EVPN,是一套跨WAN(Wide Area Network)的L2 VPN的控制層和數據層技術,數據層特指的就是MPLS。所有的這些在EVPN簡介中都有介紹,今天我們來看一個EVPN應用的變化,將EVPN的控制層與VXLAN結合。

EVPN作為控制層,通常可以對接三種數據層,MPLS,PBB和NVO。NVO(Network Virtualization Overlay),這一分類包含了VXLAN(Virtual eXtensible LAN)。

VXLAN與EVPN的結合使用

傳統的VXLAN工作方式

VXLAN是一種Overlay網絡技術,我相信大家對Overlay和VXLAN已經有一定的了解了,所以,我不在這對Overlay和VXLAN做解釋。我們直接看一下VXLAN網絡是如何工作的。

VTEP

首先看看VXLAN網絡中的重要組成部分,VTEP(VXLAN Tunnel Endpoint)。VTEP是一個網絡設備VXLAN數據是在VTEP之間傳遞。從邏輯上看,VTEP包含了兩個接口:uplink和downlink。Uplink連接Underlay網絡,原始數據封裝成VXLAN格式通過uplink在Underlay網絡上傳輸;downlink連接Overlay網絡,原始數據從downlink傳入傳出。所以,VTEP可以看成是一個連接Overlay和Underlay網絡的edge設備。

VXLAN與EVPN的結合使用

舉個例子,當Overlay中VLAN100數據包通過downlink發送至VTEP,首先會映射到VXLAN ID 1001。在這之后,VTEP根據原始數據包的目的MAC地址和剛剛轉換獲得的VXLAN ID,在VTEP L2 Table中查找對應的Remote VTEP,如果能找到,就原始的Ethernet Frame封裝成VXLAN數據包,再通過uplink發送出去。

對端VTEP的uplink收到了VXLAN數據包,解封裝獲得原始的Ethernet Frame,再將VXLAN ID與VLAN ID做映射,加入VLAN100的信息,最后數據包再通過downlink發送出去。這樣,兩個VTEP下的VLAN 100網絡相當于是連通的。(注:雖然這里都是VLAN 100,但是實際上兩個VTEP下對同一個VXLAN ID對應的VLAN ID可以不一樣)

原始的Ethernet Frame被封裝成了一個IP/UDP packet,數據的傳輸變成了VTEP之間的IP/UDP packet傳輸,VTEP之間可以是二層網絡,三層網絡,甚至更復雜,但是這對VLAN100是透明的。

VXLAN與EVPN的結合使用

flood-learn

前面的例子中,如果VTEP L2 Table中沒有找到對應的Remote VTEP,那就要通過flood-learn來獲得對端的VTEP。

VXLAN與EVPN的結合使用

為了更好的描述flood-learn,我們假設最左側虛機已經知道目的MAC了(VTEP中的L2 Table已經老化,虛機中的ARP cache還沒老化)。當最左側虛機想ping最右側虛機,ping包送到VTEP,因為在VTEP中找不到對應的Remote VTEP,VTEP會做如下操作:

原始的Ethernet Frame被封裝成VXLAN格式,VXLAN包的外層目的IP地址為組播地址。

VXLAN數據包被發送給組播內所有其他VTEP。

其實這就是flood過程。因為組播內所有VTEP都是接收方,最右側虛機可以受到組播的ping包。最右側的VTEP首先從ping包中學習到了最左側虛機的MAC地址,VXLAN ID和對應的VTEP。因為有了這些信息,當最右側虛機返回時,會直接發送到最左側VTEP。這樣最左側VTEP也能從返回包中學習到最右側虛機的MAC地址,VXLAN ID和對應的VTEP,并記錄在自己的L2 Table中,這就是learn過程。與交換機中的flood-learn不一樣的是,交換機中記錄的是對應的交換機端口和MAC的關系,這里記錄的是Remote VTEP(IP Address)和MAC的關系。

下次最左側虛機想訪問最右側虛機,不需要再flood,直接查VTEP L2 Table就能找到對應的remote VTEP。

所以從這里看出,VXLAN的轉發信息,也是通過數據層的flood-learn獲取,VXLAN不需要一個控制層也能工作,這與VPLS的情況很像啊!

EVPN control plane

VXLAN由RFC7348定義,在RFC中,只定義了數據層的行為,并沒有指定VXLAN控制層。在VXLAN技術早期,通過數據層的來獲取轉發信息,在實現上較為簡單,相應的技術門檻較低,有利于廠商實現VXLAN。但是隨著網絡規模的發展,完全依賴數據層做控制會造成網絡中廣播組播風暴,因此VXLAN也需要有一個控制層。

SDN controller也可以作為VXLAN的控制層,OpenStack中普遍用SDN controller控制OpenVSwitch,VTEP直接通過OVSDB和OpenFlow流表進行管理。這些內容很有意思,功能也很強大,不過跟本文是兩件事情,本文只討論EVPN作為控制層的情況。

EVPN作為NVO的控制層由IETF草案:draft-ietf-bess-evpn-overlay定義。上一篇講了EVPN的實現是參考了BGP/MPLS L3 VPN,那么EVPN作為VXLAN的控制層時,仍然采用相同的架構,只是架構的組成元素發生了改變。

VXLAN與EVPN的結合使用

具體的變換包括了:

  • PE設備變成了VTEP,有的時候也稱為NVE(Network Virtualization Endpoint)。相應的MP-BGP連接也建立在VTEP之間。
  • 數據層變成了VXLAN,VXLAN是在Underlay網絡傳輸。
  • CE設備變成了Server,這里可以是Virtual Server也可以是Physical Server。

控制層數據傳輸

與傳統的EVPN基本一致,Server到VTEP還是通過local learning,VTEP通過讀取Ethernet Frame獲得本地連接設備的MAC地址和對應的端口。VTEP之間通過MP-BGP傳輸Route Type 2的MAC/IP route。這里有點不一樣,以MPLS為數據層時,MAC/IP route傳輸的是MPLS Label,而以VXLAN為數據層時,MAC/IP route傳輸的是VXLAN ID。正好VXLAN ID也是3個字節,能夠匹配原來MPLS Label的空間。相應的NLRI信息如下:

VXLAN與EVPN的結合使用

MAC/IP route通過MP-BGP傳輸到對端VTEP。現實中要求BGP連接是full mesh(任意兩兩互連),而為了減輕配置壓力,通常會引入BGP RR(Router Reflector)。BGP RR的作用是將一個BGP Speaker的數據反射給所有其他連接的BGP peer。使用BGP RR可以使得所有的BGP Speaker只需與BGP RR建立連接,否則按照full mesh,任意一個BGP Speaker必須與其他所有的BGP peer建立BGP連接。

所以,在有BGP RR的環境中,網絡拓撲如下圖所示,是不是跟Spine-Leaf的網絡結構很像?

VXLAN與EVPN的結合使用

所有的VTEP學習到本地的MAC地址之后,通過MP-BGP發送給BGP RR。BGP RR再將收到的MAC轉發信息,發送給所有其他的VTEP。經過BGP RR的反射之后,各個VTEP已經有了所有其他VTEP的MAC轉發信息,如下圖所示:

VXLAN與EVPN的結合使用

看一看圖中各個VTEP的L2 Table,第一列是MAC地址,第二列是對應的Remote VTEP(遠端MAC)或者當前VTEP連接的端口(本地MAC),第三列是VXLAN ID,這三列在介紹VTEP時說過。第四列是用來做MAC Mobility,也就是MAC遷移用的,這個稍后單獨介紹。

就這樣,控制層數據分發到了各個VTEP。

數據層數據傳輸

有了控制層數據,數據層就簡單多了。Server A想訪問Server B,通過查找本地VTEP L2 Table找到VTEP2,再封裝成VXLAN數據發送到VTEP2,VTEP2將VXLAN解封裝,轉發給本地的Server B。所以可以看出,從數據層面角度來看,有沒有EVPN效果都是一樣的。EVPN只負責VXLAN的控制層面,也就是MAC轉發信息的傳輸,對VXLAN數據層面沒有影響。

VXLAN與EVPN的結合使用

EVPN作為VXLAN的控制層面就是這樣了,是不是也不太復雜?接下來看一看MAC Mobility。

MAC Mobility

MAC Mobility在RFC7432中已經定義,也就是說這不是為VXLAN專門定義的。先來看看MAC Mobility解決了什么問題?

現實中,經常會面臨Server遷移的場景,例如虛機遷移,物理機房的改造造成的遷移。以上圖為例,當Server A從VTEP1遷移到了VTEP3,VTEP3通過本地數據層面的學習(讀取ARP或者DHCP的Ethernet Header),發現了Server A。本來VTEP3上的MP-BGP進程應該將這個新學習的MAC通過Route type 2發送給其他VTEP。但是現在有幾個問題。首先,VTEP3本身已經有了Server A的MAC轉發信息,表明了Server A在VTEP1上,那么VTEP3本地數據已經有了沖突了。其次,VTEP1和VTEP2中也有Server A的MAC轉發信息,它們將如何處理VTEP3發出來的Server A的轉發信息。你可以說,后來的覆蓋先來的,但是EVPN,或者MP-BGP,這是一個L7的協議,后來的不一定是更新的數據。比如,Server A遷移到VTEP3,VTEP3本地學習到了Server A的MAC,并發送出去,VTEP2收到了這個信息,但是由于網絡阻塞,VTEP1關于Server A的信息過了一會也發送到了VTEP2。如果后來的覆蓋前面的,那這時就是舊的信息覆蓋了新的信息。

在說解決方案之前,先回顧一下EVPN新增的MP-BGP Route type和BGP Extended community。

VXLAN與EVPN的結合使用

MAC Mobility就是基于圖中標注的Extended community實現。BGP Extended community是跟隨在BGP NLRI信息之后的輔助信息,像RT(Route Target)就是最常用的一種BGP Extended community。MAC Mobility Extended Community的格式定義如下:

VXLAN與EVPN的結合使用

所以,具體工作過程是這樣,當VTEP通過本地的數據層學習獲得了一個MAC地址,如果本地的L2 Table中沒有這條MAC地址的記錄,那么VTEP接下來發布的MAC/IP route會帶上一份MAC Mobility Extended Community,其中的Sequence Number是0。(也可以不帶,這樣默認就是0)這也就是上面示意圖中第四列中的0的意義。

當VTEP通過本地的數據層學習獲得了一個MAC地址,如果本地的L2 Table中已經有這條MAC地址的記錄,那么VTEP首先會更新自己的L2 Table,將之前的MAC轉發信息覆蓋。之后VTEP發布的MAC/IP route必然會帶上一份MAC Mobility Extended Community,其中的Sequence Number是原有記錄的數值加1。這樣,當其他的VTEP收到了這條MAC/IP route,對比本地記錄,就會發現,這是一條更新的MAC轉發信息,原有記錄會被覆蓋。如果VTEP收到的MAC/IP route中的Sequence Number小于當前記錄的信息,那么這條MAC/IP route會被丟棄。

MAC Mobility中的Sequence Number可以看成是MAC轉發信息的版本號,高版本可以覆蓋低版本。

從另一個角度看,如果沒有控制層的MAC Mobility機制,那么Server遷移之后,只能等L2 Table中的表項老化以后,重新flood-learn才能獲得更新之后的MAC轉發信息,這樣的時間相對要長很多。這就是EVPN作為控制層帶來的好處之一。

最后

EVPN的提出是作為下一代L2 VPN。L2 VPN實際上是在WAN上的一個邏輯二層網絡。如果將L2 VPN與Overlay技術,例如VXLAN做對比,其實有很多相似的地方。比如都是有Overlay和Underlay,Overlay都是L2網絡,都有相應的edge設備等等。正是這些相似之處,才會有將原本是L2 VPN的控制層的EVPN,用作Overlay網絡,例如VXLAN網絡的控制層。VXLAN網絡配合EVPN作為控制層,不僅能減少網絡中的廣播與組播數量,而且能帶來EVPN作為控制層的一些優點,例如本文介紹的MAC Mobility。在一個VXLAN Fabric架構中,采用EVPN做控制層,借助功能完善的BGP(確切說是MP-BGP)協議,能夠高效的連接不同的POD,甚至連接不同的site。所以從這個角度來說,EVPN作為VXLAN的控制層的應用,并不遜色與其作為L2 VPN的應用。

作者簡介:肖宏輝,畢業于中科院研究生院,8年的工作經驗,其中6年云計算開發經驗,OpenStack社區積極活躍,有超過300個commit和超過30000行代碼的貢獻。目前關注SDN/NFV等虛擬網絡技術。本文所有觀點僅代表作者個人觀點,與作者現在或者之前所在的公司無關。

責任編輯:未麗燕 來源: SDNLAB
相關推薦

2017-09-21 13:46:50

VXLANL3網絡Overlay

2010-08-26 15:36:30

DHCP路由

2024-01-22 15:52:47

EVPN交換以太網虛擬專用網絡

2011-11-25 13:14:16

2015-01-04 09:22:08

虛擬化VXLAN

2010-03-19 15:39:41

云計算

2011-03-07 16:10:41

FireFTPFirefoxFTP

2022-05-17 09:19:17

XebianLinuxLinux 發行版

2009-06-04 10:44:34

StrutsHibernate配合

2012-10-31 12:46:24

F5解決方案

2022-04-23 10:55:51

存儲AI/ML對象鎖定

2009-02-04 17:32:03

ibmdwJavaScala

2013-03-18 11:05:26

HadoopCouchbase

2009-06-23 17:54:41

OSGi與JSF

2022-06-23 09:00:00

JavaScriptHTML應用程序

2024-06-12 08:00:00

IS-ISOSPF

2009-07-03 13:54:38

Java Servle

2023-11-21 09:44:28

開發軟件

2009-02-05 09:23:13

SaaS軟件定價軟件服務

2010-04-29 10:32:14

虛擬技術上海世博會
點贊
收藏

51CTO技術棧公眾號

主站蜘蛛池模板: 免费在线看a| 久久久久久国产一区二区三区 | 日韩精品一区二区在线观看 | 色偷偷人人澡人人爽人人模 | 美日韩免费视频 | 综合二区 | 亚洲一区二区中文字幕 | 欧美在线免费 | 一区二区视频在线观看 | 国产一区三区在线 | 日韩欧美一区二区三区免费观看 | 中文在线一区二区 | 北条麻妃一区二区三区在线视频 | 亚洲性视频 | 午夜一区二区三区在线观看 | 亚洲精品一区二区三区蜜桃久 | 久久精品黄色 | 国产一区二区视频免费在线观看 | 亚洲人精品 | 国产精品一区二区三 | 久久99视频这里只有精品 | 91综合网| 国产成人jvid在线播放 | www.788.com色淫免费 | 欧美aⅴ | 一区二区三区国产 | 久久国产成人 | 精品视频在线播放 | 国产在线视频一区二区董小宛性色 | 日本午夜在线视频 | 国产欧美一区二区三区久久 | 日日夜夜天天 | 日韩av在线不卡 | 中文字幕在线观看一区 | 国产日韩精品视频 | 美日韩免费 | 99av成人精品国语自产拍 | 91精品国产综合久久精品 | 久久久久久久一区二区 | 五月天天丁香婷婷在线中 | 人人爽人人爽人人片av |