运营商SDWAN网络网关

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

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

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

IPSec的流量顺利到达SDWAN网关后，还需要对用户的身份进行辨认，并关联到相干的VRF，技术上可以有以下几种手段：(1)利用GREoverIPSec，为GRE口关联VRF;(2)利用组网overGREoverIPSec，通过标签进行关联;(3)用VxLANoverIPSec，通过VNI来关联VRF;(4)采取IPSec逻辑口来关联VRF;(5)用ISAKMPProfile绑定VRF，辨认SPI后直接关联VRF;(6)用私有的IPSec封装，在IPSec后面单独加方案的字段。其中，(1)的标准化程度最高，但封装效力较差，(5)的封装效力较好，但是要求使用IKE作为控制平面，在不同的实现中会有不同的选择。

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

如果流量目的地是在远端，那末两真个SDWAN网关间就需要通过骨干网进行传输了。一般来讲，SDWAN网关间的传输在overlay的逻辑上一跳过去就能够了，其实现方式有以下几种：(1)SDWAN网关间走组网方案，且SDWAN网关自己具有组网方案的能力，这时候可以为出向流量标记Service标签，此时流量模型为CPE—SDWAN网关—SDWAN网关—CPE;(2)SDWAN网关间走组网方案，但是SDWAN网关其实不具有组网方案的能力，那末SDWAN网关就要通过VLAN子接口和存量的PE装备做背靠背连接，同时与PE间起静态还是eBGP买通路由，然后由PE来完成组网方案的工作，此时流量模型为CPE—SDWAN网关—PE—PE—SDWAN网关—CPE;(3)如果骨干网不具有组网方案的条件，也能够直接通过IP隧道打过去，组网overGRE还是VxLAN都是可以的，通过Service标签还是VNI来隔离租户，此时流量模型为CPE—SDWAN网关—SDWAN网关—CPE。

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

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

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

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

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

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

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