作者:楊雨
“MTU的值設(shè)置多少合適呢?現(xiàn)在最佳實踐是設(shè)置到9000。”
“其實OpenFlow只是一個概念,從這幾年SDN的發(fā)展來看,它并沒有成為一個事實的標(biāo)準(zhǔn)。”
“大規(guī)模云平臺對SDN的要求,第一是網(wǎng)絡(luò)基礎(chǔ)架構(gòu)要可擴展,第二是控制器可擴展,第三是數(shù)據(jù)平面無集中式單點,第四是跨集群的擴展網(wǎng)絡(luò)。”
“在基礎(chǔ)架構(gòu)上,如果用Tungsten Fabric,只要是用于生產(chǎn)環(huán)境的話,選擇IP CLOS架構(gòu)就行,沒必要再去折騰Fabric等二層架構(gòu)。”
“Tungsten Fabric的本質(zhì)是基于MPLS VPN的SDN。”
“跨集群的互聯(lián),或者叫多云互聯(lián),主要有兩種模式:基于控制器之間的互聯(lián),基于Cloud Gateway之間的互聯(lián)。”
本文整理自TF中文社區(qū)技術(shù)代表楊雨在TF中文社區(qū)“2020第一次Meetup”上的演講,分享Tungsten Fabric對大規(guī)模云平臺的支持。本文已經(jīng)主辦方和演講者審閱授權(quán)發(fā)布。
在TF中文社區(qū)1月7日的“2020第一次Meetup”活動上,來自Tungsten Fabric技術(shù)研發(fā)和一線使用者、關(guān)注多云互聯(lián)的從業(yè)者、開源SDN的愛好者們互相切磋、支招,現(xiàn)場氣氛熱烈,精彩內(nèi)容不斷。Tungsten Fabric在中國的廣泛應(yīng)用正在越來越真切地走來。
本次演講及TF中文社區(qū)“2020第一次Meetup”活動資料,請在“TF中文社區(qū)”公眾號后臺點擊“會議活動-Meetup”領(lǐng)取。
今天的分享偏技術(shù)一些,首先我們來看SDN的本質(zhì),然后從Tungsten Fabric架構(gòu)上解析為什么比OVS更好,為什么能支撐更大的場景。
先來看云對網(wǎng)絡(luò)的要求。首先是租戶隔離,IaaS就是多租戶,對于地址重用的要求,以VLAN的傳統(tǒng)方式也是可以實現(xiàn)的。另外,傳統(tǒng)VXLAN的協(xié)議或OVS的協(xié)議,只提供二層隔離的能力,沒有三層隔離的能力,只要你的機器綁到外網(wǎng)IP,或者綁到公共的路由層面上,三層是可以互通的,所以說在租戶隔離的層面,也有三層隔離的需求。
其次,云需要網(wǎng)絡(luò)支持虛擬機跨機柜的遷移。VXLAN的話還要跨數(shù)據(jù)中心大二層,不是說不可以實現(xiàn),但除了網(wǎng)絡(luò)要求,還有存儲的要求,比較難。虛擬機跨機柜的遷移,最難的是什么?傳統(tǒng)網(wǎng)絡(luò)架構(gòu),就是接入-匯聚-核心,路由器以下都是二層架構(gòu),機器可以在不同機架上遷移,但一個數(shù)據(jù)中心,云足夠大的時候,二層基礎(chǔ)網(wǎng)絡(luò)是支撐不了整個云的,不同機架在不同三層里面,這時虛擬機做遷移就要要求IP地址不能變。
另外,還有網(wǎng)絡(luò)功能和服務(wù)的要求。在云上面都是共享的資源池,如果以負(fù)載均衡為例,將一個性能強大的硬件負(fù)載均衡虛擬化給多個租戶使用,還是切換成小的負(fù)載均衡虛擬機實例給不同租戶使用?這里就提出網(wǎng)絡(luò)虛擬化和網(wǎng)絡(luò)功能虛擬化的需求,來支撐IaaS的運行。
網(wǎng)絡(luò)虛擬化,主要應(yīng)用的是Overlay的技術(shù),是SDN用到的其中一個技術(shù),用的比較多、比較標(biāo)準(zhǔn)的技術(shù),包括VXLAN、GRE、STT、GENEVE,以及Tungsten Fabric用到的MPLSoverUDP和MPLSoverGRE,主要的方式,是把二層的幀在vTEP上進(jìn)行三層封裝,通過VXLAN隧道傳輸?shù)綄Χ恕?/p>
這樣做的好處是,增加了租戶的數(shù)量,傳統(tǒng)VLAN是4096,如果VXLAN就是2的24次方;其次底層傳輸基于IP網(wǎng)絡(luò),擴展性遠(yuǎn)大于二層網(wǎng)絡(luò),使得網(wǎng)絡(luò)能擴展,虛擬機在不同物理網(wǎng)段上遷移。但同樣也帶來一些工作,如何讓兩邊的設(shè)備建立通信?第一建立VXLAN隧道,這是SDN控制器要做的事,第二是交換兩邊的MAC地址信息。
TF中文社區(qū)3月Meetup活動,將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐,詳細(xì)演示操作過程,并解答關(guān)于Tungsten Fabric和K8s的一切問題。關(guān)注“TF中文社區(qū)”公眾號,后臺點擊“會議活動-Meetup”領(lǐng)取。
有兩個VM,在兩個不同的主機上,就是通過Overlay來解決二層通信問題的。比如ESX1要和ESX2通信,ping的時候首先發(fā)ARP請求,那對應(yīng)的MAC地址是多少?對于VXLAN來說就要有一張轉(zhuǎn)發(fā)表,MAC2需要通過VTEP2的IP,去做一個封包,再傳輸?shù)絍TEP2,解封裝后,再傳輸?shù)较鄳?yīng)的機器里去。怎么建立這個轉(zhuǎn)發(fā)表?就是SDN需要去做的事情。
一種是自學(xué)習(xí),只要VM1發(fā)了一個ARP請求,到達(dá)vTEP網(wǎng)關(guān),它就會去洪泛請求,廣播到和它建立隧道的vTEP節(jié)點上去,看誰反饋ARP reply,就知道對端的IP地址,可以建立一個轉(zhuǎn)發(fā)表。但這樣會有很多消耗,ARP地址也有老化的過程,一旦老化,就需要重新去學(xué),直觀體驗是ping包時間會很長。如果是大規(guī)模的網(wǎng)絡(luò),頻繁洪泛,會對網(wǎng)絡(luò)可靠性帶來很大的挑戰(zhàn)。
SDN大部分情況下是和云管平臺做結(jié)合,知道在這個虛擬化服務(wù)器上,有哪些虛擬機,提前把MAC地址表或轉(zhuǎn)發(fā)表下發(fā)到vTEP設(shè)備上,這就是SDN控制平面要做的事情。
在Open vSwitch這個方案里面,就是通過數(shù)據(jù)庫和RabbitMQ,去下發(fā)一個OVSDB的命令,建立相應(yīng)的流表,讓虛擬機知道要往哪兒走。Tungsten Fabric也有相應(yīng)的機制,后面會介紹。
數(shù)據(jù)平面的作用,就是根據(jù)轉(zhuǎn)發(fā)表,對二層的幀進(jìn)行轉(zhuǎn)發(fā),另外進(jìn)行封包和解包。這里提一下MTU,這是這個二層的值,幀的transfer unit,為什么要設(shè)置很大?首先VXLAN協(xié)議會增加一些Hdr,UTP的Hdr,VXLAN的Hdr,封包的時候如果不做處理的話會超過1500,網(wǎng)卡會不發(fā)這個幀。早期做OpenStack經(jīng)常會遇到trouble shooting的MTU問題,后來解決方案是通過DHCP的Agenter,設(shè)置了一個參數(shù),如果網(wǎng)卡MTU是1500,就默認(rèn)為14XX,自動降低,這樣虛擬機的數(shù)據(jù)幀才能通過二層網(wǎng)卡。那么MTU的值設(shè)置多少合適呢?現(xiàn)在最佳實踐是設(shè)置到9000。在vTEP這一塊就是封包和轉(zhuǎn)發(fā),根據(jù)實際測試,如果增加MTU值,對吞吐量有很大的提高。
剛才說了SDN做的事情,控制下發(fā)轉(zhuǎn)發(fā)表和傳輸,接下來說一下SDN的分類。按流派來區(qū)分,SDN可分為軟件和硬件,區(qū)別就是vTEP是在vRouter上,還是在交換機的硬件轉(zhuǎn)發(fā)上,看解封包在哪里。硬件一般都是私有協(xié)議,像Cisco用的就是OPFlex。軟件也有很多不同的項目,其中Tungsten Fabric是最產(chǎn)品化的一個。
按照控制器分類,有集中式和分布式。集中式的控制器有OpenFlow、OVSDB,以及Tungsten Fabric使用XMPP(一個聊天的協(xié)議)。我們可以把Neutron的Open vSwitch理解為OVSDB協(xié)議,Neutron是通過RabbitMQ把信令下發(fā)到具體的計算節(jié)點,計算節(jié)點的OVS Agent通過OVSDB的命令,把相應(yīng)的流表增加到OVSDB交換機。
分布式的控制器,比如EVPN-VXLAN,就是使用了MP-BGP。
大家覺得哪種形式的控制器會更好一點呢?目前用OpenDaylight的項目有哪些?華為,華三等都在用,其控制器的SDN架構(gòu)就是參照OpenFlow來做的。有些廠商自己有研發(fā)能力,基于自身的硬件設(shè)備,可以開發(fā)一個比較完善的產(chǎn)品。但在開源社區(qū),很少看到一個成功的OpenDaylight項目,只是提供了一個框架和一些組件,不能很快基于開源項目run起來。其實OpenFlow只是一個概念,從這幾年SDN的發(fā)展來看,它并沒有成為一個事實的標(biāo)準(zhǔn)。
反而是OVSDB起來了,應(yīng)用在Neutron軟件的控制,還有交換機的控制上。比如Tungsten Fabric早期的BMS實現(xiàn),虛擬機要和裸機通信,裸機通過VLAN TAG,上到TOR交換機,再通過VLAN到VXLAN的轉(zhuǎn)換,到達(dá)虛擬網(wǎng)絡(luò)。其中VLAN到VXLAN的轉(zhuǎn)換,就是通過OVSDB協(xié)議下發(fā)的。你的交換機,理論上只要支持OVSDB協(xié)議,就可以做BMS場景。
我自己更傾向于這種分布式的控制器。因為集中式的永遠(yuǎn)會有瓶頸,無論是軟件瓶頸,還是性能瓶頸。而EVPN-VXLAN的核心協(xié)議是MP-BGP,BGP的擴展性有多大?看看現(xiàn)在Internet骨干網(wǎng),跑的就是BGP協(xié)議。
MP-BGP的協(xié)議,通過控制器下發(fā)流表信息,再通過BGP協(xié)議去交互,使用的時候只要針對你的相應(yīng)架構(gòu),去做相應(yīng)BGP協(xié)議的擴展性設(shè)計就可以。
針對Tungsten Fabric來說,其實是集中式和分布式兩種流派的融合,既用到集中式的架構(gòu),在對外的連接上,又采用了分布式控制器的技術(shù)。
總結(jié)大規(guī)模云平臺對SDN的要求,第一是網(wǎng)絡(luò)基礎(chǔ)架構(gòu)要可擴展。如果采用二層架構(gòu),瓶頸就是在基礎(chǔ)架構(gòu)上,受限于交換機的端口數(shù),二層交換機采用生成樹協(xié)議,對于大規(guī)模網(wǎng)絡(luò)平臺,如果運維水平較差,接出一個環(huán)路出來,就很危險。
第二,控制器是可擴展的。無論集中式還是分布式,在架構(gòu)上一定是可擴展的,至于能支持多大的量,就是代碼實現(xiàn)的問題了。
第三,數(shù)據(jù)平面無集中式單點。談到SDN的實際應(yīng)用,運維是一個比較大的挑戰(zhàn),無論是做開發(fā)還是做運維出身的人,最重要的是理解虛擬機之間,虛擬機到外網(wǎng)之間,數(shù)據(jù)流量是怎樣的?應(yīng)該通過什么命令去看這些流量,去trouble shooting,就像以前傳統(tǒng)網(wǎng)絡(luò)運維怎么去抓包一樣。對于擴展性來說,要實現(xiàn)傳統(tǒng)網(wǎng)絡(luò)的SNAT、floating IP等,每個項目都有不同的實現(xiàn)方式,實現(xiàn)過程中沒有單點的話,在架構(gòu)上就是可以擴展的。
第四,跨集群的擴展網(wǎng)絡(luò)。架構(gòu)上無論怎樣擴展,總是有極限的,對于一個單集群來說,總會到達(dá)一個瓶頸。如果要建一個更大的集群,可以橫向擴展多個集群出來,形成一個大的資源池。那么面臨的問題是,網(wǎng)絡(luò)是否需要互通。如果部署一個高可用業(yè)務(wù),跨集群的情況如何做互通,主流的一些高可用組件,需要跨兩個集群二層互通,都需要SDN去支持這樣的需求。
在基礎(chǔ)架構(gòu)上,如果用Tungsten Fabric,只要是用于生產(chǎn)環(huán)境的話,選擇IP CLOS架構(gòu)就行,沒必要再去折騰Fabric等二層架構(gòu)。IP CLOS可以帶來足夠的擴展性和高性能,包括沒有供應(yīng)商鎖定,建完以后基本不需要再動。
Leaf就是架頂式交換機,下面是子網(wǎng),不同機架用不同子網(wǎng),上層通過三層網(wǎng)關(guān)路由做通信,最主要的就是Leaf Spine之間三層怎么交互。瞻博網(wǎng)絡(luò)有個文檔介紹IP CLOS的白皮書,對OSPF、ISIS、BGP進(jìn)行了控制平面上的對比,最佳建議是用eBGP來做交互。
Tungsten Fabric的本質(zhì)是基于MPLS VPN的SDN。原來的VPN是解決多個site之間的互聯(lián),控制平面是BGP協(xié)議。到了數(shù)據(jù)中心里面,云之間的互聯(lián),一個物理機可以看做一個site,不同物理機之間借助VPN建立不同的隧道來打通,這就是Tungsten Fabric的本質(zhì)。不同之處在于控制平面,Tungsten Fabric用的是集中式的控制器并通過XMPP協(xié)議控制vRouter的路由表。
簡單看一下Tungsten Fabric的功能架構(gòu),在多云支持上,包括VMware、OpenStack容器、BMS;網(wǎng)絡(luò)功能上,二層網(wǎng)絡(luò)、三層網(wǎng)絡(luò)、DHCP、DNS、QoS、防火墻、LB等都是支持的。
在部署的時候,控制器主要分為兩種節(jié)點,一種是Analytics Cluster分析節(jié)點,主要做流的可視化。另外一種Controller節(jié)點用來控制網(wǎng)絡(luò),分為Configuration和Control Node,前者提供API,對接Neutron等云管平臺,API通過創(chuàng)建一個pod,在Configuration上記錄數(shù)據(jù)庫,轉(zhuǎn)換成相應(yīng)的IF-MAP,控制器通過XMPP命令在vRouter上創(chuàng)建相應(yīng)的接口,再把接口信息傳給不同的vRouter或外部網(wǎng)關(guān)及硬件設(shè)備,控制器核心協(xié)議是BGP協(xié)議。
控制器在整個Tungsten Fabric里就是一個router reflector,把所有的二層接口、MAC接口信息,三層路由信息全部存在這里,分發(fā)到不同的vRouter上面。對于云內(nèi)的vRouter,用XMPP推送,對于云外的Gateway等,通過BGP推送。
其中,NETCONF協(xié)議不是用來推送路由信息的,主要用于和網(wǎng)絡(luò)硬件設(shè)備的一些配置下發(fā)。比如Tungsten Fabric中增加一個BMS服務(wù)器接入到Tungsten Fabric管理的虛擬網(wǎng)絡(luò),Tungsten Fabric中的Device Manager會通過NETCONF將VLAN接口的配置和下發(fā)到TOR交換機,通過NETCONF建立接口。然后Tungsten Fabric控制器再通過OVSDB協(xié)議或EVPN-VXLAN協(xié)議去配置相應(yīng)的VLAN-VXLAN的橋接網(wǎng)關(guān)。如果需要把虛擬網(wǎng)絡(luò)擴展到Gateway,NETCONF也會幫助創(chuàng)建相應(yīng)的Routing instance配置。路由層面的交換信息,還是通過BGP來實現(xiàn)。
TF中文社區(qū)3月Meetup活動,將聚焦Tungsten Fabric與K8s的集成,由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐,詳細(xì)演示操作過程,并解答關(guān)于Tungsten Fabric和K8s的一切問題。關(guān)注“TF中文社區(qū)”公眾號,后臺點擊“會議活動-Meetup”領(lǐng)取。
Tungsten Fabric用到的數(shù)據(jù)庫,都是最近8年才有的,比如分布式數(shù)據(jù)庫的Cassandra、Zoo Keeper、RabbitMQ,在架構(gòu)上是高可用、可擴展的,具體能擴展到多大的量,還是要看代碼實現(xiàn)。反過來看Neutron,本質(zhì)就是一個數(shù)據(jù)庫,記錄了所有的信息,把所有的流表下發(fā)下去。
Tungsten Fabric的數(shù)據(jù)平面主要是通過vRouter來做轉(zhuǎn)發(fā),vRouter agent在user namespace的進(jìn)程,安排控制器基于XMPP連接拿到一些信息,再下發(fā)到kernel的轉(zhuǎn)發(fā)平面。這里提供了二層隔離和三層隔離的功能,如果說同一個網(wǎng)絡(luò)的虛擬機,接在同一個vRouter下面,雙方的通信就在這里完成。不同租戶的網(wǎng)絡(luò)虛擬機,接了不同的VRF、Routing instance,也是不能通信的。
vRouter內(nèi)置了很多網(wǎng)絡(luò)功能,比如DNS。Tungsten Fabric的DNS會根據(jù)主機的DNS配置來解析,如果遇到問題,可以檢查一下主機的DNS有沒有問題。DHCP應(yīng)答也在這里,Neutron就不一樣,專門有一個DHCP agent跑在一個節(jié)點上,OVS在大規(guī)模情況下,如果接了超過1500個接口,基本上就會出現(xiàn)丟包,并且經(jīng)常出問題。
Security Group在OVS的實現(xiàn)是通過和linux bridge關(guān)聯(lián)的iptables實現(xiàn)的,而在vRouter就是通過內(nèi)置的ACL功能實現(xiàn)。Network Policy就是一個分布式的防火墻。Floating IP也是在vRouter做了一個NAT出去。
這里多談一下Link-Local,它的場景是什么?作為一個云服務(wù)商,要向客戶提供NTP服務(wù)、ATP、YUM源、等公共服務(wù)。怎么讓虛擬機在虛擬網(wǎng)絡(luò)內(nèi)訪問到一個公共服務(wù)呢?一種方式是把這些網(wǎng)絡(luò)的路由打通,因為需要一個VTEP出口,通過cloud gateway把公共路由導(dǎo)進(jìn)去,這樣帶來一個問題,所有ATP流量、下載流量都要通過cloud gateway,流量會跟大。Tungsten Fabric提供一個Link-Local的模式,就是一個169.254的地址,在網(wǎng)絡(luò)標(biāo)準(zhǔn)里只有一跳。在OpenStack虛擬機或AWS虛擬機里面,metadata服務(wù)就是通過169.254提供的。本機沒有這個路由,到網(wǎng)關(guān)上對地址做一層NAT,本機的NAT就會訪問到配置的Link-Local映射,繼而訪問到內(nèi)部的服務(wù)。
在沒有增強的前提下,實測Neutron的OVS VXLAN的性能(只做MTU的優(yōu)化),最多達(dá)到兩個千兆的性能。而vRouter在不做任何優(yōu)化的前提下,能達(dá)到七、八千兆的性能。當(dāng)然也可以利用DPDK、Smart NIC來做優(yōu)化,或者利用SR-IOV的透傳功能。
再來看看Tungsten Fabric的Packet交互。無論是同網(wǎng)段還是不同網(wǎng)段,虛擬機之間的交互,都是在vRouter層面轉(zhuǎn)發(fā)的,不會經(jīng)過一個集中式的gateway。所以在虛擬機之間的數(shù)據(jù)交互層面,是沒有單點的。
另外一個比較重要的場景是SNAT。在OpenStack里面,如果虛擬機接了一個vRouter,可以通過vRouter的SNAT功能去訪問external的網(wǎng)段。Tungsten Fabric本身其實不提供SNAT,但也實現(xiàn)了SNAT功能,通過NS router(跑在計算節(jié)點的一個IP tables)做一個SNAT的轉(zhuǎn)發(fā),如果虛擬機要訪問一個非本網(wǎng)關(guān)的網(wǎng)絡(luò),先到gateway,轉(zhuǎn)發(fā)后,再通過vRouter連接external的網(wǎng)絡(luò)。這里NS router的創(chuàng)建,需要OpenStack nova的scheduler來配合。
對于每一個網(wǎng)絡(luò),都會有一個router去做轉(zhuǎn)發(fā),如果量太大,瓶頸可能就在NS router這里,但不會影響其它的網(wǎng)絡(luò)。
只要不在云內(nèi),都可以叫外網(wǎng),要出外網(wǎng)有兩種方式:第一種是Floating IP,在vRouter做了一個NAT,把NAT后的IP通過MPLS over GRE的隧道,發(fā)布到Cloud Gateway的某個VRF里面,和外網(wǎng)通信。
第二種外部互聯(lián)的場景,假如要提供一個云服務(wù),可以針對不同的運營商做不同的flouting IP,如果做L3 VPN或L2 VPN的專線接入服務(wù),可以通過cloud gateway接入到不同的MPLS網(wǎng)絡(luò),再把虛擬網(wǎng)絡(luò)路由到相應(yīng)的VRF,整個就都連通了。這也是Tungsten Fabric強大的地方,MPLS VPN是和傳統(tǒng)的網(wǎng)絡(luò)天然互聯(lián)互通的。
跨集群的互聯(lián),或者叫多云互聯(lián),主要有兩種模式。
第一種是基于控制器之間的互聯(lián),把VPN、網(wǎng)絡(luò)和接口的信息,通過控制器之間建立EBGP連接來傳輸,這種方案叫Federation。
兩邊的vRouter只要三層可達(dá)就可以,比如一邊的B1要訪問另一邊的B3,兩邊是不同的控制器和VPN,MPLS VPN有個route target,一邊export一邊import,路由表看到另一邊的路由,進(jìn)行路由信息交互,從而建立二層或者三層連接。Federation的方案是在控制器層面實現(xiàn)的,比較適合于同一個地域,同一個數(shù)據(jù)中心,有比較近的連接的情況。
第二種模式是通過cloud gateway之間的互聯(lián),把網(wǎng)絡(luò)的不同VRF,在cloud gateway之間建立EBGP鄰居,手動配置去import或export不同的RT,實現(xiàn)跨云的連接。需要注意的是,兩邊是不同的集群,IP地址管理不一樣的,分配地址的時候,要避免IP地址的重疊。
最后,和Neutron OVS進(jìn)行對標(biāo)的話,Tungsten Fabric可以說是完勝的。
基礎(chǔ)網(wǎng)絡(luò)方面,Tungsten Fabric可以擴展,Neutron OVS目前只能用二層網(wǎng)絡(luò),無論集中式還是分布式,floating IP下沉到計算節(jié)點這一層,目前的組件里都沒有成熟的BGP方案,能夠把floating IP發(fā)布到邊界網(wǎng)關(guān),OVS DVR和邊界網(wǎng)關(guān)只能通過二層連接。
對比架構(gòu)方面,Tungsten Fabric是可擴展的,3個節(jié)點性能不夠,可以擴展到5個節(jié)點。Neutron OVS雖然是一個高可用架構(gòu),通過MySQL集群實現(xiàn)數(shù)據(jù)庫高可用,通過K8s實現(xiàn)API高可用,但計算邏輯不是分布式的,嚴(yán)重依賴RabbitMQ。如果使用DVR模式,每個計算節(jié)點要部署四個agent,帶來更多的topic,對RabbitMQ的性能是很大的挑戰(zhàn),只要出現(xiàn)一個RabbitMQ宕機或網(wǎng)絡(luò)抖動,會馬上執(zhí)行集群恢復(fù)機制,導(dǎo)致RabbitMQ很快死掉。
另外,在轉(zhuǎn)發(fā)平面上,Open vSwitch的性能沒有vRouter好;Tungsten Fabric的網(wǎng)絡(luò)功能更豐富,而Neutron的Octavia等原生LBaaS組件也有待成熟;多云互聯(lián)方面Tungsten Fabric基于MPLS VPN;和網(wǎng)絡(luò)設(shè)備的交互方面,Neutron只有ironic的networking generic switc driver,Tungsten Fabric支持BGP、NETCONF、EVPN-VXLAN等,基于標(biāo)準(zhǔn)的協(xié)議,涵蓋了瞻博網(wǎng)絡(luò)、思科、華為、銳捷等廠商的設(shè)備。
今天就先分享到這里。謝謝大家!
本次演講及TF中文社區(qū)“2020第一次Meetup”活動資料,請在“TF中文社區(qū)”公眾號后臺點擊“會議活動-Meetup”領(lǐng)取。
申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！
