基于高性能包處理架構VPP 的帶內網絡遙測系統

潘恬，林興晨，張嬌，黃韜,2，劉韻潔,2

（1.北京郵電大學網絡與交換技術國家重點實驗室，北京 100876；2.網絡通信與安全紫金山實驗室，江蘇 南京 211111）

1 引言

隨著云計算技術的飛速發展和云計算市場的持續繁榮，數據中心網絡規模迅速增長。為了提升數據中心內硬件資源利用率以及解決高能耗問題，大量虛擬化技術被廣泛使用[1]，通過硬件資源動態共享和彈性分配，可以節省硬件購買和運維成本，提高資源整體利用率，降低整個數據中心的能耗開銷。數據中心的硬件資源通常包括服務器和連接它們的網絡設備。服務器的虛擬化可以使單臺物理機的硬件資源被多臺虛擬機共享[2]。而網絡設備的虛擬化則需要能支撐服務器虛擬化之后引入的大容量虛擬地址表和虛擬機在物理機之間的動態遷移[3]。此外，網絡設備虛擬化還需要滿足不同網絡業務之間的流量隔離、隱私控制、安全防護等剛性需求。近年來，基于x86 等通用硬件開發的虛擬網絡設備在數據中心網絡內被大量部署[4]。這些虛擬網絡設備承載了很多高速網絡功能（包括隧道網關、交換機、防火墻、負載均衡器等）的軟件處理，支撐并發部署多個互不干擾的網絡業務，以滿足用戶多樣化、復雜化、定制化的網絡業務需求。其中OVS（open vswitch）[5]和VPP（vector packet processor）[6]是兩款工業界廣泛使用的虛擬網絡設備。

隨著數據中心網絡規模的迅速擴張，網絡故障出現的概率急劇上升，且故障感知定位的過程變得復雜而漫長。另一方面，隨著數據中心網絡定制化業務的逐漸增多，付費用戶對網絡擁塞所導致的業務服務質量下降也變得更敏感。如何高效地監控和管理數據中心網絡流量，快速定位網絡故障，開展精細化的流量工程正成為亟待解決的技術挑戰[7-8]。在傳統網絡中，通常使用網絡測量的手段來感知網絡流量的實時變化。然而，傳統的網絡測量方案在數據中心網絡中的應用面臨新的挑戰。一方面，在傳統的流量監控中，運營商往往通過物理分接端口（例如分光器或流量鏡像技術）來采集數據包，這些方案需要在交換機或路由器的物理端口上實施抓包動作。而在數據中心網絡中，大多數流量是東西向的，甚至有可能只是從一個虛擬機通過虛擬網絡設備傳輸到位于同一臺物理機上的另一個虛擬機，這意味著流量有時不需要離開物理服務器。此時，通過物理分接端口采集數據包的方法就無法滿足對虛擬網絡設備的監控需求。另一方面，傳統的網絡測量方案一般采集網絡設備中的流量統計信息，例如數據包的接收數、丟棄數、字節量等，所采集的數據類型較少且粒度較粗，無法精確實時地反映流量瞬時的擁塞狀態，這就大大限制了網絡故障的快速定位以及細粒度網絡流量工程的有效實施。

隨著協議無關轉發體系架構[9]和P4 數據平面編程語言[10]的提出，帶內網絡遙測（INT,in-band network telemetry）[11]作為P4 語言的重要應用之一，能夠支持低時延、細粒度的網絡設備狀態測量。它能將網絡設備更加底層的實時狀態信息，例如網絡設備的包緩存隊列長度、數據包的路由信息、到達或離開設備的時間戳信息等，嵌入沿路到達的數據包中，并由數據包隨路攜帶，最終上報給遠端的控制器[12]。控制器將基于采集到的實時網絡擁塞信息對故障潛在位置或流量優化策略進行判斷或規劃[7]。由于整個端到端的遙測過程只在數據平面進行，不需要與控制平面進行頻繁交互（除了最后一跳的信息采集上報），INT 大大降低了遙測時延和對控制平面的中斷頻率。雖然帶內網絡遙測的以上特性顯示了其對數據中心網絡實時測量的潛在價值，然而帶內網絡遙測依賴于協議無關轉發體系架構，目前僅有少量可編程硬件交換機支持該能力，大多數虛擬網絡設備均無法運行P4 程序，以提供對帶內網絡遙測的直接支持。

鑒于虛擬網絡設備已在數據中心內大范圍部署，本文面向工業界流行的高性能開源虛擬網絡架構及設備VPP（作架構講時，VPP 全稱為vector packet processing；作設備講時，VPP 全稱為vector packet processor）[6]，給出針對性的帶內網絡遙測的設計和實現，為在虛擬網絡設備中研究網絡測量問題提供新的解決思路。具體地，本文基于帶內網絡遙測協議規范定義了相關數據包的報文格式，基于VPP 的數據包處理框架，構造了數據平面的流水線處理模塊，并在此基礎上在包頭引入源路由機制，實現了一種帶內全網遙測方案。最后，本文基于虛擬機組網方式，搭建網絡拓撲并進行了網絡性能評測，實驗展示了不同背景流量速率和不同探測頻率下的遙測性能開銷。系統實現包含1 017行C++代碼，并在GitHub 網站進行開源。

2 帶內網絡遙測

2.1 研究背景

網絡測量能在網絡管理和運維過程中為網絡故障快速定位、網絡容量合理規劃以及網絡安全有效防護等任務提供有價值的基礎數據。面對日益增長的網絡流量以及復雜多樣的業務場景，為了更加快速及時地反映流量瞬時變化情況，網絡測量應滿足精細化和實時性的探測需求，同時盡可能降低網絡測量本身的開銷以及對被測網絡性能的影響，做到輕量化測量。

