zoukankan      html  css  js  c++  java
  • 实验6:开源控制器实践——RYU

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

    安装截图

    image-20211008133048758

    拓扑可视化

    image-20211008161002844

    tcpdump查看

    h1 ping h2

    image-20211008180417489

    h1 ping h3

    image-20211008180507115

    可以看到均为洪泛转发

    查看控制器流表,如下图:

    image-20211009083438007

    看到没有流表,而使用pox的hub模块则会看到流表,如下图:

    image-20211009083744791

    所以可以看到二者都是洪泛转发,但是不同之处在于POX是直接向交换机下发流表,而Ryu是在每个 Packet In 事件之后,向交换机下发动作。

    进阶要求

    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)
            # 定义保存mac地址到端口的一个映射
            self.mac_to_port = {}
    
        # 处理EventOFPSwitchFeatures事件
        @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)
    
        # 添加流表函数
        def add_flow(self, datapath, priority, match, actions, buffer_id=None):
            # 获取交换机信息
            ofproto = datapath.ofproto
            parser = datapath.ofproto_parser
    
            # 对action进行包装
            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)
            # 发送mod
            datapath.send_msg(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]
    
            # 忽略LLDP类型
            if eth.ethertype == ether_types.ETH_TYPE_LLDP:
                # ignore lldp packet
                return
    
            # 获取源端口,目的端口
            dst = eth.dst
            src = eth.src
    
            dpid = format(datapath.id, "d").zfill(16)
            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
    
            # 查看是否已经学习过该目的mac地址
            if dst in self.mac_to_port[dpid]:
                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
    
            out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
                                      in_port=in_port, actions=actions, data=data)
            # 发送流表
            datapath.send_msg(out)
    

    代码当中的mac_to_port的作用是什么?

    保存mac地址到交换机端口的映射,为交换机自学习功能提供数据结构进行 mac-端口 的存储

    simple_switch和simple_switch_13在dpid的输出上有何不同?

    simple_switch的dpid赋值:dpid = datapath.id

    simple_switch_13的dpid赋值:dpid = format(datapath.id, "d").zfill(16)

    在python console进行测试,可以看到在simple_switch直接获取的id,在simple_switch_13中,会在前端加上0将其填充至16位

    image-20211010093641181

    相比simple_switch,simple_switch_13增加的switch_feature_handler实现了什么功能?

    实现交换机以特性应答消息响应特性请求,可查看文档

    https://ryu.readthedocs.io/en/latest/ofproto_v1_3_ref.html#ryu.ofproto.ofproto_v1_3_parser.OFPSwitchFeatures

    simple_switch_13是如何实现流规则下发的?

    在接收到packetin事件后,首先获取包学习,交换机信息,以太网信息,协议信息等。如果以太网类型是LLDP类型,则不予处理。如果不是,则获取源端口目的端口,以及交换机id,先学习源地址对应的交换机的入端口,再查看是否已经学习目的mac地址,如果没有则进行洪泛转发。如果学习过该mac地址,则查看是否有buffer_id,如果有的话,则在添加流动作时加上buffer_id,向交换机发送流表。

    总结

    本次实验难度较难,主要在于对openflow协议的理解,以及对Ryu源码的熟悉程度。在实验过程中,遇到如下问题:

    • 在用Ryu的L2Switch模块下发流表时,看到洪泛现像,但是在交换机上没有看到流表,在请教老师之后才知道,这才是Ryu与POX之间的差别
    • 在分析simple_switch.py和simple_switch_13.py源码时,遇到困难,不理解函数的作用,在查看官方文档,以及搜索相关资料之后,对源码的理解相对透彻了些

    这次实验相比上次难度更大,对源码分析和对openflow协议的理解有一定的要求,但是做完实验后感受到收获颇多,学习到了更多的知识。

  • 相关阅读:
    Day 20 初识面向对象
    Day 16 常用模块
    Day 15 正则表达式 re模块
    D14 模块 导入模块 开发目录规范
    Day 13 迭代器,生成器,内置函数
    Day 12 递归,二分算法,推导式,匿名函数
    Day 11 闭包函数.装饰器
    D10 函数(二) 嵌套,命名空间作用域
    D09 函数(一) 返回值,参数
    Day 07 Day08 字符编码与文件处理
  • 原文地址:https://www.cnblogs.com/JoshuaYu/p/15388698.html
Copyright © 2011-2022 走看看