解读《SDWAN生态技术报告》~ 运营商侧

4.2 以运营商云端为核心的SD-WAN

这种思路是对传统的MPLS VPN方案的延伸，相比于端到端的Overlay，变成了两端的最后一公里用Overlay，而中间的骨干段交给运营商的专网[A]。最后一公里的这一段，考虑到安全性通常会采用IPSec[B]，中间骨干的这一段，如果运营商有能力可以把MPLS VPN集成进去，如果短期无法集成MPLS VPN，骨干这一段用MPLSoverGRE或者VxLAN直接打过去也是可以的[C]。

【
A、	运营商SD-WAN很有意思，实际上就是提供了一张Overlay的大网，现有公有云，如阿里云与此
几乎相差不大，唯一的区分或许就是未提供SD-WAN的专项接入能力，包括多租户的管理以及服务链
的提供。而企业侧（混合云）组网则可以完全Overlay在运营商SD-WAN之上。
B、	如果POP接入为了安全或性能考虑，有特定的改造，那么运营商将提供专有的CPE，或者采用通
用的VPN即可。私网路由由企业CPE维护，并对接到有效的POP，同时保持最后一公里的安全和性能
即可。
C、	运营商首先肯定是首推其MPLS，但对企业来说，资费没有任何降低，此时就要求运营商骨干支
持普通宽带，需要在POP端进行为不同租户进行应用分流（包括访问Internet分流和骨干端应用分流-
区分使用MPLS线路还是Internet线路），并根据分流情况智能计费-方案设计需要符合监审要求，并支
持第三方审计。运营商提供SD-WAN的强项是，其在降低资费的同时，可以优化其Underlay网络，保
障其POP点宽带线路的最优。
】

除了传统的网络运营商以外，目前一些公有云运营商也开始建设私有的骨干网。要注意的是，本部分内容中所指的运营商，包括网络运营商以及公有云运营商，，由于SD-WAN架构从组网技术层面来看类似，因此没有做显示的区分，一些细节上的区别会穿插在具体内容中进行介绍。
本质上，这是一种将运营商专网的的优质连接能力，以最后一公里Overlay作为技术手段，通过Internet进行提供的架构，因此可将其看作是一种以云端为核心的SD-WAN服务[A]。

【
A、	果然如此，那么运营商需要关心的就是降费提速，体现其SD-WAN优势，在线路和POP集群上最
大化复用，产品以带宽和接入服务形式体现；最后一公里仍然可以包装为专有CPE产品进行销售，或
提供开放的VPN接入接口。
】

4.2.1 SD-WAN网关

要整合运营商的线路资源，就要在运营商的POP点里面放接入网关，由SD-WAN网关来衔接用户侧CPE的最后一公里以及网络侧的IP/MPLS骨干线路，此时用户侧的CPE就相当于CE设备，而SD-WAN网关就相当于PE设备，符合传统的组网模型。由于中间引入了SD-WAN网关进行解耦，因此传统的企业出口路由器也可以进行接入SD-WAN的组网中。另外，CPE还增加了一项最为主要的工作，就是需要能够自动地把流量牵引到SD-WAN网关上，或者在识别出关键应用后将其流量牵引到SD-WAN网关上[A]。

【
A、	企业侧组网方式与前一章SD-WAN方式完全相同，运营商SD-WAN对企业侧可以抽象为一条智能
线路即可，但要求运营商提供SD-WAN网关接入接口以及最后一公里传输传输方式。运营商由于涉及
多租户接入，因此流量隔离由运营商维护。
】

整体设计

对于网络运营商来说，SD-WAN网关与传统PE所扮演的角色并没有本质的区别[A]。SD-WAN网关作为不同客户流量的汇聚点，其端口的速率和数量通常要求在8*10Gbps或以上，而且由于它要负责大量IPSec隧道的终结，因此通常需要专用的硬件进行加解密。对于SD-WAN的创业公司来说，他们在运营商的POP点中并没有存量的PE，所以就只能放新的设备进去，形态上一般是x86服务器，高配CPU和内存，转发面通过DPDK进行加速。对于传统的设备厂商来说，他们在运营商POP中可能会有存量的PE[B]，如果存量设备具备作为SD-WAN网关的条件即可进行复用，否则也可以选择把SD-WAN网关以板卡的形式插到存量设备的机框上。对于Tier 1运营商而言，随着其端局云化的推进，SD-WAN网关也有可能以vPE这种虚拟化的形态存在，关于端局云化的介绍，可参考后面vCPE部分的内容。

