SDN实战团分享(十七):EVPN Architecture

编者的话】本文系SDN实战团微信群组织的线上技术分享整理而成,由Arista 服务工程师杨文嘉的EVPN Architecture分享。
--------------------------------------------------------------------------

嘉宾:杨文嘉,Arista服务工程师,之前在JUNIPER工作九年,TAC和SE都做过,纯网工。

分享正文
--------------------------------------------------------------------------
自我介绍一下,大名杨文嘉(英文名是小时候装逼给自己起的: Louis Yang),网名大猫猫,猥琐网工一只,天津大学材料科学与工程学院毕业,毕业后北漂八年,现居米帝,坐标Northern Virginia. 一直以来QQ群上比较活跃,特点是人贱嘴欠,所以在网上有一些名声(但不是啥好名声).

***专长是撕逼***

2006年加入JUNIPER中国Systems Engineer团队并兼任臭名昭著的Proctor工作

2010年加入JUNIPER美国大客户技术支持团队(就是TAC),主要负责AT&T骨干网CBB和IPAG以太业务网的技术支持(Labs Networks & Production Networks),& 也兼任北美JNCP team的Proctor工作。

2015年底加入ARISTA,任职ASE,负责Mid-Atlantic区域 SP/投行/Cloud/企业等客户的技术支持和培训(纯网工)

今天我们来聊聊EVPN架构,我拿个PPT基于俺老东家Juniper的,就拿这个为蓝本扯一扯。具体网络设备的部分,基本上拿JUNIPER QFX(包括10K和5100举例),但其实今天跟大伙儿聊天的目的是网络层面的解决方案,而并不是局限于BOX本身或者讨论谁家BOX好。

EVPN architectures / qfx 10k + 5k

今天主要是简单介绍一下EVPN架构并且对网络设计的一些点做一些讨论,以及做一些解决方案层面的纯技术型的比较。

Agenda就是探讨一下两个DC(数据中心)的案例,以及怎么设计EVPN并应用到整个架构里。Again,是解决方案和设计层面的探讨,有关EVPN技术的,并不是比谁家好谁家盒子不好的啊。

(我是先贴一张图,然后就着图跟大家探讨,所以是先图后文字的方式)

大概说一下基础知识,主要其实就是EVPN的NLRI类型了。这5个里咱主要说俩,type 2 和type 5,基本上type 2是发MAC地址更新的,type 5是发IP prefix更新的(哎卧槽这不成了MPLS L3VPN了么)
 
话说回来,貌似确实是比较像基于MPLS的L3VPN技术。总结一下就是EVPN其实可以通过一个BGP session能advertise IP网络信息和MAC地址信息。

看一下EVPN用户的应用情况,主要专注于两个方面,第一个是DCI,就是数据中心互联,顾名思义,就是互相传输多个不同DC之间的信息。第二个就是多租户DC,这可以是单一一个租户DC,但是主要的意思是呢,使用EVPN和VXLAN技术,可以将DC按租户或者按应用划分为多个逻辑的实体(per apps, per tenant, per line of biz). 所以我们基本上从宏观角度看看多DC互联,然后看看单一DC内部的逻辑划分。(相信群里很多大侠对这个非常熟悉,我这里还是要多讲一点基础的东西,需要照顾到对网络不是特别熟悉的同学)

DCI大白话就是互联多个数据中心。这是个简化的说法,当你更推进一步的时候,其实说法是多台router部分互联或全互联(full mesh)。 基本的意思呢就是你需要在多个数据中心互传数据,然后呢DCI可以是L2互联也可以是L3互联。你既想要DC之间数据的可控的分离与隔离,又想要某些节点和链路冗余的功能。

现在我们从技术上和协议上看看如何实现DCI,今日的DCI在协议层面基本上你要先有个类似于MPLS L3VPN的环境,其中一种在现有WAN上启用EVPN的方法就是在DC里直接终结 VXLAN连接,并且使用现有的L3VPN基础架构作为传输架构的功能。
 
