在RYU中實現交換機的功能

首先源碼，解析部分如下，同時可以參考RYU_BOOK上的解釋說明

 原文鏈接參考：https://blog.csdn.net/qq_34099967/article/details/89047741

 

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-eth0tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on h1-eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

host2：

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

host3:

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

在miniet終端執行ping命令，host1向host2發送數據

 

確認過程如下：

 

ARP Request：此時host1並不知道host2的MAC地址，因此采用廣播的方式發送，因此host2和host3都會接收到這樣的信息。
 ARP Reply：host2使用ARP Reply回復host1的請求。
 ICMP echo request：host1已經知道了host2的MAC地址，因此發送echo request給host2.
 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廣播一條消息。
————————————————
版權聲明：本文為CSDN博主「菜地里翻滾的豬」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/qq_34099967/article/details/89047741