筆者是一名從事交換機測試多年的測試工程師，尤其是最近兩年專註於OpenFlow交換機的測試。在接觸到的客戶中，很多人想將自己的網路向SDN去轉。交換機可以採購，但是完全符合自己部署運維要求的控制器基本上是找不到的。那麼一個很自然的想法就是能否基於目前最受歡迎的兩款開源控制器OpenDaylight和ONOS來做一些開發，再加上OpenFlow交換機來搭建自己的SDN網路。下面是基於我對這兩款控制器粗淺的認識給的一些建議，將控制器的內部視作黑盒，只談對外呈現。

關於SDN的本質屬性，借用衛峯的話來說，就是下面三點：

  • 控制面和轉發麵分離
  • 有開放的編程介面
  • 集中式的管理

只要符合上面三點就可以說是SDN。不過，我這裡要聊的，是和OpenFlow強相關的SDN。OpenFlow將之前網路設備對於報文的操作和轉發進行了原子化。例如三層轉發，分離抽象成了

  • 修改source/dest mac-----> set_field:xx->eth_src/eth_dst
  • IP TTL減1-------------------->dec_nw_ttl
  • 從某個埠轉發出去----->output:x

這樣至少帶來瞭如下的好處

(1)可以組合編排出之前不曾有的操作，例如單播和組播之間互轉

(2)具體業務可以通過這些原子操作的list來進行描述，方便編程

作為整個網路的大腦——控制器——就被提升到了核心的位置，而交換機不再有自我學習表項和自主決定編輯轉發的能力，對於接收到的報文的處理完全按照控制器下發的流表描述來做。因為table-miss表項的存在，對於前面表項匹配不到的報文，一般丟掉或是上送控制器，由控制器來做判斷和處理。

對於控制器來說，其應用層介面被定義為北向介面，其數據轉發層的介面被定義為南向介面。控制器上運行的App，通過調用它提供的API，將App的邏輯翻譯成南向介面的協議(例如OpenFlow)，然後通過南向介面下發給交換機。

作為目前最受歡迎的兩款開源控制器，OpenDaylight和ONOS在業界非常的火，至於Ryu/floodlight之類，只能靠後站了。但是它們還是各有側重點的。OpenDaylight作為企業主推的控制器，支持的功能較多，也更龐雜；而ONOS是運營商主推的控制器，更加貼近運營商的場景。它們的共同點，就是已經集成進了很多APP，可供使能和去使能，尤其是提供了很全面的REST API，可以非常方便地操作flow/group/meter。至於具體的表項該如何獲取，

  • OpenDaylihgt可以通過YangUI/Yangman填入表格來獲取JSON body
  • ONOS可以通過ONOS Core REST API，仿照給出的示例，填入Frame內容

這些通過基於REST over HTTP，非常容易用Python等編程語言進行調用。

但是，但是，能夠操作這些openflow的表項，距離一個真正可用的APP，還有很大的距離，最大的問題就是無法響應openflow交換機上發的報文。下面是幾類最常用的Switch-to-Controller的報文：

  • Packet_In：一般用來將沒有具體匹配項的報文，通過table-miss流表上送控制器(前面要加上packet_in的報頭)。一個典型應用就是首包上送，然後控制器下發適配的流表，這樣後續同類報文就可以直接按照流錶轉發了。
  • Send_Flow_Rem：控制器下發流表的時候，將流表中的該flag置起。當流表被刪除的時候(往往是因為timeout)，會通告控制器，方便控制器及時更新流表記錄的資料庫。
  • Port_State：當交換機的埠up/down的時候，通過該消息通告控制器，供控制器瞭解網路中的拓撲變化，及時作出策略調整提供依據。

作為控制器來說，交換機上報的這些消息，都是它採取或是改變策略重要的參考。因此這裡需要解析交換機上送的OpenFlow協議報文，提取其中的重要信息，然後作出決策，再通過對交換機下發OpenFlow協議報文，體現出自己的管理意志。那麼此時，只有那些REST API肯定就遠遠不夠了，需要自己編寫App並打包進控制器，並在控制器上運行。當然，App中還是可以調用已經提供的各種API，就沒有必要自己再寫一份了。具體如何實現，就看開發者

  • 對網路業務的理解程度
  • 對控制器架構的掌握
  • Java編程實現的能力
  • 是否需要重構WebUI
  • 是否需要集成一些自己的運維工具

至於參考，最好的肯定是官方提供的文檔(Wiki)，還有控制器開源代碼中自身提供的一些sample-case，谷歌也是必不可少(就不噴某度了)。另外國內的sdnlab也不時提供一些好的技術類的分享文章，可以看看別人踩過哪些坑。

推薦閱讀：

相關文章