實驗6:開源控制器實踐——RYU
阿新 • • 發佈:2021-10-10
實驗6:開源控制器實踐——RYU
安裝截圖
拓撲視覺化
tcpdump檢視
h1 ping h2
h1 ping h3
可以看到均為洪泛轉發
檢視控制器流表,如下圖:
看到沒有流表,而使用pox的hub模組則會看到流表,如下圖:
所以可以看到二者都是洪泛轉發,但是不同之處在於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位
相比simple_switch,simple_switch_13增加的switch_feature_handler實現了什麼功能?
實現交換機以特性應答訊息響應特性請求,可檢視文件
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協議的理解有一定的要求,但是做完實驗後感受到收穫頗多,學習到了更多的知識。