第五届SDN大赛初赛部分试题解题思路:基于ONOS的路径反转实现

作者简介:周正强,北京邮电大学未来网络实验室在读研究生,个人邮箱:857538065@qq.com

编者按:由教育部科技发展中心主管、互联网应用创新开放平台联盟主办、北京邮电大学承办的“第五届全国高校SDN网络应用创新开发大赛”初赛结果已经发布,共有30支队伍将于8月17日(报到)-8月20日在北京邮电大学迎来决赛。SDNLAB一直跟踪大赛的相关动态,包括 初赛试题发布初赛结果发布。在后台,SDNLAB君收到了不少对大赛感兴趣的师生的咨询,有好多学生对初赛试题的解题方法非常感兴趣,本次SDNLAB选择了进入决赛名单的一支队伍的初赛部分试题的答题思路,希望感兴趣的师生能有所启发。以下是正文部分。

参加了第五届SDN比赛,我也很幸运的进了复赛,本来也想着通过这种方式学习ONOS,所以想分享关于初赛第四题自己的一些解法思路,仅供大家参考。

一. 实验任务:

基于北向API开发一个简单的路由控制应用,实现动态转发路径规则设置。假设H1 ping H4,初始的路由规则是S1-S2-S5,30秒后,路由转发规则变为S1-S3-S5,再过30秒,规则变为S1-S4-S5,然后再回到最初的转发规则S1-S2-S5。通过这个循环调度的例子动态地改变交换机的转发规则。开发验证程序,使得为程序输入源IP地址和目的IP地址时,能够根据当前的流表信息分析出传输路径,并输出路径结果。

图1 网络拓扑示意图

二. 实验步骤:

2.1 仿真网络环境

采用的环境和基础题的环境一致,如下所述:

  • Ubuntu14.04LTS虚机中安装2.2.1版本的mininet网络仿真软件(IP地址为10.108.144.145);
  • 1台ubuntu16.04LTS虚机分别安装ONOS1.10.13版本的控制器(IP地址分别为10.108.147.10);
  • 1台Windows10 主机,安装Node.JS和NPM包管理器(IP地址为10.112.9.139)。

2.2 程序设计方案

2.2.1 路径动态反转方案设计

根据题目要求需要开发路由控制应用,可以实现30s的动态转发路径规则设置,其利用的基本原理是给交换机下发流表时设置hard_timeout为30s,表示到了30s后自动删除流表,这时候会重新发送报文给控制器请求新的路径。同时,我们在设计过程中用了给路径打标签的方法(具体见3中所述),其路径动态反转大致流程图如下图中所示:

图2 路径动态反转思路

1) 在控制器通过API获取全局拓扑后,控制器等待接收Packet_in消息对底层转发规则进行更改。
2) 此时解析数据包,获取数据包中的srcId和dstId,并且通过全局拓扑计算源目的IP之间的所有路径
3) 解析所有路径,从所有路径中获取到我们需要的path。
4) 在获得路径后,给该路径上的所有交换机下发对应的流表,并且设置流表中hard_timeout为30s,匹配域为源IP地址和目的IP地址,这也是为方便之后根据流表解析路径所做的准备。

5) 待30s结束流表会被清空,此时新的数据包包在进入第一个交换机时会再次packet_in给controller,此时利用上述中选定不同的路径将数据包转发,可以实现30s的动态反转。

2.2.2 IP验证程序方案设计

IP验证程序利用拓扑获取API,使用JavaScript实现,其流程图如下图中所示:

图3 IP验证程序设计实现

1) 首先会使用API获取链接和主机,并生成虚拟网络拓扑结构
2) 获取用户输入的源和目的IP地址,并获取当前网络中没给交换机中的流表
3) 匹配完成后采用DFS搜索,可以获得当前路径并显示在前端上
4) 为实现其路径反转效果,我们在程序旁边加入了当前系统时间,在一定时间内重新获取交换机中的流表,并重新计算路径,作为前后对比可以得出其路径反转效果。

