标签：控制器 simple 开源 datapath ofproto switch msg RYU port

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

一、实验目的

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

二、实验环境

Ubuntu 20.04 Desktop amd64

三、实验要求

（一）基本要求

搭建下图所示SDN拓扑，协议使用Open Flow 1.0，并连接Ryu控制器，通过Ryu的图形界面查看网络拓扑。
阅读Ryu文档的The First Application一节，运行当中的L2Switch，h1 ping h2或h3，在目标主机使用 tcpdump 验证L2Switch，分析L2Switch和POX的Hub模块有何不同。
编程修改L2Switch.py，另存为L2xxxxxxxxx.py，使之和POX的Hub模块的变得一致？（xxxxxxxxx为学号）

（二）进阶要求

阅读Ryu关于simple_switch.py和simple_switch_1x.py的实现，以simple_switch_13.py为例，完成其代码的注释工作，并回答下列问题：
a) 代码当中的mac_to_port的作用是什么？
b) simple_switch和simple_switch_13在dpid的输出上有何不同？
c) 相比simple_switch，simple_switch_13增加的switch_feature_handler实现了什么功能？
d) simple_switch_13是如何实现流规则下发的？
e) switch_features_handler和_packet_in_handler两个事件在发送流规则的优先级上有何不同？
编程实现和ODL实验的一样的硬超时功能。

（三）实验报告

基本要求需提交：回答基础要求2中有何不同，提交修改过的L2xxxxxxxxx.py代码和能够体现和验证修改的相关截图；

通过Ryu的图形界面查看网络拓扑

L2Switch和POX的Hub模块异同点

相同之处：两个模块使用的是洪泛转发ICMP报文，所以无论h1 ping h2还是h3，都能收到数据包。

对h2和h3进行抓包，在目标主机中验证验证L2Switch

不同之处：L2Switch下发的流表无法在mininet上查看，而Hub可以查看，如图所示

编程修改L2Switch.py

结果：

　　2.进阶要求为选做，有完成的同学请提交相关问题回答、代码和运行结果，交换机流表项截图，代码保存目录同要求2，有完成比未完成的上机分数更高。

阅读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):   # 继承
    # 定义openflow版本
    OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

    def __init__(self, *args, **kwargs):
        super(SimpleSwitch13, self).__init__(*args, **kwargs) 
        self.mac_to_port = {}  # 用字典存储MAC地址表


    # 处理EventOFPSwitchFeatures事件
    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):
        datapath = ev.msg.datapath  # datapath可认为是交换机n上发生的事
        ofproto = datapath.ofproto  # openflow协议的版本
        parser = datapath.ofproto_parser  # openflow协议的解析器

        # 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()  # match：流表项匹配，OFPMatch()：空的，为了匹配所有的封包
        # actions是为了转送到控制器端口，参数里是发往控制器端口，不进行缓存
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)]
        self.add_flow(datapath, 0, match, actions)  # 添加流表

        def add_flow(self, datapath, priority, match, actions, buffer_id=None):
        # 获取交换机信息
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser

        # inst是instruction的缩写，第一个参数是马上执行动作，第二个参数是执行动作的对象
        inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
                                             actions)]
        # 判断是否存在buffer_id，并生成mod对象
        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)   # 发送mod操作指令给交换机


    # 监听packet_in消息是否被触发，用来处理未知目的地的封包
    @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
            # 忽略LLDP类型的数据包
            return
        dst = eth.dst    # 获取目的端口
        src = eth.src    # 获取源端口


        dpid = format(datapath.id, "d").zfill(16)     # MAC地址表和每个交换机之间的识别，用dpid确认
        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地址已经被学习了，决定哪个从哪个端口发送数据包,否则泛洪
            out_port = self.mac_to_port[dpid][dst]
        else:
            out_port = ofproto.OFPP_FLOOD

        actions = [parser.OFPActionOutput(out_port)]

        # 下发流表避免下次触发 packet in 事件
        # 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
        # 构造一个pack_out消息然后发送
        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_to_port的作用是保存mac地址到交换机端口的映射

　　b) simple_switch和simple_switch_13在dpid的输出上有何不同？
　　　simple_switch直接输出dpid:dpid = datapath.id

　　　simple_switch_13中dpid用0在dpid前填充至总长度为16:dpid = format(datapath.id, "d").zfill(16)

　　c) 相比simple_switch，simple_switch_13增加的switch_feature_handler实现了什么功能？
　　switch_features_handler函数是新增缺失流表项到流表中，当封包没有匹配到流表时，就触发packet_in

　　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控制器实现软件定义的集线器和交换机的原理

做过了实验五后，在完成实验六的基础要求就比较得心应手，二者连接控制器以及验证的过程差别不大。通过本次实验我能够部署RYU控制器，顺利打开ryu的可视化图形界面，此外也进一步熟悉了之前tcpdump命令的用法，同时通过进阶要求对simple_switch_13有了一点了解。这次进阶要求的问题有很多，需要自己对于相关代码的理解要十分全面，主要还是由于对于英文文档阅读起来非常吃力；对于本次实验，最重要的还是了解到Hub和L2Switch的区别就在于下发流表是否可以查看，希望可以在之后的实验中能够更加深入地理解到它们的区别，有机会的话会加以使用。

标签：控制器,simple,开源,datapath,ofproto,switch,msg,RYU,port
From： https://www.cnblogs.com/Jue1108/p/16837350.html

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

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

一、实验目的

二、实验环境

三、实验要求

（一）基本要求

（二）进阶要求

（三）实验报告

相关文章

赞助商

阅读排行