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。