1. WAN外网架构的演进概述

WAN外网部分承载南北向流量，即数据中心到最终用户的数据传递。

上图是目前数据中心中，WAN外网部分所涉及角色的标准组网形式：

• 服务器连接交换机Fabric到外网服务网关
• 外网服务网关完成三/四层处理，将数据传递至外网部分
• 网关和外网对接一般也会经过交换机Fabric网络
• 和运营商出口对接一般使用路由器设备；一般通过路由器的组网来实现路由层级容灾/选路

一般来讲，所有外网智能选路和容灾部分都是由图中方框内部分完成；或是通过调节BGP属性（AS-PATH/Local Preference）、路由发布策略（umbrella routes和hot potato等）完成容灾上设计；或是通过TE技术，RSVP、SR-MPLS、SRv6来完成路由精准调度。

这种调度的思路也比较符合传统网络工程师对维护边界的定义和思路。

随着SDN思想和更多云计算需求的出现，这种架构和组网设备选型逐渐显现出了一些技术差距：

• 对数通设备功能需求迭代更加频繁；更多与业务运营功能需要添加到网络设备上，比如流量远程镜像、流量统计、Firewall等功能，这些功能与本来功能稳定性较强的路由器定位形成了矛盾
• 云计算需求10K+ VPC隔离，路由器设备仅仅能提供1K+ VRF；与之相应的路由表项目也在增加，路由器FIB表项在众多VRF需求下也变得紧张
• 路由器的控制面被限定在BGP/NetConf，而NFV-Based的网络控制面会有更丰富的选择（e.g., gRPC/Netflow等）
• 路由器设备价格昂贵，在对接外网运营商时一般采用主备两台设备部署；在以上控制面需求频繁迭代下，设备需要经常维护、割接，主备架构的故障域较大，网络设计挑战性大

为了解决以上问题，外网对流量处理的架构，逐步由单一路由器组网正在向NFV+SDN思路演进。Google Espresso、Tencent DSR架构的设计均体现了这个思想。总体思路为：

• 接入层： 简单快速，支持必要的数据转发封装（MPLS、VxLAN、SRv6), 不在处理大量的路由表、ACL规则等
• 转发层： 采用NFV方式实现，通过DPDK来满足转发面速率要求；通过海量流表处理能力满足路由表项和ACL处理需求
• 控制层：具备TE和BGP的功能，BGP保持与外部对接的兼容性； 控制器实现方式完成TE灵活调度

在以上思想加持下，外网架构模型发生如下变化。

2. 实践1 - Google Espresso

Google是业内SDN技术的倡导者，最早实现了在DCI（B4）上利用SDN技术实现了利用率98%以上且Congestion-Free的网络设计。Google外网服务承载在其B2网络上，控制器架构和B4网络一脉相承，采用了分层式控制器架构设计：

• global controller: 完成应用/业务相关的策略计算
• local controller：完成本地执行阶段的策略下发

这样的设计主要保障上层策略的高效执行和本地高可用性的设计。当本地出现端口链路中断可实现快速响应，且当全局控制和本地控制中断时，也能实现独立工作。

初始情况下，Google边缘节点内拓扑入上图所示；和运营商通过PRs连接；内部会放置7层反向代理，即网关完成交互。

在NFV+SDN思路下，外网功能的解耦，如上图。按照在第一章中提到模型，可以对这些单元职能进行一个分类：

• 接入层：Peering Fabric，由原来的PR路由器，变成了交换机
• 转发层：Edge Metro中的Host会进行Packet Processor功能，主要进行基于FIB转发和ACL过滤
• 控制层：由GC/LC/Peering Fabric Controller/BGP Speaker来组成

以上是一个逻辑功能图，如果要转变为物理部署图，可以参考下图

从这张图来看，可以看出几个层次的关系：

1）控制面全部NFV化，放在Host上； 例如BGP Speaker放在Host通过GRE Tunnel与运营商建立BGP Peer关系

2）数据面只是简单的转发，支持必要的MPLS和GRE封装

3）Host需要承担转发面的工作

4）控制面层级分布，从GC- LC- Host/PF Agent，实现TE和流量调度

5） 控制面通过OpenFlow来实现PF数据面的定义

从流量调度角度来说，GC会收集全局信息来进行TE调度，TE决策取决于：

• 收集全局路由表来判断业务流量可用的PF出口
• 用户的带宽和延时信息，上述Host所具备的反向代理功能便于收集用户带宽、RTT和重传率等指标，做为选路依据
• 链路利用率：将用户带宽需求和链路利用率进行匹配，优化链路利用率（e.g.,使用greedy算法），减少业务流量的拥塞；

3. 实践2 - Tecent DSR

腾讯公司在2021年公开的文章中也披露了分布式软件定义路由器(Disaggregated Software-Defined Router, DSR)的详细考虑。

其架构和Espresso可以做类别:

• 接入层：Access Module，采用交换机，通过VxLAN隧道来传递BGP/BFD消息
• 转发层：Forwarding Module，采用服务器集群实现
• 控制层：Routing Module/Control Module/Orchestrator, 可以分别对应到Espresso的BGP Speeker/LC/GC

该文章也更多披露当采用服务器集群进行数据分发和FIB查找中，如何来做数据面加速，例如

