一、环境：
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。