上面四个图是示意图,共有4个选项。左边是QFX10K DC1,右边是QFX10K DC2. 其中QFX10K下面你可以理解为网络层面的DC switching fabric, 有个有效的假设其实就是QFX10K是能终结VXLAN的,这个是比较重要的一点。
 
然后广域网那边是两台MX路由器(again, 其实谁家路由器都行),充当edge router的功能。DC1的edge router叫MX1,DC2的edge router叫MX2. 然后我们假设这两台edge router里面已经有了一个基于MPLS的L3VPN架构,现在我们要做的事情是:在第一个DC里建立一个VXLAN隧道,然后通过已有的L3VPN架构传到第二个DC里(图中意思就是终结到DC2里的QFX10K上)。很明显其实一般都有冗余节点设计,但为了简化起见,就先不考虑多设备冗余

Option 1, 假设你已经有了一个广域网架构,是MPLS的L3VPN,然后VXLAN隧道是QFX10K起始和终结的,然后就是over现有的WAN的。你就可以单纯理解为EVPN和L3VPN的嵌套而已,这个是比较简单的方式。

Option 2, 假设你已经有了一个广域网架构,但这个假设是你修改现有WAN架构来新增一个VPN,我们这里是新增了EVPN。所以你从现在看来,option 1很明显是L3VPN,然后option 2是EVPN跑L2. 然后从同一个DC内部的QFX10K到MX,这是EVPN/VXLAN的设计,所以整体来说是基于IP的传输,但是对于两个MX路由器来说,是MPLS, 所以是label switching network. 这里要注意的是:虽然数据转发层面(data plane)采用不同的封装,但通用的控制平面(control plane) 仍然是EVPN。

Option 3, 这里就直接不用MPLS了。这里假设就是某些客户的Internet出口就是WAN连接(统一连接),然后使用IPSec tunnel做互联,当然这也是一种选择了。 。。。这里我要说的是,option 3就是端到端的IP网络(MX1 <>MX2),可以跨越几个ROUTER也可以是跨越Internet。

这里我们打算这么干: 从DC1开启一个VXLAN隧道,路径是走MX1,然后通过DCI连接,到了MX2,然后再到DC2的QFX10K,然后这就是3个不同的VXLAN隧道给串接起来了。 如果你熟悉MPLS VPN的域间解决方案你会发现这个其实就类似于INTER-AS L3VPN的option B, MX就相当于ASBR,我们把这种设计叫作over the top DCI….. again,木有MPLS,就是基于IP的。

Option 4,最简单的。。。。基本意思就是根本木有MX edge router, 直接用dark fiber背对背互联QFX10K,解决方案是简单,没有MPLS,就是EVPN/VXLAN基于IP的。。。。问题这个是最贵的解决方案(绝大多数情况下),钱不是问题,问题是没钱。

把这4个OPTION一个一个铺开来看

Option 1, 右上角小图其实是前一页的图,就放这里,然后主图我们放大,加上一些说明。大伙儿可以看到,我们这儿就是假设已经有了一个L3VPN MPLS的网络(MX1, MX2都是这个L3VPN的PE,数据层面是MPLS, 控制层面是L3VPN BGP NLRI)。我们在这儿就干这么一件事儿:把VXLAN的数据流打进(或者叫tunnel进,或者叫封装进)这个已有的L3VPN里面去。就这么简单。

基本流程,我们在最左边的QFX10K开启VXLAN隧道,然后在最右边的QFX10K终结这个VXLAN隧道。Again, 如果你看的足够仔细,MX就是L3VPN的PE, 控制平面Multiprotocol BGP, 数据平面是MPLS LSP,这是一个非常典型的L3VPN。另外当然我们也可以从QFX10K上看到有和本地MX做BGP peer存在(MBGP),但其实这个MBGP只发IP的NLRI(family inet在JUNOS里就是ipv4 NLRI), 原因是这个其实是VXLAN封装,VXLAN封装是基于IP/UDP的。这么一来,我们可以从控制平面的角度把VXLAN header跨越L3VPN,通过BGP family EVPN在两个QFX10K之间建立直接的MBGP peer关系来advertise MAC or IP prefix.

