虛擬網絡下鏡像報文傳輸協議的設計和實現

高振宇

【摘要】? ? 虛擬網絡在很多企業中有大量應用，但是如何更好地監控虛擬網絡的流量數據成為了重要的研究方向。本文基于Geneve協議設計一種適合在overlay虛擬網絡中傳遞鏡像報文數據的協議。能很好解決在虛擬網絡中鏡像報文的傳輸問題。同時文章展示了如何基于OVS實現這種協議。

【關鍵詞】? ? 虛擬網絡? ? Geneve? ? 鏡像報文

引言：

虛擬網絡[1]這幾年正在經歷高速發展，越來越多的企業在自己的數據中心開始部署虛擬網絡。與此同時，虛擬網絡配合Kubernetes、容器、虛擬機等虛擬化技術能快速幫助企業動態擴展服務，虛擬網絡則在這之中扮演著極為重要的角色。目前業界中實際落地的虛擬網絡一般都是通過overlay網絡協議來構建，例如被廣泛使用的Geneve[2]，VXLAN[3]，STT[4]等協議。

Overlay網絡構建于underlay物理網絡之上，這使得overlay虛擬網絡具有很好的擴展性，并能在很大程度上屏蔽underlay物理網絡的變化帶來的諸多影響。但是同時這也使得傳統的underlay物理網絡的很多技術難以去探測和監控overlay虛擬網絡，給網絡安全帶來了新的挑戰。

鏡像某些重要域機器的網絡報文后用各種分析器來監控和分析來往流量是否有異常是傳統物理網絡中常用的一種主動防御的信息安全手段，目前用來傳輸鏡像報文到遠端分析器的協議主要有思科提出的ERSPAN[5]，但是它主要應用在underlay物理網絡，鏡像的流量數據只能傳遞給處在underlay網絡中三層互通的網絡設備。這種方式的弊端在于流量分析設備性能必須非常強大才能實時處理傳遞過來的巨大流量數據，硬件成本投入大，并且這種方式不易于擴展，一旦我們想監控更多機器流量時候就會發現收集端的網絡成為了瓶頸，因此ERSPAN這種協議已經很難適合虛擬網絡和當前業務多變的需求。

本文提出了一種基于Geneve用于鏡像網絡報文的協議來解決這個困難，協議用于將虛擬網絡上需要監控的報文傳遞到同處于虛擬網絡遠端處理。最后文章展示了如何使用OVS[6]來實現用這種協議來傳輸鏡像報文。

一、協議的設計

Overlay虛擬網絡協議被廣泛使用的主要有Geneve，VXLAN，STT等，其中Geneve和VXLAN協議都是基于UDP協議實現的，相對基于TCP實現的STT有更好的穿透性。VXLAN的協議的報頭大小是固定的，只能攜帶非常少量的信息。而Geneve更像VXLAN的升級版，它解決了VXLAN協議報文中難以擴展和難以攜帶metadata的問題。Geneve協議報文的option域可以很方便地被用來進行各種擴展以攜帶更多的信息，從而實現更多更復雜的功能。我們基于Geneve的option域設計了GRM（Geneve base Remote Mirroring），GRM專門用于在虛擬網絡中傳遞鏡像流量到同樣處在虛擬網絡中的收集分析程序中。這樣我們就能充分利用虛擬網絡的優勢以及各種虛擬化技術來實時動態擴縮容用于收集和分析實例，以前鏡像流量必須發到指定的物理設備中，使用GRM后就可以動態分流到實時擴容的收集端，通過分布式處理的方式來解決集中式處理能力的不足問題，這樣就不用擔心由于單個物理硬件性能不足導致出現收集和分析的瓶頸問題。

1.1 Geneve協議報文頭部的option域

Geneve協議的報文相對VXLAN有更強的擴展性，如圖1所示，一個Geneve報文可以包含多個可變成長度的option。option的作用就是用來讓用戶自己定制，存入各類需要的信息，通過option域可以插入我們想要傳遞給接收端的各類描述報文的metadata信息。

圖2展示了Geneve采用了常見的TLV（Type-Length-Value）方式來描述option基本信息，每個option中都有對應的class和type。Class和type用于唯一區分option的標識。Length則描述了該option占用的長度。Option的data域則填入我們希望攜帶的信息。每個option可以攜帶4到128byte的數據。

1.2 GRM協議的設計

