RYU控制器基本应用

一：使用命令行启动控制器，使用simple_switch_13.py组件查看效果

        1.使用mininet创建拓扑

sudo mn --topo single,3 --controller remote -x --mac --switch ovsk

        参数说明：

　　--controller 自己指定一个控制器，一般用remote指定远程控制器。还可以用--ip 与 --port 指定地址和端口号

　　--mac 自动设置mac地址，并让其从小到大排列

　　--switch 设置交换机的类型。交换机分为内核型(lxbr)，用户型(user)，OVS型(ovsk,ovsbr,ivs)。内核型和OVS型比用户型吞吐量大的多，常被选用。

　　-x 打开所有节点的终端

        2.设置交换机s1上的OpenFlow版本并查看流表

设置交换机的流表为OpenFlow1.3：

sudo ovs-vsctl set bridge s1 protocols=OpenFlow13

查看流表：

sudo ovs-ofctl -O OpenFlow13 dump-flows s1

        3.执行ryu控制器

ryu-manager --verbose simple_switch_13.py 

参数说明：

　　--verbose:显示调试信息
　　ryu.app.simple_switch_13为提供了传统2层交换机策略的组件。其他组件见下图

调试信息中，
　　EVENT ofp_event->SimpleSwitch13 EventOFPSwitchFeatures
       switch features ev
version=0x4,msg_type=0x6,msg_len=0x20,xid=0x99ea8d54,OFPSwitchFeatures(auxiliary_id=0,capabilities=79,datapath_id=1,n_buffers=256,n_tables=254)
　　这里是获取交换机的特征的过程

对以上几个字段分析：
    在ryu/ryu/lib/packet/openflow.py 可查看基本属性的意义。

在ryu/ryu/ofproto/ofproto_v1_3.py可查看各类型的值的意义。

属性	值	意义
version	0x4	OpenFlow1.3版本
msg_type	0x6	这是OPEN_FEATURE_REPLY报文
msg_len	0x20	报文长度
xid	0x99ea8d54	交互的编号

        4.查看交换机s1流表，发现多了一条Table-miss的流表项。

 

        这边使用h1 ping h2 了四次。

详细过程分析：　　
　　（1）h1 发送ARP请求报文，源mac为h1mac，目的mac为ffffffffffff，交换机未匹配到流表项，向控制器发送Packet_In报文（编号1440）。

　　（2）控制器将入端口1与h1的mac地址绑定，并回复Packet_Out报文给交换机，让其执行FLOOD（泛洪）操作，交换机向除了入端口以外的端口泛洪ARP请求报文（编号1441）。

　　（3）h2接收到ARP请求报文，回复ARP应答报文，源mac为h2mac，目的mac为h1mac，交换机未匹配到流表项，向控制器发送Packet_In报文（编号1446）.

　　（4）控制器将入端口2与h2的mac地址绑定，再看交换机送来的数据包，发现源mac（h2mac)和目的mac(h1mac)都已经和入端口绑定，所以可以下发一条流表项（Flow_Mod报文）：

　　　　  FlowEntry1:源地址：h2mac，目的地址：h1mac，动作:output 1 （从端口1发出）（编号1447）

　　（5）h1收到ARP应答报文后，开始向h2发送ICMP请求数据包，数据包发送至交换机时，交换机s1未匹配到流表项，向控制器发送Packet_In报文。（编号1450）

　　（6）控制器查看交换机发来的数据包，发现源mac(h1mac)和目的mac(h2mac)都已经和入端口绑定，所以可以下发一条流表项（Flow_Mod报文）：

　　　　  FlowEntry2:源地址：h1mac，目的地址：h2mac，动作:output 2 （从端口2发出）（编号1451）

　　（7）交换机按流表项转发ICMP请求/应答数据包，ping过程顺利完成。

         6.查看交换机流表项和控制器日志

二：分析simple_switch_13.py

         参考：软件定义网络入门学习笔记3-学习第一个ryu app-simple_switch_13.py_计算机科学与设计的博客-CSDN博客

        1.simple_switch_13.py在ryu/ryu/app目录下，以下是完整代码：　　