在傳統的網絡測量方案中，最常見的方法是基于簡單網絡管理協議（SNMP,simple network management protocol）[13]實施測量。SNMP 可以從網絡設備側采集設備以及流量的實時統計數據，如報文的接收數、丟棄數和錯誤數等。SNMP 配置簡單且性能開銷較低，被長期用于各類網管系統中。然而，SNMP 周期性地輪詢網絡設備以采集設備內部狀態的行為將引入數據平面與控制平面的頻繁交互，進而導致SNMP 具有較大的查詢時延，從而無法對突發網絡故障或數據平面的動態流量變化做出及時的反應，也無法對全網鏈路狀態進行精細化的探測覆蓋。盡管文獻[14-15]分別提出了基于管理信息庫（MIB,management information base）表組織模式和MIB 表查詢方式的性能優化，但仍然無法從根本上消除SNMP 控制平面和數據平面頻繁交互的性能瓶頸。谷歌的研究人員在2018 年甚至提出了“SNMP is dead”的觀點。根據前人對SNMP的性能測量[16-17]，SNMP 控制平面與數據平面的單次查詢時延約為0.4～21.1 ms；根據本文第5 節的實驗數據，基于VPP 的帶內網絡遙測系統能夠以10 Mbit/s 的速度向網絡系統注入探測包，從而將設備狀態查詢間隔降至0.13 ms。在高速硬件可編程交換機上，帶內網絡遙測探測包的注入頻率還能大幅提高，從而進一步提升網絡狀態探測精度。除了SNMP，還有其他的一些基于被動探測方式的網絡測量工具，例如NetFlow[18]、sFlow[19]、IPFIX[20-21]等。這些工具基于IP 流進行統計，即網絡設備把報文劃分為不同的流，并統計每個流的包數、字節數等信息。當流內報文傳輸完畢或流記錄更新超時后，該流的統計結果就會被上傳到收集器以便后續數據分析。基于流統計的測量方法能夠有效支撐業務流量的分析、統計和計費，但它們無法獲取網絡設備更加底層的實時狀態信息，例如包緩存的隊列長度、數據包的路由信息、包到達或離開設備的時間戳等。此外，微軟公司在2015 年提出的Pingmesh技術能夠基于端到端發送的Ping 包，形成對整個數據中心網絡的覆蓋[22]。然而，Pingmesh 只能采集端到端的擁塞信息，仍然無法進一步監測網絡中間設備的內部狀態。綜上所述，傳統的網絡測量方法數據采集時延較大，且可采集的網絡實時數據類型較少，或無法支持在網絡設備側采集，這就大大限制了網絡故障快速定位以及細粒度網絡流量工程的有效實施。

隨著協議無關轉發體系架構和P4 編程語言的提出，網絡數據平面的可編程能力被極大釋放。這使網絡設備在理論上能夠任意解析和編輯報文頭部。隨后，越來越多的P4 程序被提出，它們定義了數據平面包處理的諸多有趣功能[11,23-26]。INT 就是其中的一個高級應用。INT 允許數據包在通過數據平面包處理流水線時，查詢并攜帶網絡設備的內部狀態，例如隊列長度和排隊時延等。也就是說，INT 可以采集端到端轉發路徑上每一跳網絡設備的內部狀態。同時，整個狀態采集過程只在數據平面進行，與控制平面盡量解耦，最終由末梢網絡設備或接收終端將遙測結果上報給收集器。這種測量方式既能采集逐跳網絡節點上的多種內部狀態，又不需要頻繁與控制平面發生交互，所以整體的測量時延大大降低。INT 自提出以來一直由P4 聯盟的工作小組維護相關的協議規范[27]。目前，INT 正受到華為、Broadcom、Barefoot 等多家設備和芯片廠商的關注。一些廠商已將INT 功能嵌入其最新的商用交換芯片中[28-29]。

2.2 帶內網絡遙測原理

INT 實施框架如圖1 所示，該框架定義了以下技術術語。

圖1 INT 實施框架

1) INT 頭部，即INT 定義的報文首部字段。INT頭部既可用于攜帶收集到的網絡狀態信息，又能告知支持INT的設備需要收集哪些信息以及怎樣將信息寫入報文中。目前INT 規范并未強制規定INT 頭部在報文中的插入位置，只要所插入的位置能夠提供足夠的容納空間即可。例如，可將INT 頭部作為TCP/UDP 層的有效載荷，還可以基于VXLAN GPE協議對INT 頭部進行封裝。

2) INT 元數據，即所采集到的網絡狀態信息。INT 元數據將被寫入INT 頭部的特定位置。

3) INT 數據包，即攜帶INT 頭部的報文。普通流量或特殊探測包都可以被標記為INT 數據包。若把普通流量標記為INT 數據包，則可以進行指定用戶流量的隨路監測或隨流監測。

4) INT 源端，即能創建INT 數據包的實體，例如應用程序、終端主機網絡協議棧、物理網卡或與發送方直接相連的ToR（top of rack）交換機等。INT源端負責把INT 頭部封裝到數據包中。

5) INT 接收終端，即能提取INT 頭部并解析其中攜帶的INT 元數據的實體（通常既可以是最后一跳網絡設備，也可以是終端主機）。INT 接收終端接收INT 數據包，解析INT 頭部，生成探測結果，并將探測結果上報給收集器。

6) INT 轉發設備，即根據INT 頭部的指示，采集INT 元數據并將其寫入INT 頭部的網絡設備。

INT 采用帶內測量模式，其遙測過程如圖2 所示。INT 源端把INT 頭部插入原始數據包中，從而指示沿途網絡設備添加所期望采集的INT 元數據。在網絡傳輸過程中的每一跳，INT 轉發設備將根據INT 頭部的指示，在其中插入采集到的各個INT 元數據。INT 接收終端在處理原始數據包之前會提取攜帶INT 元數據的INT 頭部，并生成探測報告。該探測報告包含了數據包經過沿途網絡設備時所采集到的逐跳實時網絡狀態信息。同時INT 接收終端還會把探測報告發送給收集器。收集器一般部署在集中式控制器上，負責收集并分析從數據平面采集到的INT 元數據，為控制平面后續的決策動作（如流量工程）提供有效的數據支撐。根據INT 協議規范[27]，理論上INT 自身并不約束支持采集的數據類型。但受到網絡設備的實際硬件限制，最終INT 能夠采集到的元數據通常包括報文出入端口號（用于分析報文端到端的轉發路徑）、報文處理時延和設備內部排隊狀態（用于感知端到端的逐跳擁塞情況）。