GRM就是利用Geneve的可變長度option域來實現的。我們把option的data域的空間拆分成多個域，放入GRM描述信息、描述鏡像報文信息以及如何轉發的信息。因為GRM本身是基于Geneve，天然就可以利用Geneve在虛擬網絡中傳遞數據，而GRM攜帶的信息則在underlay物理網絡目的端的VTEP中解析出來，而后就可以根據GRM來二次轉發鏡像報文到指定接收端中。

圖3展示了GRM協議具體的結構，VER（Version）域占用2個bit空間用于存儲GRM的版本信息，VER域用于后續協議版本的升級區別，目前值設為0，表示GRM的第一個版本。Mirror-ID占用14bit空間用于給接收端區分收到的不同的鏡像數據流，該值可以人為分配，針對每個鏡像流分配一個唯一值。VLAN-ID是Geneve的payload中攜帶的鏡像報文的VLAN-ID，收集端接收到GRM報文后可以直接使用VLAN-ID這個重要信息，而不用再去一層一層解析報文后面的鏡像報文數據得到VLAN-ID，可以幫助接收端降低分析成本。T（Truncate）占用一個bit用來表示攜帶的鏡像報文是否因為長度超過鏡像限度而被截斷，0表示GRM中攜帶的鏡像報文是完整的，沒有因為長度原因被截斷。1表示GRM中攜帶的鏡像報文是不完整的。在很多時候為了性能考慮，實際應用時候都會對只保留鏡像數據的一部分，過大的報文都會被截斷。D（Direction）占用1個bit來表示被鏡像的原始報文的傳輸方向是流進還是流出vSwitch，0表示流入vSwitch，而1表示流出vSwtch。GRM在設計上考慮了多個接收端可能鏈接在同一個VTEP中，為了減少重復發送浪費資源和帶寬，GRM指定的最終接收端可以是多個，但是必須能通過同一個VTEP到達，DC（Destination MAC Count）占用2個bit表示要轉發給同一個VTEP后面多少個收集端。SeqNum（Sequence Number）占用12個bit用來描述被鏡像的原始報文前后關系，因為GRM報文是基于Geneve的，而Geneve是基于UDP協議的，所以GRM最后通過UDP方式在網絡中傳遞的，中間可能有報文丟失和亂序的情況，SeqNum可以幫助收集端重組報文順序。當然SeqNum中的數字是可以重用的，每4096個報文后都會經歷重用，對于接收端重新編排順序是完全夠用的。很多時候報文的鏡像工作是在vSwitch中進行，而現在的網卡都支持在網卡硬件處才進行報文的切分，這個時候vSwitch收到的IP報文或者四層TCP報文并沒有被物理網卡按照MTU或者MSS切分，可能會非常大，所以設定Length占用16bit表示攜帶的鏡像的報文的大小，以盡可能適應所有網絡環境和鏡像報文需求。同樣，收集端可以根據GRM格式的偏移量加上Length域來準確提取鏡像報文。最后的Destination MAC Addresses域是變長的，可存儲1至4個目的端的vNic（虛擬網卡）的MAC地址，占用48bit至192bit。接受端的vSwitch收到GRM報文后通過DC域和MAC地址來決定轉發到哪個虛擬網卡設備。

GRM中最核心的metadata數據就是Destination MAC Addresses域，其用來告知目的端vSwitch在VTEP接受到GRM后應該如何轉發到對應的vNic中。GRM中采用了vNic的MAC地址沒有采用vNic的IP作為轉發依據主要是考慮了IPV4和IPv6相互兼容問題，以及接收端的vNic虛擬網卡實際上可以不分配IP，單純用來分析報文數據。采用vNic的MAC地址還有一個好處就是vSwitch是存儲有vNic MAC和vNic的對應關系的，能最快匹配和轉發。

1.3 虛擬網絡中GRM的傳輸

GRM是基于Geneve實現的，天然就能適配使用Geneve的虛擬網絡，只要鏡像端和接收端上啟動的vSwitch能填充和解析GRM報文就能實現虛擬網絡中流量的鏡像收集和分析。

如圖四所示，同一個宿主機Host-A上VM-A和VM-B在通信時候，數據報文會經過vSwitch轉發到VM-B。而因為VM-A是重要域的機器，需要對其進出的流量進行報文分析，vSwitch會截獲VM-A發送出來的網絡報文，解析出報文的基本信息后填充GRM報文頭部之后通過VTEP創建的Geneve管道傳遞到Host-B中。Host-B的vSwitch收到報文后會解析處GRM報文并將鏡像報文同時發送給需要收集端VM-D和Container-E