# 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]

    def __init__(self, *args, **kwargs):
        super(SimpleSwitch13, self).__init__(*args, **kwargs)
        self.mac_to_port = {}

    @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

        inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
                                             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

        dpid = datapath.id
        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]:
            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

        out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
                                  in_port=in_port, actions=actions, data=data)
        datapath.send_msg(out)

                2.分段代码分析

class SimpleSwitch13(app_manager.RyuApp):

#继承了ryu.base.app_manager

OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

    def __init__(self, *args, **kwargs):
        super(SimpleSwitch13, self).__init__(*args, **kwargs)
        self.mac_to_port = {}

#OFP_VERSIONS是指OpenFlow版本，这里调取了在ofproto_v1_3.py里声明的静态变量OFP_VERSION，值为4，为OpenFlow1.3版本。


#在 __init__ 构造函数中，首先调用父类的 __init__ 函数来进行初始化，使得 SimpleSwitch13 类有自己的实例。

#然后创建了一个叫做 self.mac_to_port 的字典，用于将 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

        match = parser.OFPMatch()        #流表项匹配，OFPMatch()指不匹配任何信息
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)]
        self.add_flow(datapath, 0, match, actions)

#actions是动作，表示匹配成功不缓存数据包并发送给控制器。最后add_flow是添加流表项的函数，我们在完整代码中可以看到add_flow调用了send_msg(mod)说明这里会发出Flow_Mod报文，所以上述过程就是下发Table-miss流表项的过程。

#########################################################################################
这段代码是一个 OpenFlow 控制器中的事件处理器函数，用于在交换机连接到控制器并发送 SwitchFeatures 消息时，向交换机添加一个默认流表项。

事件处理器函数使用了装饰器 @set_ev_cls，这个装饰器可以将函数注册为对指定类型 OpenFlow 事件的响应器。在这个示例代码中，这个事件处理器函数被注册为对 EventOFPSwitchFeatures 事件的响应器。该事件在交换机启动时由控制器触发。

函数的参数 ev 是一个事件对象，包含了这个事件的相关信息，如交换机的 datapath 对象和收到的信息。

事件处理器函数首先从事件对象中获取到了 datapath 对象和交换机协议的 parser 对象。然后，创建了一个空的匹配项和一个输出至控制器的动作，最后调用了 self.add_flow 函数向交换机添加一个匹配任意流量的默认流表项，以确保所有未匹配的数据包都会被传输到控制器上进行丢包处理（即 dropped）。

#########################################################################################

控制器事件（Event)，Event具体见ryu/controller/ofp_event.py，其事件名称是由接收到的报文类型来命名的，名字为Event+报文类型，例如本例中，控制器收到的是交换机发送的FEATURE_REPLY报文，所以事件名称为EventOFPSwitchFeatures。所以本事件其实就是当控制器接收到FEATURE_REPLY报文触发。

　　控制器状态：ryu控制器和交换机交互有4个阶段，详见ryu/ryu/controller/handler.py
4个状态：

HANDSHAKE_DISPATCHER:发送Hello报文并等待对端Hello报文。
CONFIG_DISPATCHER：协商版本并发送FEATURE-REQUEST报文。
MAIN_DISPATCHER：已收到FEATURE-REPLY报文并发送SET-CONFIG报文。
DEAD_DISPATCHER：与对端断开连接。
  　  综上，以上代码说明了当控制器处于CONFIG_DISPATCHER状态并且接受到FEATURE_REPLY报文时，执行switch_features_handler()函数。

#########################################################################################

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)]//立即执行动作，各静态变量说明见 ryu/ryu/ofproto/ofproto_v1_3.py
          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)

add_flow()函数作用是增加流表项，参数有datapath，优先级，匹配项，动作，buffer_id。上述代码说明了，此流表项匹配成功后应立即执行所规定的动作。如果此函数参数有buffer_id(就是交换机发送来的数据包有buffer_id，即交换机有缓存），那发送的Flow_Mod报文就带上buffer_id，若没有buffer_id，buffer_id就是None。最后，发出Flow_Mod报文，所以添加流表项是通过Flow_Mod报文实现。

@set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
     def _packet_in_handler(self, ev):

#这段代码说明了控制器在MAIN_DISPATCHER状态并且触发Packet_In事件时调用_packet_in_handler函数。

# 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)
#　这段代码是指传输出错，打印debug信息

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

        dpid = datapath.id
        self.mac_to_port.setdefault(dpid, {})

        self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port)

