OpenDaylight VTN源码及架构分析

VTN是opendaylight中负责租户隔离的工程，最近对源码和架构研究了一段时间，现将总结如下。 从VTN架构图我们可以看出，VTN共分为两个模块：VTN Manager和VTN Coordinator。VTN通过映射机制将虚拟网络资源（比如port，bridge，route）映射到物理资源上，包在租户内转发其实是在物理资源上进行转发，隔离机制是利用OpenFlow协议，转发时通过在支持OpenFlow的交换机上通过流表判断包的转发。

1.VTN Manager

VTN Manager位于controller内部，相当于控制器的一个plugin。它提供了REST接口对其进行增删改查。它还提供了对Openstack l2的网络api。以下是VTN Manager和VTN Coordinator的关系图。VTN Coordinator通过ODC Driver与控制器中的VTN Manager还有拓扑模块，交换机管理模块相连。

 2.VTN Coordinator

VTN Coordinator通过北向接口与控制器相连接。其本身也提供REST API。一个 Coordinator可以控制多个Controller。

Coordinator通过刚开始静态下发配置，而不是在Manager收包后上交给Coordinator做收包决策。

3.源码分析

3.1 VTN映射机制

VTN采用三种映射： 端口映射：将物理交换机端口（三元组：交换机ID，端口ID，VLAN ID）映射到vBridge的端口。两者是一对一的关系。 VLAN映射：将物理交换机（二元组：交换机ID，VLAN ID或一元组：仅VLAN ID）映射到vBridge。多个VLAN ID可以map到一个vBridge，但是一个VLAN ID不能同时map到多个vBridge。Port类型为internel的无法被map。注意vlan是映射到vBridge，而不是vBridge的interface，但是实际在操作过程中，vBridge会起虚拟port对应相应的interface，该虚拟port作用相当于interface。 MAC 映射：将主机的MAC地址映射到vBridge的一个端口。（Helium版本仅在manager中支持，Lithium版本将会在coordinator中支持）该映射可以用于虚机迁移，也可以允许或禁止某些主机的通信。 注意，VTN一个端口无法映射到两个租户中。但是一个主机可以位于两个租户中，只要发包时打上不同的tag。 另外，端口映射的优先级高于VLAN映射，也就是说将会优先匹配端口映射，比如下面这个例子：

VTN有两个vBridge: bridge-1, bridge-2 bridge-1映射配置： switch-1的port-1 VLAN ID 为10 bridge-2映射配置： 不指定交换机 VLAN ID为10 当switch-1的port-1口收到一个以太网帧且VLAN ID为10，则该帧将会被认为是bridge-1的输入帧。 当别的任何端口收到以太网帧且VLAN ID为10，则该帧将会被认为是bridge-2的输入帧。

3.2 VTN 流过滤

流过滤作用于vBridge的interface，类似ACL，提供对流的允许，丢弃，此外还提供重定向功能。流匹配与openflow非常相似，元组条目如下：

• Source MAC address
• Destination MAC address
• MAC ether type
• VLAN Priority
• Source IP address
• Destination IP address
• DSCP
• IP Protocol
• TCP/UDP source port
• TCP/UDP destination port
• ICMP type
• ICMP code

对于流过滤模块，本人认为现在版本的VTN存在一些bug。比如同时创建两个相同字段的流，但优先级不同，且一个action是drop，一个是pass，预期的结果应该是高优先级的被匹配出来执行对应的action。但实验结果是匹配第一个加进行的流过滤条目，查看源码（manager/implementation/src/main/java/org/opendaylight/vtn/manager/internal/cluster/FlowFilterMap.java）发现，VTN的确就是这么设计的： for (FlowFilterImpl fi: flowFilters.values()) { if (LOG.isTraceEnabled()) { LOG.trace("{}: Evaluating flow filter: {}", getLogPrefix(fi.getIndex()), fi); } if (fi.evaluate(mgr, pctx, this)) { return; } } 我已经提交该问题到社区，目前还没有人回答。