圖2 INT 的遙測過程

3 矢量數據包處理

3.1 研究背景

在數據中心網絡中，虛擬網絡設備被大量使用。一方面，高可靠、低時延、高吞吐率等多樣化的應用需求要求網絡設備支持差異化的數據包轉發方式，例如多路徑路由、最短路徑路由、源路由等。而虛擬網絡設備支持數據平面可編程，能靈活修改數據包轉發方式，這滿足了多樣化的應用需求。另一方面，數據中心包含了海量服務器的互聯，并通過虛擬機和物理機的形式對外提供服務，且不同服務之間還存在流量隔離、隱私控制、安全防護等需求。虛擬網絡設備則可以通過x86 等通用硬件以及虛擬化技術來承載諸多網絡功能的軟件處理，從而能夠在一臺物理設備上同時運行多個性能與故障互相隔離的實例，因此可以支持多個網絡業務的并發部署，達到硬件資源共享的目的。

目前，已有多個開源項目提出了多種網絡設備虛擬化的解決方案。OVS[5]是一個開放的多層虛擬軟件交換機，其設計目的是通過軟件編程的方式實現大規模的網絡自動化部署，非常適合作為軟件交換機部署在虛擬機管理平臺上。VPP[6]是一種高效的數據包處理架構，基于該架構核心思想實現的高性能轉發設備能夠運行在通用CPU 上，實現可供生產環境使用的高速虛擬軟件交換機或路由器。VPP 最早由思科公司開源，發展至今已成為Linux基金會的開源項目FD.io 中最核心的組件。此外，還有專門用于 P4 程序驗證的開源仿真平臺BMv2[30]，它實現了具備協議無關轉發架構的軟件交換機，并通過運行P4 程序，產生程序定義的轉發行為。以上3 種典型的開源虛擬網絡設備均具備良好的編程擴展能力以及一定的數據包處理性能，所以正受到越來越多網絡開發者的關注。當需要為報文處理邏輯擴展新的功能或自定義新協議時，對于OVS，需要修改其核心軟件代碼或定義流表規則；對于VPP，由于其本身采用了模塊化的設計思想，因此能夠獨立于核心代碼創建新的協議功能邏輯；至于BMv2，它是基于P4 的轉發引擎，所以只需編寫并加載對應功能的P4 代碼，天然具備協議擴展能力。另一方面，在報文處理性能上，VPP 采用矢量化包處理技術，大幅降低包轉發開銷，所以包處理性能優于OVS；而BMv2 主要關注如何實現P4 程序定義的協議無關轉發功能，所以包處理性能并非它優化的重點，其處理性能遠低于VPP 和OVS[8]。綜上所述，本文擬基于VPP 實現帶內網絡遙測，以求兼具高性能和可擴展性。

3.2 VPP 數據包處理架構

VPP 基于批處理思想提升報文處理效率，同時基于模塊化的架構解耦添加新協議邏輯的復雜度。VPP 數據包處理架構如圖3 所示。首先，VPP從網絡I/O 收取輸入流量并將到達的數據包組織成一個個的包集合，即“數據包矢量”。然后，輸入流量以數據包矢量為單位，一批批通過VPP 的包處理結構來執行數據包的批量操作。該包處理結構是由多個圖節點構成的有向圖，而每個圖節點則代表數據包處理流程中的某一個操作環節。通常來說，圖節點可分為2 種類型：一種是包含收發數據包操作的節點，如dpdk-input 節點是基于DPDK 接收數據包的節點；另一種是處理數據包的節點，如ethernet-input 節點是解析數據包以太網頭部的節點。此外，值得注意的是，VPP 對數據包的處理順序不再是傳統的標量方式（即將數據包逐個送入圖節點進行處理），而是把整個數據包矢量整體送入當前圖節點進行處理，處理完成后再整體送入下一個圖節點。使用矢量處理相較標量處理的好處是，若以標量方式處理數據包，則每處理一個包都需要重新逐層調用協議棧處理函數，這很容易產生CPU 指令緩存的訪問時延抖動，即每個包被處理時都有可能產生一組相同的指令緩存缺失事件，這將大大影響處理效率。若以矢量方式處理，那么在一個圖節點的處理過程中，由于數據包矢量中第一個報文有緩存預熱作用，因此能大概率地減少包矢量中后續數據包處理時的指令緩存缺失事件，也就能以一組數據包來分攤第一個數據包引發的指令緩存缺失開銷，從而整體提升數據包矢量通過圖節點的效率。

圖3 VPP 數據包處理架構

VPP 數據包處理架構具備良好的可擴展性。具體而言，VPP 數據包處理架構中模塊化的圖結構有助于實現協議功能的快速迭代更新。如圖4 所示，若開發者希望定義新的報文處理邏輯，只需在程序庫中為VPP 編譯生成一個獨立的二進制插件，并在系統中加載該插件，就能重新排列包處理圖節點或引入新的圖節點。該機制允許通過插件更新的方式引入新的包處理邏輯，而不需要修改VPP 自身的核心代碼。這對網絡數據平面協議功能擴展來說是非常便捷的。

圖4 VPP 數據包處理架構的圖結構的擴展

3.3 VPP 圖形節點結構及其初始化

如前所述，如果開發人員想要開發自定義的包處理邏輯，就需要在VPP 數據包處理架構的圖結構中建立新的圖節點。

如圖5 所示，VPP 數據包處理架構的圖結構由vlib_node_main_t 結構體定義，該結構體記錄了包處理圖的全局信息。其中比較重要的2 個成員變量分別為nodes 和node_registrations。成員變量nodes以向量的數據結構進行組織，存儲了多個指向vlib_node_t 結構體類型的指針，用來保存所有在VPP中已注冊的圖節點；成員變量node_registrations 則以單鏈表的數據結構進行組織，鏈表中的各個元素類型為vlib_node_registration_t 結構體，提供給VPP的初始化函數使用，用于圖節點的注冊。

