编者按：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和交换机相关技术研发
