实验6：开源控制器实践——RYU

实验6：开源控制器实践——RYU

一、实验目的

1. 能够独立部署RYU控制器；
2. 能够理解RYU控制器实现软件定义的集线器原理；
3. 能够理解RYU控制器实现软件定义的交换机原理。

二、实验环境

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

三、实验要求

（一）基本要求

1. 完成Ryu控制器的安装。
2. 搭建下图所示SDN拓扑，协议使用Open Flow 1.0，并连接Ryu控制器。
   
3. 通过Ryu的图形界面查看网络拓扑。
4. 阅读Ryu文档的The First Application一节，运行并使用 tcpdump 验证L2Switch，分析和POX的Hub模块有何不同。

• ryu --version 结果截图
  
• tcpdump的验证过程截图
• h1 ping h2
  
• h1 ping h3
  

（二）进阶要求

1. 阅读Ryu关于simple_switch.py和simple_switch_1x.py的实现，以simple_switch_13.py为例，完成其代码的注释工作，并回答下列问题：

查看代码

  
# 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
#
#    http://www.apache.org/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 ryu.base import app_manager

from ryu.controller import ofp_event

from ryu.controller.handler import CONFIG_DISPATCHER, MAIN_DISPATCHER

from ryu.controller.handler import set_ev_cls

from ryu.ofproto import ofproto_v1_3

from ryu.lib.packet import packet

from ryu.lib.packet import ethernet

from ryu.lib.packet import ether_types
class SimpleSwitch13(app_manager.RyuApp):

OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]#OpenFlow1.3版本
def init(self, args, **kwargs):

super(SimpleSwitch13, self).init(args, **kwargs)

self.mac_to_port = {}#MAC位址表，用于存放MAC地址和端口之间的映射
@set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)

def switch_features_handler(self, ev):

datapath = ev.msg.datapath

ofproto = datapath.ofproto

parser = datapath.ofproto_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 = parser.OFPMatch()

actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,

ofproto.OFPCML_NO_BUFFER)]

self.add_flow(datapath, 0, match, actions)
为交换机的流表新增Table-miss Flow Entry项，用于封包在无法匹配到流表项后与之匹配
def add_flow(self, datapath, priority, match, actions, buffer_id=None):

ofproto = datapath.ofproto

parser = datapath.ofproto_parser
inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,

actions)]

#Entry的Instruction项，指定为output action中的动作，OFPIT_APPLY_ACTIONS表示动作立即执行

if buffer_id:

mod = parser.OFPFlowMod(datapath=datapath, buffer_id=buffer_id,

priority=priority, match=match,

instructions=inst)

else:

mod = parser.OFPFlowMod(datapath=datapath, priority=priority,

match=match, instructions=inst)

datapath.send_msg(mod)
@set_ev_cls(ofp_event.EventOFPPacketIn, 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 ev.msg.msg_len < ev.msg.total_len:

self.logger.debug("packet truncated: only %s of %s bytes",

ev.msg.msg_len, ev.msg.total_len)

msg = ev.msg

datapath = msg.datapath

ofproto = datapath.ofproto

parser = datapath.ofproto_parser

in_port = msg.match['in_port']
pkt = packet.Packet(msg.data)

eth = pkt.get_protocols(ethernet.ethernet)[0]
if eth.ethertype == ether_types.ETH_TYPE_LLDP:

# ignore lldp packet

return

dst = eth.dst

src = eth.src

#获取目的和源Mac地址
获取OpenFlow交换器的标识ID
dpid = format(datapath.id, "d").zfill(16)

#Python zfill() 方法返回指定长度的字符串，原字符串右对齐，前面填充0
self.mac_to_port.setdefault(dpid, {})
self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port)
learn a mac address to avoid FLOOD next time.
self.mac_to_port[dpid][src] = in_port
if dst in self.mac_to_port[dpid]:#判断目的Mac地址是否存在于Mac位址表中，若不存在则进行洪泛

out_port = self.mac_to_port[dpid][dst]

else:

out_port = ofproto.OFPP_FLOOD
actions = [parser.OFPActionOutput(out_port)]
install a flow to avoid packet_in next time
添加交换机中的流表项
if out_port != ofproto.OFPP_FLOOD:

match = parser.OFPMatch(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 msg.buffer_id != ofproto.OFP_NO_BUFFER:

self.add_flow(datapath, 1, match, actions, msg.buffer_id)

return

else:

self.add_flow(datapath, 1, match, actions)

data = None

if msg.buffer_id == ofproto.OFP_NO_BUFFER:

data = msg.data

#将Packet-Out讯息对应的类别OFPPacketOut的实体发送给交换机

out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,

in_port=in_port, actions=actions, data=data)

datapath.send_msg(out)

• a) 代码当中的mac_to_port的作用是什么？
  MAC位址表，用于存放MAC地址和端口之间的映射
• b) simple_switch和simple_switch_13在dpid的输出上有何不同？
  simple_switch_13的dpid的输出为右对齐的16位字符串，在前面填充0，末尾加d。
• c) 相比simple_switch，simple_switch_13增加的switch_feature_handler实现了什么功能？
  为交换机的流表新增Table-miss Flow Entry项
• d) simple_switch_13是如何实现流规则下发的？
  先判断以太网类型，若为LLDP类型则返回。再判断判断目的Mac地址是否存在于Mac位址表中，若不存在则进行洪泛。然后查看是否有buffer_id，如果有的话在添加流动作时加上buffer_id，最后向交换机发送流表。
• e) switch_features_handler和_packet_in_handler两个事件在发送流规则的优先级上有何不同？

（三）实验总结

这次实验感觉难度还是挺大的。要看很多英文文档，很多专有名词都不太懂，同时也有些地方没能找到答案。像和pox中的hub比较，我没能确认下发的流表是否像各位同学写的那样能不能查看。进阶实验的e题如果看add_flow的话，我觉得应该是_packet_in_handler的优先级高。不过对这方面的知识确实没有那么深入地去了解，所以还是放空了。留下问题没解开真是挺遗憾的，在之后的学习中希望能找到解答。除此之外，刚开始实验的时候对Ryu的使用还是有点手足无措，也是在同学的帮助下才找到方向的。感觉做实验可能会遇到很多不会的，要多查多问才好。