具體來看，vlib_node_t 結構體是單個圖節點的主要數據結構，保存了單個圖節點的名稱、節點類型、處理函數、兄弟節點及子節點等信息。vlib_node_registration_t 結構體用于圖節點的注冊，開發人員可以利用 VPP 提供的宏函數（VLIB_REGISTER_NODE），把各個圖節點預先掛載到以單鏈表組織的node_registrations 成員變量中，以供后續的初始化函數使用。圖6 是通過VLIB_REGISTER_NODE 宏函數注冊ethernet-input節點的示例，它定義了該圖節點的處理函數等一系列注冊信息。

圖6 通過VLIB_REGISTER_NODE 宏函數注冊ethernet-input 節點示例

VPP 在啟動之后，將對各個圖節點進行注冊，并創建整個數據包處理架構的圖結構。相關的初始化流程函數為vlib_main()，圖7 顯示了該函數的主要流程。vlib_main()函數首先調用vlib_register_all_static_nodes()函數，遍歷以單鏈表組織的 node_registrations 成員變量，從而創建各個圖節點，并把它們添加到以向量組織的節點成員變量中。接著，繼續調用vlib_node_main_init()函數，它會根據各個圖節點所注冊的兄弟節點及子節點等信息，建立節點之間的跳轉關系，由此，創建出一張完整的數據包處理圖。最后，在調用其他一些初始化配置函數之后，VPP 主程序將進入vlib_main_loop()函數，開始執行收發數據包和圖節點調度的流程。

圖7 VPP 數據包處理架構的圖結構的主要初始化流程

基于VPP 提供的包處理圖節點抽象機制，開發人員能夠把更多的精力投入自定義圖節點中協議邏輯功能的設計和實現里。

4 基于VPP 的帶內網絡遙測實現

4.1 設計思路

由INT 的實施框架可知，INT 元數據可以由用戶流量攜帶，也可以由專門的探測包攜帶，二者在實現上的區別主要在于INT源端封裝INT數據包的方式。目前，本文采用由專門的探測包攜帶INT 數據的實現方式，即標記特殊探測包為INT 數據包。基于此，使用額外的發包終端來發送特殊的UDP探測包。該UDP 探測包被第一臺VPP 虛擬網絡設備接收后，將被封裝INT 頭部，從而生成真正的INT數據包。該臺VPP 虛擬網絡設備實際上扮演了INT源端的功能角色。

若后續的VPP 虛擬網絡設備接收到INT 數據包，作為INT 轉發設備，它們需要依據INT 頭部的指示，統計設備自身的INT 元數據，并將其寫入INT頭部的對應位置，由此完成數據采集工作。

由于目前VPP 虛擬網絡設備暫時無法從自身判斷INT 數據包是否已被轉發至最后一跳節點，因此也無法完成INT 接收端的功能。本文將指定端側服務器作為數據包接收終端，負責解析INT 頭部中記錄的各個INT 元數據。

接下來，本文基于IPv4 和INT 協議規范，闡述在VPP 中設計和實現帶內網絡遙測的技術細節。

4.2 系統設計與實現

4.2.1 數據包格式

在標記特殊探測包為INT 數據包的實現方式中，共出現2 種數據包，一種是特殊UDP 探測包，另一種是INT 數據包。它們的包格式如下所述。

特殊UDP 探測包由額外發包終端向VPP 虛擬網絡設備發送，使用攜帶特殊目的端口號（55555）的UDP 包封裝，表示它是生成INT 數據包的原生探測包。當INT 源端識別到攜帶該端口號的UDP 包后，將其封裝成INT 數據包。此外，它的目的IP 地址為所發往的VPP 虛擬網絡設備的網絡地址。

INT 數據包的報文格式基于IPv4 協議和INT規范設計，如圖8 所示。

圖8 INT 頭部報文格式

1) 8 bit 的type 字段表示INT 數據包的類型，本文定義“1”是基于特殊UDP 探測包封裝的INT數據包。

2) 8 bit 的length 字段記錄了INT 頭部的長度。

3) 8 bit 的nextProtocol 字段用于區分INT 頭部封裝的上層協議，它復制了原始IPv4 頭部中的協議字段號（protocol）。這是因為，本文把INT 頭部放置在IP 層之后，使用自定義的協議號200 來表示IP 層之后的上層協議是INT，所以IP 頭部中原始的協議字段號需要重新被記錄在INT 頭部中，以指示INT 頭部之后的上層協議類型。

4) 16 bit 的標志位（flags）字段，包括INT 協議的版本號等標志位信息。

5) 8 bit 的hopML 字段，表示每一跳節點需要添加的INT 元數據的最大長度。

6) 8 bit 的pointer 字段，指向在INT 元數據堆棧中下一個可填充INT 元數據的空白空間地址。

7) 16 bit 的instructionMap 字段，其每bit 代表一種INT 元數據類型，指示了每跳節點需要統計的各個INT 元數據類型的組合，例如交換機標識號、出入端口時間戳、包緩存隊列長度等。

8) 后續的metadataStack 即INT 元數據堆棧，記錄了在每一跳節點上采集到的各個 INT元數據。

可以看出，對于一條端到端探測路徑，如果總共有n跳節點，且每一跳節點需要添加的INT 元數據的最大長度為hopML B，則INT 頭部所占空間為（12+nhopML）B。

4.2.2 INT 轉發設備功能

INT 轉發設備完成接收INT 數據包，采集設備本地的INT 元數據并將其寫入INT 頭部，轉發INT數據包的功能。

如前所述，VPP 的數據包處理架構以數據包矢量為單位，通過包處理架構的圖結構對包矢量進行統一處理。本文根據轉發流程設計了INT 數據包處理的VPP 圖結構，如圖9 所示。

圖9 INT 數據包處理的VPP 圖結構

具體而言，圖9 的圖結構擴展了VPP 已經提供的處理普通IPv4 數據包的簡單流程。

1) VPP 虛擬網絡設備通過收發數據包邏輯的相應節點接收IPv4 數據包（如dpdk-input 節點）。

2) 解析數據包的以太網頭部（ethernet-input節點）。

3) 解析數據包的IPv4 頭部（ip4-input 節點）。

4) 依據解析結果，查找路由表項（ip4-lookup節點）。

