newlogo7.png

前言


最近用 Ryu Framework 開發 SDN 的 Network address translation (NAT) 已經告一個段落(非常感謝在資策會兩位強大同事能夠請教、學習)。目前已經由另外一位夥伴,接力去開發 Multi-WAN port 的功能,期望最終目標能做到 Load Balance 的效果。

在利用 OpenFlow 開發 SDN 應用程式的同時,對處理網路封包有更深一層的認識,如何用軟體(Software)去定義(Define)網路(Network)是一件非常有趣的事情。
Controller 在 SDN 網路裏幾乎扮演著上帝的角色,由開發者去決定網路封包的流向,甚至能做到修改封包的 Source IP, Destination IP, Source port, Destination port, 偽造並發出 IP, ARP 封包等等…

開發 SDN / OpenFlow 的環境介紹


目前開發的環境是利用 OpenFlow switch 加上一台 Controller 與若干台 Host PC:

  • Controller:僅開發用途,一般的電腦或筆電即可,作業系統建議採用 Linux / Mac OS

  • OpenFlow Switch 這邊有幾個解決方案,依照建議順序分別為:

  • Host:一般的電腦即可,安裝什麼作業系統不會有影響,建議安裝 Wireshark 方便 Debug

OpenFlow Switch 的選擇


如果在學校實驗室有經費,當然首推使用 Openflow supported switches 不過要注意的是 OpenFlow Protocol 協定雖然目前都號稱支援到 1.3 但是有些功能其實根本沒有支援(應該是沒有 OpenFlow supported 的晶片),像是 Spec. 中目前還是 Option 的 Actions Set-field.

值得注意的是使用 Open vSwitch 的環境比較特別,若想實體化,需要有一個嵌入式的開發平台,並且有2個以上乙太網路孔一個 Controller Plane 其他為 Data Plane 的目前我們是用 Pandaboard 上面有 Arch Linux 並植入 Open vSwitch 的 kernel modules.

最近我也同時在研究如何將 Open vSwitch v2.1 放到 OpenWRT 透過 Cross compile 編出 TL-1043ND v1.1的韌體,目前已經成功編譯出支援 OpenFlow Protocol 1.3 的 Binary (有需要 Binary 自己嘗試的,可以寄 Email 給我),但是 network config 有一些小問題尚未解決,或許有機會可以再來寫一篇如何編譯即設定 OVS 環境。

三個方法我比較少用的是 Mininet 因為想要做出真實的網路,而不是模擬網路拓蹼環境,不過未來不會排斥使用 mininet。

OpenFlow Controller Framework 的選擇


因為軟體定義網路的關係,目前 Open Source 的 Controller 可以說是百家爭鳴,但是支援 OpenFlow Protocol 1.3 以上的 Controller 目前還不算多。

目前較受歡迎的 Controller 如下

  • Ryu:開發利用 Python,官方宣稱支援到 OpenFlow Protocol 1.4 為日本 NTT 主導開發。

  • Open Daylight:開發利用 Java 支援到 OpenFlow Protocol 1.3 是目前最強大的陣容,彙集各大網路設備商包含 Cisco, Juniper, HP, IBM

  • Floodlight:開發利用 Java 目前僅支援到 OpenFlow Protocol 1.0

  • NOX:算是第一款出現的 OpenFlow controller 開發利用 C++ 僅支援到 OpenFlow Protocol 1.0 目前看似已經沒有再繼續開發,名稱改為 NOX-Classic,開發者似乎把精力都投往 POX 上做開發。

  • POX:開發利用 Python 僅支援到 OpenFlow Protocol 1.1

目前我使用 Ryu 作為開發框架,會選 Ryu 主要原因是本身對 Python 的熟悉程度較高,次要的原因就是 OpenFlow Protocol 支援的程度較快。當然 Python 因為其語言特性,本身寫起來十分的簡潔易懂,所以相較于其他語言的 OpenFlow Controller 框架,Ryu 開發速度較為快些。