Option 2和option 1其实有点像,但是实际上我们在option 2里做的事情是把VPN在MX路由器里穿成串~ 我们在option 2里把MX之间的VPN修改了一下,变成了Ethernet VPN(EVPN). 所以我们现在在两个MX之间启用的MPLS,但是MX对本地QFX10K提供的是L2链路。现在我们在两台MX之间控制平面上跑的也是EVPN family NLRI, 所以端到端角度来看,可以从QFX10K直接接受L2流量然后通过这个design直接发到另一个QFX10K

这里有一个需要解决的问题就是EVPN stitching…..大伙儿也许听说过这个名词。。。说白了,这个就是要把不同的封装类型stitch起来(stitch英语是缝起来的意思)。所以在这儿大伙儿可以看到QFX10K和MX之间,存在一个VXLAN隧道。Again, VXLAN是基于IP的,然后我们要把这个基于IP的隧道stitch到基于MPLS的隧道,这个具体工作由MX来完成,我们叫做EVPN stitching

控制平面在这个option里是一致的,都是EVPN(从QFX到MX,从MX到另一个MX,另一个MX再到另一个QFX). 有意思的是,这3个VXLAN隧道是独立的,不同的隧道。两头两个基于IP的,中间一个基于MPLS LSP的,将这3个VXLAN隧道编织起来会出现2处VNID转换点,本图所示,左侧是VNID 100,要stitch到中间的MPLS LSP,然后中间的MPLS LSP还要stitch到右边的VNID 200. 有同学要问,为何如此?答案很简单,MPLS LSP label只对路由器本地有效(所以你不同地方相同的label value完全不是一回事啊). 和MPLS label不同的是,VXLAN是全局有效的。在这个例子里,VNID 100全局有效,所以如果QFX10K 2有VNID 100,那么可以使用VNID 200。然后L2 traffic从左到右转发的时候,需要经过这些隧道(不同的封装)。这个选项其实比较少用了。

我们专门来看看stitching,我们看一下MX 2, 你会看到有两个routing instance,我们管这叫EVI(EVPN的术语),然后我们有一个EVI for EVPN-MPLS, 还有另一个EVI for EVPN-VXLAN. 这两个EVI需要通过落进隧道被stitch到一起,方法就类似于把两个routing instance编织到一起是类似的。Juniper自己的解决方案就是用LT接口。这就是为啥这个option看起来像MPLS Inter-AS option 1,因为从EVI角度来看,实际上呢并无控制平面。所以L2 learning(MAC learning)时,直接用数据平面做MAC地址学习(就跟交换机或者VPLS一样)

就JUNIPER路由设备来说,可以用内部的LT接口把L2VPN和VPLS串接起来,提供一种二层的端到端互通的解决方案。早些年北京电信就拿M10i和M320干过martini <-> vpls互通的事儿。

Option 3目前看来是最经济有效的解决方案,先把刚才说的IPSec放一边儿不管。简单来说,就是两个edge router MX1 MX2之间的三层连接(probably over internet)。跟前面说过的类似,同一个DC内部,QFX10K和MX1有一个VXLAN隧道,区别在于两台MX之间的连接是基于纯IP的VXLAN隧道,就是个路由可达的三层网络而已。当然了,DC 2内部QFX10K和MX 2也是另一个VXLAN隧道。
 
好这下数据平面全是不同的VXLAN隧道了,所以还有VNI转换点。在这里如果你有重复的或者冲突的VNID,你可以per-router的修改。但是从控制平面来讲,是一路BGP EVPN NLRI。

Option 4 出场,这是最简单最直接的方法(当然大多数情况也是TMD最贵的,废话直接拉光纤能不贵么). 技术上讲,两台QFX10K直接互联,控制平面BGP-EVPN,数据平面VXLAN隧道,没有VNI转换点,也不需要router。

