RYU控制器基本应用

Posted 2020-12-11 kl107

 

参考：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抓包详细过程

• h1 ping h2过程：

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请求报文触发的。