实验4:开源控制器实践——OpenDaylight

实验4:开源控制器实践——OpenDaylight

一、实验目的

  1. 能够独立完成OpenDaylight控制器的安装配置;
  2. 能够使用Postman工具调用OpenDaylight API接口下发流表。

二、实验环境

  1. 下载虚拟机软件Oracle VisualBox或VMware;
  2. 在虚拟机中安装Ubuntu 20.04 Desktop amd64,并完整安装Mininet;

三、实验要求

(一)基本要求

  1. 配置JAVA环境,下载并解压安装OpenDaylight,版本选择Carbon 或 Beryllium;
  2. 下载并解压安装Postman;
  3. 利用Mininet平台搭建下图所示网络拓扑,并连接OpenDaylight控制器;
    实验4:开源控制器实践——OpenDaylight
  • 创建拓扑
    实验4:开源控制器实践——OpenDaylight
  • 打开ODL
    实验4:开源控制器实践——OpenDaylight

实验4:开源控制器实践——OpenDaylight

  • pingall并观察拓扑
    实验4:开源控制器实践——OpenDaylight
  1. 通过Postman工具调用OpenDaylight提供的API下发流表,实现拓扑内主机h1和h3网络中断10s。
  • 相关配置
    实验4:开源控制器实践——OpenDaylight

实验4:开源控制器实践——OpenDaylight

  • 先h1 ping h3,后send。观察结果
    实验4:开源控制器实践——OpenDaylight

四、个人总结

  • 实验难度
    本次实验对于我来说算是比较难的,因为我对于这些工具的掌握不是很熟练,导致在使用工具过程中产生了一系列问题。从而大大延长了我做实验的时间。
  • 遇到的困难以及解决方法
  1. 拓扑建立并pingall之后在ODL上显示的拓扑为空白?
    这主要是因为我在之前建立了很多拓扑,所以只需要使用命令 sudo mn -c 清空拓扑,再次建立拓扑之后就会显示出来了。
    实验4:开源控制器实践——OpenDaylight

  2. 使用postman下发流表,但没有作用?
    可以通过观察下面返回的状态码来判断是什么错误,我的是401,所以猜测为用户名或密码写错了。于是将密码中的adimin改为admin之后就成功了。
    下列为常用状态码:

    • 100:这个状态码是告诉客户端应该继续发送请求,这个临时响应是用来通知客户端的,部分的请求服务器已经接受,但是客户端应继续发送求请求的剩余部分,如果请求已经完成,就忽略这个响应,而且服务器会在请求完成后向客户发送一个最终的结果。
    • 200:这个是最常见的http状态码,表示服务器已经成功接受请求,并将返回客户端所请求的最终结果。
    • 202:表示服务器已经接受了请求,但是还没有处理,而且这个请求最终会不会处理还不确定。
    • 204:服务器成功处理了请求,但没有返回任何实体内容 ,可能会返回新的头部元信息。
    • 301:客户端请求的网页已经永久移动到新的位置,当链接发生变化时,返回301代码告诉客户端链接的变化,客户端保存新的链接,并向新的链接发出请求,已返回请求结果。
    • 404:请求失败,客户端请求的资源没有找到或者是不存在。
    • 500:服务器遇到未知的错误,导致无法完成客户端当前的请求。
    • 503:服务器由于临时的服务器过载或者是维护,无法解决当前的请求。
  3. 安装时报各种错误。
    这些错误大多是因为复制命令的时候多复制了空格或者少复制了一个 - 导致的,因此复制完最好先检查一遍。

  • 心得体会
    在本次实验中,我还是学到了很多东西,毕竟做一步错一步(bushi)。不仅了解到了ODL和postman的使用方法,同时也对拓扑结构的了解更为深入。但是,这些还只是了解到了一点皮毛,通过不断的学习我了解到自己所学的不过是冰山一角,期待自己可以在接下来的课程中运用的更加熟练。
上一篇:开源控制器实践——OpenDaylight


下一篇:实验4:开源控制器实践——OpenDaylight