Network Service Optimization with the VPP Platform

By Chen Jianyong, Senior Technical Expert at Alibaba Cloud

This article introduces the R&D background and application scenarios of Smart Access Gateway for Alibaba Cloud network products, the reasons for using Vector Packet Processing (VPP) as the technology foundation based on the project, and which aspects we have made optimization and choices in.


Based on these product requirements, the technical product needed to support Internet Key Exchange (IKE), route-based VPNs, IP forwarding, and VRF as well as have a high forwarding processing capacity. We eventually chose VPP as the technical base because our surveys found that it matched our requirements at a relatively high level.

However, VPP is just a framework and POC, and is far away from being a real product. We will show in which aspects we have made optimization later.

IP and IPsec Fragmentation and Assembly

No code inside VPP 18.01 supports fragment assembly, but a patch outside VPP 18.01 does. Therefore, we integrated this patch into VPP 18.01 to enable such support. This patch is currently combined into the 18.04 branch in the community.

For IPsec fragmentation, fragmentation before encryption is different from fragmentation after encryption. In general, we can choose fragmentation before encryption so that the decryption end can directly send fragments out after decryption to let the client do the assembly work. However, we always need to perform a packet back-to-back IPsec test when developing devices. In this case, the tester cannot recognize the messages that the receiving port receives because these messages are fragmented. To get the testing performance data, the decryption end needs to send out the same messages as the sending end. In general, the encryption end first encrypts and then fragments 1,500 bytes of received messages. Therefore, the decryption end can assemble fragments, decrypt the received messages, and send out the same 1,500-byte messages as the sending end. We support both scenarios.

Support for Linux Self Messages

The implementation methods include KNIs, tap interfaces, and AF_PACKET. We chose to take the tap-inject module out of the patch of router-plugin in VPP, and implement the reception and delivery of self-messages by using tap-inject. Specific nodes are as follows:

Of course, we have encountered some problems. For example, reading and writing tap interface data are done through system calls, which has some influence on the message processing of VPP. Another problem is that we do not have too many messages. We will consider porting KNIs to make improvements.

Inter-Process Communication

There are several options, such as simple UNIX sockets and NetLink sockets, and the complex TIPC protocol. We decided to use nanomsg for inter-process communication, because nanomsg provides high supportability for synchronizing a variety of information types due to its simplicity and support for communication patterns such as req/response and pub/sub.

IKE Problems and Solutions

There are several IKED options, including strongswan, freeswan, and ipsec-tools.

Support for 4G

You can choose a proper technical solution based on your own requirements.


About the LC3 Conference


Follow me to keep abreast with the latest technology news, industry insights, and developer trends.