二、協議的設計

OVS（Open Virtual Switch）是Linux、Windows系統中常用的用于構建虛擬網絡的開源組件，同時它也很好支持Geneve協議，通過它可以方便地來對各種數據報文進行處理以實現GRM。

OVS通過給vSwitch配置上不同openflow[7]組合，可以實現各種復雜的網絡功能。

OVS雖然可以通過openflow實現報文轉發，但是對于實現GRM收發邏輯來說，僅僅使用openflow還不能對GRM進行填充，需要構建一個運行在用戶態的程序GRM-Controller來輔助完成GRM報文的填充。

圖5中GRM-Controller啟動后會將自身注冊到的vSwitch中，然后告知OVS通過openflow來配置vSwitch，即如果發現某個報文需要被鏡像的時候會執行controller 這個action，vSwitch將會把需要鏡像報文傳遞給用戶態程序GRM-Controller，GRM-Controller會接收到這個報文，GRM-Controller通過解析鏡像報文的報頭來填充GRM并存儲到OVS的tun_metadata中返回給vSwitch，vSwitch拿到tun_metadata后就可以直接將其當作Geneve報文的option，在后續的VTEP中封包中，OVS將自動幫封裝成完整的攜帶GRM的Geneve報文。

圖6顯示在接收端同樣要啟動GRM-Controller，配置OVS的vSwitch如果接收到帶有GRM option的Geneve的報文后會把Geneve的option數據存儲到tun_metadata中，而后通過提前設置的openflow將包含了GRM報頭的tun_metadata等發送給GRM-Controller。GRM-Controller可以根據tun_metadata來解析出GRM各個域的信息以及需要轉發到哪個MAC對應的vNic，而每個鏈接到vSwitch的vNic都有對應的ovs-port。GRM-Controller后續將轉發到哪個ovs-port寫入到register中，后續報文就可以根據傳遞下來的register來自動匹配發送到哪些端口。

三、結束語

本文通過利用Geneve協議報文中的高擴展性的option域來設計了基于Geneve虛擬網絡下鏡像報文傳輸協議GRM。GRM的引入能很好解決虛擬網絡下報文鏡像的傳輸問題，結合各種虛擬化的能力將以前需要集中處理的鏡像流量分發到虛擬網絡中的各個分布式節點中，很好地解決了集中化處理產生的各類瓶頸問題。本文同時還介紹了如果通過OVS來在實際的Geneve虛擬網絡中實現GRM的封裝和解析，驗證了通過增加編寫的用戶態的程序就能很好在Geneve虛擬網絡中支持GRM。

參? 考? 文? 獻

[1] N.M. Mosharaf Kabir Chowdhury and Raouf Boutaba. 2010. A survey of network virtualization. Comput. Netw. 54， 5 （April， 2010）， 862-876. DOI：https：//doi.org/10.1016/j.comnet.2009.10.017

[2] Gross J， Sridhar T， Garg P， et al. Geneve： Generic network virtualization encapsulation[J]. IETF draft， 2014.

[3] Mahalingam， M.， Dutt， D.， Duda， K.， Agarwal， P.， Kreeger， L.， Sridhar， T.， Bursell， M.， Wright， C.： Virtual eXtensible Local Area Network （VXLAN）： A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks. RFC 7348 （Informational）. http：//www.ietf.org/rfc/rfc7348.txt

[4] Davie， B.， Gross， J.： A Stateless Transport Tunneling Protocol for Network Virtualization （STT）. Internet-Draft draft-davie-stt-08， Internet Engineering Task Force. https：//datatracker.ietf.org/doc/html/draft-davie-stt-08. Work in Progress

[5] Chung C J， Khatkar P， Xing T， et al. NICE： Network intrusion detection and countermeasure selection in virtual network systems[J]. IEEE transactions on dependable and secure computing， 2013， 10（4）： 198-211.

[6] Open vswitch. http：//openvswitch.org.

[7] McKeown N， Anderson T， Balakrishnan H， et al. OpenFlow： enabling innovation in campus networks[J]. ACM SIGCOMM computer communication review， 2008， 38（2）： 69-74.