OpenvSwitch + OpenFlow:Let’s get start
在Fedora完成OpenvSwitch+OpenFLow部署所需要的用戶空間工具、必備的內核模塊都應經包含在Fedora的發佈版中了。我在弄清楚這些包的時候花了很多時間，現在，這裏有介紹瞭如何使用這些組件的信息。
*注：下文中簡稱OpenvSwitch爲OVS
1、簡介：
自從2.4版本以來，OVS對於內核中網橋模塊來說是可選擇的。OVS比標準的網橋模塊有非常大的改進。這些改進都會在OpenvSwitch.org這個網站中進行了詳細的闡述。然而在這些增強的功能中，有一項便是：支持OpenFlow協議。
從概念上來講，交換機功能可以分成兩個部分：控制層和數據層。而控制層是交換機處理髮現、路由、通路計算，與其他交換機通信等功能的核心。控制層創建一個轉發流表，數據層根據這些流表以線路速度處理進入交換機的數據包。OpenFlow協議可以將將交換機的控制層分離到控制器中，並且用軟件定義整個網絡的行爲（也被稱爲SDN）。
與這種（OpenFlow）設置相區別，現有的交換機使用專有的下層工具/協議來進行管理。OpenFlow成爲一種可以開放的標準，它可以不爲下層綁定專有的工具而統一的標準管理來自不同供應商的交換機。
2、安裝：
在Fedora中，OVS的實現分爲兩個部分：OVS內核模塊(數據層data pane)和用戶空間工具(控制層control pane)。由於輸入的數據包要儘快處理，OVS的數據層被推送到內核空間。
爲了使用OVS進行網絡的虛擬化時，OVS服務必須啓動，並且命令行工具必須已經正確的配置，OVS是架在網橋上的。在Fedora中，虛擬交換機工作在兩種模式下：獨立主機和OpenFlow模式。
這篇文章首先會重點介紹如何在獨立主機和OpenFlow兩種模式下建立可以連接到OVS網橋的虛擬機。
在這之前，先安裝一下OVS和tunctl包：
$yum install openvswitch
3、橋接：
3.1、獨立主機模式
如題，在這種模式下虛擬交換機處理所有自身的交換/轉發功能。爲虛擬交換機搭建網橋：
$service openvswitch start
使用標準tunctl命令行工具創建一個虛擬網卡設備：
$tunctl -t tap0 -u root
使用如下的命令停止網絡管路服務，關閉em0接口，清空em1接口(em1接口是虛擬機使用的接入物理網絡的網卡)上所有的IP地址。
$service NetworkManager stop
$ip add flush em1
$ifconfig down em1
運行如下命令創建一個虛擬交換機網橋，並命名爲”ovs-switch”：
$ovs-vsctl add-br ovs-switch ##(創建一個”ovs-switch”網橋)
$ovs-vsctl add-port ovs-switch tap0 ##(爲網橋添加虛擬網卡設備接口)
$ovs-vsctk add-port ovs-switch em1 ##(爲網橋添加em1接口)
$ifconfig tap0 promisc up ##(在混雜模式下啓動接口)
$ifconfig em1 promisc up
這些命令創建了一個新的網橋並添加了一個虛擬網卡設備併爲網橋添加了一個本地網絡端口(em1)，在混雜模式下設置這些端口會建立虛擬機到物理網絡之間的數據轉發通路，反之亦然。設置OVS交換機DHCP接口的IP地址：
$dhclient ovs-switch
現在，你可以使用如下命令啓動你虛擬機：
$/usr/bin/qemu-kvm -smp 2,cores=2 -net tap,ifname=tap0,script=no
-net nic,model=rt18139,macaddr=52:54:00:45:67:30 -m 2048M
~/mutiqueue/fedora.img
*注：上面三行命令爲一條命令，行與行之間爲空格隔開
虛擬管理臺還不支持OVS，所以目前還沒有用來啓動虛擬機的OVS虛擬控制檯。
3.2、OpenFlow模式
在OpenFlow模式下運行OVS，上文的很多命令還會被用到。所以將上面的命令全部拷貝到下面：
$yum install openvswitch
$service openvswitch start
$ovs-vsctl add-br of-switch
$ovs-vsctl add-port of-switch tap0
$ovs-vsctl add-port of-switch em1
$ifconfig tap0 promisc up
$ifconfig em1 promisc up
*注：在OpenFlow模式下網橋設置指向這邊的虛擬交換機
（原文：NOTE:the bridge setup in OpenFlow mode will be referred to as of-switch here on）
4、POX Controller
在此之前，OpenFlow控制器必須已經正確運行，在網橋啓動時轉發任何數據都必須和控制器通信。無論是硬件還是軟件，控制器的選擇都相當的多。本文中採用的是POX控制器（Software）。下載POX的源代碼：https://github.com/noxrepo/pox。你也可以通過命令獲得：
$git clone https://github.com/noxrepo/pox
下載之後控制器就能這樣運行：
$./pox.py forward.12_learning
上面的命令讓POX監聽所有的網絡接口。如果POX已經監聽了某個特定的接口或端口，你可以這樣啓動POX：
$./pox.py OpenFlow.of_01 --address=192.168.2.197 --port=6666 forwarding.12_learning
OVS不支持混在OpenFlow模式，混雜OpenFlow模式就是一部分數據通路由OVS內置的交換邏輯處理，另一部分由OpenFlow控制器處理。(The openvswitch has a failure mode of operation though)。如果交換機與控制器斷開連接，OVS可以迴轉並使用自身內置的邏輯進行轉發。這種迴轉機制能通過以下命令實現：
$ovs-vsctl set-fail-mode ovs-switch standlone
上述的命令可以使得網橋在某些時間斷開連接後回到獨立主機模式
$ovs-vsxtl set-fail-mode ovs-switch secure
在設置迴轉模式爲安全狀態後，如果連接OF控制器失敗，交換機不會轉發任何數據包。
4.1、遠程控制器
考慮到OF控制器可能運行在遠程的主機上，並且虛擬交換機的網橋以安全模式運行的情況。如果在OF交換機上執行dpclient命令，交換機是不知道怎樣通過DHCP通路轉發數據的，因爲它沒有遠程控制器的IP地址。所以，你既需要將設置OF交換機的接口設置爲迴轉模式到獨立主機模式或者分配一個靜態的IP並且設置靜態的路由那麼，網橋將能夠接入遠程控制器。一旦網橋年建立了到遠程控制器的連接，這些通路信息將會被OF控制器中的網橋（基於插件安裝）轉發。
既然網橋和OF控制器已經正在運行，那麼可以通過以下命令將控制器信息分配到網橋。
$ovs-vsctl set-controller of-switch tcp:0.0.0.0:6633
*注：輸入以上全部命令之後，網橋通過本的主機的6633端口，連接到一個OF控制器上。
5、相關命令
既然網橋和控制器已經配置完畢，你現在可以啓動虛擬機（如上面的qemu命令所示）了，並且得到控制器指定的通路。無論何時，當一個新的數據包進來，但網橋中被沒有相應的處理方法的信息，網橋將會發送該數據包的包頭（包含了2層、3層甚至一些4層的信息）到控制器。控制器回發OF命令作爲響應，告訴網橋該如何轉發類似的數據包。這些因此而被分配到網橋的流可以通過一下命令羅列出來：
$ovs-ofctl dump-flows of-switch
下面是一個類似的控制器響應的例子。一個流表項最初包含一組域=值表項和行動表項(原文：A flow entry primarily contains a set of filed=value entries and action entry)。域=值(value)表項的被用來認證進入的數據包，操作表項則告訴網橋匹配什麼通路和執行那些操作。
cocookie=0x0, duration=14.604s, table=0, n_packets=61, n_bytes=7418, idle_timeout=10, hard_timeout=30,tcp, vlan_tci=0x0000, dl_src=78:2b:cb:4b:db:c5, dl_dst=00:21:9b:8e:36:62, nw_src=192.168.7.189, nw_dst=192.168.1.150, nw_tos=0, tp_src=22, tp_dst=60221
actions=output:1
上面的流信息不言而喻。如果通路來自源物理地址(src mac address)：78:2b:4b:db:c5，目的物理地址(desrination mac address)：00:21:9b:8e:36:62，通路(traffic)是TCP通路，源IP=192.168.7.189，目的IP=192.168.1.150，TCP源端口爲22，TCP目的端口60221 轉發包端口1(actions:1)。
在網橋上的端口配置可以用以下命令查看：
$ovs-ofctl show ovs
OFPT_FEATURES_REPLY (xid=0x1): ver:0x1,
dpid:0000782bcb4bdbc5
n_tables:255, n_buffers:256
features: capabilities:0xc7, actions:0xfff
1(em1): addr:78:2b:cb:4b:db:c5
config: 0
state: 0
current: 1GB-FD COPPER AUTO_NEG
advertised:
10MB-HD 10MB-FD 100MB-HD 100MB-FD 1GB-HD 1GB-FD COPPER AUTO_NEG AUTO_PAUSE
supported: 10MB-HD 10MB-FD
100MB-HD 100MB-FD 1GB-HD 1GB-FD COPPER AUTO_NEG
2(tap0): addr:a6:30:4d:0f:40:49
config: 0
state: LINK_DOWN
current: 10MB-FD COPPER
LOCAL(ovs): addr:78:2b:cb:4b:db:c5
config: 0
state: 0
OFPT_GET_CONFIG_REPLY (xid=0x3): frags=normal
miss_send_len=0
根據以上提及的流，通路(traffic)被轉發到主機em1接口的端口1。
如果必要的話，某些用戶流可以手動分配到網橋，下面就是一些例子：
$ovs-ofctl add-flow of-switch
"in_port=LOCAL,table=0,idle_timeout=60,ip,hard_timeout=60,vlan_tci=0x0000, dl_src=78:2b:cb:4b:db:c5,dl_dst=00:09:8a:02:80:c0, nw_proto=1,nw_dst=192.168.1.100, n w_src=192.168.7.189,actions=drop"
以上規則使網橋丟棄所有192.168.7.189到192.168.1.100的ICMP通路(nw_prpto=1)
正如上面所展示的add-flow的例子，value idle_timeout和hard_timeout是定義所有的流的。這些值告訴網橋這些規則會被網橋使用多長時間。相關流在超過定義的時間不活動的話idle_timeout就會導致這些流被刪除。而hard_timeout則會在超過定義時間後不管在此期間流是否活躍，都將相關的流刪除。如果要在網橋中配置了靜態的規則，則需要把hard_timeout和idle_time的值都設置爲0.
以上包含了我到目前位置的所有研究。希望這篇文章將會幫助到更多的用戶開啓研究openFlow技術的旅途！
免責申明：
以上的文章僅僅是爲了信息的即時傳遞。內容來自翻譯相關技術文檔和術語。這些提供的信息可能包含排版上或技術的錯誤。
