当p4遇见nat64，ucloud如何快速从ipv4向ipv6演进？-威尼斯人网址

      ipv4发展到今天已存在着诸多缺陷，比如地址枯竭、安全和服务质量难以保证、路由膨胀等，这些问题将极大制约云计算等相关it行业的发展。ipv6以其更大的地址空间、更高的安全性等特点，能够很好的解决ipv4这些缺陷。

      ucloud于2018年上半年开始研发公网入口的ipv6转换，依托nat64技术和可编程p4交换机，现已成功推出了免费的ucloud公网入口ipv6转换服务。该产品功能简洁易用，申请eip后一键开启ipv6转换，无需任何改造，即可对外提供ipv6的访问。目前，ucloud ipv6转换服务已成功用于云主机、eip、负载均衡、容器集群、堡垒机等产品。地域内单集群（16台nat64服务器，4台p4交换机）最高可实现3.2m cps和1.6g的并发连接，且可在以后的演进过程中平滑扩容。

      对于ipv6技术的预研与探索，ucloud早在几年之前就已经开始了，内部已有完整的ipv6预研方案。但我们仍需要清晰的认识到网络基础设施的改造不是一蹴而就的，这里面不仅涉及到技术难题的攻克，其本身还是个非常巨大的工程问题。

      而且最重要的是在不影响用户现有业务的同时，让用户的业务慢慢的迁移至ipv6。正是基于这种考虑，针对ipv4到ipv6的演进，ucloud制定了以下战略：

      1. 2018年完成互联网入口ipv6转换服务，使ucloud超过百分之五十的产品能够支持ipv6，客户只需在eip开启ipv6转换服务，无需更改任何业务即可使业务获得对外提供ipv6访问服务的能力，实现业务和ipv6网络的平滑对接；

       2. 2018年完成管理网ipv6改造，使得依托于管理网的云产品诸如主机入侵检测，容器镜像库等产品支持ipv6；

       3. 2019年完成ucloud主要产品支持ipv6，其中vpc、ulb（ucloud负载均衡）等重要产品将于2019 q2之前支持ipv6，具备主动访问ipv6网络能力；

      4. 2019年完成idc双栈改造，使得数据中心内部支持ipv6，提供完整的ipv6支持。

      ipv6从技术到落地的过程中，ucloud做了很多工作，也遇到了比较多的挑战。本文接下来将从技术的角度详细介绍ucloud ipv6转换服务的实现与优化演进。

◆ nat64及其技术挑战

      在实现技术上，ucloud使用有状态的nat64技术来实现ipv6转换服务，nat64是一种通过网络地址转换（nat）形式促成ipv6与ipv4主机间通信的ipv6转换机制。nat64网关需要至少一个ipv4地址和一个包含32位地址空间的ipv6网段来完成ipv4与ipv6协议间的翻译。

      nat64将这个32bit的ipv4地址嵌入的ipv6目的地址转换成目的ipv4地址，源ipv6地址转换成一个特定的源ipv4地址。nat64网关则创建ipv6与ipv4地址间的映射，这可以为手动配置，也可以自动确定。

      如下图所示，ucloud ipv6转换功能基于nat64实现，可为用户现有ipv4的eip生成一个ipv6地址，在用户不修改现有ipv4网络和相应服务的情况下，相应云资源和服务可以获得被公网ipv6访问的能力，并可使得用户的云资源和服务被ipv4和ipv6同时访问。

      ipv6与ipv4之间的转换是一种有状态转换，考虑整个系统层面的稳定性与扩展性需求，ipv6转换服务的实现主要有两大技术关键点：

• 高可用，由于ipv6转换服务是有状态服务，因此必须保证在集群内节点发生变化时，不能影响已有连接（准确的说影响不超过1/n，其中n标识后端节点数目）；

• 安全防护，由于ipv6转换服务是有状态服务，因此当碰到恶意攻击（比如ddos），很容易导致服务器被打挂进而导致服务不可用，因此一定的ddos防护能力对整个系统来说至关重要。

