软件定义网络实验 5：OpenFlow 协议分析和 OpenDaylight 安装
一、实验目的
回顾 JDK 安装配置，了解 OpenDaylight 控制的安装，以及 Mininet 如何连接；通过抓包获取 OpenFlow 协议，验证 OpenFlow 协议和版本，了解协议内容。
二、实验任务
Mininet 生成拓扑连接 OpenDaylight，在 Mininet 上通过 ping 抓包验证 OpenFlow 1.3 协议
三、实验步骤
1. 实验环境
安装了 Ubuntu 16.04.7 Desktop AMD64 的虚拟机
2. 实验过程
（1）安装 OpenDaylight 控制器（提供两个版本）
-
由于 OpenDaylight 是基于 Java 运行的，因此需要先安装 JDK 8 环境（版本不宜过高）。
$ sudo mkdir /usr/local/java $ sudo mv jdk-8u261-linux-x64.tar.gz /usr/local/java $ cd /usr/local/java $ sudo tar -zxvf jdk-8u261-linux-x64.tar.gz //需将 jdk 压缩包提前放在相应目录下 $ gedit ~/.bashrc -
在文件末尾追加内容如下：
export JAVA_HOME=/usr/local/java/jdk1.8.0_261 export JRE_HOME=${JAVA_HOME}/jre export CLASSPATH=.:${JAVA_HOME}/lib:${JRE_HOME}/lib export PATH=${JAVA_HOME}/bin:$PATH注：写入文件每行开头不需要 $ 符号。
保存退出，然后运行命令：
$ source ~/.bashrc $ java -version //验证安装版本
-
解压安装
$ tar -zxvf distribution-karaf-0.6.4-Carbon.tar.gz //Carbon 版本 -
运行 karaf（不能用超级权限）
$ ./distribution-karaf-0.6.4-Carbon/bin/karaf //Carbon 版本
-
第一次启动需安装插件，这里给出 Carbon 版本
$ feature:install odl-restconf odl-l2switch-switch-ui odl-openflowplugin-flow-services-ui odl-mdsal-apidocs odl-dluxapps-applications注：该步部分 PDF 软件直接复制下来有的连接符会消失或变为空格，执行后会报类似错误，注意核对
Error executing command: Can't install feature odl-openflowplugin-flow-servicesui/0.0.0: null
（2）启动 Mininet 虚拟机，生成一个最简拓扑并连接 OpenDaylight
为了能够抓到控制器和交换机最初的交互，应在 Mininet 拓扑创建前开启抓包。
连接前应确认 Mininet 和 OpenDaylight 的网络互通，如果是安装在同一台虚拟机上，那么可以忽略。
运行命令生成拓扑并连接控制器：
$ sudo mn --switch ovs,protocols=OpenFlow13 --controller=remote,ip=192.168.75.132,port=6633
注：IP 地址可以用 ifconfig 命令获得。用本地环回地址 127.0.0.1 也可以。
（3）Wireshark 抓包分析 OpenFlow 1.3
sudo wireshark 命令开启 wireshark，选择 any，抓取所有数据包。
查看抓包结果，利用 openflow_v4 过滤出 OpenFlow 1.3 协议，可以看到 OpenFlow 协议下，交换机和控制器的交互过程。
-
HELLO——控制器与交换机互相发送 Hello 消息，告诉对方自己能够支持的 OpenFlow 版本，向下兼容双方都能够兼容的版本，建立后续的通信。
-
FEATURES_REQUEST——控制器向交换机要求特征信息。
-
FEATURES_REPLY——交换机会送特征信息。
-
SET CONFIG——控制器向交换机下发两个配置，一个是 flags，指示如何处理 IP 分片；另一个是 Miss send length，指示交换机遇到无法处理的数据包时， 向控制器发送消息的最大字节数。
-
PACKET IN——交换机查找流表，发现没有匹配条目时，或有匹配条目但是对应的 action 是 OUTPUT=CONTROLLER 时，向控制器发送消息 PACKET IN 消息，前者数据包会被放到交换机缓存中等待处理，后者不会。
-
PACKET OUT 和 FLOW MOD——控制器接收到交换机 PACKET IN 消息后的响应方式有两种，FLOW MOD 下发流表，告知交换机匹配项（MATCH）和对应的动作（ACTION），去处理这一类数据包；PACKET OUT 不下发流表，直接告知交换机如何处理这一个数据包。
下面的 PACKET OUT 有两个动作，对控制器来的消息转发到 1 和 2 端口
下面的 FLOW MOD 下发了两条流表，Cookie 不一样
用 OVS 命令查看交换机中确实存在相应版本的流表，cookie、priority 等信息跟上面的抓包能够对应上。
$ sudo ovs-ofctl dump-flows s1 -O OpenFlow13
四、实验要求
（已在实验步骤中体现）
-
根据实验步骤重复上述实验。
-
在博客园发表一篇博客，记录最终的结果、实验过程遇到的问题和解决办法。
五、实验总结
本次实验为重复性实验，总体不是很难。（可能安装包的下载最难吧……不做特殊操作超级慢）通过这次实验了解到了 OpenDaylight 控制器，虽然还不知道怎么用，不过大概查了一下相关资料知道了它的用途。Wireshark 抓包软件上学期学计算机网络时就听说了，这回终于用上了，图形化界面很容易上手。几种 OpenFlow 包的内容都大致看了一遍，对 OpenFlow 协议更熟悉了一些。