下面说说多租户数据中心,T1-T4表示tenant 1-tenant 4(tenant英语是租户的意思)。基本上在网络层面我们要分为spine leaf架构(PPT右边)。三级拓扑上我们想要提供租户之间的隔离,如果你从单一租户角度来看,你希望能跑二层和三层(也就是说路由和交换全有)但是我并不关心你底层是物理的还是虚拟的:again, 作为租户,我只是想在自己的网络内部想跑三层跑三层,想跑二层跑二层,就这么简单。

现在主流的也是最简单的DC网络架构就是三级CLOS架构的拓扑(上图左),是spine leaf的架构,适用于中小型的部署。基本上有一种BGP的设计,就是IBGP。
 
另一个选项是5级CLOS架构的拓扑(上图右),适用于大中型部署,这种架构有更多的BGP设计的考虑,我们一个一个会探讨。架构的选择和设计的细微差别取决于你把网关放哪儿,POD的 namespace,等等。需要考虑的内容还是挺多的。

我们稍微先看一下EVPN FABRIC的具体配置。上面是个简单的spine leaf拓扑,我们先不考虑冗余啊多链路神马的,先看看工作原理。

*******上面这个JUNOS配置不用看,我会解释********
从一个租户角度来看,他的数据流会被封装在一个VRF里(或者叫routing instance)。在这些routing instance里,如果要跑三层流量,那么就是VRF(Virtual Routing & Forwarding instance),下一步我们需要一个二层的routing instance,图中我们叫作VRF_1_VS, 这里VS 是Virtual Switch的缩写,说白了就是二层的routing instance. 好了,我们现在有了三层的routing instance和二层的routing instance

下一个配置的组件,叫作bridge domain(我想术语最好还是别翻译,避免混乱)。每个租户可以有多个bridge domain或多个VLAN,这里我就标识了BD1-BD4. 前面说过了,我们要在每个租户内部能路由也能交换,所以我们需要某种机制来这么做,这就是IRB接口的作用。我们可以通过POLICY来控制租户之间和租户内部的路由。

这里做一个厂商级别的假设(没办法总要稍微落一下地嘛),设备是QFX5100,使用Broadcom Trident 2芯片,这个芯片不支持VXLAN ROUTING,只能做VXLAN二层网关。我们做了bridge domain的配置,然后下一步我们要做个VTEP的配置,VTEP原理这里不多说了,其实就是个绑定到loopback接口的状态机,每个switch上一个VTEP,VTEP的作用就是封装流量和解封流量,其中一个给到状态机的参数就是你想在VNID上用什么数值。上图配置上我们想每个bridge domain都有各自不同的VNID。
 
BD1关联到VXLAN VNID 1, BD2关联到VNID 2,以此类推。VTEP就一个,BD是四个,VNID也是四个,VXLAN隧道也是4个。

看一下Spine的配置,这里不同层次级别的配置被高亮了不同的颜色。首先有个L3 instance VRF_1, 分配给一个IRB接口,然后分配RD, RT……这就组成了EVPN FABRIC的L3部分。

接下来我们要配置L2 instance….VRF_1_VS, 这是给virtual switch的。另外,VTEP里的配置其实就是说“用我的loopback接口做source” ,这里正是配置EVPN控制平面的地方。EVPN一个值得注意的地方是他支持多个封装,并且因为我们是在一个DC内部,我们使用VXLAN封装。然后我们给这个租户配置一套VNID就行了。比如,tenant 1, 你就配置BD1和BD2,然后我们可以看到VNI列表。对于BUM流量,我们使用ingress replication做封装。

我们定义了bridge domain的参数,举例,对于BD1,我们用VLAN 1,跑三层的话我们要起个路由接口,irb.1。 我们还要对VLAN和VXLAN做个映射,所以我们要配置使用哪个VNI数值。我们还要指明BUM流量用什么方式封装通过fabric。

