一、實驗目的
- 能夠獨立完成OpenDaylight控制器的安裝配置；
- 能夠使用Postman工具調用OpenDaylight API接口下發流表。
二、實驗環境
- 下載虛擬機軟件Oracle VisualBox或VMware；
- 在虛擬機中安裝Ubuntu 20.04 Desktop amd64，並完整安裝Mininet；
三、實驗要求
（一）基本要求
- 配置JAVA環境，下載並解壓安裝OpenDaylight，版本選擇Carbon 或 Beryllium；
- 下載並解壓安裝Postman；
- 利用Mininet平台搭建下圖所示網絡拓撲，並連接OpenDaylight控制器；
- 創建拓撲
- 打開ODL
- pingall並觀察拓撲
- 通過Postman工具調用OpenDaylight提供的API下發流表，實現拓撲內主機h1和h3網絡中斷10s。
- 相關配置
- 先h1 ping h3，后send。觀察結果
（二）進階要求
1.查找資料，整理和記錄ODL控制器主要的REST API文檔，包括但不限於ODL提供的文檔鏈接，獲取拓撲的交換機、獲取流表狀態數量、獲取特定交換機端口的狀態、新增修改和刪除流表等。
-
獲取拓撲交換機
-
流表的增刪改查
-
獲取交換機中某個流表信息
-
獲取指定交換機信息
四、個人總結
- 實驗難度
本次實驗對於我來說算是比較難的，因為我對於這些工具的掌握不是很熟練，導致在使用工具過程中產生了一系列問題。從而大大延長了我做實驗的時間。 - 遇到的困難以及解決方法
-
拓撲建立並pingall之后在ODL上顯示的拓撲為空白？
這主要是因為我在之前建立了很多拓撲，所以只需要使用命令sudo mn -c清空拓撲，再次建立拓撲之后就會顯示出來了。
-
使用postman下發流表，但沒有作用？
可以通過觀察下面返回的狀態碼來判斷是什么錯誤，我的是401，所以猜測為用戶名或密碼寫錯了。於是將密碼中的adimin改為admin之后就成功了。
下列為常用狀態碼：- 100：這個狀態碼是告訴客戶端應該繼續發送請求，這個臨時響應是用來通知客戶端的，部分的請求服務器已經接受，但是客戶端應繼續發送求請求的剩余部分，如果請求已經完成，就忽略這個響應，而且服務器會在請求完成后向客戶發送一個最終的結果。
- 200：這個是最常見的http狀態碼，表示服務器已經成功接受請求，並將返回客戶端所請求的最終結果。
- 202：表示服務器已經接受了請求，但是還沒有處理，而且這個請求最終會不會處理還不確定。
- 204：服務器成功處理了請求，但沒有返回任何實體內容 ，可能會返回新的頭部元信息。
- 301：客戶端請求的網頁已經永久移動到新的位置，當鏈接發生變化時，返回301代碼告訴客戶端鏈接的變化，客戶端保存新的鏈接，並向新的鏈接發出請求，已返回請求結果。
- 404：請求失敗，客戶端請求的資源沒有找到或者是不存在。
- 500：服務器遇到未知的錯誤，導致無法完成客戶端當前的請求。
- 503：服務器由於臨時的服務器過載或者是維護，無法解決當前的請求。
-
安裝時報各種錯誤。
這些錯誤大多是因為復制命令的時候多復制了空格或者少復制了一個 - 導致的，因此復制完最好先檢查一遍。
- 心得體會
在本次實驗中，我還是學到了很多東西，畢竟做一步錯一步(bushi)。不僅了解到了ODL和postman的使用方法，同時也對拓撲結構的了解更為深入。但是，這些還只是了解到了一點皮毛，通過不斷的學習我了解到自己所學的不過是冰山一角，期待自己可以在接下來的課程中運用的更加熟練。