另外还有几个bug，比如反复对同一条流进行修改，最后就莫名其妙ping通了；另外有时候port的status就为down，删除配置重新配置就可以了，感觉这个问题有可能也是ODL的问题。

3.3 Path Map/Policy

与flow filter类似，VTN中还添加了Path Policy的概念，Path Policy用于给固定源，目的点中间经过的路径加上权重，通过权重影响路径走向：

Flow condition: 等同于Flow list中的Flow filter。

Path policy: 给定路径不同的权重。

Path map: 将Flow condition与Path policy绑定起来。

如上述右图所示，不同的流（三种颜色）可以给定不同的Path policy，比如Path map可以做到尽管源点和汇点相同，但是可以走不同的路径。

3.4 VTN各个名词概念

Manager/Coordinator栏表示VTN Manager和VTN Coordinaator中是否存在该element。

下面我们来看一下host1 ping host2和host1 ping host3在VTN Manager代码中发生的具体的数据流。

3.5 VTN vBridge收包数据流分析

Boundary链路。ovs2和ovs6的两个连接host的port通过port map方式映射到两个vBridge的两个interface。

假设上图是我们的网络拓扑：6个ovs交换机，3个host，其中左边3个交换机连接一个控制器，右边3个交换机连接另外一个控制器。上面两个是VTN起的vBridge，中间通过vLink连接，该vLink map到物理网络中是ovs3和ovs5之间的Boundary链路。ovs2和ovs6的两个连接host的port通过port map方式映射到两个vBridge的两个interface。

下面我们来看一下host1 ping host2和host1 ping host3在VTN Manager代码中发生的具体的数据流。

VTNManagerImpl.java receiveDataPacket进行收包，进行一些预处理，比如是否来自disableNodes，丢弃不是以太网的包，忽略控制器发来的包，忽略lldp等等。然后根据映射方式（port, vlan, mac），NodeCoonector，src Mac Address找到对应的租户类VTenantImpl。VTenantImpl调用receive进行收包。

VTenantImpl.java receive进行收包。同VTNManagerImpl一样，也是一堆预处理，比如初始化包的老化时间，判断是否发送给控制器。然后对包设置RouteResolver，RouteResolver会在PathMap中寻找是否存在对应的path，如果存在则返回对应path的权重，不存在则会返回默认，该类将在后面转发时使用。接着，flowFilters将会对流进行过滤。最后，将会调用PortBridge进行下一步收包。

PortBridge.java receive进行收包。PortBridge类的作用是处理从物理交换机Port到vBridge interface的映射。该类将根据报的NodeConnector，vlan，src Mac Address等获得映射的虚拟结点的Interface，此处，即为vBridge interface，所以将会触发VBridgeImpl的handlePacket进行收包。

VBridgeImpl.java handlePacket进行收包，这个类是本流程的核心类。该类首先获得VBridgePath（该vBridgeImpl在VTN中的位置）以及对应vBridge上的MAC表，并学习源MAC地址。然后查找MAC表尝试获得目的地址的表项，如果表中不存在该表项则会进行洪泛；存在则会进行转发。（这两个比较重要，我把它进行细分介绍）

4.A) 　　若表中存在目的MAC表项将直接转发。首先获得源和目的结点对应的物理结点，注意之前我们所说的都是虚拟结点，即位于VTN上的。然后计算物理实际路由，计算类即为之前保存的RouteResolver，该类内部调用ODL IRouting根据之前PathMap给定的权重进行计算。找到物理网络的路径后调用ODL IDataPacketServce处理发包，从出口端口转发（物理NodeConnector），然后下发流表同时更新VTNFlowDatabase。这样之后同样的包将不会被递送到controller。