#这里是从接收到的Packet_In报文中取出各种信息，如果报文时lldp报文，忽略它。
#随后用此dpid（交换机id)初始化mac_to_port，并在日志打印此Packet_In的基本信息。

# learn a mac address to avoid FLOOD next time.
self.mac_to_port[dpid][src] = in_port

#交换机自学习，类似传统二层交换机的MAC地址表自学习。
#取来往数据包的交换机id、源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)]

        # install a flow to avoid packet_in next time 创建流表项来避免再次收到Packet_in报文
        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://有buffer_id，带上buffer_id，然后只发送Flow_mod报文，因为交换机已经有缓存数据包，就不需要发送packet_out报文
                self.add_flow(datapath, 1, match, actions, msg.buffer_id) //add_flow函数内部就已发送了Flow_mod报文。，后面不用send_msg()
                return
            else://若没有buffer_id，发送的Flow_Mod报文就无需要带上buffer_id，但是下一步要再发送一个Packet_out报文带上原数据包信息。
                self.add_flow(datapath, 1, match, actions)
        data = None
        if msg.buffer_id == ofproto.OFP_NO_BUFFER:
            data = msg.data
　　　　 //发送Packet_out数据包 带上交换机发来的数据包的信息
        out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
                                  in_port=in_port, actions=actions, data=data)
        datapath.send_msg(out)

1. 首先判断接收到的数据包的目的MAC地址是否存在于交换机的MAC地址表中（通过交换机的datapath dpid 和 MAC地址表来判断），如果存在，就将对应的出端口信息赋值给 out_port 变量。
2. 如果不存在，则设置 out_port = ofproto.OFPP_FLOOD 对应的out_port表示泛洪，即广播所有的端口。
3. 根据上述判断生成动作（actions）列表。
4. 如果out_port != ofproto.OFPP_FLOOD，即非广播情况，则创建一个match匹配规则，并将其与上述动作一起写入交换机的流表项中。如果此时消息的 buffer_id 不为空，也就是已经存在缓存了，直接通过 self.add_flow() 函数来发送一个表示 flow mod 操作的操作给交换机。如果消息的 buffer_id 为空，即没有缓存，那么设置 data = msg.data 代表将消息本身作为data变量传递下面的数据包处理，然后再发送一个出来的packet-out数据包。
5. 如果 buffer_id != ofproto.OFP_NO_BUFFER，表明交换机中已经包含了需要处理的缓存，并且已经发了对应的 flow mod 操作，这里就直接返回了。
6. 如果没有缓存，那么就生成一个 packet-out 消息。参数包括 datapath，buffer_id，in_port，actions，data。其中，buffer_id 表示数据包的ID，表示这是一个新的数据包，需要将缓存中的数据包发送出来，而不是在缓存中转发。
7. 最后，调用 datapath.send_msg(out) 将这个出来的 packet-out 或 flow mod 操作发送给交换机。

flow mod是什么？

        Flow mod 是 OpenFlow 协议中的一个消息类型，可以由交换机的控制器发送给交换机，用于增加、删除或修改交换机流表中的表项。当交换机收到 flow mod 消息时，会根据消息中所包含的匹配规则（match）、指令（instruction）、优先级等信息，在流表中增加、删除或更新对应的表项，以实现控制器下发的网络流量控制目的。

        Flow mod 消息中所含的信息包括：匹配规则用于匹配数据包的头部信息、指令用于数据包转发的规则、优先级用于确定交换机使用哪条流表规则进行数据包的处理、生存时间（idle timeout 和 hard timeout）等。

        Flow mod 消息在 OpenFlow 协议中起到了控制器对交换机的流量控制的作用。控制器可以通过发送 flow mod 消息，对交换机传输流量的细节进行精细控制以达到网络运营的目的。Flow mod 消息通常是通过控制器与交换机之间的 OpenFlow 连接发送的。