摘要：?國際知名開源社區(qū)Linux基金會主辦的開源大會LinuxCon + ContainerCon + CloudOpen China 2018(LC3)于6月25日在北京開幕。今年阿里云作為白金合作伙伴亮相本次中國開源盛會。

國際知名開源社區(qū)Linux基金會主辦的開源大會LinuxCon + ContainerCon + CloudOpen China 2018(LC3)于6月25日在北京開幕。今年阿里云作為白金合作伙伴亮相本次中國開源盛會。阿里云網(wǎng)絡(luò)團隊的三位技術(shù)專家在論壇上分享了各自專業(yè)領(lǐng)域的經(jīng)驗。分享主題包括開源平臺的優(yōu)化、網(wǎng)絡(luò)大數(shù)據(jù)應(yīng)用等。如果你錯過了親臨現(xiàn)場的機會，沒關(guān)系，我們通過三篇回顧總結(jié)來感受下。

?

主講人：陳建永 阿里云高級技術(shù)專家

主題：Network Service Optimization with VPP Platform（基于VPP平臺的網(wǎng)絡(luò)服務(wù)優(yōu)化）

分論壇：Network & Orchestration

摘要：這篇文章介紹了阿里云網(wǎng)絡(luò)產(chǎn)品智能接入網(wǎng)關(guān)的研發(fā)背景和使用場景，以及基于項目為什么選擇了VPP做為技術(shù)基礎(chǔ)，做了哪些方面的優(yōu)化和選擇。

項目背景

本次產(chǎn)品的背景是實現(xiàn)一款類似于VPN網(wǎng)關(guān)的產(chǎn)品。產(chǎn)品使用的三大典型場景是混合云、連鎖零售和分支與總部互聯(lián)，實現(xiàn)加電就上阿里云，加電就互聯(lián)的目標。

基于這樣的產(chǎn)品要求，對技術(shù)產(chǎn)品的要求包括需要支持IKE、支持route-based VPN、支持IP轉(zhuǎn)發(fā)和VRF以及有比較高的轉(zhuǎn)發(fā)處理能力。考察下來，VPP跟我們的要求相對比較match，所以最終選擇了VPP做為基座。

但是VPP只是一個框架和POC，離真正的產(chǎn)品還有比較大的差距，后面我們會詳細展開我們做了哪些方面的優(yōu)化。

IP和IPSec分組片

我們選擇的VPP基線版本是18.01，已經(jīng)包含了基本的分片函數(shù)，但是主要是用在ip4-map node上面，基本轉(zhuǎn)發(fā)里反而沒有分片功能。基于此，我們在ip4-rewrite的節(jié)點后增加了ip4-frag節(jié)點，實現(xiàn)了通常轉(zhuǎn)發(fā)流程中對分片的支持。

VPP 18.01里是沒有組片支持的代碼的，但是外面有一個組片支持的patch，那么我們就把改patch合并到了18.01里，實現(xiàn)了組片的支持。目前該patch已經(jīng)被社區(qū)合并到了18.04分支里。

關(guān)于IPsec分片的支持，先加密后分片，還是先分片后加密，這個是不一樣的。一般情況下，可以選擇先分片后加密，這樣解密端可以直接解密后發(fā)送出去，組片的工作由客戶端完成。但是做設(shè)備都會面臨測試一個大包背對背IPSec測試的問題，這種情況下，測試儀的接收口收到的報文是分片的，他是不認識的。為了測試出性能數(shù)據(jù)，就需要解密端發(fā)送出跟發(fā)送端一樣的報文。此時，一般是加密端選擇對收到的1500字節(jié)報文先加密后分片，這樣解密端收到報文后先組片，組完片以后再解密，然后發(fā)送出一個跟發(fā)送端一樣的1500的報文。我們自己是2種情況都支持了。

Linux self報文支持

我們實現(xiàn)的是一款商業(yè)的產(chǎn)品，除了轉(zhuǎn)發(fā)報文，設(shè)備還要支持VPN IKE協(xié)商，DHCP server功能，SSH/Telnet管理等，此時的報文都是發(fā)送給設(shè)備上面的Application的。但是，設(shè)備以太網(wǎng)口已經(jīng)被VPP下的DPDK接管了，那么就需要把接收大的報文區(qū)分出self的報文，發(fā)送給APP；同時，APP發(fā)出的報文要讀取到VPP里并且通過以太網(wǎng)口發(fā)送出去。

實現(xiàn)的途徑包括DPDK的KNI、tap接口、AF_PACKET等，我們的選擇是從VPP的router-plugin的patch里拿出了tap-inject模塊，通過tap-inject實現(xiàn)self報文的收發(fā)，具體的node如下：

當然，這里也是有問題的，就是tap接口的數(shù)據(jù)讀寫是走系統(tǒng)調(diào)用的，對VPP的報文處理還是有影響的，還在我們的self報文不多。后續(xù)考慮移植KNI接口來進行改善。

進程間通信

上面說，我們的設(shè)備上面跑了很多的服務(wù)，這些應(yīng)用之間是需要做信息同步的。典型的比如agent接收控制器的數(shù)據(jù)，需要發(fā)送給IKED做協(xié)商用；IKED協(xié)商出密鑰需要把密鑰下發(fā)給VPP做加解密等。這就需要提供一種進程間通信的機制。

這里有很多種選擇，比較直接的比如采用unix socket、netlink等，復(fù)雜一點采用TIPC等。我們采用了nanomsg來完成進程間通信，主要考慮是nanomsg相對來說沒有那么復(fù)雜，同時支持req/response，pub/sub等通信模式，這對于將來多種信息同步的方式支持比較好。

IKE問題及解決方案

VPP已經(jīng)支持IKE，但是只做了一半，只支持IKEv2。這一半也只做了一半，只支持IKEv2做為responder，不能做為request方。另外，VPP也不適合集成復(fù)雜的IKE協(xié)商。基于上面的情況和考慮，我們在設(shè)備商單獨起了專門的IKE應(yīng)用來做協(xié)商，這個應(yīng)用跟VPP再做SA的同步。

這里，IKED的選擇可以是strongswan、freeswan、ipsec-tools等。

4G支持

在連鎖等場景下，有些客戶提出了4G支持的需求。一般來說，4G模塊的驅(qū)動都是基于內(nèi)核做收發(fā)包處理的。VPP要支持一般有兩種方式：一種是基于AF_PACKET，通過AF_PACKET做VPP和Linux內(nèi)核的報文橋梁，這種方式的好處是改動相對比較小，壞處是性能不是很好。另外一種方式是修改4G模塊的驅(qū)動，支持DPDK，這種方式的好處是性能會非常好，因為不用經(jīng)過內(nèi)核直接到了VPP，壞處就是驅(qū)動的改動會非常大，而且每換一個4G模塊就需要改動一次。

大家可以根據(jù)自己實際的需要來選擇采用的技術(shù)方案。

總結(jié)

總的來說，VPP是一個比較好的框架，實現(xiàn)了很高的性能和非常多的feature。但是只是適合做POC，里邊的坑非常多，用于商業(yè)需要對其非常了解和熟悉，做好填坑的準備。