有人要问了“我们需要什么样的policy才能实现多租户的功能?” 实际上你只需要accept ESI community即可,这个ESI community是对服务器做multi-homing的(有人说EVPN实际上就是VPLS的增强版,增强了multi-homing的功能,就是这个ESI的作用)。网络配置层面,你需要接受ESI community和你的RT。 举例来说,一个租户内部,我们要导入他的子网路由条目,我们需要routing policy来完成,如果一个主机在LEAF 1和LEAF 2上同时存在,那么就会有同样的RT数值,这样我们做配置的时候就可以引用。(这就是多租户的POLICY的实现方法,我个人的理解和MPLS VPN的RT所起的作用是类似的,就是标识用户/租户 )

接下来探讨一下LEAF交换机的配置。
 
这个例子和上面的例子的SPINE是QFX10K,LEAF是QFX5100. 对于VXLAN来说可以做L2交换也可以做L3路由。协议方面还是要配置EVPN和VXLAN。

各位请注意:这一点上JUNIPER作为一个厂商,在解决方案上,是规避了自家LEAF SWITCH不能做VXLAN ROUTING这个缺陷的,JUNIPER不能在TRIDENT 2上做VXLAN ROUTING但不代表别家不能做,如CISCO/ARISTA,CISCO是通过一个T2的外部芯片直接recirculate的,ARISTA是T2上直接recirculate的 , 后续上市的芯片如T2+、Tomahawk以及Jericho,都可以做VXLAN ROUTING毫无问题。

下一个配置的选项是交换下面的配置,你想把VTEP和谁关联?很明显,loopback地址,我们需要配置import policy(RT什么的)。对ESI来说你得配置一个特定的RT(因为你要在每个instance里import并accept).

然后是定义VLAN BD1到BD4,这个简单,就不细说了。

那么,下一个问题出现了,到底要不要为每个BD制定一个RT呢?答案是NO. 这里就利用到了auto-generate RT的功能。从一个比较传统的角度来说,RT是一个不同的子类型,并且要带着AS号码的。但是,现在我们创建了一个新的RT格式,也就是左下角绿色的显示,从1开始,然后放VNID,后面其他数值是自动计算的。所以基本上能保证一组LEAF/SPINE总使用同一个RT。配置方法就是route-target ASN:auto.

我们第一个探讨的是ingress replication。 这个特性完成的是: leaf收到BUM流量,就复制到任意其他的LEAF。举例来说:如果LEAF1收到了广播流量,会复制给LEAF 2, 3, 4.

小范围的部署来讲,上面方法没任何问题。但如果你超过1000个LEAF这种部署级别怎么样?会采用另一种方式,叫Assisted Replication,差异就是leaf复制一份给spine, 结束。 举同样的例子,LEAF1收到广播流量,复制给LEAF 2,3,4. 这里他就不这么做,而是用SPINE来干这事儿。这么干对scalability提高是有好处的,因为spine switch一般是比较高型号的设备,更多CPU,更多带宽,更好的ASIC。

我们来看一下不同的VXLAN FABIC的BGP选项。大家都认为有2个通用选项,你用EBGP,每个SWITCH有自己的AS,或者IBGP,整个FABRIC一个AS。EVPN FABRIC比这稍微复杂一点儿,因为你要把UNDERLAY和OVERLAY分开考虑。

为什么要分开考虑?因为你想要一个能感知拓扑的协议。一般来说,我们用BGP来建设IP FABRIC。原因就是我们可以在任何地方使用BGP而不必担心IGP。这就使得你的设计很简单,我们实际上推荐EBGP作为UNDERLAY协议 – 每个SWITCH自己有AS号,从路由角度来说你直接把LOOPBACK的网段发出去就可以了,这样LEAF之间就形成了逻辑互联并且你不用担心RR的问题。
 
