SDN第六次实验
(一)
ryu –version
h1 ping h2
h1 ping h3
Ryu L2Switch与POX的 Hub模块不同:
分析:L2 Switch模块和POX的hub无太大区别,都是使用OFPP_FLOOD标记让数据包向所有端口发送,本质是集线器
交换机(Hub)基于mac地址识别,能完成封装转发数据功能的设备;集线器(Switch)采用广播的形式传输数据,即向所有端口传送数据。
https://blog.csdn.net/hardlearn/article/details/73650529
(二)进阶
simple_switch13的源代码与注释
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] #标注版本号为1.3
def __init__(self, *args, **kwargs): # 初始化类
super(SimpleSwitch13, self).__init__(*args, **kwargs)
self.mac_to_port = {} # 初始化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 # 用packet library分析收到的数据包
dpid = format(datapath.id, "d").zfill(16)# 获得Datapath ID以便于识别OpenFlow交换机
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.
# 记录mac地址以避免下次的消息范洪
self.mac_to_port[dpid][src] = in_port
if dst in self.mac_to_port[dpid]: # 如果目标Mac地址已经被学习了,决定哪个从哪个端口发送数据包。否则范洪
out_port = self.mac_to_port[dpid][dst]
else:
out_port = ofproto.OFPP_FLOOD
actions = [parser.OFPActionOutput(out_port)] #构造action表
# install a flow to avoid packet_in next time
# 安装流表以避免下次pactet_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:
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
# 构造一个pack_out消息然后发送
out = parser.OFPPacketOut(datapath=datapath, buffer_id=msg.buffer_id,
in_port=in_port, actions=actions, data=data)
datapath.send_msg(out)
a) 代码当中的mac_to_port的作用是什么?
答:记录mac地址以避免下次的消息Flood
b) simple_switch和simple_switch_13在dpid的输出上有何不同?
答:simple_switch_13对dpid进行了格式化,并填充为16位数字
c) 相比simple_switch,simple_switch_13增加的switch_feature_handler实现了什么功能?
答:安装无目标的流表条目
d) simple_switch_13是如何实现流规则下发的?
答:构造一个flow_mod消息并发送
e) switch_features_handler和_packet_in_handler两个事件在发送流规则的优先级上有何不同
答:switch_features_handler发送的priority=0,_packet_in_handler发送的流表的priority设置为1
https://osrg.github.io/ryu-book/zh_tw/html/switching_hub.html
https://blog.csdn.net/weixin_42094589/article/details/104160571
https://blog.csdn.net/weixin_46239293/article/details/115560411
https://github.com/faucetsdn/ryu/blob/master/ryu/app/simple_switch_13.py
http://osrg.github.io/ryu-book/en/html/switching_hub.html#execution-of-ryu-application
(三) 心得
此次实验也较为简单,只要安装好ryu,使用vim编辑器写好L2Switch.py并运行就可以。其他步骤和pox的验证一样。这次重点看了一些RYU源码解读通过老师提供的参考文件以及自我搜索和实践更多的了解到了ryu。尤其是进阶学习中的simple_switch_13.py为例, 完成其代码的注释工作。也尝试了启动控制器,利用Web图形界面查看网络拓扑(默认web端口8080): ryu-manager ryu/ryu/app/gui_topology/gui_topology.py --observe-links等等。并且下载了ryu的帮助文档等等https://ryu.readthedocs.io/en/latest/index.html https://github.com/faucetsdn/ryu 进阶狠狠借鉴和学习了同学的代码哈哈哈哈,下次再接再厉!