• 采用DPDK+网卡RSS来增加包处理能力和性能
• 修改原生DPDK LPM二级查找表为三级查找表
• 缩短数据包处理PipeLine

4. 实践3 - Meta（Facebook）

Meta（Facebook）的外网调度通过Controller直接向PR注入BGP 路由来实现，策略按照30s的周期来实施。 Controller通过netflow获取PR实时流量状态;通过BMP获取PR的路由状态；通过应用层面收集用户的时延。

• 服务器进行DSCP打标；
• PR和ASW间为ISIS/SR, 当流量不均时在PR上进行PBR，通过SR做导流

早先时间，Meta（Facebook）也曾使用NFV/SDN的服务器方式来完成流量调度，并尝试了基于MPLS、GRE封装进行转发面上调度。在这种方式下PR只需要完成数据转发即可。这种NFV/SDN的TE方式在Meta的使用过程中，出现了如下问题：

• NFV/SDN方式在网络故障排查、网络审计上需要完成多个层面的联动；这种情况是由于NFV/SDN实质上已经把路由器集成式的功能分布到了不同的软件模块中，从功能维护上也需要做分布式的考虑，复杂性增加
• 当接入设备端口出现故障、路由出现撤销时，NFV主机侧也需要快速同步来避免黑洞，也对NFV Host、PR和Controller间的状态同步带来的很高的要求

基于以上原因，Meta（Facebook）最终采用了路由器方式的来完成流量的调度。相比NFV/SDN方式，这种方式的调度精度被限制到某个发布的prefix粒度下，从这个方面相比NFV/SDN IP级别的调度粒度有一定的劣势，但Meta（Facebook）认为这个粒度已经能够满足生产需求了。

5 实践4 - Microsoft Cascara

microsoft在21年公布的"Cost-Effective Cloud Edge Traffic Engineering with CASCARA"中描述了建立平衡成本和时延的外网流量工程方法。基于IPFIX、BMP、时延和链路成本来对不同类型的流量做出方向链路调度。对于时延不敏感（大文件传输、备份数据流量）和时延敏感流量（实时的音视频流量）在不同成本的链路上做出方向调度，其效果验证可在成本上获得35%的收益。

具体外网TE调度的实现技术没有匹配，但文中也指出了Google和Facebook所使用两类调度技术比较具有代表性。

6. 一些思考

​从黑盒路由器到NFV+SDN+白盒可编程交换机的演进目前看是一种技术趋势，但架构还是为生产服务的。所谓的生产，是业务应用的生产，也是网络运营服务的生产。脱离了生产需求来单纯的就技术论架构，架构方案可能就会沦为paper work或是技术广告。

业内实践也在权衡各自网络发展需求、软件素养主张、运维生产习惯等因素基础上做出的最适合的选择。在NFV/SDN架构下，对路由器的网络运维习惯需要迁移到交换机和BGP NFV上，对网络监控、日常网络操作、工具都会有新的改变和要求。更本质的是，网络生产会更加依赖于软件质量和相应团队资源支撑，需要更多兼具网络技术栈和软件技术栈的工程师来胜任，一定程度上提出了更高要求。架构改变可能需要配合团队技能改变。

​要找到适合的架构，还是需要对目前实践做解剖，发现最小以及本质的单元，再进行组合衍生出新的适合自身网络发展的建议。如下是一个最小单元拆解，并进行新组合的尝试。

如下为最小的组成单元：

• 接入单元： 完成与运营商网络的对接，适应10G/100G...等多种物理电器特性对接要求
• FIB管理单元：存储全球互联网表项并完成转发表的计算下发
• 网关单元： 进行4、7层方向代理以及数据处理
• BGP单元：与运营商网络做协议控制层面对接
• 包转发处理单元：对后端服务器发送数据做向互联网方向的转发
• TE Controller单元：完成业务需求语言向网络流量调度的翻译和执行

上图中右侧框可以看到，不同单元的组合可以呈现出方案级别的差异。例如1和2分别是上文中提到的路由器模式和NFV/SDN模式。当然，也可以衍生出新的模式：

• 方式3，保持路由器部署形态，将TE调度域从原来的路由器网络延生到网关服务上，即网关完成智能选路、路由器网络完成选路路径QoS保障和灵活隧道建立。
• 方式4，进一步统计流量调度功能到NFV一侧，但BGP/FIB维护仍保持数通设备形态（可以考虑Server Switch，需要更多论证...）
• ....， 相信还有其他拼装模式，结合自己需求来搭乐高

此外，各个基本元素也可以做演进考虑：

• 接入单元： 路由器 - > 交换机 - > 可编程交换机（向P4一致化上靠拢）
• FIB管理单元：路由器 - > NFV实现（例如DPDK LPM模块）- > ...
• 网关单元： ipvs - > dpvs- > 流表
• BGP单元：路由器 - > FRR - > FRR
• 包转发处理单元：内核处理 - > DPDK- > 可编程交换机
• TE Controller单元：BGP属性调度 - > mpls - > srv6

总体上来讲，一方面是看别人走的路，更重要的是，需要知道别人为什么走这条路，了解过程比结果更重要，以上是对别人为什么走这条路由的一个浅显分析。