实验3：OpenFlow协议分析实践

实验3：OpenFlow协议分析实践
一、实验目的
能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；
能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。
二、实验环境
Ubuntu 20.04 Desktop amd64

三、实验要求
（一）基本要求
搭建下图所示拓扑，完成相关 IP 配置，并实现主机与主机之间的 IP 通信。用抓包软件获取控制器与交换机之间的通信数据。

主机 IP地址
h1 192.168.0.101/24
h2 192.168.0.102/24
h3 192.168.0.103/24
h4 192.168.0.104/24
查看抓包结果，分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图。
控制器6633端口（我最高能支持OpenFlow 1.0） ---> 交换机50846端口

交换机50846端口（我最高能支持OpenFlow 1.5） ---> 控制器6633端口

双方建立连接，使用OpenFlow1.0
Features Request：控制器向将交换机发送Featrues Request消息，获取交换机特征信息
控制器6633端口---> 交换机50846端口

Set Conig：控制器告诉交换机如何配置
控制器6633端口---> 交换机50846端口

Port_Status：当交换机端口发生变化时，告知控制器相应的端口状态
交换机50846端口--->控制器6633端口
第一次抓包未出现port，做完之后重新抓了一次，所以端口号发生了变化

Features Reply：Featrues Request的回复的交换机的特征信息
交换机50846端口---> 控制器6633端口

Packet_in：交换机收到数据包后问控制器如何处理
有两种情况会触发交换机向控制器发送 Packet-in 消息：
1.当交换机收到一个数据包后，查找流表。如果流表中有匹配条目，则交换机按照流表所指示的 action 列表处理数据包。如果没有，则交换机将数据包封装在 Packet-in 消息中发送给控制器处理，注意这时候数据包仍然会被放进缓冲区等待处理而不是被丢弃。
2.数据包在流表中有匹配的条目，但是其中所指示的 action 列表中包含转发给控制器的动作（Output = CONTROLLER），注意这时候数据包不会被放进缓冲区。

Flow_mod：分析抓取的flow_mod数据包，控制器向交换机下发流表项，指导数据的转发

因为第一遍的时候并没有执行PINGALL所以没有mod的信息，从新抓了一次所以端口号发生了变化。
Packet_out：告诉交换机将数据输出到交换机的哪个端口
控制器6633端口---> 交换机50846端口

回答问题：交换机与控制器建立通信时是使用TCP协议还是UDP协议？
TCP协议

（三）实验报告
请用Markdown排版；
基础要求只需要提交导入到/home/用户名/学号/lab3/目录下的拓扑文件，wireshark抓包的结果截图和对应的文字说明；
进阶要求为选做，有完成的同学请提交相关截图对应的OpenFlow代码，加以注释说明，有完成比未完成的上机分数更高。
个人总结，包括但不限于实验难度、实验过程遇到的困难及解决办法，个人感想，不少于200字。
个人感想：
一定要先开启抓包再构建拓扑。通过抓包了解openflow协议中交换机与控制器的消息交互过程与机制。
与同学多沟通自己遇到的问题。