一、group表介紹
OpenFlow v1.1中增加了組表（Group Table）的概念，并一直被後續的版本所沿用。
OpenFlow支援四種組表類型：
- Indirect：執行該group中一個已定義的bucket， 該組僅支援一個bucket。 允許多個流表項或組表項指向一個公共的組（例如IP轉發的下一跳）。 這是最簡單的group類型，交換機通常比較支援這種類型的group。
- All：執行該group中所有的bucket。這種類型的group用來進行multicast和broadcast。為每個bucket克隆一份資料包，然後分别執行每個bucket中的actions。
- Select：執行該group中的一個bucket。基于一種選擇算法（使用者定義的雜湊演算法或者輪詢算法）選擇group中的一個bucket對資料包執行actions。這種選擇算法應該盡量支援負載均衡并且為每個bucket提供一個權重用于配置設定。當一個bucket指定的端口down掉，交換機應該将選擇限制在剩下的正常的bucket中而不是丢掉，這是為了減少鍊路中斷。
- Fast failover：執行第一個活動的bucket。 每個action bucket都與控制其活動性的特定端口和/或組相關聯。 按照group定義的順序評估bucket，并選擇與活動端口/組關聯的第一個bucket。 這個group類型使交換機可以更改轉發行為而無需往返于控制器。 如果沒有bucket，則丢棄資料包。
group表的常用指令如下：
- 檢視目前裝置對group的支援
ovs-ofctl -O OpenFlow13 dump-group-features br0
- 檢視group表
ovs-ofctl -O OpenFlow13 dump-groups br0
- 建立group表
# 類型為all
ovs-ofctl -O OpenFlow13 add-group br0 group_id=1,type=all,bucket=output:1,bucket=output:2,bucket=output:3
# 類型為select
ovs-ofctl -O OpenFlow13 add-group br0 group_id=2,type=select,bucket=output:1,bucket=output:2,bucket=output:3
# 類型為select，指定hash方法(5元組，OpenFlow1.5+)
ovs-ofctl -O OpenFlow15 add-group br0 group_id=3,type=select,selection_method=hash,fields=ip_src,bucket=output:2,bucket=output:3
- 删除group表
ovs-ofctl -O OpenFlow13 del-groups br0 group_id=2
- 建立流表
ovs-ofctl -O OpenFlow13 add-flow br0 in_port=1,actions=group:2
二、group表實驗過程
1、實驗概述
為了更加直覺的觀察實驗過程，本次實驗使用mininet進行網絡拓撲的建構，mininet的使用見之前的bolg（https://blog.csdn.net/weixin_40042248/article/details/109274982）。在mininet中，建構兩台主機h1、h2作為測試的主機，利用五個交換機建構出兩條鍊路便于測試group的不同類型的資料轉發情況，其中s1和s5裡使用group表，其餘的交換機作為普通的二層交換機使用，具體的拓撲如下圖所示。
拓撲建構完成之後，運作拓撲，在終端中檢視網卡端口的對應關系，友善添加流表，使用指令links，對應關系如下圖所示。
接下來，為h1和h2配置設定ip
h1 ip addr add 10.0.0.1/24 dev h1-eth0
h2 ip addr add 10.0.0.2/24 dev h2-eth0
為s2、s3、s4添加流表，将這三個交換機作為普通交換機使用，流表添加的指令如下。
ovs-ofctl add-flow s2 priority=0,actions=normal
ovs-ofctl add-flow s3 priority=0,actions=normal
ovs-ofctl add-flow s4 priority=0,actions=normal
（1）添加group表，類型為all
首先為s1進行group表設定，檢視s1中的網卡對應的number，指令ovs-ofctl show s1，結果如下圖所示。
向s1中添加group表，類型為all，bucket動作為向所有端口轉發。
ovs-ofctl -O OpenFlow13 add-group s1 group_id=1,type=all,bucket=output:1,bucket=output:2,bucket=output:3
再向s1中添加流表，從端口1進入的資料轉發執行s1内的group表，從2、3端口進入的資料将其從端口1轉發出去。這樣設定之後，從h1發送的資料就會向所有的路徑轉發出去，從其他地方進入的資料就會發送給h1。
ovs-ofctl add-flow s1 priority=1,in_port=1,actions=group:1 -O openflow13
ovs-ofctl add-flow s1 priority=1,in_port=2,actions=output:1 -O openflow13
ovs-ofctl add-flow s1 priority=1,in_port=3,actions=output:1 -O openflow13
接下來，為s5進行group表設定，檢視s5中的網卡對應的number，指令ovs-ofctl show s5，結果如下圖所示。
向s5中添加group表，類型為all，bucket動作為向所有端口轉發。
ovs-ofctl add-group s5 group_id=5,type=all,bucket=output:1,bucket=output:2,bucket=output:3 -O openflow13
再向s5中添加流表，從端口1進入的資料轉發執行s5内的group表，從1、3端口進入的資料将其從端口2轉發出去。這樣設定之後，從h2發送的資料就會向所有的路徑轉發出去，從其他地方進入的資料就會發送給h2。
ovs-ofctl add-flow s5 priority=1,in_port=2,actions=group:5 -O openflow13
ovs-ofctl add-flow s5 priority=1,in_port=1,actions=output:2 -O openflow13
ovs-ofctl add-flow s5 priority=1,in_port=3,actions=output:2 -O openflow13
以上步驟設定成功後，h1--h2之間便有兩條鍊路可以正常通信， 接下來，在mininet指令行下輸入h1 ping h2的指令，觀察結果如下圖所示。
注意：DUP是DUPLICATE的一個縮寫，也就是ping包的時候收到多個重複值回應，通常發生在linux環境下比較多，windows環境對ping的reply隻接到第一個，後續的重複回應會被廢棄。
是以，可以看出兩條鍊路在類型為all的group表下，都可以正常的進行資料轉發。
接下來，将一條鍊路down掉，如下圖所示，h1 ping h2觀察結果如下圖所示。
（2）添加group表，類型為select（實作ECMP）
首先，清除上一步的s1中的group表，添加group表，類型為select，方法用hash，目的是将h1發出的資料按照hash算法選擇轉發的路徑（hash根據五元組）。在s1中添加group表後，如下圖所示。
ovs-ofctl add-group s1 group_id=1,selection_method=hash,type=select,selection_method=hash,bucket=output:2,bucket=output:3
在s1中添加流表，actions執行group表。
ovs-ofctl add-flow s1 priority=1,in_port=1,actions=group:1 -O openflow13
接下來，在mininet指令行下輸入h1 ping h2，結果如下圖所示。由于s5的group仍然為上一步的group表，是以傳回的icmp應答封包仍然重複。
為了更好的檢視資料轉發的過程，當h1 ping h2 後，使用tcpdump監測s2-eth1和s3-eth1資料，如下圖所示。可以看出，設定select類型的group表後，icmp請求封包隻選擇了上面一條路徑，由于每次icmp請求的五元組都是一樣的，是以每次轉發選擇的路徑都相同。
（3）添加group表，類型為Fast failover
通過fast failover這個名字就能發現該類型是一個快速恢複的類型。具體來說就是當轉發的端口down掉之後組表能夠感覺到并且切換到另一個up的端口。在這種類型的組表的行動桶中，具有設定監視對象端口 的watch_port這一個設定項目，可以實作對實體端口的監控，進而實作當轉發的端口down掉之後組表能夠感覺到并且切換到另一個up的端口。
在這裡，重新建構了一個網絡拓撲如下所示。其中，h1，h2，h3的ip分别設定為10.0.1.1/24，10.0.1.2/24，10.0.1.3/24。
端口對應的關系如下所示。
實驗中，設定兩個組表的bucket，分别監聽s1-eth2和s1-eth3，output分别對應的h2和h3。組表的指令如下。
ovs-ofctl -O openflow13 add-group s1 group_id=1,type=ff,bucket=watch_port:2,actions=output:2,bucket=watch_port:3,actions=output:3
接下來，對s1添加流表，指令如下。
ovs-ofctl add-flow s1 priority=1,in_port=1,actions=group:1 -O openflow13
ovs-ofctl add-flow s1 priority=1,in_port=2,actions=output:1 -O openflow13
ovs-ofctl add-flow s1 priority=1,in_port=3,actions=output:1 -O openflow13
流表添加完成後，就可以開始實驗結果驗證了。
首先，在h1中 ping h2，結果如下所示。可以正常的ping通。
然後，在h1中 ping h3，結果如下所示。無法ping 通。
此時，若斷開s1-h2之間的鍊路，就可以實作h1 ping h3了。接下來，将s1-h2之間的鍊路斷開，再在h1中 ping h3，結果如下所示。可以發現已經能夠互相ping通了。