4.B)　　若表中不存在目的MAC表项将直接进行洪泛。由于vBridge interface的特殊性：其可以由3种方式映射过来（port, vlan, mac），所以洪泛时不同的映射方式需要分别进行处理。此处，我们仅举例port类型，因为我们图中是用port map方式。首先调用PortInterface.java进行两部操作：查看interface状态是否up，若不为up是无法操作的；根据出口interface的map方式重构数据帧头。然后调用VTNManagerImpl.java处理剩下的操作：调用ODL IConnectionManager判断连接的对端端口是否为同一自治域，即位于同一个控制器下。若是同一个控制器（host1 ping host2），则直接调用IDataPacketService发包；若不是同一个控制器(host1 ping host3)，则调用postEvent函数，它将会调用ClusterEvent处理不同自治域间的发包（其实最后处理是一样的）。其中IVTNResourceManager在当前控制器VTN Manager下保存全局Coordinator的信息（应该是由VTN Coordinator通过REST api指定的信息；另外，图中vLink/Boundary对应的两端interface应该是通过port map形式的，尽管我没找到源码）。

问：其中对于4.B，不涉及虚拟网络到实际网络的路由映射，而是直接在vBridge出口interface发送洪泛，其会寻找对应物理网络的port然后发送包，那么这时候问题就来了，为什么对于每个洪泛报文不进行映射到物理网络，同4.A一样寻找一条路由进行发送？

答：在4.A中，我们计算实际路由是为了下发实际流表到ovs中，而此时目的地址不确定，采用洪泛方式。此时如果进行实际物理网络路由计算，计算出来的路由不一定是最终物理的从源点到汇点的路由，更没有必要下发流表，因此此时路由是错误的。所以vtn的作者采用简单的反映射方式（从虚拟结点映射回物理网络结点再发包）搞定这一问题。

3.6 vRouter的作用

vRouter在目前版本和Lithium暂时不支持，仅在Coordinator提供对应的api，也就是说，只有空壳。基本上表所述的虚拟结点除vBridge外都没有实现。

4 关于VTN的几个问题总结

4.1 出口转发，对端在不同控制下与同一控制器下有何不同？

答：没什么不同，最后调用的都是直接发送。发送时只是判断发送口状态，而不管发送口对端连接的端口是否属于同于控制器下。这个可以这么理解：因为连接不同控制器下的Boundary链路通过port map映射到vLink上，其打上了vlan的标记，所以对端收到的包也会拥有同样的vlan标记，所以可以告知对应vlan+port的vBridge去接收。使得VTN达到跨控制器的效果。

4.2 VTN如何区分不同租户？

答：VTNManagerImpl.java receiveDataPacket（第一个收包函数）收包时，通过mac+interface+vlan确定属于的vtn，vtn类（VTenantImpl继承FlowFiterNode）不存在vtn id的概念，但是有个序列化的id，该id没实际意义。代码如下：

其中ref用于映射物理网络到虚拟网络，通过它完成映射的过程，传进的三个参数：src，nc，vlan分别代表着mac，interface，vlan。刚好代表之前所说的三种映射方式，通过这三个可以确定租户。

4.3 根据mac映射规则，只是改变mac地址可否换到一个新的租户内？

答：根据上面这个问题所示，映射规则是三元组（mac, interface, vlan），所以只是改变mac地址是不能改到一个新的租户内。

4.4 VTN的隔离的粒度是流的还是ip？

答：一个主机可以位于两个租户内，只要在包上打上不同vlan id，分属于两个不同的租户，即可以达到隔离的目的。从这个角度来说，隔离的粒度应该为流粒度。

4.5 VTN对于底层支持的openflow协议是1.0还是1.3？

答：目前仅支持openflow1.0。

4.6 vLink映射物理网络是否可以为ecmp路径？

答：vtn的vLink只是一条虚拟链路，其不关心底层实现的路仅是否为ecmp还是单路径。我们在vLink两个端点转发时涉及到实际路径的两个端点间的路由计算，此部分计算会调用ODL路径计算模块去实现。倘若底层采用of1.3协议并考虑到ecmp，则路径计算将会采用ecmp，但是此部分操作对上层vtn来说是透明的。但是目前odl默认的路由计算是Dijkstra算法，暂未看到底层有关ecmp实现的部分。目前，VTN只支持openflow1.0。