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。
最新文章
- 我所了解的meta
- MVC中你必须知道的13个扩展点
- Python入门笔记(20):Python函数(3):关于lambda
- python练习程序(c100经典例19)
- Giraph之SSSP(shortest path)单机伪分布运行成功
- NSarray 赋值 拷贝 等问题记录
- Servlet &; JSP - 中文字符问题
- 多线程与网络之SDWebImage和NSCache
- HDOJ/HDU 5686 Problem B(斐波拉契+大数~)
- zoj 1760 floyd构图+Dinic最大流
- Android中的SQLiteOpenHelper类
- Swift - 类型属性(类静态属性)和类方法(类静态方法)
- 什么是dtd文件,为什么需要
- Redis客户端管理工具,状态监控工具
- C#设计模式(11)——装饰者模式
- spring中获取dao或对象中方法的实例化对象
- Application.Current的使用
- Day5-----------------------系统监控
- UNITY优化资料收集
- 在ubuntu16.04编译安装httperf