Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

Vinllen Chen


To be a better coder

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还有拓扑模块,交换机管理模块相连。
p1.png
p2.png
p3.png

2.VTN Coordinator

  VTN Coordinator通过北向接口与控制器相连接。其本身也提供REST API。一个 Coordinator可以控制多个Controller。
  Coordinator通过刚开始静态下发配置,而不是在Manager收包后上交给Coordinator做收包决策。
p4.png

3.源码分析

3.1 VTN映射机制

VTN采用三种映射:

  1. 端口映射:将物理交换机端口(三元组:交换机ID,端口ID,VLAN ID)映射到vBridge的端口。两者是一对一的关系。
  2. 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。
  3. 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非常相似,元组条目如下:

  1. Source MAC address
  2. Destination MAC address
  3. MAC ether type
  4. VLAN Priority
  5. Source IP address
  6. Destination IP address
  7. DSCP
  8. IP Protocol
  9. TCP/UDP source port
  10. TCP/UDP destination port
  11. ICMP type
  12. 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用于给固定源,目的点中间经过的路径加上权重,通过权重影响路径走向:
vtn_xxx.png

  • Flow condition: 等同于Flow list中的Flow filter。
  • Path policy: 给定路径不同的权重。
  • Path map: 将Flow condition与Path policy绑定起来。

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

3.4 VTN各个名词概念



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

3.5 VTN vBridge收包数据流分析

vtn1.png
  假设上图是我们的网络拓扑: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代码中发生的具体的数据流。

  1. VTNManagerImpl.java receiveDataPacket进行收包,进行一些预处理,比如是否来自disableNodes,丢弃不是以太网的包,忽略控制器发来的包,忽略lldp等等。然后根据映射方式(port, vlan, mac),NodeCoonector,src Mac Address找到对应的租户类VTenantImpl。VTenantImpl调用receive进行收包。
  2. VTenantImpl.java receive进行收包。同VTNManagerImpl一样,也是一堆预处理,比如初始化包的老化时间,判断是否发送给控制器。然后对包设置RouteResolver,RouteResolver会在PathMap中寻找是否存在对应的path,如果存在则返回对应path的权重,不存在则会返回默认,该类将在后面转发时使用。接着,flowFilters将会对流进行过滤。最后,将会调用PortBridge进行下一步收包。
  3. PortBridge.java receive进行收包。PortBridge类的作用是处理从物理交换机Port到vBridge interface的映射。该类将根据报的NodeConnector,vlan,src Mac Address等获得映射的虚拟结点的Interface,此处,即为vBridge interface,所以将会触发VBridgeImpl的handlePacket进行收包。
  4. 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形式的,尽管我没找到源码)。

odl<em>vtn</em>shoubao_2.png
:其中对于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没实际意义。代码如下:
daima.png
其中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。

说明

转载请注明出处:http://vinllen.com/opendaylight-vtnyuan-ma-ji-jia-gou-fen-xi/


About the author

vinllen chen

Beijing, China

格物致知


Discussions

comments powered by Disqus