作者简介：李俊武，sina微博北京-小武，著有《云计算网络珠玑》；三年多交换机研发经历（熟悉Broadcom、Marvell等公司交换芯片转发流程和网络协议），两年多基于Openstack云计算平台架构设计经验，现在华为IT产品线的云计算网络架构与设计组，参与华为公有云和私有云的架构设计方面的工作，包括云平台网络集成华为SDN控制器方面的设计工作等

EVPN（Ethernet VPN）是很早就提出的一种基于转发面控制信令同步MAC转发表项的草案，最近讨论比较多，这里也对其进行更深层次的解读。原创作品，转载需得授权。

一、什么是EVPN及SD-WAN

EVPN的需求文档在RFC 7209中描述，解决问题的场景是客户在广域网下通信时各局点MAC地址的动态通知，主要是针对L2VPN（VPLS，Virtual Private LAN Service）的缺陷（比如无法支持MP2MP、无法支持多链路全活转发等）来提出的；其问题范畴包括：多链路同时负载、基于流的负载均衡、基于流的多路径、跨地理域多PE节点冗余、流量转发优化、组播优化、广播抑制、快速收敛（受限于PE的MAC地址数目等）等方面。

EVPN的方案文档在RFC7432中描述，提出了每EVPN实例有一个唯一的RD（Route Distinguisher，包括一个唯一的MAC-VRF及一个或多个全局唯一的RouteTargets），然后客户的环境通过CE设备连接多个运营商的PE，并且是可选的单路径工作的一主多备或全链路工作的多活（CE到每个运营商PE的以太网链路称之为一个Ethernet segment）；每个PE对其他PE设备通过BGP添加新的route type来互相发布自己本地CE所具备的MAC/IP地址给其他PE，并可以通过安全的鉴权控制与其进行互相发布Active的Mac表项。

从RFC7432的文档描述来看，EVPN的解决方案（以Vlan为Ethernet Tag ID例子）第一个draft版本发布时间是2012年2月，最新一个版本是2015年10月，所解决的问题比较类似于SD-WAN的解决问题领域：通过其使用的术语比如PE/CE等可以看出，是WAN场景下的转发信息同步：从实现层面来看，做法类似于OSPF/ISIS/BGP等传统路由协议，在转发面通过控制信息，实现网络设备间相互发布自己所具备的网络MAC转发信息给彼此的目标。SD-WAN提供的还是运营商网络的边界客户自己设备处进行控制的能力（这里的SD-WAN不包括SD-DCI），以实现网络带宽等资源的最优化调度分配，从而充分且合理的利用首先的网络资源，降低客户办公场所或数据中心跨WAN通信的成本。EVPN方案来讲，则是通过标准的控制信息，通过在PE之间相互交换转发表项来实现自动的多地通信；SD-WAN依然无法对运营商的网络进行控制，因为运营商的网络无法随意对开发者提供控制的API，无论从安全角度还是从工程角度，毕竟多加运营厂商的网络部署短期内还无法融合。

从EVPN的方案角度，并没有限制其Ethernet Tag ID的类型，所以很多设备商提出了针对Vxlan的EVPN解决方案的实现，毕竟Vxlan在云计算场景下是广泛被使用的技术。那如果这样的话，能否搭建一套基于EVPN的云环境：虚拟机通过云平台管理发放，而网络则是各个网络设备通过EVPN来实现转发表项同步，类似于传统的DC?后面就和大家一起来探讨下这个问题。

二、EVPN术的本质及相应的技术

