实验5：OpenFlow协议分析和OpenDaylight安装

一、实验目的

回顾JDK安装配置，了解OpenDaylight控制的安装，以及Mininet如何连接；通过抓包获取OpenFlow协议，验证OpenFlow协议和版本，了解协议内容。

二、实验任务

Mininet生成拓扑连接OpenDaylight，在Mininet上通过ping抓包验证OpenFlow1.3协议

三、实验步骤

1.实验环境

安装了Ubuntu 18.04.5 Desktop amd64的虚拟机

2.实验过程

（1）安装OpenDaylight控制器（提供两个版本）

由于OpenDaylight是基于Java运行的，因此需要先安装jdk 8环境（版本不宜过高）。

$ sudo mkdir /usr/local/java
$ sudo tar -zxvf jdk-8u211-linux-x64.tar.gz //需将 jdk 压缩包提前放在相应目录下
$ gedit ~/.bashrc

在文件末尾追加内容如下：(注意，不要加上开头的$和它后一个空格）

$ export JAVA_HOME=/usr/local/java/jdk1.8.0_211
$ 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 版本
$ tar -zxvf distribution-karaf-0.4.4-Beryllium-SR4.tar.gz //Beryllium 版本

运行 karaf（不能用超级权限）

$ ./distribution-karaf-0.6.4-Carbon/bin/karaf //Carbon 版本
$ ./distribution-karaf-0.4.4-Beryllium-SR4/bin/karaf  //Beryllium 版本

第一次启动需安装插件，这里两个版本开始有所区别
Carbon 版本

$ feature:install odl-restconf odl-l2switch-switch-ui odl-openflowplugin-flow-servicesui odl-mdsal-apidocs odl-dluxapps-applications

Beryllium 版本

$ feature:install odl-restconf odl-l2switch-switch-ui odl-openflowplugin-all odl-mdsalapidocs odl-dlux-core odl-dlux-node odl-dlux-yangui

至此 ODL 控制器启动完毕（本例中使用的是碳版本）

（2）启动Mininet虚拟机，生成一个最简拓扑并连接OpenDaylight

连接前应确认Mininet和OpenDaylight的网络互通，如果是安装在同一台虚拟机上，那么可以忽略。
运行命令生成拓扑并连接控制器：

$ sudo mn --switch ovs,protocols=OpenFlow13 --controller=remote,ip=[此处填入控制器所在虚拟机的 IP],port=6633

本例中，我的虚拟机IP地址为127.0.0.1。若不清楚自己虚拟机的IP地址，可以通过在终端里输入ifconfig命令来查看，通过ping命令来测试连通性。

（3）Wireshark抓包分析OpenFlow1.3

sudo wireshark命令开启wireshark，选择any，抓取所有数据包。
为了能够抓到控制器和交换机最初的交互，应在Mininet拓扑创建前开启抓包。
查看抓包结果，利用openflow_v4过滤出OpenFlow1.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等信息可以上面的抓包能够对应上。

如果wireshark未安装，那么执行下面的命令安装。

$ sudo apt-get install wireshark

四、总结

这次实验较为麻烦，主要还是因为对下载安装包以及如何安装不了解，实验中的要在终端中输入的命令也大多较长，导致一不小心就容易输错，还不好发现= =
通过本次实验，可以进一步了解在SDN架构下，基于OpenFlow协议的控制器与交换机之间是如何交流的，在交换机进行转发的过程中，控制器会指示交换机如何处理“新的”数据包。

提示：下载链接
（1）jdk 8（需要 Oracle 账号）
https://www.oracle.com/java/technologies/javase-downloads.html

（2）OpenDaylight（建议下载 Carbon，碳版本）
https://nexus.opendaylight.org/content/repositories/public/org/opendaylight/integration/distribution-karaf/