Ryubook_1_switch_hub_部署执行

一、环境：

mininet、ovs、Ryu。

二、实验过程：

1、搭建拓扑：

执行sudo mn --topo single,3 --mac --switch ovsk --controller remote -x创建拓扑。

执行后会启动5个Xterm窗口分别对应3个主机、一个交换机和一个控制器。

首先看一下ovs的状态，在ovs的xterm中执行命令ovs-vsctl show和命令ovs-dpctl show。

设置Openflow的版本为1.3。

查看空流表。ovs-ofctl命令需要指定openflow的版本，默认为1.0。

2、执行switching hub：

执行命令：ryu-manager --verbose ryu.app.example_switch_13

此时，控制器连接到交换机并且已经handshake，添加Table-miss flow entry到流表，控制器处于等待Packet-in的状态。

查看Table-miss flow entry：

　　　　action指定为CONTROLLER，传输数据长度指定为65535(0xffff=OFPCML_NO_BUFFER)。

3、执行ping命令，查看操作：

首先在各host上执行：tcpdump -en -i hx-eth0。如host1：tcpdump -en -i h1-eth0。用于查看host上发送接收的数据包。

在mininet控制台执行：h1 ping -c1 h2。

首先，查看交换机的流表：ovs-ofctl -O openflow13 dump-flows s1

可以看到，除了Table-miss flow entry，有多了两条流表项：

　　1.接收端口(in_port)：2，目的MAC(dl_dst)：host1，actions：传输到端口1；

　　2.接收端口(in_port)：1，目的MAC(dl_dst)：host2，actions：传输到端口2；

第(1)条entry，使用了2次，因为host2的ARP reply和ICMP echo reply都能匹配到这个表项。

第(2)条entry，使用了1次，因为host1的ARP request是广播的，只有ICMP echo request都能匹配到这个表项。

然后，查看控制器：

第1个Packet-in由h1广播的ARP request引起，控制器学习h1的MAC地址，没有流表项下发，但是有Packet-out message发出。

第2个Packet-in由h2发往h1的ARP reply引起，此时下发流表项(前文中的第(1)条流表项)。

第3个Packet-in由h1发往h2的ICMP echo request引起，此时下发流表项(前文中的第(2)条流表项)。

当h2向h1发送ICMP echo reply时，能匹配上第(1)条流表项，因而不会引起Packet-in。

最后，查看每个host发送接收到的数据包：

h1：

h2：

h3：

host上发送接收的数据包信息很明白。

三、总结：

这个实验展示了实现Ryu app的基本步骤，以及通过OpenFlow使用简单的方法来控制OpenFlow switch。