5) 依據出端口信息，更新數據包頭部對應的字段值（ip4-rewrite 節點）。

6) 轉發數據包（interface-ouput 節點）。

為了進一步在IPv4 協議之上實現INT 元數據的采集工作，需要對若干原有節點的邏輯功能做相應的擴展。本文在原有的ethernet-input 節點和interface-output 節點中增加了部分代碼，使數據包能在剛進入數據平面流水線進行處理以及處理結束時，分別采集所需的INT 元數據。

本文采集了3 種類型的INT 元數據，如下所示。

1) 入端口時間戳：ingress_timestamp_s 和ingress_timestamp_us，秒和微秒級，分別占4 B。

2) 出端口時間戳：egress_timestamp_s 和egress_timestamp_us，秒和微秒級，分別占4 B。

3) 出端口MAC 地址：switch_addr，占6 B。

以上元數據共占22 B，所以此時每一跳節點需要添加的INT 元數據的最大長度為22 B。

圖10 展示了采集INT 元數據的程序流程，具體的INT 元數據采集流程描述如下。

圖10 采集INT 元數據的程序流程

在ethernet-input 節點中執行原有解析動作之前，首先記錄入端口時間戳。當數據包完成以太網層和IP 層的流水線處理之后，進入interface-output節點等待轉發。此時，首先判斷數據包是否為INT數據包（ether-＞type==ETHERNET_TYPE_IP4 且ip-＞protocol==200），若是，則繼續完成下列動作，否則直接轉發數據包。當判斷是INT 數據包后，分別記錄出端口MAC 地址以及出端口時間戳。接著，根據INT 頭部的指令信息（即instructionMap 字段）和指針值（即pointer 字段），把指令要求采集的各個INT 元數據復制到INT 元數據堆棧中的空白區域。最后，更新指針值，并繼續執行數據包的轉發動作。

4.2.3 INT 源端功能

INT 源端接收特殊UDP 探測包，封裝INT 頭部以生成INT 數據包。

同樣地，本文設計了如圖11 所示的INT 源端包處理架構的圖結構。具體而言，當INT 源端接收到特殊UDP 探測包后（dpdk-input 節點），首先執行以太網頭部（ethernet-input 節點）和IPv4 頭部（ip4-input 節點）的解析操作；當解析得到的IP 目的地址為本設備地址，且IP 層頭部協議字段號為UDP 時，將繼續解析數據包的UDP 層（ip4-local節點和ip4-udp-lookup 節點），獲取UDP 頭部的目的端口號；接著，根據自定義的目的端口號（55555），執行數據包頭部的重新封裝操作（int-probe-packet-generation 節點），使其成為INT數據包；最后，由于此時INT 源端也是VPP 虛擬網絡設備，也需采集本網絡設備的狀態信息（即也需完成INT 轉發設備的功能），因此生成的INT 數據包會被重新送到以太網頭部的解析節點（ethernet-input 節點），繼而執行前文所述的INT 轉發設備處理流程，即采集INT 元數據并完成轉發。

圖11 INT 源端包處理架構的圖結構

受限于數據包大小，INT 源端無法在INT 頭部中預留無限大的空白INT 元數據堆棧空間。這就希望可以由用戶指定遙測過程的最大轉發跳數以及所采集的INT 元數據類型，基于此計算預留空間的大小。因此，除了封裝INT 頭部之外，INT 源端還應提供相應的配置接口。

綜上，本文把INT 源端的功能實現劃分為以下2 個模塊，即指令配置模塊和INT 數據包生成模塊。

1) 指令配置模塊

指令配置模塊負責提供配置指令和初始化INT頭部模板。配置指令可暴露給用戶或控制平面調用，根據配置參數來計算INT 頭部中需要預留的空白INT 元數據堆棧空間大小。INT 頭部模板則在配置指令下發后被初始化，以便INT 數據包生成模塊據此模板來重新封裝UDP 探測包，生成INT數據包。

借助VPP 提供的開發接口，可以實現CLI 配置指令以及指令響應函數。指令格式為int header

指令響應函數的程序流程如圖12 所示。首先，解析CLI 配置指令，得到各參數值；接著，先刪除原有的INT 頭部模板（即上一輪創建的頭部模板全局變量），再依據指令參數值，生成新的模板。

圖12 指令響應函數的程序流程

2) INT 數據包生成模塊

當接收到特殊UDP 探測包后，該模塊依據INT頭部模板，對探測包執行重新封裝操作，以生成真正的INT 數據包。如圖11 所示，本文在包處理架構的圖結構中增加了新的圖節點（即int-probe-packet-generation 節點，該節點的注冊函數如圖13 所示），并在ip4-udp-lookup 節點中通過解析UDP 目的端口號是否為55555 來判斷是否跳轉到該新節點進行處理。INT 數據包生成模塊的程序流程如圖14 所示。其中，本文借助VPP 提供的開發接口，為自定義的UDP 目的端口號注冊了新的節點跳轉關系。此外，在int-probe-packet-generation節點中，首先，為UDP 探測包分配足夠的INT 頭部空間；其次，將INT 頭部模板中的內容復制到UDP 探測包對應的空間中；接著，更新UDP 探測包IPv4 頭部中的protocol 字段值為200（標識上層協議為INT），并將原始值記錄到INT 頭部中；最后，重新計算IPv4 頭部校驗和，再把數據包發往ethernet-input 節點，以便繼續執行后續的INT 元數據采集工作。

圖13 int-probe-packet-generation 節點的注冊函數

圖14 INT 數據包生成模塊的程序流程

4.3 擴展案例：帶內全網遙測

4.3.1 帶內全網遙測機制簡介

INT 數據包的遙測路徑取決于該數據包如何在網絡中被轉發，即取決于網絡設備中的路由表項。若想由用戶控制遙測路徑，則可以為INT 數據包添加源路由[31]，使INT 數據包可以預先被指定轉發時的下一跳地址。基于這種源路由機制可以主動規劃全網范圍的遙測路徑，以實時獲取覆蓋全網的所有網絡設備及鏈路的狀態信息[32]。下面，本文基于VPP 給出一種帶內全網遙測的實現案例。

