## sdn - 初步分析基于OpenFlow的SDN網絡控制功能
題目要求：
1、下發流表項實作 h1 和 h2，h2 和 h3 不能互通、h1 和 h3 可互通。
2、結合捕獲的 SDN 相關協定（例如 OpenFlow 協定）封包，分析其封包結構， 并簡要描述該類封包的作用。（一種即可，限 500 字）
3、說明在相同的網絡拓撲中傳統分布式網絡如何實作要求 1，并分析與 SDN 實 現之間的差别。
### 第一題
#### 分析
題目已經說的很明白了，現在問題是怎麼樣去實作。
基于我現在所了解的sdn的知識，在sdn網絡中，有一個網絡拓撲，裡面有各種路由器和主機，同時還有控制器連接配接着路由。在說控制器之前，先說一下路由。
在路由中， 有着流表，其中的作用就是當網絡中的包經過路由，路由就會根據流表進行比對，進而進行對應的操縱。
現在就有問題了，當一個包出現不比對任何流表，路由應該怎麼辦呢。
這時，路由器就會找到控制器，控制器會就可以根據情況下發對應的流表，告訴路由器怎麼處理。
以上是簡單的對sdn的了解，是以要處理這題就是要給路由添加一條流表，把進入h2或從h2出來的包丢棄就好了。
#### 實作
因為内容比較簡單，可以不考慮控制器下發流表的做法，直接使用mininet控制台使用ovs指令進行控制。
另外要求的是ping通h2。
ping是應用層直接使用icmp的回送請求與回送回答封包，就意味着，h1 ping h2 時，h1發送請求後，h2要回報給h1。是以隻要限制了h2的發送，外界就無法ping通h2，并且h2也無法ping通其他主機了。
#### 代碼
##### topo結構如下：
<code>
class MyTopo(Topo):
def __init(self):
Topo.__init__(self)
h1 = self.addHost('h1')
h2 = self.addHost('h2')
h3 = self.addHost('h3')
s1 = self.addSwitch('s1')
s2 = self.addSwitch('s2')
self.addLink(h1, s1)
self.addLink(h2, s1)
self.addLink(h3, s2)
self.addLink(s1, s1)
topos = { 'mytopo' : (lambad:MyTopo() ) }
<code/>
##### 啟動mininet
<code>
sudo mn --custom mytopo.py --topo mytopo --mac
<code/>
##### 手動添加流表
<code>
sh ovs-ofctl add-flow s1 priority=12,in_port=2,action=drop
<code/>
##### 上一條作用就是把從口2進入的包給丢棄，并且這條流表的優先級為12
##### 關于流表的一些簡單的知識，來源<a href="http://blog.csdn.net/zhongbeida_xue/article/details/54945496" target="_blank" rel="external nofollow" >這裡</a>
每條流規則由一系列字段組成，分為基本字段、條件字段和動作字段三部分
1.基本字段包括生效時間duration_sec、所屬表項table_id、優先級priority、處理的資料包數n_packets，空閑逾時時間idle_timeout等，空閑逾時時間idle_timeout以秒為機關，超過設定的空閑逾時時間後該流規則将被自動删除，空閑逾時時間設定為0表示該流規則永不過期，idle_timeout将不包含于ovs-ofctl dump-flows brname的輸出中。
2.條件字段包括輸入端口号in_port、源目的mac位址dl_src/dl_dst、源目的ip位址nw_src/nw_dst、資料包類型dl_type、網絡層協定類型nw_proto等，可以為這些字段的任意組合，但在網絡分層結構中底層的字段未給出确定值時上層的字段不允許給确定值，即一條流規則中允許底層協定字段指定為确定值，高層協定字段指定為通配符(不指定即為比對任何值)，而不允許高層協定字段指定為确定值，而底層協定字段卻為通配符(不指定即為比對任何值)，否則，ovs-vswitchd 中的流規則将全部丢失，網絡無法連接配接。
3.動作字段包括正常轉發normal、定向到某交換機端口output：port、丢棄drop、更改源目的mac位址mod_dl_src/mod_dl_dst等，一條流規則可有多個動作，動作執行按指定的先後順序依次完成。
##### 結果
### 第二題
##### 分析具體的openflow1.0協定
#### 1.Hello
##### 控制器與交換機之間的OpenFlow協定是應用于TCP傳輸層上，是以解析應用層。他們首先發送hello消息，建立初始化連接配接
##### 1.Version：OpenFlow版本，低位為版本号
##### 2.Type：OpenFlow消息類型
##### 3.Length：消息總長度，包含頭部
##### 4.Xid：事件ID，同一件事件的ID号一緻。如feature_request和對應的feature_reply就使用同一個Transaction id，但是兩個hello消息的Transaction id并不相同，不過據兩個id一般是兩個相鄰的數字。并且packet_in的transaction id都為0。
#### 2.Feature
##### 會話一建立，控制器就會向交換機發送一個ofpt_feature_request消息，該消息隻有of標頭，如下所示。交換機會回複一條ofpt_feature_reply消息
##### ofpt_feature_request如圖：
##### ofpt_feature_replyt如圖：
##### 1.datapath_id : 資料通道獨一無二的辨別符，低48位是一個MAC位址，而高16位是自定義的。例如，用高16位代表VLAN ID差別一個實體交換機中的多個虛拟交換機
##### 2.n_buffers : 一次最多緩存的資料包數量
##### 3.n_tables : 表示交換機支援的流表數量。而每個流表可以設定不同的通配符和不同數量的流表項。控制器和交換機第一次通信的時候，控制器會從feature_reply消息中找出交換機支援多少流表，如果控制器還想了解大小、類型和流表查詢的順序，就發送一個ofpst_table stats請求，交換機必須按照資料包周遊流表的順序把這些流表回複給控制器，并且精确比對流表排在通配流表前
##### 4.capabilities : 所支援的功能
##### 5.actions : 該bitmask表示交換機所支援的actions，“required”action必須支援，vendor action不應該通過該bitmask顯示，actions根據ofp_action_type的值決定需要左移幾位。
##### 6.ports[] : 以數組的形式羅列出該系統中支援OpenFlow的實體端口。資料長度可以根據OpenFlow頭部中的length推測出來
#### 3.Packet_in
當交換機碰到新資料包不知道如何處理，或者action要求發送給控制器，那麼交換機就會用packet_in消息發送給控制器。一般将資料包緩存在交換機中，将有效的資料包資訊（預設的128位元組，如果原因是 “send to controller” action，那麼長度由action_out的max_len決定；如果是原因table miss，那麼長度由set_config消息中的miss_send_len決定。）和緩存id發送給控制器，不過，如果交換機不支援緩存或者記憶體用光了，那麼就把整個資料包放在資料部分發給控制器，并且緩存id為-1
##### packet_in消息如下
##### total_len ： 整個資料幀的長度
##### in_port ： 接收資料幀的端口
##### reason ： 将資料包發送給控制器的原因，一般有倆原因，一是沒有比對到流表項，二是動作要求發給控制器
#### 4.Packet_out
##### Packet_out如圖：
當控制器希望交換機發送某個資料包，就使用packet_out消息
#### 參考連結
#### 1.流表相關 - <a href = 'http://www.sdnlab.com/15119.html'>http://www.sdnlab.com/15119.html<a/>
#### 2.openflow協定分析 - <a href = 'http://www.jianshu.com/p/e660508f1c5d'>http://www.jianshu.com/p/e660508f1c5d<a/>
轉載于:https://www.cnblogs.com/UNWILL2LOSE/p/6756088.html