◆ 系统架构

      根据以上关键点，我们开始着手设计基于nat64和p4交换机实现ipv6转换功能的系统架构，如下图所示，其中nat64 access使用p4交换机实现，通过nat64 access的一致性hash实现高可用。同时在nat64 access对cps进行限速，实现ddos防护。

      nat64 access与物理交换机1组成三层网络，通过bgp向物理交换机1宣告一个/96的ipv6地址段，作为该地域的ipv6 prefix。pop1与pop2中access向外宣告的地址段相同，实现负荷分担和pop点级别的容灾。同理，pop点内两个access之间也是负荷分担和容灾。

      access与物理交换机2以及nat64服务器组成二层网络，nat64服务器北向通过bgp向access宣告vip，access即可获得vip对应的下一跳信息（mac地址）。当收到internet流入的入向ipv6报文时，将所述报文的mac地址设定为某个nat64服务器的mac地址，即可实现将报文送达至特定的nat64服务器。同时nat64服务器南向需要向物理交换机4宣告一个源地址池，实现回程的可达性。

      需要说明的是，在实际部署中，物理交换机2和1通常合一部署，形成nat64 access以旁挂的形式存在。下面以云主机为例，通过业务流程来简要说明整个系统的工作机制：

      由于每个nat64服务器上会配置一个源地址池且互不重叠（其中ipv4_1是nat64源地址池中的一个地址，ipv4_2对应eip）并且南向通告了该地址池，因此云主机的响应报文（目的地址为源地址池中的地址，即ipv4_1）能够通过路由到达相应的nat64服务器。

◆ 当p4遇见nat64

      通过上文的系统架构，可以发现，通过物理交换机可以实现pop点级别的负荷分担和容灾，但是实际上系统能够实现高可用的关键在于当nat64服务节点的状态发生变化（比如扩容或者某个节点down）时，系统需要保证已有连接不被破坏，这就要求nat64 access选择后端节点时能够支持一致性hash，因此实质上nat64 access的最重要属性是一致性hash网关。

      在各大云计算厂商的实现中，一致性hash网关的实现，dpdk是当前主流的实现方案。但是dpdk也存在以下缺陷：

• 基于dpdk的应用可以达到很高的包转发速率，但这是通过多服务器、多核负载均衡实现的。且负载均衡算法通常是由硬件交换机或者网卡实现，并不能被软件定义。如果网络中出现单个大象流，无法被硬件交换机或者网卡的负载均衡算法很好的分发，就会造成单根网线或者单个cpu core出现拥塞，对业务造成巨大影响。

• 随着网络带宽从10g向25g、40g、50g、100g的演进，dpdk需要更强力的cpu才能够达到线速，而更强力的cpu通常价钱也很昂贵，不利成本。特别是单core的主频越高，价格越贵，且主频增加之间和价格增加是非线性关系。

      因此，我们最终决定采用p4可编程交换机（基于barefoot tofino芯片实现）来实现nat64 access，实际上ucloud早在2017年就开始预研p4可编程交换机，并且目前已有基于p4可编程交换机的gw灰度上线。相比于dpdk网关，p4可编程交换机具有诸多优势：

      1. 与dpdk相比，有更高的转发性能（1.8t~6.4t）；

      2. 转发性能稳定，不受cpu loading等影响；

      3. 单线100g，可以避免单线拥塞；

      4. p4语言开放性好，可编程能力强；

      5. 很好的生态圈，支持p4 runtime。