圖15 給出了一種帶內全網遙測機制，該機制包含數據平面和控制平面的實現。在數據平面上，INT 源端向網絡周期性地發送INT 數據包。這些INT 數據包同時還會被封裝源路由標簽棧。當INT轉發設備接收到它們時，除了采集INT 元數據并寫入INT 頭部之外，還需解析源路由標簽棧，獲取下一跳INT 轉發設備的地址。綜上，INT 數據包在網絡中的遙測路徑由其攜帶的源路由信息唯一指定。

圖15 一種帶內全網遙測機制

源路由標簽棧的內容則需由網管人員或控制器預先進行規劃。也就是說，控制平面除了分析遙測結果之外，還要借助完整的網絡拓撲圖進行全局遙測路徑的設計。然后，控制平面把計算出的各條遙測路徑下發到數據平面的INT 源端。INT 源端據此信息封裝INT 數據包中的源路由標簽棧。

4.3.2 方案實現思路

基于前文設計的基于VPP 的INT 功能方案，本節闡述帶內全網遙測機制的實現思路。

為了在IPv4 數據包中增加源路由信息，可借助IPv4 頭部的可選字段（option）。圖16 展示了源路由標簽棧的報文格式，介紹如下。

圖16 源路由標簽棧的報文格式

1) 8 bit 的NOP 字段是填充字符，使后面的字段能與4 B 長度對齊。

2) 8 bit 的code 字段標識了可選字段的選項類型，其中137 表示嚴格的源路由選項。

3) 8 bit 的length 字段記錄了整個可選字段的長度。

4) 8 bit 的pointer 字段記錄了指向下一個可使用的路由地址的指針。

5) 后續的DIP 標簽棧以4 B 為單位，記錄著數據包在網絡中傳輸時被指定的每一跳節點的網絡地址。

對于INT 轉發設備，為了解析源路由標簽棧，可以在包處理架構的圖結構中增加新的圖節點（如圖17 所示的int-sr-forwarding 節點，該節點的注冊函數如圖18 所示）。新的圖節點位于ip4-input 節點和ip4-lookup 節點之間，其程序流程如圖19 所示，具體描述如下。在ip4-input 節點中解析IPv4 頭部之后，判斷其protocol 字段值是否為200（自定義協議號，表示上層為INT 協議），若是，則把數據包發往新增加的int-sr-forwarding 節點；否則說明該數據包為普通數據包，繼續執行IP 層后續的操作。在int-sr-forwarding 節點中，首先分別判斷IPv4 頭部中的可選字段是否為源路由選項（sr-＞code==137），以及可選字段存儲的指針是否已經超出頭部長度（sr-＞pointer ＜ sr-＞length）；其次，根據指針值獲取源路由標簽棧中指定的下一跳IP 地址，并將其復制到IPv4 頭部的目的地址字段中；接著，更新可選字段中的指針值；最后，把數據包發往ip4-lookup 節點，繼續執行后續的路由表查找操作。

對于INT 源端，除了為特殊UDP 探測包添加INT 頭部之外，還需為其封裝源路由標簽棧。由于前文已經在INT 源端中設計了指令配置模塊和INT數據包生成模塊，因此只要對這2 個模塊進行適當的擴展，就能支持源路由標簽棧的封裝操作。

圖17 擴展案例中INT 轉發設備報文處理邏輯對應的VPP 圖結構

圖18 int-sr-forwarding 節點的注冊函數

圖19 INT 轉發設備解析源路由標簽棧的程序流程

一方面，由于源路由標簽棧的內容由控制平面下發，因此可以擴展指令配置模塊中的指令，以暴露給控制平面調用。增加源路由信息后的配置指令格式為int header

新格式中增加了next 參數，它按序記錄了源路由中每一跳節點的IP 地址。相應地，在指令響應函數的程序流程圖中，也需解析next 參數值，據此創建源路由標簽棧模板，并在模板中填充指定的各跳節點的地址。

此外，在INT 數據包生成模塊中，新增加的int-probe-packet-generation 節點除了為特殊UDP探測包封裝INT 頭部之外，還應該繼續在IPv4頭部的option 字段中復制源路由標簽棧模板的內容，使該INT 數據包能夠攜帶源路由信息。

5 系統功能和性能評測

5.1 實驗環境

基于VPP，本文實現了上述帶內全網遙測機制。系統包括1 017 行C++代碼，并在GitHub 網站開源。下面，基于虛擬機組網的方式，對系統進行網絡仿真實驗，以驗證遙測結果的有效性。仿真實驗環境包括一臺具有Intel i5-6500 四核CPU、16 GB內存以及1 TB 硬盤的臺式計算機。在這臺物理機上，本文又基于VirtualBox 虛擬機，創建了如圖20所示的網絡拓撲。該拓撲由3 個VPP 虛擬網絡設備（VPP1、VPP2、VPP3）、一個控制面終端、一個UDP 發包終端（P1）以及2 個主機終端（H1、H2）組成。它們分別運行在具有單核CPU、2 GB內存、Ubuntu 16.04 操作系統的VirtualBox 虛擬機中，并使用由虛擬機提供的虛擬網卡以及橋接模式進行組網。

5.2 實驗場景及目的

基于不同的實驗場景，本文希望回答以下問題。1) 單個VPP 節點在轉發普通流量和INT 流量時的性能怎么樣？本文也將比較VPP 與同類軟件（如OVS 和BMv2）的轉發性能差異。2) INT 探測包能否真正地感知到因為背景流量速率變化引發的網絡擁塞？且INT探測包自身的采樣頻率設置為多少是合適的？其中，實驗場景2)的背景流量速率設置會參考當前實驗環境的虛擬網絡鏈路最大帶寬的測量結果。

圖20 仿真實驗網絡拓撲

5.3 測試流量生成方法及流量路徑

