实验一：单流表（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
