标签:out art net 开始 地址 优先 png inf request
参考:https://blog.csdn.net/caiqiiqi/article/details/79698143
一、实验步骤
1、创建拓扑
参数说明:
--controller 自己指定一个控制器,一般用remote指定远程控制器。还可以用--ip 与 --port 指定地址和端口号
--mac 自动设置mac地址,并让其从小到大排列
--switch 设置交换机的类型。交换机分为内核型(lxbr),用户型(user),OVS型(ovsk,ovsbr,ivs)。内核型和OVS型比用户型吞吐量大的多,常被选用。
-x 打开所有节点的终端
2、设置交换机s1上的OpenFlow版本并查看流表
3、执行ryu控制器
参数说明:
--verbose:显示调试信息
ryu.app.simple_switch_13为提供了传统2层交换机策略的组件。其他组件见下图
调试信息中,
EVENT ofp_event->SimpleSwitch13 EventOFPSwitchFeatures
switch features ev version=0x4,msg_type=0x6,msg_len=0x20,xid=0x99ea8d54,OFPSwitchFeatures(auxiliary_id=0,capabilities=79,datapath_id=1,n_buffers=256,n_tables=254)
这里是获取交换机的特征的过程,会在其他随笔里具体分析。
对以上几个字段分析:
在ryu/ryu/lib/packet/openflow.py 可查看基本属性的意义。
在ryu/ryu/ofproto/ofproto_v1_3.py可查看各类型的值的意义。
属性 | 值 | 意义 |
version | 0x4 | OpenFlow1.3版本 |
msg_type | 0x6 |
这是OPEN_FEATURE_REPLY报文 |
msg_len | 0x20 | 报文长度 |
xid | 0x99ea8d54 | 交互的编号 |
4、查看交换机s1流表,发现多了一条Table-miss的流表项。
存在时长11秒,表号为0,匹配数据包22个,匹配字节数1764B,优先级为0(最低),动作为发送到控制器,65535表示不缓存数据包(OFP_NO_BUFFER)。
5、用h1 ping h2,并用wireshark抓包详细过程
1). h1 -> ff:ff:ff:ff:ff:ff(广播) ARP Request, 查询h2的MAC地址;
2). h2-> h1 ARP Reply, 响应h2的MAC地址;
3). h1-> h2 ICMP echo request;
4). h2-> h1 ICMP echo reply
(1)h1 发送ARP请求报文,源mac为h1mac,目的mac为ffffffffffff,交换机未匹配到流表项,向控制器发送Packet_In报文(编号1440)。
(2)控制器将入端口1与h1的mac地址绑定,并回复Packet_Out报文给交换机,让其执行FLOOD(泛洪)操作,交换机向除了入端口以外的端口泛洪ARP请求报文(编号1441)。
(3)h2接收到ARP请求报文,回复ARP应答报文,源mac为h2mac,目的mac为h1mac,交换机未匹配到流表项,向控制器发送Packet_In报文(编号1446).
(4)控制器将入端口2与h2的mac地址绑定,再看交换机送来的数据包,发现源mac(h2mac)和目的mac(h1mac)都已经和入端口绑定,所以可以下发一条流表项(Flow_Mod报文):
FlowEntry1:源地址:h2mac,目的地址:h1mac,动作:output 1 (从端口1发出)(编号1447)
(5)h1收到ARP应答报文后,开始向h2发送ICMP请求数据包,数据包发送至交换机时,交换机s1未匹配到流表项,向控制器发送Packet_In报文。(编号1450)
(6)控制器查看交换机发来的数据包,发现源mac(h1mac)和目的mac(h2mac)都已经和入端口绑定,所以可以下发一条流表项(Flow_Mod报文):
FlowEntry2:源地址:h1mac,目的地址:h2mac,动作:output 2 (从端口2发出)(编号1451)
(7)交换机按流表项转发ICMP请求/应答数据包,ping过程顺利完成。
6、查看交换机流表项和控制器日志
交换机多了2条流表项,源mac地址分别为h1和h2,目的mac为h2和h1,优先级为1,入端口分别为1和2,动作分别为从2/1端口发出,这也就是由ping生成的流表项。第二条流表项匹配数据包数比第一条少1的原因是h1一开始发的ARP请求是广播形式,所以dst_mac为ff:ff:ff:ff:ff:ff,而不是00:00:00:00:00:01。
同样,在控制器的Log日志里也写明了触发了多次Packet_In事件,由上述的分析说明最后3次Packet_In事件是由这次ping触发的,第一次为 h1的ARP请求报文触发的,第二次由ARP回复报文触发的,第三次是h1给h2发送ICMP请求报文触发的。
标签:out art net 开始 地址 优先 png inf request
原文地址:https://www.cnblogs.com/kl107/p/13138568.html