实验6：开源控制器实践——RYU
实验6：开源控制器实践——RYU
一、实验目的
- 能够独立部署RYU控制器；
- 能够理解RYU控制器实现软件定义的集线器原理；
- 能够理解RYU控制器实现软件定义的交换机原理。
二、实验环境
- 下载虚拟机软件Oracle VisualBox或VMware；
- 在虚拟机中安装Ubuntu 20.04 Desktop amd64，并完整安装Mininet；
三、实验要求
（一）基本要求
- 完成Ryu控制器的安装。
- 终端输入 ryu --version 查看ryu版本
- 搭建下图所示SDN拓扑，协议使用Open Flow 1.0，并连接Ryu控制器。
- 终端输入 sudo mn --topo=single,3 --mac --controller=remote,ip=127.0.0.1,port=6633 --switch ovsk,protocols=OpenFlow10 搭建图示拓扑
- 通过Ryu的图形界面查看网络拓扑。
- 终端输入 ryu-manager ryu/ryu/app/gui_topology/gui_topology.py --observe-links 查看网络拓扑（图为添加控制器后的界面）
- 阅读Ryu文档的The First Application一节，运行并使用 tcpdump 验证L2Switch，分析和POX的Hub模块有何不同。
- 编写 L2Switch.py 文件
from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import MAIN_DISPATCHER
from ryu.controller.handler import set_ev_cls
from ryu.ofproto import ofproto_v1_0
class L2Switch(app_manager.RyuApp):
OFP_VERSIONS = [ofproto_v1_0.OFP_VERSION]
def __init__(self, *args, **kwargs):
super(L2Switch, self).__init__(*args, **kwargs)
@set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
def packet_in_handler(self, ev):
msg = ev.msg
dp = msg.datapath
ofp = dp.ofproto
ofp_parser = dp.ofproto_parser
actions = [ofp_parser.OFPActionOutput(ofp.OFPP_FLOOD)]
data = None
if msg.buffer_id == ofp.OFP_NO_BUFFER:
data = msg.data
out = ofp_parser.OFPPacketOut(
datapath=dp, buffer_id=msg.buffer_id, in_port=msg.in_port,
actions=actions, data = data)
dp.send_msg(out)
- 终端输入 ryu-manager L2Switch.py 运行 L2Switch.py 文件并验证功能
h1 ping h2:
h1 ping h3:
可见 h1 ping h2 或 h1 ping h3 时，h2 和 h3 抓到数据包。L2Switch 与 Hub 都是洪泛转发 ICMP 报文，但 L2Switch 下发的流表无法在 mininet 查看，Hub 却可以。
四、实验总结
本次实验让我了解了ryu控制器的部署、实现软件定义的集线器和交换机原理以及与 POX 的区别。鉴于上一次实验使用过tcpdump，本次实验这个模块比较熟练，除了用 mininet 的 xterm 打开端口时忘记输入tcpdump 命令外没有遇到什么难点。
第一次搭建完用tcpdump运行验证时 h2 和 h3 的端口都不能抓到报文：
很奇怪，于是在 mininet 下输入 pingall 测试连通性发现全都不连通：
进而发现没连接上控制器：
百度了一下说 ryu 的端口 6633 用于 openflow 目的，而我之前构建拓扑的端口号设置的是 8080，于是将构建拓扑的 mininet 命令中端口设置改为 6633 就成功连接上了控制器。
另外，ryu可视化界面一直不能显示完整拓扑结构，仍未解决。
