當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的併發鏈接，且可在之後的演進過程當中平滑擴容。

UCloud IPv6演進戰略步驟

對於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轉換服務的實現與優化演進。

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

NAT64 Access支持高可用

經過上文的系統架構，能夠發現，經過物理交換機能夠實現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

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的工做原理

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，實現節點變化時的快速響應。

NAT64 Access DDoS安全防禦

因爲IPv6轉換服務自己是有狀態的，也就意味着有可能受到DDoS的攻擊，所以咱們在NAT64 Access上對每一個EIP針對TCP SYN報文進行入向和出向PPS限速。由於UCloud在公網接入有着強大的安全保護和DDoS檢測、清洗等，所以NAT64 Access上所執行的SYN報文的限速僅僅是做爲一個補充和二次防禦。可是其優勢在於無需檢測分析而直接進行限速，這可使得在極端攻擊場景下縮短NAT64服務的不可用時間（安全中心完整的DDoS防禦一般都存在檢測和分析等步驟，存在必定程度的滯後性）。

目前單個EIP的SYN報文的速率限制在50000，超過50000時會進行丟包。該參數是可調的，若是用戶業務層面有超大CPS的需求，UCloud相關的技術支持人員也能夠協助進行調整。

P4表配置優化

Tofino芯片包含4條pipeline，每一個pipeline包含12個stage，目前主流的場景仍是全部pipeline使用相同的表配置，即便用同一份P4代碼。可是一旦兩個表之間相互依賴，就沒辦法放入同一個stage，這是底層芯片的執行邏輯決定的。

考慮業務邏輯的複雜性，數據面一般須要定義不少的表才能夠完成整個業務邏輯，且這些表之間彼此依賴性很高。所以在實際編碼過程當中出現了stage用光，可是每一個stage資源利用率很低，具體到咱們的項目，資源利用率低就會致使一臺NAT64 Access可以支持的EIP數量有限。這種問題一般有如下三種解決方案：

優化表配置，或者修改必定的業務邏輯，減小表之間的相互依賴，這樣可以大大提升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轉換服務處於免費公測階段，歡迎使用。