OpenDaylight下发流表

实验一：单流表（v1.0）

下发流表实现h1和h2之间不能互通。

1、启动OpenDaylight

./karaf

查看6633端口是否处于监听状态

netstat -an | grep 6633

在物理机浏览器中访问虚拟机ip:8181/index.html登录OpenDaylight网页端。

账号密码都是admin。

后面做实验的时候，出现过无法登录的情况，点击登录后，提示无法登录，重启也没用。后来发现，多等一会儿就能登录上了。

需要注意的是，ODL资源开销比较大，我2G内存的虚拟机，ODL就占用了60%多的内存。

后来把虚拟机内存调到4G，启动ODL的速度明显变快了。

2、创建拓扑

重新打开一个终端，使用Mininet创建拓扑，并指定控制器为OpenDaylight1.0的控制器

mn --topo=single,3 --controller=remote,ip=127.0.0.1,port=6633 --switch ovsk,protocol=OpenFlow10

注意：OpenFlow10需区分大小写，不能写成openflow10

在浏览器中刷新OpenDaylight的界面，查看是否出现了交换机。

在Mininet交互界面中输入pingall，再次刷新OpenDaylight界面，出现了三台主机。

3、定义流表

在浏览器中访问OpenDaylight的Nodes页面，查看Node ID。记住这个Node ID。openflow:1

打开Yang UI界面，展开opendaylight-inventory rev.2013-08-19

补全node id。node id就是刚才Nodes页面要记住的那个ID。

openflow:1

添加流表

输入table id。由于是单流表，只有一个表项，所以就填0。

定义流策略

以太帧中type字段值为0x0800表示上层协议使用的是IP协议。（下图中写成了0x800，不过也不影响）

h1到h2的流，源IP为h1的IP：10.0.0.1，目的IP为h2的IP：10.0.0.2。

往下滑~

定义流行为

继续往下滑~

设置优先级，超时时间等参数

将cookie设置为10进制的10，待会再mininet中查看流表时，cookie=0xa的那条流表就是现在编辑的这条流表。

下发流表

回到上方url板块，将动作类型更改为PUT，点击Send使用put方式下发流表。

下方出现这样的提示表示下发成功

在Mininet交互界面查看流表是否已下发

dpctl dump-flows
# 或
sh ovs-ofctl dump-flows s1

寻找cookie=0xa或优先级priority=10的流表，可以看到刚刚下方的流表已经下发成功了。

验证流表是否生效

使用h1 ping h2不通，其他主机之间能够互通，流表生效。

4、删除流表

一定要记得把流表删除，不然以后做实验时，流表可能还在，影响做实验。

# 删除流表
sh ovs-ofctl del-flows s1 dl_type=0x0800,nw_src=10.0.0.1,nw_dst=10.0.0.2
# 查看流表
sh ovs-ofctl dump-flows s1

再次测试连通性，h1和h2之间连通。

实验环境不要关，可以接着做下一个实验。

实验二：多级流表（v1.3）

下发多级流表实现h1和h2之间不能互通。

1、创建topo

基于Open Flow v1.3下发多级流表。

如果第一个实验还没关，可以继续使用。（记得注意检查一下三台主机是否能ping通，我做实验时，将流表删除了，后面这条流表又自己出现了）

在mininet交互界面直接更改Open Flow的版本。

sh ovs-vsctl set bridge s1 protocols=OpenFlow13

如果是重新开始，就先启动ODL，登录到web端，再使用以下命令创建一个topo。

mn --topo=single,3 --controller=remote,ip=127.0.0.1,port=6633 --switch ovsk,protocol=OpenFlow13

2、下发第一条流表

打开Yang UI界面，展开opendaylight-inventory rev.2013-08-19。

与单流表不同，到table时，需要再展开一层，到达flow。

补全node id和table id。node id仍然与实验一中查询到的node id相同。table id设置为2。

# node-id
openflow:1
# table-id
2

添加流表

设置flow id为1。

