2023年7月23日发(作者：)

实验6：开源控制器实践——RYU⼀、实验⽬的能够独⽴部署RYU控制器；能够理解RYU控制器实现软件定义的集线器原理；能够理解RYU控制器实现软件定义的交换机原理。⼆、实验环境下载虚拟机软件Oracle VisualBox或VMware；在虚拟机中安装Ubuntu 20.04 Desktop amd64，并完整安装Mininet；三、实验要求（⼀）基本要求1、完成Ryu控制器的安装。在Ryu安装⽬录下执⾏ryu --version查看版本2、搭建下图所⽰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_ --observe-links4、阅读Ryu⽂档的The First Application⼀节，运⾏并使⽤ tcpdump 验证L2Switch，分析和POX的Hub模块有何不同。新建⼀个⽂件，编辑保存为 ⽂件from import app_managerfrom ller import ofp_eventfrom r import MAIN_DISPATCHERfrom r import set_ev_clsfrom o import ofproto_v1_0class L2Switch(app_): OFP_VERSIONS = [ofproto_v1__VERSION] def __init__(self, *args, **kwargs): super(L2Switch, self).__init__(*args, **kwargs) @set_ev_cls(ofp_FPPacketIn, MAIN_DISPATCHER) def packet_in_handler(self, ev): msg = dp = th ofp = o ofp_parser = o_parser actions = [ofp_ionOutput(_FLOOD)] data = None if _id == _NO_BUFFER: data = out = ofp_ketOut( datapath=dp, buffer_id=_id, in_port=_port, actions=actions, data = data) _msg(out)使⽤命令ryu-manager 运⾏并验证（运⾏后再搭拓扑）：h1 ping h2h1 ping h3由上述结果可知，与POX的Hub模块相⽐，L2Switch的相同之处在于：Hub和L2Switch实现的都是洪泛发送ICMP报⽂，所以在h2和h3可以看到都有抓到数据包。不同之处在于：L2Switch下发的流表⽆法查看，⽽Hub可以查看。(⼆)进阶要求阅读Ryu关于simple_和simple_switch_的实现，以simple_switch_为例，完成其代码的注释⼯作，并回答下列问题：simple_switch_注释# Copyright (C) 2011 Nippon Telegraph and Telephone Corporation.## Licensed under the Apache License, Version 2.0 (the "License");# you may not use this file except in compliance with the License.# You may obtain a copy of the License at## /licenses/LICENSE-2.0## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or# implied.# See the License for the specific language governing permissions and# limitations under the License.# 引⼊包from import app_managerfrom ller import ofp_eventfrom r import CONFIG_DISPATCHER, MAIN_DISPATCHERfrom r import set_ev_clsfrom o import ofproto_v1_3from import packetfrom import ethernetfrom import ether_typesclass SimpleSwitch13(app_): # 定义openflow版本 OFP_VERSIONS = [ofproto_v1__VERSION] def __init__(self, *args, **kwargs): super(SimpleSwitch13, self).__init__(*args, **kwargs) # 定义保存mac地址到端⼝的⼀个映射 _to_port = {} # 处理EventOFPSwitchFeatures事件 @set_ev_cls(ofp_FPSwitchFeatures, CONFIG_DISPATCHER) def switch_features_handler(self, ev): datapath = th ofproto = o parser = o_parser # install table-miss flow entry # # We specify NO BUFFER to max_len of the output action due to # OVS bug. At this moment, if we specify a lesser number, e.g., # 128, OVS will send Packet-In with invalid buffer_id and # truncated packet data. In that case, we cannot output packets # correctly. The bug has been fixed in OVS v2.1.0. match = ch()#match：流表项匹配，OFPMatch()：不匹配任何信息 actions = [ionOutput(_CONTROLLER, _NO_BUFFER)] _flow(datapath, 0, match, actions)#添加流表项 # 添加流表函数 def add_flow(self, datapath, priority, match, actions, buffer_id=None): # 获取交换机信息 ofproto = o parser = o_parser # 对action进⾏包装 inst = [tructionActions(_APPLY_ACTIONS, actions)] # 判断是否有buffer_id，⽣成mod对象 if buffer_id: mod = wMod(datapath=datapath, buffer_id=buffer_id, priority=priority, match=match, instructions=inst) else: mod = wMod(datapath=datapath, priority=priority, match=match, instructions=inst) # 发送mod _msg(mod) # 触发packet in事件时，调⽤_packet_in_handler函数 @set_ev_cls(ofp_FPPacketIn, MAIN_DISPATCHER) def _packet_in_handler(self, ev): # If you hit this you might want to increase # the "miss_send_length" of your switch if _len < _len: ("packet truncated: only %s of %s bytes", _len, _len) # 获取包信息，交换机信息，协议等等 msg = datapath = th ofproto = o parser = o_parser in_port = ['in_port'] pkt = () eth = _protocols(et)[0] # 忽略LLDP类型 if ype == ether__TYPE_LLDP: # ignore lldp packet return # 获取源端⼝，⽬的端⼝ dst = src = dpid = format(, "d").zfill(16) _to_ault(dpid, {}) ("packet in %s %s %s %s", dpid, src, dst, in_port) # 学习包的源地址，和交换机上的⼊端⼝绑定 # learn a mac address to avoid FLOOD next time. _to_port[dpid][src] = in_port # 查看是否已经学习过该⽬的mac地址 if dst in _to_port[dpid]: out_port = _to_port[dpid][dst] # 否则进⾏洪泛 else: out_port = _FLOOD actions = [ionOutput(out_port)] # 下发流表处理后续包，不再触发 packet in 事件 # install a flow to avoid packet_in next time if out_port != _FLOOD: match = ch(in_port=in_port, eth_dst=dst, eth_src=src) # verify if we have a valid buffer_id, if yes avoid to send both # flow_mod & packet_out if _id != _NO_BUFFER: _flow(datapath, 1, match, actions, _id) return else: _flow(datapath, 1, match, actions) data = None if _id == _NO_BUFFER: data = # 发送Packet_out数据包 out = ketOut(datapath=datapath, buffer_id=_id, in_port=in_port, actions=actions, data=data) # 发送流表 _msg(out)a) 代码当中的mac_to_port的作⽤是什么？保存mac地址到交换机端⼝的映射，为交换机⾃学习功能提供数据结构进⾏mac端⼝的存储。b) simple_switch和simple_switch_13在dpid的输出上有何不同？dpid = # simple_switch的dpid赋值dpid = format(, "d").zfill(16) # simple_switch_13的dpid赋值由上可见在simple_switch_13中，会在前端加上0以填充⾄16位，simple_switch直接输出dpidc) 相⽐simple_switch，simple_switch_13增加的switch_feature_handler实现了什么功能？实现了交换机以特性应答消息响应特性请求d) simple_switch_13是如何实现流规则下发的？在接收到packetin事件后，⾸先获取包学习，交换机信息，以太⽹信息，协议信息等。如果以太⽹类型是LLDP类型，则不予处理。如果不是，则获取源端⼝⽬的端⼝，以及交换机id，先学习源地址对应的交换机的⼊端⼝，再查看是否已经学习⽬的mac地址，如果没有则进⾏洪泛转发。如果学习过该mac地址，则查看是否有buffer_id，如果有的话，则在添加流动作时加上buffer_id，向交换机发送流表e) switch_features_handler和_packet_in_handler两个事件在发送流规则的优先级上有何不同？switch_features_handler下发流表的优先级更⾼四、个⼈总结实验难度：基础要求较简单，进阶要求较难实验过程遇到的困难及解决办法：基本要求是连接ryu并通过Ryu的图形界⾯查看⽹络拓扑，⼀开始⽤图形界⾯时出现了问题，询问⽼师后知道是python的版本发⽣了改变，之后按照⽂件中的⽅法删除旧的软链接，然后添加新的软链接以后就把python版本改回3.0了，不是很清楚为什么回⾃⼰变掉。改完以后还是出现⼀样的问题，然后发现⾃⼰终端打开的位置出现错误了，应该在学号⽂件夹⾥⾯打开，还是得细⼼⼀点。在使⽤ tcpdump 验证L2Switch时，由于是和上次实验⼀样的⽅法，所以会⽐较顺利。就是因为⾃⼰是⼀开始就建⽴了拓扑，后⾯在验证的时候，发现抓包时ping不出来，询问同学以后，重新构建了拓扑，成功解决。最后⼀个问题是⽤ryu图形界⾯，出现了两个图形，后⾯想了⼀下，应该是⾃⼰在不⼩⼼既在ryu⽂件夹⾥⾯建了⼀个拓扑的原因个⼈感想：基本要求都会了，了解了hub模块与L2Switch模块的异同，知道了怎么连接ryu，怎么开ryu的图形界⾯，此外也进⼀步熟悉了tcpdump的⽤法，也通过进阶要求对simple_switch_13有了⼀点了解。并且了解了怎么修改python版本，还是第⼀次修改，另外就是要细⼼⼀点，⽐如通过ryu开启图形界⾯的代码就知道了应该是在学号⽂件夹下打开终端，但是⾃⼰却开错了，实在不应该。