到了探讨EVPN的设计的时候,我们想要一个独立于拓扑的设计,这样就可以不关心底层用的是 ospf,isis,bgp。 设计的时候不需要考虑underlay你用的啥协议。这基本上意味着你要使用IBGP – OVERLAY用IBGP,UNDERLAY用EBGP。
 
网络设计的原则就是KISS。 比如你想LEAF1到LEAF4使用evpn来广播MAC地址,最简单的设计就是LEAF1直接PEER两个SPINE,就酱紫。所以要考虑RR, 然后你要从全局考虑MAC地址的发布。。。IBGP在这里就比较合适。

配置就这么写的
 
橙色和蓝色配置组,橙色是UNDERLAY,蓝色是OVERLAY。

唯一需要注意的就是underlay的配置: multipath multiple-as, 这个命令可以实现full multipathing

underlay使用EBGP,每个SWITCH试用自己的AS号码

overlay使用单一AS和IBGP,使用的是EVPN的NLRI

总结一下,就是SPINE LEAF拓扑,包括有不同PEER会话的。我们使用IBGP EVPN NLRI和loopback地址然后我们使用EBGP IPV4 NLRI和物理接口地址

最后的网络架构就像是这样:100% BGP, 从网络的排错角度来说,如果你排错underlay的话,你可以看到full as path. 举个例子,如果你从某个LEAF来show route,你可以看到2个不同AS去往spine,显示的就是101和102。如果你排错overlay的话,你不用担心AS号以及AS PATH.

IBGP=拓扑独立
EBGP=拓扑感知

这个架构和5级CLOS IP FABRIC架构是一样的。

来看看五级FABRIC的设计。EBGP UNDERLAY, IBGP OVERLAY。并没有L2一说

探讨控制平面选项之前,VXLAN L3有一些选项也值得探讨。从上图可以看到,FABRIC是蓝色,SPINE是橙色,LEAF是绿色. JUNIPER QFX10K可以做FABRIC也可以做SPINE, 而QFX5100可以做绿色LEAF。
 
很明显的,QFX10K支持VXLAN路由,我们可以把把L3路由网关的功能放在SPINE层面,把VXLAN L2网关的功能放在QFX5100上。基本上对于FABRIC层面,并没有VXLAN的需求,现今的VXLAN ROUTING的功能是在SPINE上在做的。

自家产品多个嘴:现今的Arista 7050X2可以native支持VXLAN ROUTING功能而不需要packet recirculation (Trident II +)

三种不同的路由的设计选项实际上 影响了我们对于控制平面的设计思路。主要取决于谁来做路由,EVPN UPDATE里type 2 / type 5的路由走向。

如果你能确保你的EVPN设计里绝对不会出现需要用到共享type 2 prefix的设计(每个POD有自己的namespace和并且L2之间并无二层DCI),你可以使用上图的第一个设计思路,这个思路把每个POD设计为一个单独的IBGP岛屿,这个岛屿有自己的AS和自己的RR。在这种设计思路下,FABRIC上用AS-OVERRIDE选项时我们可以在LEAF层面使用同一个AS号码, 这就还是JUNIPER老本行——ISP建网的思路,你可以在POD之间使用type 5 prefix. 但是说实话,这个设计选项并不是非常的符合实际情况因为随着数据中心的发展,必然会有type 2 prefix在多个POD之间会交互……

所以我们实际上可以使用第二个选项(上图中间部分的设计),基本上我们推荐使用SPINE来完成RR的功能(fabric也做RR,也就是多级RR的思路),所以每个POD就相当于BGP协议的cluster,这样当LEAF广播host route的时候,直接类似于普通BGP路由反射器反射路由的情况。Leaf > spine > fabric > spine > leaf。这种情况其实就并不区分type 2或者type 5路由。这是目前推荐的 部署方式。

最后一个选项其实是有点儿fancy和诡异的方法(但其实也并没有那么诡异),那就是把RR单独提炼出来,用外部设备单独反射EVPN路由。如果探讨到多个RR的设计的话,类似L3VPN的情况,你可以对RR做partition(为了提高scalability)。你可以做VNI range,1-4000第一个RR,4000-8000第二个RR,以此类推(可以互相重叠)。