【
A、	此处采用CE-PE模型仍属于L3组网，需要运营商SD-WAN网关到企业的CPE路由可达（一般采用
VPN拨号分得TUN口IP），并打通运营商网络，这属于典型的CE-PE模型，实现上可采用VXLAN
 VPN或IPSEC VPN，前者在L2上隔离私网，但L3上仍然需要划分到不同VRF。企业侧CPE将入运营
 商的POP接点后得到的TUN接口当作“物理口”，并在之上建立企业侧的端到端通路，技术上延用上一
 章节的GRE+IPSEC方案即可。
B、	盒子PE在扩容性上不足，后续仍然会被vPE代理，并以大规模云化CPE提供服务。由于性能考
虑，POP点提供IPSEC VPN接入能力的支持必要性并不明显-运营商仅提供传输通道，保证传输通道
的最优。数据安全交企业侧CPE提供端到端保护。另外，Tier 1运营商如果使用盒子PE，那么骨干网
可能仍然是Underlay网络，仅接入端实现Overlay，此种方式在路由层面扩展性和可控性较差。
】

公有云运营商的POP点中很可能并不具备存量设备，不过他们可以选择复用VPN网关的产品进行POP接入。由于公有云运营商通常会采用自研的方式来实现网关，因此很难定义其产品形态，基于x86服务器来实现网关集群的方式较为常见，并可根据接入地区的需求，去调整网关集群的性能与规模[A]。

【
A、POP点采用VPN网关集群较为合适，对外体现为单IP接入（或少量双IP备份接入），对内使用负
载均衡器分流，即通用的NFV处理模型。
】

控制器的设计上，CPE的管理[A]和SD-WAN网关的管理[B]，两者可以独立实现，也可以采用一套控制器实现统一的控制。从控制器部署的位置来看，对于Tier 1网络运营商，通常是在地市级的核心机房里面，负责控制下属的各个机房的SD-WAN网关，以及本地企业的CPE。对于其他运营商而言，通常可采用全网扁平化的部署方式，部署在POP点/云中。Portal运营商通常会选择自己来做定制，其部署的位置也取决于运营商站在什么层面上来看待SD-WAN的业务，这里不再多说。

【
A、	CPE部署在企业侧，可以由SD-WAN运营商提供服务的同时提供CPE设备，此时CPE可以纳入运
营商的统一管理域中（个人觉得运营商可以提供管理服务，但不会与其SD-WAN网关纳入一体）；如
果CPE由企业外够或自研，则由企业的控制器来管控。两者都应是分层次的管理。
B、	SD-WAN网关属于CE-PE-(P)-PE-CE模型，内部运行流量工程选路即可，同时兼备提速降费的目
标，技术实现上与企业侧大致相同。
】

另外当SD-WAN引入到运营商后，实现上必须要进行多租户的增强与改造。对于CPE和SD-WAN网关来说，需要封装上能够标识租户并进行VRF关联[A]。对于控制器来说，要明确CPE所属的租户，以及SD-WAN网关上所接入的租户列表，另外在分发策略和路由的时候，需要能带着租户的信息下去。对于Portal来说，则要提供RBAC的能力，对不同账号的权限进行区分与隔离。多租户所带来的细节问题还有很多，可能会贯穿到整个系统中，此处无法逐一而述。

【
A、SD-WAN网关PE-CE侧由TUN口标记租户VRF，PE-PE侧如果使用IP VPN，则通过扩展选项携带
租户VRF，如果使用MPLS VPN，则由LABEL区分，如果内部转发关联用户等级，则需要扩展IP选项
或LABEL划区域支持。
】

接入段的实现

CPE与SD-WAN网关间的最后一公里，以非Tier 1网络运营商的角度来考虑，通常就是用IPSec打通[A]，把Tier 1网络运营商的接入网Overlay掉。这种方式下，CPE与SD-WAN网关间的传输承载在Internet上，SD-WAN网关的选择将直接决定接入端的质量，因此CPE需要能够优选一个SD-WAN网关进行就近接入[B]。SD-WAN网关可以采用多条Tier 1线路进行接入，以保证不同企业客户的接入质量[C]。

【
A、	按上段落分析，个人觉得此处不需要IPSEC，仅GRE即可，运营商不需要保证此段的安全性，而
是可达性，再何况使用IPSEC也会在SD-WAN网关解包，何来安全？
B、	由控制器根据CPE所有区域下发CPE可选的POP接入点集合，CPE探测最近POP点接入或双备接
入或多线路负载接入。
C、	国内需要考虑南北传输问题，所以POP点需要接入多种运营商，对外提供一系列IP地址。
】

