OpenFlow協議學習
OpenFlow協議思想是，網路設備維護一個FlowTable，並且只通過FlowTable對報文進行處理，FlowTable本身的生成、維護和下發完全由外置的控制器Controller來實現。
此外，OpenFlow交換機把傳統網路中，完全由交換機/路由器控制的報文處理轉變為由交換機和控制器來共同完成數據的轉發操作，從而實現數據的轉發與路由控制的分離。控制器則通過事先規定好的介面操作OpenFlow交換機中的流表，從而達到數據轉發的目的。
目前OpenFlow協議主要支持三種消息類型，分別是:
Controller-to-switch消息：由控制器發起，用來管理或獲取switch狀態
asynchronous消息：由switch發起，用來將網路事件或交換機狀態變化更新到控制器。
symmetic消息：可由交換機或控制器發起。
Hello、Feature、Echo消息分別包含REQUEST與REPLY消息，每一個消息REQUEST與REPLY的TransactionID相同，交換機通過ID進行識別對應事件埠。
OpenFlow協議基本報文格式如下：
通過構建OpenDaylight控制器與Mininet模擬器相結合的測試環境，來研究OpenFlow協議。Mininet中構建1個交換機和2個主機，這2個主機屬於同網段。
1、啟動OpenDaylight：
root@ubuntu:/home/rain/opendaylight/karaf-0.7.2/bin#./karaf
通過瀏覽器訪問http://localhost:8181/index.html）頁面。用戶名和密碼都是admin。
2、抓包驗證
在ODL虛擬機上執行以下命令開始抓包
tcpdump-i any port 6633 -s0 -w openflow.pcap
3、登錄Mininet虛擬機，執行以下命令啟動Mininet，生成測試拓撲結構：
mn--controller=remote,ip=192.168.28.131,port=6633
4、分析抓的OpenFlow數據包
參考：OpenFlow協議抓包實驗https://www.jianshu.com/p/e660508f1c5d
OpenDaylight二層轉發機制實驗https://www.sdnlab.com/15126.html
OpenFlow協議wireshark抓包分析https://www.cnblogs.com/cing/p/7709544.html
打開抓取的openflow.pcap文件，找到OFPT_HELLO報文，追蹤TCP流。
可以看出先是進行了三次TCP握手，建立TCP連接。因而，OpenFlow協議的數據包封裝在TCP報文中。
控制器與交換機通信過程詳解：
1、hello消息
當交換機連接到控制器時，交換機與控制器會相互發送hello包，而hello消息中只包含ofHeader，沒有主體部分。而of頭部結果如下：
/*Header on all OpenFlow packets. */
structofp_header {
uint8_t version; /* OFP_VERSION. */
uint8_t type; /* One of the OFPT_ constants. */
uint16_t length; /* Length including this ofp_header. */
uint32_t xid; /* Transaction id associated with thispacket.
Replies use the same id as was in the request tofacilitate pairing. */
};
ofHeader中的version欄位為發送方支持的最高版本的of協議版本。如果兩者協議版本兼容，則建立of連接，否則發送error消息，斷開連接。交換機向控制器發送的Hello消息如下所示：
2、feature消息
可以看到該報文裡面包含了發送給交換機的OFPT_HELLO報文，但是TransactionID:21和交換機發給控制器的不一樣。
交換機響應控制器發送的OFPT_FEATURES_REQUEST報文，向控制器發送OFPT_FEATURES_REPLY
連接建立後，控制器向交換機發送一個featuresRequest消息查詢交換機的特性，features request消息也只包含ofHeader，交換機接受到該消息之後會返回一個features reply消息，這個消息就包含Header和Message。request和reply兩個消息的TransactionID是一樣的。
reply消息分析：
[0:8]為header(version、type、length、xid)
[8:32]長度24byte為sw的features，包含如下：
datapath_id：交換機的標識符，低48位是一個MAC地址，高16位是自定義的。
n_buffers：一次最多緩存的數據包數量。
n_tables：表示交換機支持的流表數量。每個流表可以設置不同的通配符和不同數量的流表項。控制器和交換機第一次通信的時候，控制器會從feature_reply消息中找出交換機支持多少流表，如果控制器還想了解大小、類型和流表查詢的順序，就發送一個ofpst_tablestats請求，交換機必須按照數據包遍歷流表的順序把這些流表回復給控制器，並且精確匹配流表排在通配流表前。
auxiliary_id：標識輔助連接。
capabilities：所支持的功能。交換機的一些詳細信息的bitmap。
reserved：保留欄位。
ofpt_feature_reply消息結構如下：
structofp_switch_features {
struct ofp_header header;
uint64_t datapath_id; /* Datapath unique ID. The lower 48-bits are for
aMAC address, while the upper 16-bits are implementer-defined. */
uint32_t n_buffers; /* Max packets buffered at once. */
uint8_t n_tables; /* Number of tables supported bydatapath. */
uint8_t pad[3]; /* Align to 64-bits. */
/* Features. */
uint32_t capabilities; /* Bitmap of support "ofp_capabilities".*/
uint32_t actions; /* Bitmap of supported"ofp_action_type"s. */
/* Port info.*/
struct ofp_phy_port ports[0]; /* Port definitions. The number of ports is inferred from thelength field in the header. */
};
3、barrier消息
控制器通過Barrier請求及相應報文，確認相關消息已經被滿足或收到完成操作的通知。
Barrier消息：當控制器需要確認消息依存關係是否滿足，或者希望接收到操作完成的通告時，就發送barrier消息，這個消息就是OFPT_BARRIER_REQUEST，它沒有主體部分。OpenFlow交換機收到這個消息後，必須結束對所有之前收到的消息的處理，才能執行任何barrier請求之後接收的消息。當前處理完成後，交換機必須發送應答消息OFPT_BARRIER_REPLY，並在消息中攜帶原始請求交易的ID（xid）。
4.flow_mod消息
Flow-Mod消息用於添加、刪除、修改openflow交換機的消息；Flow-Mod消息共有5種類型:
ADD類型消息用來添加一條新的流表項（flowentry）
DELETE類型消息用來刪除所有符合一定條件的流表項
DELETE‐STRICT類型消息用來刪除某一條指定的流表項
MODIFY類型消息用來修改所有符合一定條件的流表項
MODIFY‐STRICT類型息用來修改某一條指定的流表項
Flow-Mod消息對應修改的是流表中的流表項（flow entry）而不是整個流表（flowtable）。
控制器向交換機下發OFPT_FLOW_MOD消息：
消息解釋：
cookies為控制器定義流表項標識符
Command：flow-mod的類型
Ldle_timeout是流表項的空閑超時時間；
Hard_timeout是流表項的最大生存時間；
Priority為流表項的優先順序，交換優先匹配高優先順序的流表項；
Buffer_id為交換機中的緩衝區ID，flow-mod消息可以指定一個緩衝區的ID，該緩衝區的數據包會按照此flow-mod消息的action列處理。如果是手動下發的流，buffer_id應填-1，即0xffff,告訴交換機這個數據包並沒有緩存在隊列中。
Out_port為刪除流表的flow_mod消息提供的額外的匹配參數。
Flags為flow-mod命令的一些標誌位，可以用來指示流表刪除後是否發送flow-removed消息，添加流表時是否檢查流表重複項，添加的流表項是否為應急流表項。
當OFPFF_SEND_FLOW_REM被設置的時候，表項超時刪除會觸發一條表項刪除的信息。
當OFPFF_CHECK_OVERLAP被設置的時候，交換機必須檢查同優先順序的表項之間是否有匹配範圍的衝突。
當OFPFF_EMERG被設置的時候，交換機將表項當作緊急表項，只有當與控制器連接斷的時候才啟用。
5、PACKET_IN消息
Packet-in事件在以下兩種情況下會被觸發：
1）當交換機收到一個數據包後，並未與流表中匹配成功，那麼交換機就會將數據封裝在Packer-in消息中，發送給控制器處理。此時數據包會被緩存在交換機中等待處理。
2.交換機流表所指示的action列表中包含轉發給控制器的動作（Output=Controller），此時數據不會被緩存在控制器中。
一般將數據包緩存在交換機中，將有效的數據包信息（默認的128位元組，如果原因是「sendto controller」action，那麼長度由action_out的max_len決定；如果是原因tablemiss，那麼長度由set_config消息中的miss_send_len決定。）和緩存id發送給控制器，不過，如果交換機不支持緩存或者內存用光了，那麼就把整個數據包放在數據部分發給控制器，並且緩存id為-1。
交換機向控制器遞交OFPT_PACKET_IN消息:
Packet_in消息結構如下：
/*Packet received on port (datapath -> controller). */
structofp_packet_in {
struct ofp_header header;
uint32_t buffer_id; /* ID assigned by datapath. */
uint16_t total_len; /* Full length of frame. */
uint16_t in_port; /* Port on which frame was received. */
uint8_t reason; /* Reason packet is being sent (one ofOFPR_*) */
uint8_t pad;
uint8_t data[0]; /* Ethernet frame, halfway through32-bit word,
so the IP headeris 32-bit aligned. The
amount of datais inferred from the length
field in theheader. Because of padding,
offsetof(structofp_packet_in, data) ==
sizeof(structofp_packet_in) - 2. */
};
協議解釋：
buffer_id是packet-in消息所攜帶的數據包在交換機中的緩存ID
Total_len為data段的長度
Reason為packet-in事件的產生原因
8、PACKET_OUT消息
Packet-out消息的應用場景：
指定某一個數據包的處理方法
讓交換機產生一個數據包並按照action流表處理。
典型應用：鏈路發現
控制器向一個交換機發送packet-out消息，buffer_id=-1，data段為某種特殊數據包，actions為從交換機的某個埠進行轉發，如果發出這個數據包的埠另一端也連接一個openflow交換機，對端的交換機會產生一個packet-in消息將這個特殊的數據包轉發給控制器，從而控制器他側到一條鏈路的存在（控制器實現鏈路發現，就是依靠packet-out消息）。
當控制器斷電或者交換機與控制器之間的連接斷開，則交換機會尋找備用控制器，當無法找到備用控制器時便會進入緊急模式（交換機初始化時也是在這個模式下），在緊急模式下，交換機默認將所有接受到的數據包丟棄。
Packet_out消息結構：
structofp_packet_out {
struct ofp_header header;
uint32_t buffer_id; /* ID assigned by datapath (-1 ifnone). */
uint16_t in_port; /* Packet"s input port (OFPP_NONEif none). */
uint16_t actions_len; /* Size of action array in bytes. */
struct ofp_action_header actions[0]; /*Actions. */
/* uint8_t data[0]; */ /* Packet data. The length is inferred
from the length field in theheader.
(Onlymeaningful if buffer_id == -1.) */
};
協議解釋：
buffer_id為交換機中緩存的buffer_id（同flow-mod）；特別注意的是當buffer_id為「-1」時，指定的緩衝區為packet-out消息的data欄位。
In_port為packet-out消息提供額外的匹配信息，當packet-out的buffer_id=-1，並且action流表中指定了output=TABLE的動作，in_port將作為data段數據包的額外匹配信息進行流表查詢。
action_len指定了action列表的長度，用來區分actions和data段Data為一個緩衝區，可以存儲一個乙太網幀。
TAG:菜鳥新世界 |