如何將Linux打造成OpenFlow Switch:Openvswitch
因為工作上被指派去做SDN,自然需要SDN的網路設備才可以。問題是SDN Switch賣的超級貴的,一台差不多要30萬台幣。這跟當初推廣SDN的人說法完全不一樣!他們當初說SDN網路設備會變得比較便宜,因為網路設備上不需要在堆疊這麼多的網路協定,因此硬體可以Cost Down,也可以省下軟體的錢。問題是,如果單單賣純種SDN Switch根本是不可能的事情啊,因為缺少可以在上面跑的軟體和控制器,所以只好保留傳統設備上的功能,再多加OpenFlow的支援,並提供給使用者選擇的開關。這樣當然只會更貴不會便宜啊!! 在沒錢、沒人、沒資源的情況下,要怎麼辦呢?用模擬軟體?可惜要Demo的時候行不通。那就只好自己來打造一台SDN Switch了。雖然沒有晶片的支援,但只要不牽扯到效能的話,應該沒太多問題。下面是我和同事想過的一些解決方案: 自己打造OpenFlow的Agent,反正OpenFlow的網路協定並不複雜,然後透過Linux Kernel的netfilter來模擬晶片的行為。因為是用軟體模擬,所以效率會比較差,但反過來說,因為是軟體,所以我可以滿足所有OpenFlow的要求,不會有做不到的事情。不過這個提案被一個PM的同事封殺了,理由是這不能賣錢 ... 有一個同事找到一個有趣的專案 FlowForwarding 。這個專案提供了Open Source的OpenFlow Agent: LINC。LINC是用Erlang所開發的軟體。雖然我根本不會Erlang,但程式語言不是我考慮的重點,我好奇的是它要怎麼模擬晶片來處理封包。從網頁上看到,LINC在使用上需要libpcap的函式庫,初步猜測,LINC應該是把所有的封包透過libpcap攔截到user space以後進行修改。這樣做的效率應該會比我的解決方案更差。 OpenVswitch 。這是大部份產品的解決方案。我聽過一堆公司宣稱自己有了SDN Switch,而內容只不過是把Openvswitch移植到自己原有的產品上罷了。一樣,我好奇它要怎麼模擬晶片來處理封包,看了編譯過程,它會產生openvswitch.ko,在加上它利用bridge的特性,所以應該是在linux bridge那邊進行hook後修改。 考量到移植的方便性,所以後來我個人選擇openvswitch作為SDN Switch...