在Ryu中实现交换器

                                           在Ryu实现交换器

OpenFlow交换器会接受来自于controller的指令并达到下列功能：

• 对于接收到的封包进行修改或针对指定的端口进行转发。
• 对于接收到的封包进行转发到Controller的动作（Packet-In）。
• 对于接收到的来自Controller的封包转送到指定端口（Packet-out）。

利用Packet-in功能达到Mac地址的学习。Controller使用Packet-In接受来自交换机的封包后进行分析，得到连接端口相关的资料和所连接的host的Mac地址。学习之后，将封包的目的地址，在已经学习的host资料中进行检索，根据检索结果进行以下处理：

• 如果是已经存在在记录中的host：使用packet-out功能转发到所对应的连接端口。
• 如果是尚未存在记录的host：使用packet-out功能来达到Flooding。

 

在Ryu安装文件的app目录下已经存在了交换器的程序源码：

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


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表示事件修饰符，任何一个OpenFlow讯息都会产生一个对应的事件，事件类别的名称规则为
\\ryu.controller.ofp_event.EventOFP+<OpenFlow讯息名称>
\\第二个参数表示交换机的状态。表示在CONFIG_DISPATCHER的交换机状态下，接收到交换机的\\SwitchFeatures讯息就会执行对应事件处理**_handle（）函数。
    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):
\\datapath是交换机实体
        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.
\\为交换机的流表新增Table-miss Flow Entry项，用于封包在无法匹配到流表项后与之匹配。
\\match表示匹配约束，为空则说明可以匹配所有封包。action表示匹配成功后执行的操作，此处 
\\为向Controller端口发送最大数据长度的封包。OFPCML_NO_BUFFER表示不需要在交换机上缓存封包
\\将封包整体发给controller。优先级为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):
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser
\\Entry的Instruction项，指定为output action中的动作，OFPIT_APPLY_ACTIONS表示动作立即执行
        inst = [parser.OFPInstructionActions(ofproto.OFPIT_APPLY_ACTIONS,
                                             actions)]
\\FlowMod讯息的类别为OFPFlowMod，使用FlowMod所产生的实体透过datapath.send_msg()来发送、、\\FlowMod讯息给OpenFlow交换机。
        mod = parser.OFPFlowMod(datapath=datapath, priority=priority,
                                match=match, instructions=inst)
        datapath.send_msg(mod)
\\交换机的一般状态下接收交换机的packet-In讯息所作处理
    @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER)
    def _packet_in_handler(self, ev):
        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]
\\获取目的和源Mac地址
        dst = eth.dst
        src = eth.src
\\获取OpenFlow交换器的标识ID
        dpid = datapath.id
        self.mac_to_port.setdefault(dpid, {})

        self.logger.info("packet in %s %s %s %s", dpid, src, dst, in_port)
\\每个datapath建立一个mac位址表，将host的mac地址与交换机对应的端口号进行映射。
        # learn a mac address to avoid FLOOD next time.
        self.mac_to_port[dpid][src] = in_port
\\判断目的Mac地址是否存在于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
\\添加交换机中的流表项
        if out_port != ofproto.OFPP_FLOOD:
            match = parser.OFPMatch(in_port=in_port, eth_dst=dst)
            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)

 

OpenFlow交换机的几种状态：

Features消息属于controller-switch消息，在交换机和控制器的交换通道建立后，控制器发送feature-request信息给交换机，交换机回复feature-reply信息，获取交换机支持的特性。

ofproto表示openflow版本对应的ofproto对应的ofproto module，代表常数模组，用来为通讯协定中的常数设定使用。

ofproto_parse表示解析模组，提供各个OpenFlow讯息的对应类别，定义了相关协议版本的消息封装格式。如ryu.ofproto.ofproto_v1_3_parser.OFPSwitchFeatures。

执行Ryu应用程序

使用Miniet构建拓扑，命令为：

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

创建三个主机一个交换机的拓扑

接下来在s1终端中查看OVS的配置信息，常用的OVS命令行工具指令如下：

接下来用ovs-vsctl show显示OVS数据库中的配置信息，ovs-dpctl查询流表的情况。另外务必设置交换机的openflow版本为1.3，

使用

ovs-vsctl set Bridge s1 protocols=OpenFlow13

然后在C0的xtem下启动ryu应用，使用命令

ryu-manager --verbose ryu.app.simple_switch_13

出现下述显示，则说明握手已经完成，Table-miss Flow entry项也应该加入到流表中

通过命令

ovs-ofctl -O openflow13 dump-flows s1

来查看openflow交换机中的流表情况，如下：

这条流表项在Featue reply消息的处理事件中被添加，将所有匹配该项的封包送往控制器端口。为接下来的packet-in事件作准备。65535代表重送资料的大小。

然后对每一个主机执行监听命令：

host1：

root@ryu-vm:~# tcpdump -en -i h1-eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

host2：

root@ryu-vm:~# tcpdump -en -i h2-eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

host3:

root@ryu-vm:~# tcpdump -en -i h3-eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on h3-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

在miniet终端执行ping命令，host1向host2发送数据

确认过程如下：

1. ARP Request：此时host1并不知道host2的MAC地址，因此采用广播的方式发送，因此host2和host3都会接收到这样的信息。
2. ARP Reply：host2使用ARP Reply回复host1的请求。
3. ICMP echo request：host1已经知道了host2的MAC地址，因此发送echo request给host2.
4. ICMP echo reply：host2此时也知道了host1的MAC地址，因此发送echo reply给host1.

 

至此实现了两次握手，流表中应新增两个流表项：

1.接收端口（in_port）：2，目的MAC地址（dl_dst）：host1-》action：从host1的绑定的端口1进行转发。

2.接收端口（in_port）：1，目的MAC地址（dl_dst）：host2-》action：从host2的绑定的端口2进行转发。

然后查看控制器端的输出：

第一个packet-in消息是host1发送的ARP Request，因为通过广播方式因此没有增加Flow Entry，发送Packet-out消息。

第二个packet是host2回复的ARP reply，目的地址为host1的Flow entry（1）被新增。

第三个packet是从host向host2发送echo request，会新增flow entry（2）.

host2向host1回复的echo reply消息会和flow entry（1）match，故直接转发封包到host1而不用发送packet-in。

综上flow entry（1）被匹配了两次，flow entry（2）被匹配一次。

可以看出两次握手的过程，前两次为ARP的请求和回复，后两次为ICMP echo的请求回复。

host3只收到了host1的ARP request广播一条消息。