實驗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

有兩種情況：

1. 交換機查找流表，發現沒有匹配條目,但是這種包沒有抓到過
   

2. 有匹配條目,對應的action是OUTPUT=CONTROLLER,固定收到向控制器發送包

7、PACKET_OUT

8、FLOW_MOD

實驗總結

• 本次實驗其實并沒有想前兩次實驗那樣有明顯的難點，主要的困難之處在于操作十分的繁瑣，而且必須很嚴謹地按照實驗手冊PDF上寫的那樣做：先打開wireshark，之后才打開拓撲程序進行捕捉。一開始我是先打開了拓撲再打開wireshark捕獲，結果不出所料地沒有捕捉到hello等數據包。
• 做這個實驗的時候也有看一看其他同學是怎么做的，我發現找源碼這一步可以直接利用系統就已經提供的查找功能，這樣會更加便捷一些。
• 總的來說，本次實驗幫助我了解 Wireshark 抓包流程與 OpenFlow 協議的報文結構，讓我熟悉了如何運用報文信息對使用 OpenFlow 協議通信的過程進行分析。