在实现方式上，管理平面/控制平面可以根据CPE的部署位置，直接为CPE指定要接入的SD-WAN网关的IP地址，其实现相对简单，不过控制器需要维护SD-WAN网关的状态，而且可能无法保证接入的最优。相比之下，管理平面/控制平面也可以为CPE提供一组备选的SD-WAN网关IP地址列表，然后由CPE去主动地去探测与不同SD-WAN网关间的访问质量，选择访问质量最优的SD-WAN网关进行接入。

SD-WAN网关为了保证接入的高可用性，需要能够在当前所接入的SD-WAN网关挂掉，或者服务质量下降后进行自动切换，这种自动的切换可能会面临着一些问题，比如基于IKE的IPSec重新协商会导致业务的延时/中断，而且如果选到不同地理区域的POP，还可能会给计费带来额外的复杂性[A]。解决此问题，可采用双隧道主备接入的方式，或者同一地区的SD-WAN网关以集群方式进行实现与部署，采用控制器来实现主备、集群的集中管控。如果要求在不同SD-WAN网关间进行负载均衡，其实现难度将进一步加大。

【
A、转换为在PE-PE侧和PE-Internet侧收口计费是一种替代方式。
】

另外，还有一种实现思路，是利用Anycast的方式来部署SD-WAN网关，不同地区的SD-WAN网关集群均采用同一个Anycast IP地址提供服务，对于CPE而言只需要与这个Anycast IP建立隧道，即可通过Internet的路由来保证SD-WAN网关的就近接入[A]。不过，这通常需要运营商具备通过BGP对外发布Anycast地址的能力，门槛较高。

【
A、Anycast IP除需要运营商支持外，同时也依赖于运营商的路由发布；另外一个缺点是无法实现主备
或多线POP接入。如果在POP点实现可靠的集群，此种方式就是一种节省IP并同时达到就近接入的好
方法。
】

IPSec的流量顺利到达SD-WAN网关后，还需要对用户的身份进行识别，并关联到相关的VRF，技术上可以有以下几种手段：（1）利用GREoverIPSec，为GRE口关联VRF[A]；（2）利用MPLSoverGREoverIPSec，通过标签进行关联[B]；（3）用VxLANoverIPSec，通过VNI来关联VRF[C]；（4）采用IPSec逻辑口来关联VRF[D]；（5）用ISAKMP Profile绑定VRF，识别SPI后直接关联VRF[E]；（6）用私有的IPSec封装，在IPSec后面单独加VPN的字段[F]。其中，（1）的标准化程度最高，但封装效率较差，（5）的封装效率较好，但是要求使用IKE作为控制平面，在不同的实现中会有不同的选择。

【
这里说的像是CE-PE侧，此侧流量识别采用上述方法1，6比较合适，但6更适用于动态GRE，下面结
合上述方法，对PE-PE侧的VPN模型进行分析：
A、	如果是PE-PE侧，那么需要为每一个租户启用一个PE-PE侧的GRE隧道，并绑定VRF，但多租户
的GRE，Source IP和Dest IP肯定是复用Underlay的一对IP，故而IPSEC肯定也仅一路，所以同时要
求IPSEC能区分不同GRE收发的报文，IPSEC扩展选项中也必须携带此信息。
B、	如果是PE-PE侧，通过标签区分租户，需要BGP为CE侧路由分标签，然后在PE-PE侧复用GRE
和IPSEC隧道，此种用法比较少见。
C、	如果是PE-PE侧，将PE-CE侧TUN口划分到不同的VXLAN中，并对入口报文流打VXLAN ID，经
SD-WAN网关L3处理后到达PE-PE侧，再经GRE(加VXLAN头部)转出，由IPSEC透明保护发送。
D、	如果是PE-PE侧，为每一个租户启用一条IPSEC隧道，并复用是同的Underlay Source和Dest，
此方式隧道数目较多，管理繁重，且IPSEC隧道口对组播业务支持不够，用法较少见。
E、	如果是PE-PE侧，未详细分析，与D很类似，显示使用ISAKMP区分VRF，此方式需要控制面与
转发面耦合。
F、	如果是PE-PE侧，此方式较通用，并且容易理解，不同租户VRF在转发面复用GRE隧道，经GRE
转出后，由IPSEC识别GRE和VRF，通过IPSEC扩展选项携带VRF发出。
】

对于Tier 1网络运营商来说，在SD-WAN网关接入段的设计上会有些不同。对于异网企业用户，可以通过上述Overlay的方式进行灵活的接入，但是对于本网企业用户则没必要使用IPSec，可以直接利用以太网/PON等存量的接入技术。不过，这些存量接入技术的灵活性一般都比较差，因此也可以在适当的位置上引入VxLAN等Overlay技术，通过控制器来实现新型业务的自动化开通。

