VPP 相关的一些开源项目

1、UPG-VPP

UPG基于3GPP TS 23.214和3GPP TS 29.244 Release 15实现GTP-U用户平面。它是作为FD.io VPP的树外插件实现的。UPG的可能用途有: 1、5G网络的UPF (User Plane Function)功能。 2、分组数据网络网关用户平面(PGW-U)。 3、用户平面流量检测功能(TDF-U)--基于报文五元组的回话管理。 在上家单位参考这个开源项目实现了一套基于报文五元组做key，使用bihash+timewhile实现一套无锁化的（tcp、stcp报文）回话管理模块。项目地址：https://github.com/travelping/upg-vpp，编译可以参考：基于vpp的开源upf-vpp编译。

2、vpp-ctrlcap

项目地址：https://github.com/vpp-dev/vpp-ctrlcap VPP控制抓包的一个插件，可以配置基于报文SIP-Sport，DIp-Dport进行抓包，项目比较久了，一致没有更新。

3、frr-vpp

项目地址：https://github.com/garyachy/frr-vpp 参考博客：https://haryachyy.wordpress.com/2020/04/17/learning-vpp-ospf-routing-protocol/ 在VPP路由器上使能OSPF。使用FRRouting (FRR它是一种用于Linux和Unix平台的IP路由协议套件）在vpp上使能OSPF。它使用VPPsb的router插件，它实现了将控制包推到Linux网络堆栈的逻辑，以及一个基于netlink的机制，它将Linux的路由表同步到VPP的FIB中。 vppsb项目地址：https://github.com/garyachy/vppsb.git 分支compile_problems已经适配vpp2001版本。

4、vpp-mb

项目地址：https://github.com/mami-project/vpp-mb mmb是一个插件，目的是实现可以使用通用CLI命令配置的中间件策略。它根据网络或传输协议字段约束的任意组合、有状态TCP和UDP流匹配、包重写、包丢弃、双向映射执行无状态包匹配。MMB是协议无关的，允许匹配和重写字段ip4-payload, udp-payload和tcp-opt。 看项目介绍功能还是很强大的，没有研究过。有相关业务需求的可以参考一下。

5、flexiWAN

项目地址：https://gitlab.com/flexiwangroup 总部位于以色列的初创公司flexiWAN发布了其开源SD-WAN的项目，基于vpp+vppsb+frr实现，项目中有很多配置相关的脚本，学习vpp隧道配置很有用。 https://gitlab.com/flexiwangroup/flexirouter/-/tree/dev/scripts 有gre-ipsec-vxlan、ikev2、nat、vxlan、ipsec等等。

6、Netgate

项目地址：https://github.com/Netgate 美国德克萨斯州的一家公司，基于开源软件打造出高性能防火墙、vpn、路由器等产品。产品架构如下：

最近关注于vpp新加入的一个插件linux-cp（Linux Control Plane Integration）主要flows through linux-cp to and from the host stack now run 30X-40X faster than with the router plugin。性能比vppsb的route插件性能高30-40倍。值得研究一下。下面是linux cp插件的介绍（有道翻译，哈哈）：

Linux-cp插件(https://www.netgate.com/blog/tnsr-release-20-08-is-here.html 内容有道翻译) 路由器可以被认为是一个数据平面和一个控制平面。数据平面是负责转换和转发流量的功能和流程的集合，而控制平面则由决定如何转发数据包的功能和流程组成。BGP、OSPF、LDP和生成树等路由协议都是控制平面功能的例子。TNSR使用VPP作为其数据平面，而使用FRR路由协议功能。 这就要求FRR能够与VPP进行通信。在过去的四年里，解决这个问题的捷径是基于VPP提供的示例代码实现一个路由器“插件”。这段代码的问题在于它在架构上有缺陷，您越是试图修复它，问题就变得越困难。例如，路由器插件使用了一组“tap”接口，但它没有将VPP接口的状态映射到相关联的tap接口。传统的linux路由实现(如Bird或FRR)依赖于这种接口状态来发挥作用。因为路由器插件视图是以VPP为中心的，所以解决方案的一部分是将VPP接口状态复制到相关的tap接口。这反过来又会导致一系列其他问题，因为linux端可能最终处于与VPP不同的状态。另一个问题是路由器插件和相关的tap接口是低性能的。在低端硬件(8核Intel C2000)上，我们测量的吞吐量约为300Mbps输入和100Mbps输出。虽然这只影响在路由器上终止的网络流(比如BGP UPDATE消息)，但在我们看来还是太慢了。现有路由器插件代码的这类问题非常严重，需要我们也维护一个自定义的FRR变体，以正确地使用VPP。 现在所有这些问题都解决了，原来的TNSR路由器插件已经被linux-cp插件取代。我们从Cisco的Neale Raans编写的代码开始——然后花了将近6个月的时间来改进代码并将其融入TNSR。linux-cp插件有一个以linux为中心的视图，即配置了linux接口，并且将该配置复制到相关的VPP接口。无论是FRR还是一个简单的“ip route”命令，任何进程添加、更改或删除路由的Netlink消息都被正确地跟踪并反映到VPP。 这大大增加了产品的稳定性，简化了特性的插入、测试和与其他系统级功能的集成，以及通过网络名称空间和虚拟路由和转发实现控制/数据平面分离。性能也有所提高。在相同的基于c2000的系统上，通过linux-cp进出主机堆栈的速度现在比使用路由器插件快30X-40X倍。这种性能的提高可以直接导致相关的影响，包括缩短BGP等协议的收敛时间。所有这些工作还需要对我们的测试工具和相关的测试环境进行重大更新。 最后，所有linux-cp更改都被上游流到FD中。io VPP项目，证明了我们对开源软件贡献的持续承诺。

7、Strongswan-Vpp2001

项目地址：https://github.com/rayshi-10/Strongswan-Vpp2001 基于vpp（数据面）+strongwan（控制面）实现的高性能vpn项目。

8、VPP-latency-middlebox

项目地址：https://github.com/mami-project/VPP-latency-middlebox 基于vpp实现的延迟测量插件（tcp、quic协议RTT）