SDN实战团分享（十七）：E*** 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/企业等客户的技术支持和培训（纯网工）
今天我们来聊聊E***架构，我拿个PPT基于俺老东家Juniper的，就拿这个为蓝本扯一扯。具体网络设备的部分，基本上拿JUNIPER QFX（包括10K和5100举例），但其实今天跟大伙儿聊天的目的是网络层面的解决方案，而并不是局限于BOX本身或者讨论谁家BOX好。
E*** architectures / qfx 10k + 5k
今天主要是简单介绍一下E***架构并且对网络设计的一些点做一些讨论，以及做一些解决方案层面的纯技术型的比较。
Agenda就是探讨一下两个DC（数据中心）的案例，以及怎么设计E***并应用到整个架构里。Again，是解决方案和设计层面的探讨，有关E***技术的，并不是比谁家好谁家盒子不好的啊。
（我是先贴一张图，然后就着图跟大家探讨，所以是先图后文字的方式）
大概说一下基础知识，主要其实就是E***的NLRI类型了。这5个里咱主要说俩，type 2 和type 5，基本上type 2是发MAC地址更新的，type 5是发IP prefix更新的(哎卧槽这不成了MPLS L3***了么)
话说回来，貌似确实是比较像基于MPLS的L3***技术。总结一下就是E***其实可以通过一个BGP session能advertise IP网络信息和MAC地址信息。
看一下E***用户的应用情况，主要专注于两个方面，第一个是DCI，就是数据中心互联，顾名思义，就是互相传输多个不同DC之间的信息。第二个就是多租户DC，这可以是单一一个租户DC，但是主要的意思是呢，使用E***和VXLAN技术，可以将DC按租户或者按应用划分为多个逻辑的实体(per apps, per tenant, per line of biz). 所以我们基本上从宏观角度看看多DC互联，然后看看单一DC内部的逻辑划分。（相信群里很多大侠对这个非常熟悉，我这里还是要多讲一点基础的东西，需要照顾到对网络不是特别熟悉的同学）
DCI大白话就是互联多个数据中心。这是个简化的说法，当你更推进一步的时候，其实说法是多台router部分互联或全互联(full mesh)。 基本的意思呢就是你需要在多个数据中心互传数据，然后呢DCI可以是L2互联也可以是L3互联。你既想要DC之间数据的可控的分离与隔离，又想要某些节点和链路冗余的功能。
现在我们从技术上和协议上看看如何实现DCI，今日的DCI在协议层面基本上你要先有个类似于MPLS L3***的环境，其中一种在现有WAN上启用E***的方法就是在DC里直接终结 VXLAN连接，并且使用现有的L3***基础架构作为传输架构的功能。
上面四个图是示意图，共有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的L3***架构，现在我们要做的事情是：在第一个DC里建立一个VXLAN隧道，然后通过已有的L3***架构传到第二个DC里（图中意思就是终结到DC2里的QFX10K上）。很明显其实一般都有冗余节点设计，但为了简化起见，就先不考虑多设备冗余
Option 1, 假设你已经有了一个广域网架构，是MPLS的L3***，然后VXLAN隧道是QFX10K起始和终结的，然后就是over现有的WAN的。你就可以单纯理解为E***和L3***的嵌套而已，这个是比较简单的方式。
Option 2, 假设你已经有了一个广域网架构，但这个假设是你修改现有WAN架构来新增一个***，我们这里是新增了E***。所以你从现在看来，option 1很明显是L3***，然后option 2是E***跑L2. 然后从同一个DC内部的QFX10K到MX，这是E***/VXLAN的设计，所以整体来说是基于IP的传输，但是对于两个MX路由器来说，是MPLS， 所以是label switching network. 这里要注意的是：虽然数据转发层面(data plane)采用不同的封装，但通用的控制平面(control plane) 仍然是E***。
Option 3, 这里就直接不用MPLS了。这里假设就是某些客户的Internet出口就是WAN连接（统一连接），然后使用IPSec tunnel做互联，当然这也是一种选择了。 。。。这里我要说的是，option 3就是端到端的IP网络(MX1 <>MX2)，可以跨越几个ROUTER也可以是跨越Internet。
这里我们打算这么干: 从DC1开启一个VXLAN隧道，路径是走MX1，然后通过DCI连接，到了MX2，然后再到DC2的QFX10K，然后这就是3个不同的VXLAN隧道给串接起来了。 如果你熟悉MPLS ***的域间解决方案你会发现这个其实就类似于INTER-AS L3***的option B, MX就相当于ASBR，我们把这种设计叫作over the top DCI….. again，木有MPLS，就是基于IP的。
Option 4，最简单的，基本意思就是根本木有MX edge router, 直接用dark fiber背对背互联QFX10K，解决方案是简单，没有MPLS，就是E***/VXLAN基于IP的。。。。问题这个是最贵的解决方案（绝大多数情况下），钱不是问题，问题是没钱。
把这4个OPTION一个一个铺开来看
Option 1, 右上角小图其实是前一页的图，就放这里，然后主图我们放大，加上一些说明。大伙儿可以看到，我们这儿就是假设已经有了一个L3*** MPLS的网络（MX1, MX2都是这个L3***的PE，数据层面是MPLS, 控制层面是L3*** BGP NLRI）。我们在这儿就干这么一件事儿：把VXLAN的数据流打进（或者叫tunnel进，或者叫封装进）这个已有的L3***里面去。就这么简单。
基本流程，我们在最左边的QFX10K开启VXLAN隧道，然后在最右边的QFX10K终结这个VXLAN隧道。Again, 如果你看的足够仔细，MX就是L3***的PE, 控制平面Multiprotocol BGP, 数据平面是MPLS LSP，这是一个非常典型的L3***。另外当然我们也可以从QFX10K上看到有和本地MX做BGP peer存在（MBGP），但其实这个MBGP只发IP的NLRI(family inet在JUNOS里就是ipv4 NLRI), 原因是这个其实是VXLAN封装，VXLAN封装是基于IP/UDP的。这么一来，我们可以从控制平面的角度把VXLAN header跨越L3***，通过BGP family E***在两个QFX10K之间建立直接的MBGP peer关系来advertise MAC or IP prefix.
Option 2和option 1其实有点像，但是实际上我们在option 2里做的事情是把***在MX路由器里穿成串~ 我们在option 2里把MX之间的***修改了一下，变成了Ethernet ***(E***). 所以我们现在在两个MX之间启用的MPLS，但是MX对本地QFX10K提供的是L2链路。现在我们在两台MX之间控制平面上跑的也是E*** family NLRI， 所以端到端角度来看，可以从QFX10K直接接受L2流量然后通过这个design直接发到另一个QFX10K
这里有一个需要解决的问题就是E*** stitching…..大伙儿也许听说过这个名词。。。说白了，这个就是要把不同的封装类型stitch起来（stitch英语是缝起来的意思）。所以在这儿大伙儿可以看到QFX10K和MX之间，存在一个VXLAN隧道。Again, VXLAN是基于IP的，然后我们要把这个基于IP的隧道stitch到基于MPLS的隧道，这个具体工作由MX来完成，我们叫做E*** stitching
控制平面在这个option里是一致的，都是E***(从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（E***的术语），然后我们有一个EVI for E***-MPLS, 还有另一个EVI for E***-VXLAN. 这两个EVI需要通过落进隧道被stitch到一起，方法就类似于把两个routing instance编织到一起是类似的。Juniper自己的解决方案就是用LT接口。这就是为啥这个option看起来像MPLS Inter-AS option 1，因为从EVI角度来看，实际上呢并无控制平面。所以L2 learning(MAC learning)时，直接用数据平面做MAC地址学习（就跟交换机或者VPLS一样）
就JUNIPER路由设备来说，可以用内部的LT接口把L2***和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 E*** NLRI。
Option 4 出场，这是最简单最直接的方法（当然大多数情况也是TMD最贵的，废话直接拉光纤能不贵么）. 技术上讲，两台QFX10K直接互联，控制平面BGP-E***，数据平面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，等等。需要考虑的内容还是挺多的。
我们稍微先看一下E*** 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……这就组成了E*** FABRIC的L3部分。
接下来我们要配置L2 instance，VRF_1_VS, 这是给virtual switch的。另外，VTEP里的配置其实就是说“用我的loopback接口做source” ，这里正是配置E***控制平面的地方。E***一个值得注意的地方是他支持多个封装，并且因为我们是在一个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的（有人说E***实际上就是VPLS的增强版，增强了multi-homing的功能，就是这个ESI的作用）。网络配置层面，你需要接受ESI community和你的RT。 举例来说，一个租户内部，我们要导入他的子网路由条目，我们需要routing policy来完成，如果一个主机在LEAF 1和LEAF 2上同时存在，那么就会有同样的RT数值，这样我们做配置的时候就可以引用。（这就是多租户的POLICY的实现方法，我个人的理解和MPLS ***的RT所起的作用是类似的，就是标识用户/租户 ）
接下来探讨一下LEAF交换机的配置。
这个例子和上面的例子的SPINE是QFX10K，LEAF是QFX5100. 对于VXLAN来说可以做L2交换也可以做L3路由。协议方面还是要配置E***和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。E*** FABRIC比这稍微复杂一点儿，因为你要把UNDERLAY和OVERLAY分开考虑。
为什么要分开考虑？因为你想要一个能感知拓扑的协议。一般来说，我们用BGP来建设IP FABRIC。原因就是我们可以在任何地方使用BGP而不必担心IGP。这就使得你的设计很简单，我们实际上推荐EBGP作为UNDERLAY协议 – 每个SWITCH自己有AS号，从路由角度来说你直接把LOOPBACK的网段发出去就可以了，这样LEAF之间就形成了逻辑互联并且你不用担心RR的问题。
到了探讨E***的设计的时候，我们想要一个独立于拓扑的设计，这样就可以不关心底层用的是 ospf,isis,bgp。 设计的时候不需要考虑underlay你用的啥协议。这基本上意味着你要使用IBGP – OVERLAY用IBGP,UNDERLAY用EBGP。
网络设计的原则就是KISS。比如你想LEAF1到LEAF4使用e***来广播MAC地址，最简单的设计就是LEAF1直接PEER两个SPINE，就酱紫。所以要考虑RR， 然后你要从全局考虑MAC地址的发布。。。IBGP在这里就比较合适。
配置就这么写的
橙色和蓝色配置组，橙色是UNDERLAY，蓝色是OVERLAY。
唯一需要注意的就是underlay的配置: multipath multiple-as, 这个命令可以实现full multipathing
underlay使用EBGP，每个SWITCH试用自己的AS号码
overlay使用单一AS和IBGP，使用的是E***的NLRI
总结一下，就是SPINE LEAF拓扑，包括有不同PEER会话的。我们使用IBGP E*** 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 +)
三种不同的路由的设计选项实际上影响了我们对于控制平面的设计思路。主要取决于谁来做路由，E*** UPDATE里type 2 / type 5的路由走向。
如果你能确保你的E***设计里绝对不会出现需要用到共享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单独提炼出来，用外部设备单独反射E***路由。如果探讨到多个RR的设计的话，类似L3***的情况，你可以对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 E*** options)？
A7：当然可以结合，只会更乱而已。说白了，网络怎么做都可以，但是你不能乱到把OPEX顶到天上的高度。Option 2 & option 3结合你的OPEX直接上天了（层次化IBGP RR + 外部RR）.
Q8：这三个场景arista都能支持么
A8：是的，全部支持
Q9：为什么DCI互联一定要用E***作为控制层协议，纯VXLAN应该也是可以得吧
A9：VXLAN是转发平面的东西，E***是控制平面的东西，这两个负责不同的工作
Q10：fabric spine leaf这种分层方式算是arista还是juniper的提法？
A10：这是大型ott正在用的，不是厂家提的。FACEBOOK就是五级CLOS架构
标签：十七,MPLS,我们,Architecture,QFX10K,SDN,MX,VXLAN,L3 来源： https://blog.51cto.com/u_15127681/2821712