虚拟网络下镜像报文传输协议的设计和实现

高振宇

【摘要】    虚拟网络在很多企业中有大量应用，但是如何更好地监控虚拟网络的流量数据成为了重要的研究方向。本文基于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.