EVPN首先作为一种新的转发面通过控制信息来发布转发表项的方案来提出，根本原因是现在的客户内部DC或办公组网规模越来越大、转发规则也越来越复杂，但是对整体网络资源使用率的协调能力要求越来越高。纵观以太网的组网历史，最初小规模L2组网使用STP协议进行防环来扩大组网规模，但是其一方面浪费了太多带宽，另一方面则是在网络规模稍大时（50-100台交换机设备）收敛时间就会变得异常慢，使得本来带宽利用率就不高的诟病得到了放大，所以STP的组网限制在本地一个有限的组网规模下使用；后来提出了IP层路由的概念，通过TTL来防环，并提出了ECMP等让同一个设备的流通过多路径转发，来提升链路利用率和链路冗余，并提出了RIP/OSPF/BGP等多种路由协议，使得大规模组网时通过设备自身来发布在自己所具有的转发表项，为互联网的出现提供了基础。现在EVPN则是继续沿着这个思路前行，在新的场景下，越来越多的大量客户业务（办公场所或业务所在数据中心）在全世界的不同区域分布，并且需要进行数据通信，尤其是云计算商业模式的出现。

与这种思路不同的另一种解决方案是SDN的架构，通过将网络设备控制面权限收回并集中，实现和设备转发面的分离，从而实现了网络转发表项的协同工作；SDN架构下网络更加灵活，并且集中式控制南向需要标准来控制不同设备商的设备，而北向的标准化为不同业务提供控制网络的能力有了可能，从而打破了以前网络分层带来的网络黑盒概念，让业务对网络低层能力充分感知，最大化利用网络，带来网络资源利用率的提升，降低所需的网络成本；这种架构天然的与云计算网络的架构的需求相匹配，只是云计算对网络设备南向的控制需要的是兼容能力，倡导通过多种控制能力来管理尽可能多的设备商网络设备，对统一性或标准性并不是苛刻要求的；但是在北向上，由于要对业务提供可演进的平滑过度能力，反而比SDN的北向标准性更加注重（这样就可以解释了为什么SDN的北向API工作一直进展不大，而OpenStack的网络组件Neutron的北向API则是已经基本标准化）。

两种思路在云计算下的业务场景进一步相比而言，传统的通过转发面控制信令自主同步转发表项的做法是无法满足云计算要求的；具体体现在云计算业务的弹性上，因为网络的转发面基本是随计算实例的变动而变化的，包括新建算实例、删除计算实例以及计算实例的开关机和迁移等，而计算实例的变动在云计算场景下规模较大且极其频繁，并且云平台下租户业务的一切网络行为都要可预期的可控（比如ARP请求的广播、位置单播/组播的报文转发等），否则可能会导致很多不可预期的网络问题，包括租户间业务带宽的抢占、业务转发行为的一致性等，这几个方面就要求云平台的租户业务网络尤其是VPC内部要能够在有网络拓扑变化时（基本是租户计算实例操作引起的），及时的通知到各个相关网络转发网元，否则很大可能导致流量的部分误转发。这个要求下，SDN架构则可以在计算实例操作的动作下触发SDN的控制器进行集中判断和计算，然后同步所控制网元的转发表项实现协同；而传统路由协议等方式，则需要自己通过控制信令感知并计算来处理转发表项，除了无法最优化利用网络外，更不能及时收敛，因为虚拟网络的计算实例是一直在添删改，那么虚拟网络则会一直处于未收敛的状态，这个情况所带来的问题对于有大规模组网的人来说是很严重的，因为数据中心路由协议大量的BUG是出现在路由协议在网络拓扑变更的处理过程中的转发路径更新计算上。另外，SDN架构通过控制面集中处理的思路，还解决了网络设备RIP局部路由的局限和OSPF各个全局路由计算的浪费及苛刻的一致性要求。所以从这个角度而言，云计算网络的虚拟网络必须是Overlay方式的两层架构，这个不仅仅是传统数据中心向云网络数据中心演进的需要。不然的话，虚拟机的任何操作，都会引起整个数据中心网络设备路由协议栈的重新收敛计算（一个数据中心大规模组网不使用路由协议，完全靠静态路由的手工配置，搭建起来是不可能的，云环境下网络弹性和网络自动化也更是无法实现）。

所以，如果一家云计算公司的网络中，虚拟网络有和物理网络相关组网的耦合，那将天生是个无法实现大规模的侏儒。而OpenStack的Neutron组件对于路由协议的使用也基本限制在网络节点，VPC内部还看不到可能性。