maglev算法的选择及验证

      在一致性hash算法的选择时，我们选择了google maglev项目中使用的 hash算法（下文简称maglev hash），该算法的核心优势在于当后端服务节点发生变化时，具有极致的稳定性。并且lookup表的size保持不变，非常适合于p4交换机来承载lookup表。（原始论文：maglev: a fast and reliable software network load balancer）

      根据该论文中对一致性hash的介绍可以看出，maglev hash算法本质上设计算法让每个后端按照一定的规则去填满数组lookup表的empty entry，确保所构造出来的lookup表的元素中，所有后端服务器出现的次数尽可能相等（实质上，根据算法出现次数最多的节点和最少的节点之间的差值最大为1），因此可以达到极致的平均性能。

      maglev hash算法所产生的lookup表，虽然有着极致的平均性能，但是也有一个缺陷，那就是当后端服务节点发生变化时，会有部分连接中断的情况（理想的一致性hash算法中断连接的比例为1/n，maglev hash可能存在略微超过1/n）。

      在maglev项目中，通过connection track表来弥补这一缺陷，然而connection track将带来一系列缺点，使得nat64 access有状态，易于收到攻击。从论文中可以看出，当lookup表的size大于后端节点的100倍时，连接中断的情况低于2%。但是2%还是一个相对比较高的比例，本着严谨的态度，我们在扩容和缩容（缩容也对应某台nat64服务器down机）场景下又针对lookup表size与后端节点的比例进行了一系列测试与验证。

      上图分别对应于后端节点增加和减少的情况，通过上述测试可以发现，当lookup表的size较小时，该算法的稳定性略差，以上述测试为例，当lookup表的size为1024时，在扩容和缩容场景，会有将近百分之二的连接会受到影响（具体表现为entry改变），这点与论文maglev论文中的结论基本一致。

      但是随着lookup表的size增大，对已有连接的影响越来越小，最终逼近与1/n。具体到上述两图，当lookup表的大小超过后端服务节点的2000倍时，连接中断的比例低于0.01%，但是由于没有connection track，整个nat64 access是无状态的，这就大大提升了nat64 access的稳定性，并且极大的减小了实现复杂度。

      nat64 access上承载着一张lookup表，格式如下：

      需要说明的是，此处的lookup表实际上是由maglev中数张lookup表构成的，通过vip加以区分。

      具体工作机制如下：

      不同的nat64集群通过bgp向nat64 access宣告不同的vip， nat64 manager通过grpc获取nat64 access的路由表信息和邻居表信息，获取各个vip以及对应的下一跳mac地址信息。然后遍历所有vip，根据每个vip的下一跳信息调用maglev hash engine生成相应的每个集群的entry list（具体值为各个nat64的mac地址）。所有的entry list以及vip构成上述lookup表。

      当数据面收到报文时，将根据eip查询到vip（通过另外的表以及控制面相应逻辑实现，在此不再展开），然后根据数据包的源ip、目的ip、源端口、目的端口、调用p4语言的hash函数通过计算得到entry index，最后根据vip和entry index匹配lookup表，设置目的mac，至此就完成了后端服务节点的选择。

      nat64 manager将持续监控nat64 access的路由表以及邻居表，一旦某个vip的下一跳发生了改变（比如扩容场景或者某个nat64 down），将重新调用maglev hash engine重新生成该vip对应的lookup表中对应的那部分entry，并通过grpc修改相应的entry，实现节点变化时的快速响应。

      由于ipv6转换服务本身是有状态的，也就意味着有可能受到ddos的攻击，因此我们在nat64 access上对每个eip针对tcp syn报文进行入向和出向pps限速。因为ucloud在公网接入有着强大的安全保护和ddos检测、清洗等，因此nat64 access上所执行的syn报文的限速仅仅是作为一个补充和二次防护。但是其优点在于无需检测分析而直接进行限速，这可以使得在极端攻击场景下缩短nat64服务的不可用时间（安全中心完整的ddos防护通常都存在检测和分析等步骤，存在一定程度的滞后性）。

      目前单个eip的syn报文的速率限制在50000，超过50000时会进行丢包。该参数是可调的，如果用户业务层面有超大cps的需求，ucloud相关的威尼斯5139手机版的技术支持人员也可以协助进行调整。 

      tofino芯片包含4条pipeline，每个pipeline包含12个stage，目前主流的场景还是所有pipeline使用相同的表配置，即使用同一份p4代码。但是一旦两个表之间相互依赖，就没办法放入同一个stage，这是底层芯片的执行逻辑决定的。

      考虑业务逻辑的复杂性，数据面通常需要定义很多的表才可以完成整个业务逻辑，且这些表之间彼此依赖性很高。因此在实际编码过程中出现了stage用光，但是每个stage资源利用率很低，具体到我们的项目，资源利用率低就会导致一台nat64 access能够支持的eip数量有限。这种问题通常有以下三种威尼斯5139手机版的解决方案：

•  优化表配置，或者修改一定的业务逻辑，减少表之间的相互依赖，这样能够大大提高stage资源的利用率；

• 由于ingress和egress虽然共享stage，但是ingress和egress的表之间从硬件层面没有任何依赖关系。因此将业务逻辑拆分，一部分放于ingress，另一部分放于egress。这种方案比较简单易行，且通常收效明显；

• pipeline串行，拆分业务逻辑，每个pipeline放置一部分业务逻辑，不同pipeline之间通过自定义metadata传递信息。这种方案也是一种行之有效的方案，且能够提升tofino整体的表项空间，可以预见未来可能会有很多这样的应用。

      在nat64项目中，我们采用了1和2结合的方案，经过优化后，资源利用率达到百分之七十左右（没有优化之前只达到百分之三十左右）。下图是我们优化后tofino芯片的资源利用图和table占用图。

系统构建完成后，我们针对单台nat64（nat64服务器配置为cpu：32核；内存：64gb；网卡： x710 10gb * 2）服务器进行了完整的性能测试，client是ipv6，server端是ipv4 双向udp数据流，一应一答。client发送请求到server，server端应答回到client。其中最为关键的cps和并发连接数指标测试结果如下：

• cps测试结果：

• 并发连接数测试结果：

       我们初始单set上线了16台nat64服务器，因此单地域最高可实现3.2m cps和1.6g的并发连接。此外，整个系统支持平滑的无缝扩容，支持任意添加nat64 access和nat64服务器。

       当前，ucloud ipv6转换服务处于免费公测阶段，欢迎使用。