首先，UDP 發包終端（P1）借助Iperf 發包工具向VPP 虛擬網絡設備（VPP2）發送具有特殊目的端口號（55555）的UDP 探測包。然后，VPP2作為INT 源端，接收特殊UDP 探測包，并依據CLI指令配置內容，為探測包封裝INT 頭部以及源路由標簽棧。實驗中設置的源路由路徑為hop1→hop2→hop3→控制面終端。此時，3 個VPP虛擬網絡設備（VPP1、VPP2、VPP3）都將執行INT轉發設備功能，以采集本設備的INT 元數據。接著，在控制平面終端接收到INT 數據包后，將執行INT接收終端功能，即解析INT 頭部，獲取逐跳節點統計的INT 元數據。本文依據Raw Socket 提供的API，使用C++語言實現了該解析功能。最后，主機終端（H1、H2）也借助Iperf，向網絡中發送特定速率的UDP 背景流量，這將引起沿路網絡轉發設備（VPP1、VPP2）內部排隊處理時延的增加。在對單臺VPP設備進行轉發性能測試時，本文也會直接由P1向VPP2發送普通UDP 流量。

5.4 實驗過程及結果分析

5.4.1 VPP 單節點的轉發性能

首先，本文測量單個VPP 節點在分別轉發普通流量和INT 流量時的性能。實驗過程中，P1向VPP2分別發送2 種不同類型的UDP 包：一種為普通UDP包，即VPP2按照正常數據包的處理流程執行轉發操作；另一種為前文所述的特殊UDP 探測包，即VPP2作為INT 源端，為其封裝源路由標簽棧以及INT 頭部，并將采集本設備的INT 元數據嵌入INT頭部中，最后完成轉發操作。為了公平比較，普通UDP 包以及INT 數據包的包長度均為162 B。在不同發送速率下，本文使用Linux top 命令分別測量了VPP2處理這2 類數據包的CPU 利用率，實驗結果如圖21 所示。實驗結果表明，隨著輸入包速率的增大，VPP 虛擬網絡設備的CPU 利用率也在上升。此外，由于增加了封裝額外包頭部信息和采集INT元數據等操作，相比轉發普通UDP 流量，處理和轉發INT 流量需要消耗更高的CPU 算力。經統計，CPU 利用率平均增加的百分比約為25.6%。值得注意的是，以上增加部分包括INT 源端生成源路由標簽棧和INT 頭部的開銷，如果單純執行INT 的源路由轉發操作，根據在VPP3上進行的測量，這部分增加比例會降低到20.6%。在實際部署時為了降低INT 的開銷，可以考慮使用基于采樣的INT 頭部添加策略進行INT 開銷分攤，避免為每個包添加INT頭部所帶來的較大開銷。

圖21 單臺VPP 虛擬網絡設備的CPU 利用率隨流量變化情況

此外，為了橫向比較，本文對VPP、OVS 和BMv2 的單跳轉發性能也進行了測量。轉發流量為由Iperf 產生的100 Mbit/s 的流量，3 類設備均設置為L3 最長前綴匹配轉發，包含單條轉發表項，收發包終端與轉發設備直接相連，測量結果如表1 所示。由表1 可知，具備矢量包處理能力的VPP 在100 Mbit/s 流量沖擊下具有最高的吞吐率、最低的時延和最小的丟包率。OVS 在這3 項指標中均接近VPP 但仍然存在一定差距。具體而言，OVS 和VPP 吞吐率較接近，但OVS的轉發時延達到了VPP 的2 倍多，且產生了2 倍的丟包率。相比之下，BMv2 的轉發性能較有限，并在100 Mbit/s 流量的沖擊下產生了23.4%的丟包，且轉發時延達到了驚人的10.8 ms，這和BMv2內部使用軟件模塊逼真模擬P4 交換機的硬件流水線的設計實現機制有關。BMv2 為了模擬P4 交換機的硬件流水線，在自身內部引入了多級的計算和緩存單元，且計算單元完全通過軟件指令模擬真實硬件轉發行為，這就使數據包處理時延大幅增加。但因為BMv2 內部包含大量緩存，吞吐率和丟包率降低的數量級相對時延增加來說仍然較有限。

表1 VPP、BMv2、OVS 單跳轉發測量結果

5.4.2 虛擬網絡的鏈路帶寬測量

由于是在單個物理機上采用虛擬機組網，每個虛擬機可分配到的CPU 及內存等資源較有限，這導致了組網規模較小，且無法滿足非常高速的網絡轉發性能需求。本文借助Iperf，對虛擬網絡的實際鏈路帶寬進行了測量。在如圖20 所示的網絡拓撲下，本文從H1主機終端發送UDP 報文到H2主機終端，測量結果顯示虛擬網絡轉發UDP 流量的鏈路最大帶寬約為100 Mbit/s。在100 Mbit/s 的發包速率下，產生了0.021%的輕微丟包，如果超過這個發包速率，鏈路丟包率將急劇增大，如圖22 所示。

圖22 虛擬網絡中UDP 流量的最大帶寬測量值（無丟包或輕微丟包）

5.4.3 INT 網絡狀態探測實驗過程描述

在驗證INT 探測包效果的實驗中，本文仍然借助Iperf 發包工具，從H1主機終端向H2主機終端發送不同速率的UDP 背景流量。同時，通過改變P1向VPP2發送特殊UDP 探測包的速率，來控制INT探測頻率。如前所述，目前系統僅支持采集3 種類型的INT 元數據。其中，可依據出端口MAC 地址來定位采集數據的網絡設備，由出入端口時間戳來計算數據包在網絡設備中的單跳處理時延，從而初步判斷當前網絡設備的負載壓力。

本文通過改變背景流量速率和INT探測速率這2 個變量，分別完成了3 組實驗，并觀察INT 數據包采集到的各個虛擬網絡設備的單跳處理時延變化情況。為了增強結論的可靠性，本文對每組實驗重復進行了10 次。考慮到網絡的UDP 最大（無丟包）帶寬約為100 Mbit/s，在每組實驗中，在15～25 s時間段內發送速率為90 Mbit/s 的UDP 背景流量，在30～40 s 時間段內發送速率為200 Mbit/s 的UDP背景流量（盡可能耗盡鏈路帶寬）。此外，第一組的INT 探測速率為100 kbit/s（最大帶寬的0.1%），第二組的INT 探測速率為1 Mbit/s（最大帶寬的1%），第三組的INT 探測速率為10 Mbit/s（最大帶寬的10%）。每組實驗中的INT 數據包大小均為162 B。為了方便觀察，本文只繪出了拓撲中hop2（VPP3）和hop3（VPP1）兩跳的處理時延，3 組實驗結果的一次記錄分別如圖23～圖25 所示。另外，表2 還分別列出了10 次重復實驗下，3 組實驗在不同背景流速率下統計出的hop3單跳平均處理時延。