骨干段的实现

SD-WAN网关终结封装并识别租户后查找路由，如果流量目的地同样是在同一地区进行接入，那么SD-WAN网关就直接发送给目的CPE即可[A]，流量模型为CPE—SD-WAN网关—CPE，当然对于这部分流量，如果两个CPE间可以，旁路掉SD-WAN网关。

【
A、由于需要SD-WAN网关再路由，所以IPSEC VPN隧道应为隧道模式。此处，如果在企业侧，采用
FULL MESH组网，如果SPOKE1->SPOKE2旁路通信时未获取到SPOKE2的公网IP，可在紧急模式下
将SPOKE2的公同IP指向HUB，能可能获取不同SPOKE2的IP吗？
】

如果流量目的地是在远端，那么两端的SD-WAN网关间就需要通过骨干网进行传输了。一般来说，SD-WAN网关间的传输在overlay的逻辑上一跳过去就可以了，其实现方式有如下几种：（1）SD-WAN网关间走MPLS VPN，且SD-WAN网关自己具备MPLS VPN的能力，这时可以为出向流量标记Service标签，此时流量模型为CPE—SD-WAN网关—SD-WAN网关—CPE；（2）SD-WAN网关间走MPLS VPN，但是SD-WAN网关并不具备MPLS VPN的能力，那么SD-WAN网关就要通过VLAN子接口和存量的PE设备做背靠背连接，同时与PE间起静态或者eBGP打通路由，然后由PE来完成MPLS VPN的工作，此时流量模型为CPE—SD-WAN网关—PE—PE—SD-WAN网关—CPE[A]；（3）如果骨干网不具备MPLS VPN的条件，也可以直接通过IP隧道打过去，MPLSoverGRE或者VxLAN都是可以的[B]，通过Service标签或者VNI来隔离租户，此时流量模型为CPE—SD-WAN网关—SD-WAN网关—CPE。

【
A、	复用存量PE和线路的这种方式是比较合适的，短期来看，SD-WAN网关完全代替PE MPLS功能无论是在性能上还是稳定性上是不可能的。
B、	使用VXLAN比较轻量，将VRF映射到VNI，通过复用GRE（带VXLAN头部）再由IPSEC保护发送。（或上述F方式，无VXLAN支持，由IPSEC携带VRF信息）
】

如果骨干的这段传输还要做两个运营商间的跨域，这就比较麻烦了，路径中不可避免地要引入两个运营商的ASBR，流量模型可能为CPE—SD-WAN网关（运营商A）—PE（运营商A）—ASBR（运营商A）—ASBR（运营商B）—PE（运营商B）—SD-WAN网关（运营商B）—CPE。除了网络模型比较复杂以外，还需要在不同运营商间进行业务的协同。

另外，还可以在不同的SD-WAN网关间进行多跳中继，流量模型变为CPE—N*SD-WAN网关—CPE，这种方式通常出现在线路资源比较有限的方案中，如果源和目的SD-WAN网关间不存在专用的线路，通过Internet直接打通所获得的质量又比较差，此时有可能就需要找到一些POP点来进行中继，这需根据不同POP点间的传输质量进行动态的路由调度[A]。

【
A、首先是解决不同运营商跨域的南北问题，使用BGP线路打通不同运营商，再考虑POP组网TE工
程，对于Tier 1运营商可能完全不需要考虑，其可以最大化使用线路。而对于新型创业性SD-WAN运营
商则需要考虑整体性能问题。
】

可以看到的是，不同的场景与业务需求会导致不同的路径选择，流量模型不再是简单的CPE间IPSec一跳打通。当然，对于原生的SD-WAN架构，如果采用Hub-Spoke的拓扑，流量也需要通过Hub进行中继，不过Hub是企业自有的设备，数量比较有限、分布比较固定、Hub间如果需要进行中继也通常有固定的路径，相比之下SD-WAN网关属于运营商的设备，其数量更多、分布更加广泛，SD-WAN网关间流量的转发可能也会更加动态。因此在引入SD-WAN网关后，对于控制器提出了较大挑战，可能需要在集中式和分布式间重新进行决策[A]，以求在两者之间找到平衡。不同方案中的路由实现，可能会存在较大差异。

【
A、主要体现在多租户AAA管理，以及大量POP群中SD-WAN的管理。同时涉及POP组网和路径优
化。
】