三、再谈SDN网络创新及革命

SDN网络架构的概念已经很久了，也衍生了很多新的概念，甚至衍生到了存储SDS、计算SDC、运维等领域，从而诞生了SDDC的说法。SDN的几个基本原则（集中式控制、控制和转发向分离、开放标准的南北向接口等）是很明确的，其核心思想是让应用能够来直接和网络打交道，即对网络控制来获取所需的资源；凡是提“SDN是一千个读者眼里有一千个哈姆雷特”说法的人是没有理解什么是SDN的托辞。但是SDN的这几个原则从网络技术历史上而言却是又都出现过类似的做法，比如集中控制类似网管软件Mib等、电信网中智能网的交换功能和业务控制功能相分离、云平台网路组件的北向标准API和南向对多种网络设备的集中控制等。当然SDN和这些是绝然不同的，这部分概念对于真正做SDN领域的人，应该在2013年基本确定，现在再讨论似乎已经感觉有点老生常谈了，多讨论也没太多的意义。

类似SDN出现时候一样，现在网络很多新技术提出后也被炒作较多，主要原因是传统网络架构太成熟了，承载了现今的各种主要业务，极其难于演进和创新，所以但凡有点改进只能被包装，不然估计无法推动或体现价值。比如最近的Segment Routing（SR），其实称呼叫Source Rouing比较合适，但是SR方案提出就比较乖巧，一方面找到了原来MPLS方案下RSVP协议的复杂性带来的不可部署从而解决了现网中的一些问题，另一方面在控制面则同时兼容SDN思路和传统路由协议同步的思路，并且方案依赖于MPLS和IPv6的现有压栈技术，根据头标签进行转发（但是仍然需要转发能力的提升，MPLS大多可以沿用原有交换芯片能力实现，IPv6场景下则基本需要芯片重新构建）。
从网络创新角度再讨论下Vxlan，这个技术从其RFC解决的问题来看主要是解决隔离域数目不够、交换机表项不足等问题；但是仔细思考下，隔离域传统网络Vlan只有4K个确实比较少，但是MPLS的Label还是足足有20bit的，这个数目对于一个Region下的规模基本是满足的，为什么不使用MPLS来隔离不同租户哪？而且数据中心或运营商使用BGP+MPLS的组网非常盛行，是极其成熟的技术。交换机表项不足的说法也有点夸张，现在数据中心大量部署万兆交换机是基于博通提供的万兆交换芯片Trident系列的，其MAC地址表项有128K之多，而且云网络下每个交换机并不要求学习所有租户的所有虚拟机MAC表项，对于一定程度上还是可以满足租户甚至是公有云网络诉求的，现在国内大部分公有云厂商的一个Region物理服务器规模都还没到这个量级。那么这两个问题思考后，Vxlan对于云网络的价值更大的比重在于Overlay的分层，一方面给传统数据中心向云数据网络中心演进提供了可能和便利，另一方面则是物理网络的路由协议组网继续使用，云网络虚拟网络VPC则无法使用动态路由协议，从而为二者解耦提供了实现的确切方案。其他的比如NvGre/STT等技术依然同样的效果。

四、随风去吧，EVPN

技术的事情确切来讲很那说那个可以盛行，涉及的不仅仅是技术可行性或优劣，更重要的是很多时候网络设备厂商、互联网数据中心和运营商对于技术的选择，而且更多的是基于他们自身的利益，SDN的发展现状足以说明这些；也可能会类似于MPLS，有心栽花花不开，无疑在柳柳成荫。EVPN技术对于客户而言是有价值的，对于运营商而言需要一定的投资，在SDN这种架构的冲击下，依靠转发面控制信令同步转发表项的做法是否还会被继续青睐，恕难预料，但是可以看清楚的是，EVPN在云场景下尤其是针对Vxlan的MAC转发同步，场景价值基本是设备商的一家说辞。