SDN第三次实验
实验3：OpenFlow协议分析实践
实验目的
- 能够运用 wireshark 对 OpenFlow 协议数据交互过程进行抓包；
- 能够借助包解析工具，分析与解释 OpenFlow协议的数据包交互过程与机制。
实验要求
（1）基本要求
搭建拓扑，完成相关 IP 配置
（2）查看抓包结果
- HELLO
控制器6633端口（我最高能支持OpenFlow 1.0） ---> 交换机42530端口
交换机42530端口（我最高能支持OpenFlow 1.6） ---> 控制器6633端口
于是双方建立连接，并使用OpenFlow 1.0
- FEATURES_REQUEST
控制器6633端口（我需要你的特征信息） ---> 交换机42530端口
- SET_CONFIG
控制器6633端口（请按照我给你的flag和max bytes of packet进行配置） ---> 交换机42530端口
- PORT_STATUS
当交换机端口发生变化时，告知控制器相应的端口状态。
- FEATURES_REPLY
交换机42530端口（这是我的特征信息，请查收） ---> 控制器6633端口
- PACKET_IN
交换机42530端口（有数据包进来，请指示）--->控制器6633端口
- PACKET_OUT
控制器6633端口--->交换机42530端口（请按照我给你的action进行处理）
- FLOW_MOD
分析抓取的flow_mod数据包，控制器通过6633端口向交换机42530端口、交换机42530端口下发流表项，指导数据的转发处理
-
分析OpenFlow协议中交换机与控制器的消息交互过程，画出相关交互图或流程图
-
回答问题：交换机与控制器建立通信时是使用TCP协议还是UDP协议？
答：TCP协议，如下图所示
（3）进阶要求
将抓包基础要求第2步的抓包结果对照OpenFlow源码，了解OpenFlow主要消息类型对应的数据结构定义。
1、Hello
2、FEATURES_REQUEST
源码参数格式与HELLO的一致
3、SET CONFIG
4、PORT_STATUS
5、FEATURES_REPLY
6、PACKET_IN
有两种情况：
-
交换机查找流表，发现没有匹配条目,但是这种包没有抓到过
-
有匹配条目,对应的action是OUTPUT=CONTROLLER,固定收到向控制器发送包
7、PACKET_OUT
8、FLOW_MOD
实验总结
- 本次实验其实并没有想前两次实验那样有明显的难点，主要的困难之处在于操作十分的繁琐，而且必须很严谨地按照实验手册PDF上写的那样做：先打开wireshark，之后才打开拓扑程序进行捕捉。一开始我是先打开了拓扑再打开wireshark捕获，结果不出所料地没有捕捉到hello等数据包。
- 做这个实验的时候也有看一看其他同学是怎么做的，我发现找源码这一步可以直接利用系统就已经提供的查找功能，这样会更加便捷一些。
- 总的来说，本次实验帮助我了解 Wireshark 抓包流程与 OpenFlow 协议的报文结构，让我熟悉了如何运用报文信息对使用 OpenFlow 协议通信的过程进行分析。