2.3 具体反转解题思路

  • 首先根据题目中所示拓扑,左边的主机和右边的主机通信的时候就只有三条路径,分别是S1-S2-S5, S1-S3-S5, S1-S4-S5,这三条路中唯一不同的只有中间的交换机S2,S3,S4,因此我给每条路径都打上标签,S1-S2-S5设置的标签为数字1, S1-S3-S5设置的标签为数字2,S1-S4-S5设置的标签为数字3,在选择路径匹配时用该条路径的数字标签和对应的中间交换机进行比对即可判断是否符合路径的选择判断。
  • 根据以上想法,我设计两个Map的键值对变量。其中map用于存储的键是<源主机ID,目的主机ID>,值为对应的路径标签1-3中的其中一个,表示当前源主机到目的主机应该选择的路径。mapDevice则是根据当前路径标签去筛选出对应的中间交换机的DeviceId, 通过这个DeviceId去匹配当前算法得到的路径是否符合要求,并在activate函数中将此变量初始化备用。

  • 进行数据包的解析操作,需要解析出源和目的IP用于下发流表时备用,arp泛洪等操作和一般的解析文件一样。其中,会先通过onos自带的topologyService获取源目的主机之间所有可经过的路径并存储到paths变量中

  • paths变量传入选择路径函数中,从里面选择出理论上应该走过的路径。其中getPathCenterDeviceId函数是根据当前的源主机ID和目的主机ID去查找理论上应该经过的路径的中间交换机的值,每调用一次map中的值变量就对一个+1,按照1-3的次序循环变化(满足题目中的依次反转),然后通过mapDevice返回对应路径的交换机ID。其中在pickForwardPathIfPossible函数中不知道本身获取的paths出于什么原因,会出现一个bug,部分路径在找寻时会发生函数返回的path为null的情况,导致最后反转的路径不对,因此在返回path为null前对map中源主机和目的主机ID对应的链路值进行减1操作,保证下一次再进入寻找路径时可以正常的反转,而不是出现隔一次路径跳转的情况。

  • 在获取到对应的路径后,通过ONOS中的flowRule接口下发流表到对应的交换机中,其中设置hard_timeout为30s时间,匹配域为源和目的IP地址。我们在主机连接的第一个交换机处就会上传封包到控制器中,此时解析到的path通过迭代解析会下发给后续所有的交换机,数据包从第一个交换机转发到后面交换机之后,就可以直接匹配流表转发。选择flowRule的原因在于intent下发流表中没有设置hard_timeout这个选项,不能达到题目的要求。

2.4 具体验证操作

1) 本文所述只涉及到后台设计,前端展示实现还请自行实现,可以使用log.info将路径打印在后台显示查看,代码中均已注释
2) 开启ONOS,默认会有fwd的app开启,此时需要关闭此app,并安装开启我自己编写名为ifwd的app,如下图中所示。

图4 onos启动

图5 安装ifwd app

图6 激活ifwd app

3) Mininet脚本连接到控制器中,如下图中所示:

图7 Mininet脚本连接控制器

4) Mininet一侧进行ping操作并且在前端获取显示路径结果(也可以直接在onos后台用log.info命令打印路径输出在控制台查看),其结果显示如下:

图8 第一次路径探测结果

图9 第二次路径探测结果

图10 第三次路径探测

2.5 onos源码链接

onos的源代码链接请见github链接:
https://github.com/zhouwaiqiang/onos_sample/tree/master/ifwd


  • 本站原创文章仅代表作者观点,不代表SDNLAB立场。所有原创内容版权均属SDNLAB,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用,转载须注明来自 SDNLAB并附上本文链接。 本站中所有编译类文章仅用于学习和交流目的,编译工作遵照 CC 协议,如果有侵犯到您权益的地方,请及时联系我们。
  • 本文链接https://www.sdnlab.com/21019.html
分享到:
相关文章
条评论

登录后才可以评论

zhouwaiqiang 发表于18-07-03
0