2021 SDN實驗6：開源控制器實踐——RYU
實驗6：開源控制器實踐——RYU
一、實驗目的
- 能夠獨立部署RYU控制器；
- 能夠理解RYU控制器實現軟體定義的集線器原理；
- 能夠理解RYU控制器實現軟體定義的交換機原理。
二、實驗環境
- 下載虛擬機器軟體Oracle VisualBox或VMware；
- 在虛擬機器中安裝Ubuntu 20.04 Desktop amd64，並完整安裝Mininet；
三、實驗要求
（一）基本要求
-
完成Ryu控制器的安裝。
-
搭建下圖所示SDN拓撲，協議使用Open Flow 1.0，並連線Ryu控制器。
-
通過Ryu的圖形介面檢視網路拓撲。
-
閱讀Ryu文件的The First Application一節，執行並使用 tcpdump 驗證L2Switch，分析和POX的Hub模組有何不同。
·L2Switch.py程式碼
from ryu.base import app_manager from ryu.controller import ofp_event from ryu.controller.handler import MAIN_DISPATCHER from ryu.controller.handler import set_ev_cls from ryu.ofproto import ofproto_v1_0 class L2Switch(app_manager.RyuApp): OFP_VERSIONS = [ofproto_v1_0.OFP_VERSION] def __init__(self, *args, **kwargs): super(L2Switch, self).__init__(*args, **kwargs) @set_ev_cls(ofp_event.EventOFPPacketIn, MAIN_DISPATCHER) def packet_in_handler(self, ev): msg = ev.msg dp = msg.datapath ofp = dp.ofproto ofp_parser = dp.ofproto_parser actions = [ofp_parser.OFPActionOutput(ofp.OFPP_FLOOD)] data = None if msg.buffer_id == ofp.OFP_NO_BUFFER: data = msg.data out = ofp_parser.OFPPacketOut( datapath=dp, buffer_id=msg.buffer_id, in_port=msg.in_port, actions=actions, data = data) dp.send_msg(out)
· 命令ryu-manager L2Switch.py執行。
· h1 ping h2
· h1 ping h3
· 根據上方兩張截圖中的結果，與POX的Hub模組相比的區別是：
Hub和L2Switch實現的都是洪泛傳送ICMP報文，比如當h1 ping h2時，h1傳送給h2的ICMP報文，h3也會收到，但L2Switch下發的流表無法檢視，而Hub可以檢視。
（二）進階要求
·閱讀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) # 定義儲存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)<details>
回答以下問題：
a)程式碼當中的mac_to_port的作用是什麼
mac_to_port是一個儲存(交換機id, mac地址)到轉發埠的對映。
b)simple_switch和simple_switch_13在dpid的輸出上有何不同？
simple_switch的dpid賦值：dpid = datapath.id
simple_switch_13的dpid賦值：dpid = format(datapath.id, "d").zfill(16)
可以看出，simple_switch直接獲取的id，而simple_switch_13，會在前端加上0將其填充至16位
c)相比simple_switch，simple_switch_13增加的switch_feature_handler實現了什麼功能？
實現交換機以特性應答訊息響應特性請求。
d)simple_switch_13是如何實現流規則下發的？
在接收到packetin事件後，首先獲取包學習，交換機資訊，乙太網資訊，協議資訊等。如果乙太網型別是LLDP型別，則不予處理。如果不是，則獲取源埠目的埠，以及交換機id，先學習源地址對應的交換機的入埠，再檢視是否已經學習目的mac地址，如果沒有則進行洪泛轉發。如果學習過該mac地址，則檢視是否有buffer_id，如果有的話，則在新增流動作時加上buffer_id，向交換機發送流表。
e)switch_features_handler和_packet_in_handler兩個事件在傳送流規則的優先順序上有何不同？
switch_features_handler下發流表的優先順序比_packet_in_handler高
原因：switch_features_handler是在交換機處於協商版本併發送FEATURE-REQUEST報文狀態時呼叫的，而_packet_in_handler是在已收到FEATURE-REPLY報文併發送SET-CONFIG報文時被呼叫的。
（三）實驗報告
⚪ 實驗難度：
適中。這次的實驗的部分內容在上次實驗都已經做過了，因此做起來不是很困難，但進階部分難度較高。
⚪ 遇到的問題及解決辦法
· 問題1：ryu-manager ryu/ryu/app/gui_topology/gui_topology.py --observe-links，報錯，無法在網頁中開啟視覺化拓撲。
· 解決：看了幾眼命令，發現我的終端在031902210/ryu開啟，此時需要用相對路徑，路徑修改為"./ryu/app/gui_topology/gui_topology.py"便可以順利開啟檢視視覺化拓撲。
· 問題2：在完成進階要求中的程式碼註釋時遇到了困難，很多地方看的不是很懂。
· 檢視官方文件、搜尋相關資料和同學完成註解，有了一定理解後，完成了註釋。
⚪ 收穫感想：
做過了實驗五後，在完成實驗六的基礎要求就比較得心應手，二者連線控制器以及驗證的過程差別不大。通過本次實驗我能夠部署RYU控制器，順利開啟ryu的視覺化圖形介面，此外也進一步熟悉了之前tcpdump命令的用法，同時通過進階要求對simple_switch_13有了一點了解。對於本次實驗，最重要的還是瞭解到Hub和L2Switch的區別就在於下發流表是否可以檢視，希望可以在之後的實驗中能夠更加深入地理解到它們的區別，有機會的話會加以使用