Internet流量的处理

对于Internet流量，分流可以由企业分支站点的CPE实现，流量模型是CPE—Internet，CPE还需要在本地完成NAT、QoS、安全等处理。如果企业采用Hub-Spoke的拓扑，Internet流量可能会需要回传Hub进行集中式的处理，不过由于Hub数量较为有限，Spoke到Hub的回传距离可能会比较远，导致Spoke访问Internet流量的质量下降，而且所有的Internet流量都通过Hub接入，对Hub的接入带宽也提出了较高的要求。

引入SD-WAN网关后，流量模型可能会变为CPE—SD-WAN网关—Internet[A]，由SD-WAN网关完成Internet流量与VPN流量的分流。对于企业来说，这种区域性SD-WAN网关分流的优势在于，既可以通过SD-WAN网关为本地的多个分支集中地提供NAT、QoS、安全等服务，避免了以分支为单位去使用这些服务的成本与复杂性，另外也可以避免Internet流量绕行Hub所造成的时延与带宽消耗。

【
A、思考：门户接入侧还需要计费吗？，包括上述提到的异网络接入的情况，这种双重收费如何体现
在“提速降费”的目标上（下段落有描述）？ 访问Internet流量经SD-WAN出，一方面是利用到POP点的
公共安全机制，另一方面避免流量绕行到HUB。
】

当然Internet业务的具体设计，还取决于运营商自身的角色。对于Tier 1网络运营商而言，将SD-WAN网关引入Internet路径上，能够将企业客户在本地所有分支的Internet业务统一地管理起来，不过需要考虑好存量Internet接入设备与SD-WAN网关间的关系，以及对现有接入业务的影响，例如是否允许在一根接入线上同时承载企业宽带和VPN两种业务。对于非Tier 1网络运营商来说，由于并不掌握企业的Internet最后一公里的接入资源，通过Overlay的方式把SD-WAN网关引入Internet路径上，可能会增加接入业务的成本与复杂性。对于公有云运营商来说，可以通过SD-WAN网关把Internet流量回传到云上的VPC，通过VPC集中地提供NAT、安全等服务，相当于以VPC作为企业的Hub，但是要考虑好Hub VPC所能提供的价值，是否能覆盖掉回传到云上的成本。

对于企业的SaaS办公流量，可以通过Overlay的方式把SD-WAN网关引入Internet路径上，利用其骨干段专网的高品质传输，将其加速牵引到距离访问目标较近的位置，从而绕过公众互联网的传输，优化SaaS的访问质量。不过SaaS作为一种WEB内容，可能会下沉到距离用户很近的位置，此时DNS将成为决定SaaS访问质量的关键因素，骨干段的牵引可能反而是南辕北辙[A]。

【
A、DNS优化是比较重要的一点。但路径优化仍然是比较重要的一方面，取决于SD-WAN运营商的角
色。如果是运营商，则提供通路即可，无法牵引用户的SaaS流量，但同时兼服务商的能力，则需要在
打通路径的同时牵引最优路径。如上述，SaaS访问后(发往某特定Internet DST)，则在SD-WAN网关
间，将寻找一条最短路径，可能最快的出口在SaaS服务最近的几个POP点。
】

4.2.2 云化CPE

在网络运营商传统的端局节点中，为了支撑话音、宽带、专线等不同专业的业务，需要采购大量专用的硬件设备，开放性和灵活性很差。在云计算/NFV/SDN等新型架构的驱动下，全球各大运营商纷纷投身于端局云化的重构进程中。端局云化后，各类专用的硬件设备在形态上将被基于通用x86平台的VNF所替代，在架构上转发和控制得以分离解耦，这对于运营商具有巨大的价值。一方面在于开放性、灵活性等方面的提高，长期来看能够有效地降低成本。另一方面，运营商得以将各种增值服务的VNF以服务的形式提供给客户，这将是一笔相当可观的业务增收，也是破局“管道化”困境的有效方式。(略)

【
POP点肯定是采用vCPE集群才是大势所趋，而存量PE在SD-WAN发展初期的过渡作用是必要的。云
化CPE将所有用户侧接入业务全部纳入，而用户侧CPE可能就是一个轻量级的Router或vRouter接入到
云端。但由于用户侧Underlay网络还需要支持普通的Internet业务，故而针对某些特定企业或用户的加
速支持是运营商提出SD-WAN服务的突破条件。
特别的，对于Tier 1运营商可能会为VPN提供专项的加速硬件，如IPSEC加速卡；创新创业型公司为了
节省成本，可能采用大规模云化vCPE集群方式提供服务。
】