圖23 100 kbit/s 的INT 探測速率下的交換機時延測量結果

圖24 1 Mbit/s 的INT 探測速率下的交換機時延測量結果

圖25 10 Mbit/s 的INT 探測速率下的交換機時延測量結果

表2 3 組實驗的hop3單跳平均處理時延

5.4.4 INT 網絡狀態探測實驗結果分析

圖23～圖25中的每個數據點表示在對應的出端口時間戳上，INT 數據包所采集到的單跳網絡設備處理時延（通過出端口時間戳減去入端口時間戳得到）。由于端口時間戳的時間精度是微秒級的，因此INT 能夠提供較高精度的探測結果。在每組實驗中，由于背景流量經過的路由路徑為VPP1→VPP2，而不經過VPP3，因此hop2（VPP3）的處理時延總是較低且穩定，基本不受背景流量的影響。在圖24和圖25 中，個別hop2數據點的增高主要是在高負載壓力下，運行在同一臺資源受限物理機上的各個虛擬機之間互相競爭資源所導致的。而由于背景流量最終會經過hop3（VPP2），當背景流量顯著增長，甚至超過圖22 中虛擬網絡中測試得到的網絡最大帶寬時，就會出現明顯的擁塞現象。此時背景流量數據包與INT探測包共同在設備隊列中經歷較長的排隊過程，INT 探測包能夠將該排隊時延精準記錄并傳送到控制面終端上。

從這3 組實驗hop3（VPP1）的數據點可以看出，在不發送背景流量時，hop3的處理時延與hop2基本一致；而在15～25 s、30～40 s 時由于引入背景流量，導致hop3的處理時延有所增高。特別地，當背景流量速率為200 Mbit/s 時（30～40 s，背景流量速率已經大于網絡最大帶寬），INT 探測包實時采集得到的處理時延也相應地大幅增加，由此能判斷出此時hop3鏈路已經出現擁塞。另外，如表2 所示，經過計算，在第二組實驗1 Mbit/s 的INT 探測速率下，由于背景流量的變化（無背景流量、90 Mbit/s、200 Mbit/s），采集到的INT 數據包所攜帶的hop3單跳平均處理時延分別為6.1 μs、10.8 μs、41.8 μs。由此也可以判斷出，當背景流量為200 Mbit/s 時，hop3鏈路出現了較嚴重的交換機內部隊列排隊現象。

此外，通過對比各組實驗結果，本文還觀察到不同的INT 探測速率對探測效果的影響。例如，通過對比100 kbit/s 和1 Mbit/s 的實驗結果（圖23 和圖24）可以看出，更高的INT 探測速率在一定程度上有利于提高探測結果的精度。但是，INT 探測速率越高，其所占用的網絡帶寬也越大，且INT 探測包在設備隊列中的排隊行為也將大大提升背景流量的轉發時延。如表2 所示，在10 Mbit/s 的INT探測速率下，在無背景流量、90 Mbit/s 背景流量、200 Mbit/s 背景流量時，計算得到的hop3單跳平均處理時延分別為15.9 μs、52.9 μs、137 μs，均大大高于1 Mbit/s 的INT 探測速率下測得的6.1 μs、10.8 μs、41.8 μs。這也說明如果INT 探測速率太大，INT 數據包本身在網絡設備中的處理開銷就會大幅提高，使轉發處理時延大大增加，反而不利于提升探測結果的精確度。因此，在實際部署中，需要依據具體的探測精度需求和探測開銷評估，設計合適的INT 探測速率。

5.5 與其他網絡測量方法的比較分析

綜上，本節對本文提出的方法與其他網絡測量方法進行比較分析。對于非INT 方法來說，存在測量效率和測量功能的缺陷。例如基于Poll 模式的SNMP 控制平面對數據平面的數據采集時延往往為0.4～21.1 ms[17]。而本文方案的探測時間間隔在目前的機器配置下能夠輕松達到0.13 ms。對于NetFlow、sFlow、IPFIX 等方法[18-21]，本文方案可以探測到交換機端口的擁塞和排隊信息，而不僅僅局限于包計數或流量計數等宏觀信息。相較于Pingmesh[22]，本文方案除了能夠監測路徑擁塞狀態，還能監測路徑上逐跳交換機的擁塞狀態。對于基于協議無關轉發架構實現的P4 硬件交換機[9,10,33]來說，本文方案更好地支持虛擬網絡設備，而不依賴于協議無關轉發架構本身。對于BMv2 軟件交換機[30]來說，表1 顯示VPP 的轉發性能遠高于BMv2，這也意味著本文方案可以在實際生產環境部署，而不是僅僅局限于網絡功能驗證的場景。

6 結束語

虛擬網絡設備在數據中心內被大量使用。在虛擬網絡設備上增加低時延、高精度的帶內網絡遙測功能有助于在大規模數據中心內開展實時流量可視化、故障快速定位、細粒度流量工程等網絡優化任務。作為P4 的重要應用之一，帶內網絡遙測依賴于協議無關轉發架構，目前僅有少量可編程硬件交換機支持該能力，大多數虛擬網絡設備均無法運行P4 程序，以提供帶內網絡遙測的直接支持。本文首先基于開源虛擬網絡設備VPP，設計了帶內網絡遙測的實現方案；然后基于帶內網絡遙測協議規范定義了相關數據包的報文格式，基于VPP 的數據包處理框架構造了數據平面的流水線處理模塊，并在此基礎上實現了一種帶內全網遙測機制的擴展案例；最后基于虛擬機組網方式，搭建網絡拓撲并進行了網絡性能測試，通過實驗展示了不同背景流量速率和不同探測頻率下的遙測性能數據。