编者按:OpenDaylight ping模块开发及当ping操作触发数据流,对其进行分析及流程原理的疏通讲解,并在开发过程中遇到的问题进行总结,希望给大家能够带来帮助。
OpenDaylight ping模块开发中遇到的问题总结
最近开始学习opendalight二次开发,从官网的给定的文档以及李呈的文档。不过配置时总有点问题,由于之前没怎么倒腾过java这一套东西,包括osgi, RESTful api, maven等这一套。现总结如下,如果有谁有错误的可以帮助到:
新手常问的问题就是:为什么我和xxx配置一模一样,我的就不行?好吧,其实我也一样。
1.定义yang文件,然后mvn install。此处不会有太大问题,要是mvn报错一般是因为网速不行,有些包download不下来,换个网速快点的就可以了。
2.创建bundle实现之前yang文件定义的接口。此处会有较大的问题,在配置pom.xml时,我按文档上给的配置,然后将mvn后生成的包拷到controller的plugin中(该文件存放所有运行的jar包),启动一直报错:
1 |
BundleException: The bundle "org.opendaylight.controller.ping.plugin_0.4.0.SNAPSHOT [98]" could not be resolved. Reason: Missing Constraint: Import-Package: org.opendaylight.controller.sal.binding.api; version="[1.1.0,2.0.0)" |
根据这篇报错文档给出的说明:这类错误往往是版本的问题。这里报错提示的版本号最低需要1.1.0。这是因为自己pom.xml定义的该版本。查阅controller plugin文件发现,只存在版本号为1.0-1的。但是~/.m2目录下存在1.1.0版本号。于是我将该版本号对应的包拷贝至controller的plugin目录下,发现还是不行。正确的方式是:修改pom.xml文件中的版本号为1.0-1,然后重新mvn install一下,继续重复以上操作;这时候发现还是有依赖问题,只不过这一次报的是:
1 |
gogo: BundleException: The bundle "org.opendaylight.controller.ping.plugin_0.4.0.SNAPSHOT [258]" could not be resolved. Reason: Missing Constraint: Import-Package: org.opendaylight.controller.sal.common.util; version="[1.1.0,2.0.0)" |
注意:从~/.m2文件夹中拷贝相应的包到controller的plugin下即可,注意这时候还需要修改pom.xml下的sal.common.util版本号从1.1到1.0-1。Osgi下ss ping发现对应的包为active,即为可用。Done!利用代码测试,返回成功。
3.基本没什么问题,需要注意的就是pom.xml中的版本号需要跟上面一样修改一下。
4.键入命令:
1 |
curl --user "admin":"admin" -X PUT http://localhost:8080/controller/nb/v2/ping/127.0.0.1 |
完成ping功能。
5.最后一步整合到controller总体编译时,注意作者写的model.ping有误,应该为model-ping。
Done!
OpenDaylight ping触发的数据流分析
下图给出了一次ping触发的大概数据流,由于模块较多,未能全部画出来,一些其他的模块比如UserManager,SwitchManager等都用到了,但是未被我画出来。注意,在Hydron版本中转发报文用的是SimpleForwarding,在Helium用的是l2switch。
1.host1 ping host4,首先发送一个arp报文,交换机收到arp报文,由于本身流表没有,上传到controller。
2.由于是of 1.0的协议,走的of 1.0 模块,of1.0收到后上传到SAL层。
3.SAL层之上多个模块监听IListenDataPacket收包,每个监听IListenDataPacket的都会收到一份拷贝。Arp报文将会被ARPHandler模块接收。
4.ARPHandler通知HostTracker学习源主机地址。
5.HostTracker学习源主机地址。
6.HostTracker同时通知TopologyManager新主机被发现。理论上,还会触发流表下发,告诉每个ovs host1的地址,但是源码上没有找到。
7.ARPHandler下发广播报文,每个交换机都会发送一个广播。学习到地址之后告知ARPHandler。(目的主机host4将会发回ARPResponse,同样也会被HostTracker学习,此步骤在图中被省略)。到此为止,arp包处理完毕。
8.SAL层收到上传的ping包,告知SimpleFowarding进行转发。(此步骤省略了从host到switch到OF1.0到sal上传的过程,由于基本一致,下发操作在图中也被我省略)
9.SimpleFowarding询问HostTracker目的主机地址。
10.SimpleFowarding询问Routing模块路由地址,注意此处粒度到交换机的端口为止,该模块实现为Dijsktra寻路。
11.Routing模块需要TopologyManager告知全网拓扑才能完成计算。
12.TopologyManager告知全网拓扑。
13.Routing模块计算后告知ForwardingRulesManager下发流表。
14.Routing模块告知SimpleFowarding转发路径。(注意此处流表和转发报文都会被下发)
15.SimpleFowarding告知SAL转发报文。
如果启用北向接口,比如TopologyManager提供北向接口,App1可以通过REST api被动或者主动获取拓扑变化情况;也或者App2自己设置转发规则,则取代SimpleForwarding进行路由转发。
关于粒度问题: NodeConnector标识交换机上对应主机的端口,所以计算粒度只计算到交换机为止。
转载自:http://vinllen.com/opendaylight-pingmo-kuai-kai-fa-zhong-yu-dao-de-wen-ti-zong-jie/ & http://vinllen.com/opendaylight-pinghong-fa-de-shu-ju-liu/
作者简介:
vinllen,从事SDN和交换机相关技术研发