任務目的
1、瞭解OpenFlow交換機與OpenFlow控制器建立TCP連接的過程。
2、掌握配置安全通道中的OpenFlow版本的方法。
3、掌握OpenFlow交換機和OpenFlow控制器的消息交互流程。
任務環境
| 設備名稱 | 軟件環境（鏡像） | 硬件環境 |
|---|---|---|
| 控制器 | Ubuntu 14.04桌面版 Floodlight 1.0 |
CPU：1核 內存：2G 磁盤：20G |
| 主機 | Ubuntu 14.04桌面版 Mininet 2.2.0 |
CPU：1核 內存：2G 磁盤：20G |
注：系統默認的賬戶爲root/root@openlab，openlab/user@openlab。
任務內容
1、配置交換機與控制器，使其支持OpenFlow1.3。
2、分析消息包，掌握交換機與控制器的消息交互流程。
實驗原理
一、OpenFlow協議簡介
2006年，斯坦福大學Clean Slate計劃資助的Ethane項目開始部署，致力於企業網架構的創新，OpenFlow協議的雛形就誕生於這個項目。2008年，Nick McKeown教授的一篇重要論文“OpenFlow：Enabling Innovation in Campus Networks”使得OpenFlow正式進入人們的視野，繼而成爲了標準化組織ONF（Open Network Foundation，開放網絡基金會）主推的南向接口協議。經過多年的發展，OpenFlow現已成爲SDN的主流南向接口協議之一。目前，OpenFlow協議還在不斷地演進中，本實驗採用OpenFlow v1.3協議，並對控制器與OpenFlow交換機之間的交互過程進行深入分析。
OpenFlow主要有3種類型的消息，分別是Controller-to-Switch、Asynchronous和Symmetric，其中每個類型又包含多個子類型。Controller-to-Switch消息由控制器發起，用於管理、查看交換機的狀態。Asynchronous消息由交換機發起，向控制器彙報交換機的事件和改變。Symmetric消息由控制器或交換機任一方發起，無需請求直接發起消息。詳細信息如下表所示：
| 消息類型 | 消息例子 | 描述 |
|---|---|---|
| Controller-to-Switch | Packet_out Barrier Switch Configuration Switch Features Multipart |
控制器使用這些消息可以添加、修改或刪除流表項 查詢交換機的功能和統計 配置交換機 配置交換機端口屬性 將數據包發送出指定交換機端口 |
| Asynchronous（異步） | Error Packet_in Port Status Table Status Controller Role Status |
由交換機發起，發送消息給控制器 這些消息可以是沒有匹配交換機中任意流表項的數據包或數據包頭，因此需要發送給控制器進行處理 在流狀態、端口狀態改變，或者產生錯誤消息時，進行通知 |
| Symmetric（對稱） | Hello Echo Experimenter |
Hello消息在控制器與交換機建立連接過程中使用 Echo消息用來確定Controller-to-Switch連接的延時，驗證連接是否處於活躍狀態 Experimenter消息用於未來消息的擴展 |
二、OpenFlow連接建立交互流程
在OpenFlow1.3協議的情況下，控制器與OpenFlow交換機的消息完整交互流程如下：
1、 控制器與OpenFlow交換機通過TCP“三次握手”，建立有效的連接。其中，控制器一端的端口號爲6633。
2、 控制器與OpenFlow交換機之間相互發送Hello消息，用於協商雙方的OpenFlow版本號。在雙方支持的最高版本號不一致的情況下，協商的結果將以較低的OpenFlow版本爲準。如果雙方協商不一致，還會產生Error消息。
3、 控制器向OpenFlow交換機發送Features Request消息，請求OpenFlow交換機上傳自己的詳細參數。OpenFlow交換機收到請求後，向控制器發送Features Reply消息，詳細彙報自身參數，包括支持的buffer數目、流表數以及Actions等。
4、 控制器通過Set Config消息下發配置參數，然後通過Get config Request消息請求OpenFlow交換機上傳修改後的配置信息。OpenFlow交換機通過Get config Reply消息向控制器發送當前的配置信息。
5、 控制器與OpenFlow交換機之間發送Packet_out、Packet_in消息，通過Packet_out中內置的LLDP包，進行網絡拓撲的探測。
6、 控制器與OpenFlow交換機之間通過發送Multipart Request、Mutipart Reply消息，控制器能獲取OpenFlow交換機的狀態信息，包括流的信息、端口信息等。
7、 控制器與OpenFlow交換機之間通過發送Echo Request、Echo Reply消息，保證二者之間存在有效連接，避免失聯。
說明：以上爲控制器與OpenFlow交換機之間的標準交互流程，在具體實驗過程中某些階段可能會缺失。
實驗步驟
一、實驗環境檢查
步驟1 登錄控制器，查看控制器所在主機的IP地址。桌面版鏡像可以通過雙擊桌面上的“Terminal”圖標打開命令終端，也可以使用Ctrl+Alt+t快捷方式打開命令終端，如下圖所示。
步驟2 登錄主機1，查看Mininet所在主機的IP地址，如下圖所示。
二、捕獲數據包
步驟1 登錄Floodlight控制器，啓動抓包工具Wireshark，捕獲控制器與交換機建立連接過程中的數據包，通過分析這些數據包瞭解控制器與交換機基於OpenFlow協議進行交互的流程。執行以下命令：
$ sudo wireshark
步驟2 雙擊eth0網卡，查看eth0網卡上數據包收發情況，如下圖所示。
步驟3 登錄Mininet虛擬機，啓動Mininet。通過“--controller”參數設置Mininet連接遠程控制器，並指定控制器的IP和端口號。
$ sudo mn --controller=remote,ip=30.0.1.3,port=6633 --switch=ovsk,protocols=OpenFlow13
步驟4 登錄Floodlight控制器，停止Wireshark，觀察數據包列表，可以看出控制器與交換機的基本交互流程。
三、OpenFlow1.3交互流程分析
步驟1 交換機連接控制器的6633端口，經過3次握手後雙方建立TCP連接。查看捕獲到的數據包，分析交換機與控制器建立TCP連接的流程。分析TCP連接建立過程，需要先了解TCP的狀態位，主要包括SYN、FIN、ACK、PSH、RST和URG。SYN表示建立連接，FIN表示關閉連接，ACK表示響應，PSH表示有DATA數據傳輸，RST表示連接重置。可以看出交換機與控制器經歷一次連接重置後，成功完成三次握手，建立TCP連接，如下圖所示。
步驟2 當控制器與交換機建立TCP連接後，由其中某一方發起Hello消息，雙方協調協OpenFlow議版本號。控制器和交換機都會向對方發送一條Hello消息，消息中附上自己支持的OpenFlow的最高版本。接收到對方Hello消息後，判斷自己能否支持對方發送的版本，能支持則版本協商成功，不能支持則回覆一條OFPT_ERROR消息。查看Hello消息詳情，本實驗中由於交換機和控制器都能支持OpenFlow1.3版本，所以版本協商爲1.3，如下圖所示。
步驟3 OpenFlow版本協商完成後，控制器發送一條features_request消息獲取交換機的特性信息，包括交換機的ID（DPID）、緩衝區數量、端口及端口屬性等等。相應的，交換機回覆features_reply消息，如下圖所示。
查看數據包詳情，ofpt_feature_request消息只有包頭，如下圖所示。
ofpt_feature_reply數據包詳情如下，交換機的DPID是數據通道獨一無二的標識符，低48位是一個MAC地址，高16位是自定義的。本實驗中交換機緩衝區數量（n_buffers）爲256，交換機支持的流表數量（n_tables）爲254，交換機所支持的功能，如下圖所示。
步驟4 OpenFlow1.0協議中feature_reply消息還包含交換機端口信息，OpenFlow 1.3協議將‘stats’框架更名爲‘multipart’框架，並且將端口描述移植到multipart消息中。其中OPPT_PORT_DESC類型的multipart消息就是用於獲取交換機端口信息的。
查看OPPT_PORT_DESC類型multipart_reply消息，消息中列出了交換機的端口以及每個端口的詳細信息，包括端口名稱和mac地址等，如下圖所示。