一个RR断掉,不会影响路由,也不会影响整个FABRIC,只会影响特定的VNI range(没有RR冗余的情况下)。

这些设计的方法们肯定会有trade-off, 很难说哪一个选项是绝对最好,个人认为,适合自己的才是最好的。

Again, 目前综合来看,最流行最简单也最推荐的是中间的的设计方式。

本群很多老JUNIPERer和新Brocader 肯定可以看出来,Juniper的数据中心设计不管是从数据平面还是协议的控制平面,都是遵循着做SP大网的思路,这种思路,到底是否真正适合数据中心呢?关于这一点,值得探讨和商榷。

Q&A

Q1:能讲讲arp proxy 的实现么?这个feature对于mpls和vxlan两种封装场景好像不太一样
A1: 不是很理解此问题,因为并没有看到MPLS和VXLAN场景下实现PROXY-ARP的区别

Q2:那4种方案中,哪种最接SDN的地气?也就是是否有SDN对应的实现?
A2: 没有放之四海而皆准的真理,这是DCI的解决方案,和SDN无实质关系,具体采用哪种方案要看用户的场景和设备条件

Q3:Option3 中的VNI转换点是否也是VXLAN缝合点? 是否跟VXLAN GW 实现两个VXLAN间的路由? VNI转换点一定需要路由吗?
A3:是的。不需要VXLAN ROUTING,不是非得需要路由来做VNI转换

Q4: ES的mac单位的BGP update过WAN的话,负担有多大你们测过么?
A4: 并无一个测量标准,所以也没有量化的测试过

Q5:tenant level的过WAN的PBR route control实现了么?
A5: JUNOS PBR(juniper叫FBF, filter based forwarding)支持在VRF内部实现

Q6:比如tenant的用户上跑不同业务 voip 批处理的话怎么保证qos和pbr能下到underlay
A6:对underlay来说,这些只是IP流量。那么传统上网络是怎么处理IP流量的,在这里就是怎么处理的。但到了underlay层面,网络是一个基础设施架构(infrastructure),是不可能针对per-user来细分流量的

Q7:为什么不能结合option2 和 option3(BGP family EVPN options)?
A7:当然可以结合,只会更乱而已。说白了,网络怎么做都可以,但是你不能乱到把OPEX顶到天上的高度。Option 2 & option 3结合你的OPEX直接上天了(层次化IBGP RR + 外部RR).

Q8:这三个场景arista都能支持么

A8:是的,全部支持

Q9:为什么DCI互联一定要用EVPN作为控制层协议,纯VXLAN应该也是可以得吧
A9:VXLAN是转发平面的东西,EVPN是控制平面的东西,这两个负责不同的工作

Q10:fabric spine leaf这种分层方式算是arista还是juniper的提法?
A10:这是大型ott正在用的,不是厂家提的。FACEBOOK就是五级CLOS架构

--------------------------------------------------------------------------
SDN实战团微信群由Brocade中国区CTO张宇峰领衔组织创立,携手SDN Lab以及海内外SDN/NFV/云计算产学研生态系统相关领域实战技术牛,每周都会组织定向的技术及业界动态分享,欢迎感兴趣的同学加微信:eigenswing,进群参与,您有想听的话题可以给我们留言。


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。
  • 本文链接http://www.sdnlab.com/16113.html
  • 本文标签技术/tech

分享到:
相关阅读
3条评论

登录后才可以评论

  1. comment reply 风行者 2016/03/04 12:50
    不错技术文章,专门注册一个来顶帖
        1楼
  2. comment reply Holger 2016/04/10 16:15
    大猫猫就是6
        2楼
  3. comment reply liufengchun100 2016/08/01 22:47
    PPT不错。
        3楼
SDNLAB君 发表于16-03-04
0