源IP为h1的IP，目的IP为h3的IP。

往下滑

继续往下滑，滑到底

cookie设置为11，待会查看流表时，该条流表的cookie=0xb。

下发流表

查看下发的流表

由于OpenFlow协议版本改为了1.3所以命令也需要做一些调整

sh ovs-ofctl -O OpenFlow13  dump-flows s1

测试连通性，都能ping通，原因再书上P119页步骤12中有解释。还需要再下发一条流表。将table 0匹配到的流表交给table2处理。

3、下发第二条流表

第二条流表与第一条流表类似。

table id设置为0，flow id设置为1.

注意，这里与第一个流表不同。

滑到最下面

下发流表

查看流表

sh ovs-ofctl -O OpenFlow13  dump-flows s1

测试连通性，1，3不通，其他都同，说明流表生效。

实验完成，删除流表，以免影响后续实验。

sh ovs-ofctl -O OpenFlow13 del-flows s1

推出mininet交互界面，清楚缓存

mn -c

问题

问题一：Mininet拓扑创建不成功

创建Mininet拓扑不成功，提示有一个控制器已经在端口6653上运行

解决方法：

# 查看占用6653端口的进程
netstat -tulnp | grep :6653
# 停止该进程
kill -9 进程号
# 清理Mininet残留
mn -c

问题二：无法连接控制器

重新打开一个终端，查看网桥是否已经连接上了控制器。

ovs-vsctl show

由于当时没连接成功的时候忘记做记录了，这次做实验没有遇到。哪次遇到了再补充。

删除控制器，再重新设置。

root@UbuntuDesktop:~# ovs-vsctl del-controller s1
root@UbuntuDesktop:~# ovs-vsctl show

再次在浏览器中查看拓扑图中是否显示了交换机s1。出现下图中的is_connected:true字样则表示连接成功。

在Mininet交互界面执行pingall命令后，各主机之间互通，浏览器中显示出拓扑图。

问题三：新创建的topo无法ping通

新创建的topo，控制器也链接成功了，但是ping不通。

又ping了一次，发现是只有h1和h2ping不通。估计是上次做的单流表实验的缓存还在。

通过sh ovs-ofctl dump-flows s1查看流表。发现确实是上次做的流表内容还在。

下面这条cookie=0xa，就是做单流表实验时最后设置的那个cokie值，设置为10进制的10，这里以16进制显示为0xa。（源为10.0.0.1，目的为10.0.0.2，动作为阻止drop）

cookie=0xa, duration=1432.332s, table=0, n_packets=4, n_bytes=392, idle_age=472, priority=27,ip,nw_src=10.0.0.1,nw_dst=10.0.0.2 actions=drop

删除这条流表就行了。

# 删除指定流表
sh ovs-ofctl del-flows s1 "cookie=0xa/0xffffffff, priority=27, ip, nw_src=10.0.0.1, nw_dst=10.0.0.2"

• cookie=0xa/0xffffffff 用来确保只删除具有特定cookie值的流表项。0xffffffff是掩码，它确保了我们只匹配这个确切的cookie值。
• priority=27, ip, nw_src=10.0.0.1, nw_dst=10.0.0.2 指定了其他匹配条件，以确保仅删除这条流表项。

千万不要为了方便，直接这样删除。

sh ovs-ofctl del-flows s1 "nw_src=10.0.0.1,nw_dst=10.0.0.2"

其他的流表也被匹配到了，一并删除了。

不过好在，重新ping了一遍，流表由自动生成了。

问题四：做完实验一后，做实验二时，莫名奇妙多出一条流表

做完实验一接着做实验二，实验二下发第一条流表的时候，发现第一个实验的流表又冒出来了，导致h1和h2不通。

再把它删掉，不过因为协议该为了1.3所以，命令也有些改变。删除后就能ping通了

sh ovs-ofctl -O OpenFlow13 del-flows s1 dl_type=0x0800,nw_src=10.0.0.1,nw_dst=10.0.0.2