TEST

wrifhbioewurghoerghehrehrtjty

【Mininet 流量分析工具 — 使用 sFlow-RT】

今天要跟大家介紹的是一款網路流量的分析工具，它具有可以即時監看網路封包流量的圖形化工具，其特色包含即時分析(本篇教學的重點)，可彈性擴充許多相關支援的套件，開放式平台供許多開源軟體開發與執行

相關的套件資訊可參考：https://sflow-rt.com/index.php

安裝步驟如下

• 下載sFlow-RT 套件並解壓縮

wget https://inmon.com/products/sFlow-RT/sflow-rt.tar.gz
tar -zxvf sflow-rt.tar.gz

使用wget指令下載 sFlow-RT 套件

解開壓縮檔案

• 進入sFlow-RT底下目錄，並安裝mininet-dashboard 介面 app

cd sflow-rt
./get-app.sh sflow-rt mininet-dashboard

安裝完mininet-dashboard後，系統提示請重新啟動來生效

[PS] 相關關於sFlow-RT的app套件參考如下，可使用./get-app.sh flow-rt [app套件名稱] 來進行安裝

擷取自sFlow-RT官方網站

• 啟動執行 sFlow-RT套件

./start.sh

啟動後http協定在port 8008進行監聽，所以等等瀏覽器的網址列必須指名http://[your host IP]:8008才能看到介面

• 執行mininet

mn –custom slow-rt/extras/sflow.py –topo tree,depth=2,fanout=2

mininet缺少 requests 套件以至於報錯，故下pip install requests 指令來安裝所需但缺少的套件

待系統提示安裝成功後，我們進行下一步

再次執行mininet已成功執行

• 打開瀏覽器，並切到mininet-dashboard介面

http://127.0.0.1:8008/app/mininet-dashboard/html/

看到流量介面了，但由於還沒有封包流經，故無流量顯示曲線

• 執行pingall 指令讓各個 host 彼此間進行封包交換

在mininet底下pingall

剛剛pingall 下所產生的封包流量，已顯示折線的方式顯示在介面上

 

 

廣告

【Ryu Controller 運作原理】

當Ryu Controller要與mininet建立連接時，我們會執行「reu-manager –verbose ryu/app/simple_switch_13.py」，其中simple_switch_13.py它是一個由python所撰寫的程式原始碼，其主要功能包含switch的mac address 對應 port 關係，以及flow entry的新增與刪除作業

以下程式碼針對「simple_switch_13.py」來做改寫

• 程式碼分析 :

  def switch_features_handler(self, ev): 

  該程式碼區塊主要負責監控關於switch的各種狀態，包含初次建立連接時的握手訊息交換，目前該switch的連線狀態（連接還是斷線）等

新增 Table-miss Flow Entry 區塊

OpenFlow 交換器的握手協議完成之後，新增 Table-miss Flow Entry 到 Flow table 中為接收 Packet-In 訊息做準備。

Table-miss Flow Entry 的優先權為 0 即最低的優先權，而且此 Entry 可以 match 所有的封包。 這個 Entry 的 Instruction 通常指定為 output action ，並且輸出的連接埠將指向 Controller。 

   def _packet_in_handler(self, ev):

在Ryu 中當有未知的封包流經switch時，便會觸發PacketIn 事件，也就是此段程式區塊所做的事情

目的 MAC 位址若存在于 MAC 位址表，則判斷該連接埠的號碼為輸出。反之若不存在于 MAC 位址表則 OUTPUT action 類別的實體並生成 flooding（ OFPP_FLOOD）給目的連接埠使用

對於 Flow Entry 來說，設定 match 條件以分辨目標封包、設定 instruction 以處理封包以及 Entry 的優先權和有效時間。

對於交換器的的實作，Apply Actions 是用來設定那些必須立即執行的 action 所使用。

最後透過 Flow Mod 訊息將 Flow Entry 新增到 Flow table 中。

• 程式實作

執行Ryu和Mininet

當Mininet與Ryu Controller開始建立連接時，觀察Ryu的交換訊息

當初次建立連接時，分別會在每個switch上新增預設的「table-miss flow entry」，該規則中將所有封包都先往Controller送

接著在mininet中執行 pingall 指令

• 程式運作原則

1. 初次建立連接時，新增table-miss flow entry，作為前置作業
2. 使用Flooding機制得知host MAC address 對應的port，並存入mac_to_port table中
3. flow流經switch時有來源位址(eth_src)和目的位址(eth_dst)和來源port(in_port)，新增至flow entry

【多個 Mininet host 連接 — 使用Gre Tunnel 】

前者所分享關於Mininet的文章都是僅有一個虛擬機裡面執行mininet模擬環境，所測試host間的連接也都是在同一個Mininet環境，然而若是在多個不同間的VM或是Mininet環境要進行網路連接時，就要用到所謂的Gre Tunnel了

根據網路上關於Gre Tunnel的介紹，整理如下：

GRE（Generic Routing Encapsulation，通用路由封裝）是一種 IP-over-IP 的隧道協定（Tunneling Protocol），可以在虛擬對等鏈路中封裝多種網路層協定，是現今主要使用的 Overlay 網路技術之一。GRE 是 Cisco 等公司提出的技術，對部分網路層協定進行封裝並在 IPv4/IPv6 網路中傳輸，簡單說就是一種協定封裝格式，定義了如何用一種網路協定去封裝另一種網路協定。

簡單說 GRE Tunnel 原理，當我們讓兩台網路介面建立了私有通道時。當封包傳送給對方時，會將封包丟到建立 GRE Tunnel的邏輯介面進行轉送，當資料抵達另一方的邏輯介面時，在將被封裝成 GRE 的封包恢復成原始狀態傳送給目的地，因此取得的封包是乾淨的。

GRE 有以下優缺點：

• 可跨區域部署的 L3 通道技術。
• 使用 4 bytes 的 segment id 來通當 vlan id 的租戶隔離。
• 基於點對點通道協定（Point to Point Tunneling Protocol），每兩個點需要有一個通道，對於第四層網路埠口（port）資源是一種浪費。
• 增加 IP Header，因此會減少 Instance 的 MTU 值，因此會影響傳輸效率。
• 不支援群組廣播，同網路中的一個虛擬機發送廣播 frame 後，GRE 會將其廣播到所有與該節點有通道連接的節點。
• GRE 封裝的 IP 封包過濾與負載平衡問題，有許多第三層網路與防火牆裝置無法解析。

在實作前先看看待會我們要實作的架構

host 1 和 host 2 透過 Gre Tunnel 進行通訊

現在就開始準備實作吧！！首先準備兩個VM環境
VM 1 配置IP為 192.168.100.3
VM 2 配置IP為 192.168.100.4

[ VM 1 配置]

開啟兩個terminal分別執行Ryu Controller和Mininet
[ Ryu ]
# ryu-manager –verbose ryu/app/simple_switch_13.py

[ Mininet ]
# mn –topo=single,1 –controller=remote

VM 1 執行  Ryu Controller 和 Mininet

[ VM 2 配置]

開啟terminal執行Mininet

[ Mininet ]
# mn –topo=single,1

VM 2 只執行 Mininet，和 VM 1 不一樣喔 ！！ 

＃更改VM 2 host 1 的IP 為 10.0.0.2 (避免重複)

ifconfig h1-eth0 inet 10.0.0.2

此時測試host 1 和 host 2 是否可以通訊 ？

#設定Gre Tunnel
[host 1] ovs-vsctl add-port s1 s1-gre1 — set interface s1-gre1 type=gre options:remote_ip=192.168.100.4
———————————————————-
[host 2] ovs-vsctl add-port s1 s1-gre1 — set interface s1-gre1 type=gre options:remote_ip=192.168.100.3

VM 1 host1 的gre tunnel 配置

VM 2 host2 的gre tunnel 配置

設定完gre tunnel 後host間可以進行通訊了

 

 

 

 

 

 

 

【Gogobee 機車衛星導航實測】

對有關交通相關議題充滿興趣的阿寬，偶然在一次滑facebook，被一個商品廣告所吸引，於是就不小心點進去了商品頁面，抱持著好奇姑且一試的心態，而且現在官網正好特價，在這樣的因緣際會下，這台「小黃」成為了我的新寵

官方網站打折頁面

我選購了「重機超值包」的版本

gogobee 來看鏡頭

內容物有本體機器 x 1 + 固定支架 x 1 + 磁吸座包 x 1 + App 授權帳號 x 1

現在將機器和固定支架合體吧

 

好啦！本篇的重點在於Gogobee的導航實測，好像花太多的時間在開箱了，事不宜遲，我們就開始實測吧

這次的實測路線為 新北市新店區溪園路389號 —-> 台北市文山區指南路二段64號(政治大學)

平常都是走這條，不知道「小黃」想怎麼走

「小黃」想走的路線，和我預估的路線一模一樣，我們還真有“默契”呢 ！！

• 起點出發

小黃和黑色的車身可以說是「天作之合」！！搭配起來挺好看的

• 拯救「小黃」大作戰：
  才出發沒多久我就看到「小黃」隨著機車後照鏡震動的很劇烈，主人深怕他摔落地面，於是暫且停在路邊重新調整鬆緊度，讓他不至於震動的太劇烈

調整完後真的有好很多，原來是固定支架沒有緊緊貼牢後照鏡

• 新人難免會緊張嘛！！
  大概到了考試院附近 ( 可能怕考試吧 XD )，就發現「小黃」緊張的一直跟我說靠右前方走，但其實這條路 ( 木柵路一段 )是直線的，有點不懂它想要幹嘛，好拉！念在你的「第一次」，我就原諒你這次的小失誤

一直叫我靠右前方走，但我沒有要右轉啊！！

• 這次這樣就對了
  剛好前方就是「Y」字路口，依照路徑規劃的確是要往右前方 ( 木柵路二段 ) 移動，這次「小黃」叫的特別賣力，在等紅燈的同時，隔壁的騎士都紛紛被「小黃」所吸引，彷彿好像是要彌補上次所犯下的錯誤

Good Job !!

• 最後一哩路：
  下了道南橋後其實就到了政大的校區了，蠻好奇定位的準度，於是我就繼續騎到政大的校門口看看會有什麼結果呢？

加油「小黃」，目的地就在前面了

也太厲害了，剛好到學校門口導航結束，恭喜「小黃」順利完成任務

 

使用心得：

以下分「外表」和「內在」來做分享，外型方面的設計感很有簡約的風格，運用外框的燈號表示方向，中間數字表示要轉彎的剩下距離，介面上讓人淺顯易懂，且操作上不會有太多繁雜的步驟，其操作主要都是在App上，對於平常有習慣使用導航App的人算非常容易上手，另外固定支架上的設計也別有巧思，有別於傳統手機支架，同時兼具美感與實用性

在導航部分也算是表現的不錯，比我預期中的還要好，當初想說「小黃」裡面沒有GPS晶片，完全仰賴手機的GPS，而且騎車過程中我手機放在口袋，訊號難免會有些不穩定，當然使用GPS本來就會有誤差，但「小黃」的表現還蠻不錯的！！轉彎時的提示音也蠻大聲的，在吵雜的車流環境中也聽得到，不至於錯過轉彎，如果真的覺得太大聲的話，可以去App裡面做警示音的音量調整

評價（各項滿分5分）：
定位精準      ★★★★☆ 4分
外觀設計      ★★★★☆ 4分
支架穩固      ★★★★★ 5分
電力續航      ★★★☆☆ 3分

[ 小提醒 ]

• 對於不熟的路使用「小黃」前，建議先看一下App所規劃的路線，多少對路要稍微有印象，不然如果騎快一點或GPS反應較慢時，容易錯過重要的轉彎路口
• 固定支架盡量緊貼機車的照後鏡，以免「小黃」摔落受傷
• 遇到沒有GPS訊號或者是進入到室內時，「小黃」會暫時迷失方向，開始亂報方向，所以如果不熟路況會被帶著亂走，不過這也是GPS衛星導航的通病，平常我們用手機的導航App也會常有訊號迷失的情況
• 在導航App中記得要調成「機車」模式，不然「小黃」有機會帶你去高速公路兜兜風喔！！還好我對文山區的路算熟悉，不然有一次就差點騎上了“信義快速道路”了

緊貼照正面

緊貼照側面

緊貼照背面

 

 

【SDN Switch Flow Table 設定 — 使用MiniNam 】

上一篇提到關於MiniNam的安裝，現在我們就以MiniNam為例子，研究關於SDN Switch上Flow Table的設定吧

• 考慮一個環狀的網路拓樸(ring)

  

  自定義環狀拓樸語法如上

• 同時執行Ryu controller 和 MiniNam
  

  [ Ryu ]
  ryu-manager –verbose –observe-links ryu/app/rest_topology.py ryu/app/ofctl_rest.py ryu/app/simple_switch_13.py

  [ MiniNam ]
  ./MiniNam –custom topo_new4.py –topo myoop –controller remote

  

  

  環狀拓樸圖形介面

• 進行ping測試，兩主機間彼此不相通，為什麼？
• Ryu ofctl API 介紹
  

  ＃取得所有Switch資訊
  $ curl -X GET http://localhost:8080/stats/switches （localhost可用127.0.0.1取代）

  ＃ 獲得單一Switch上目前設定的Flow Table規則
  $ curl -X GET http://localhost:8080/stats/flow/<Switch的dpid&gt;

  
  

  

  系統預設有兩條flow entry，其中「Output: 4294967293」表示直接將封包交由給Controller做處理，第一條和第二條的差別在於match欄位，第一條將比對到的“01:80:c2:00:00:0e”(系統保留mac)交給controller執行

  第二/三/四台switch其flow entry同第一台，故省略

• 在開始新增flow entry前，我們要先了解dpid和port的關係

  

  比對switches 和 interface 便可得知其關係

  

  其對應 port 關係如圖所示

• 開始新增flow entry至switch
  

  # 新增指令
  curl -X POST -d {要送到SWITCH的FLOW ENTRY} http://127.0.0.1:8080/stats/flowentry/add

  

  新增6比flow entry至switch 1

  

  分別加入的這6筆封包流向

  

  新增2筆flow entry 至 switch 2

  

  

  

  

  

• ping 測試

  

  h1 ping h2 成功

  

  h2 ping h1 成功

• 上述已成功完成flow entry雙向設定，也就是說h1和 h2 之間有兩條路徑可走，接下來我們只設定單向的路由(順時針方向)

  

  switch 1 設定

  

  switch 2 設定

  

  switch 3 設定

  

  switch 4 設定

• h1 和 h2 可相互ping 通，且封包走順時針方向

 

【MiniNam 視覺化網路拓墣模擬器】

之前使用mininet原生的模擬器套件，偶然發現「OpenState SDN」機構竟然也有類似mininet的圖形化介面，而且其整合性功能還比mininet齊全，其中最吸引人的地方是有封包傳輸過程中的模擬動畫，於是就來安裝看看

(參考網站 http://www.cs.ucc.ie/~ak18/MiniNAM/examples)
——————————— 安裝流程 ——————————-

• 安裝以下指令前請先確認Mininet和Ryu均已正確安裝
• 安裝OpenState所需要的相關套件
  

  bash -c “$(wget -O – http://openstate-sdn.org/install.sh)"

  

  

  OpenState會自動安裝缺少的套件

• 下載MiniNam主程式並解壓縮
  

  wget http://www.cs.ucc.ie/~ak18/MiniNAM/code/MiniNAM.tar.gz

  

• 賦予位於MiniNam目錄底下的「paping」和「MiniNam」檔案執行權限
  

  sudo chmod +x paping
  sudo chmod +x MiniNAM

  

• 執行Ryu Controller和MiniNam，步驟類似於Ryu和MiniNet
  

  [ Ryu ]
  ryu-manager –verbose ryu/app/simple_switch_13.py

  [ MiniNam ]
  ./MiniNam –topo single,4 –controller remote

  

  

  執行MiniNam後會自動跳出網路拓墣出來

• MiniNam偏好設定
  

  主要可以設定動畫的速度，顯示的封包內容，是否開啟CLI命令列等

  

• MiniNam介面統計
  

  主要顯示目前各個介面已傳送/接收的封包數

  

• pingall封包測試

  

  將Start CLI打勾後按下OK

  

  執行pingall指令後可以看到封包的動畫

 

 

 

 

【實體host與虛擬host通訊 — 不同網段】

今天的研究目標是讓實體主機(執行虛擬機的host)和虛擬主機(執行在Mininet上的主機)進行通訊，在環境上面的設定其實不難，其中最關鍵的地方在於「路由表」的設定，我們要告知實體主機目標網址(Mininet上的主機)的走向，否則封包會找不到，而導致無法通訊的情形發生

環境建置如下

• 實體主機(IP: 192.168.1.7)
• 虛擬主機(IP: 192.168.1.5) –> 使用橋接網路，網段會落在192.168.1.0/24
• 虛擬主機(IP: 10.211.55.5) –> 使用NAT網路，網段會落在10.211.55.0/24
• Mininet主機共10台(IP: 192.168.80.1 ~ 192.168.80.10)

介面設定如下

橋接介面(實體端)

橋接介面(虛擬端)

NAT網路(實體端)

NAT網路(虛擬端)

Mininet host的IP從192.168.80.1 ~ 192.168.80.10

執行過程

# 執行Controller 和 Mininet
利用ipbase指令來分派host的IP

進行路由表設定[橋接網路]

未設定前，無法ping通虛擬主機

無法ping通192.168.80.1

路由表中沒有192.168.80.0/24網段，故往192.168.1.1預設閘道出去

開始設定實體主機路由表
netstat -r  #查看路由表
route -n add 192.168.80.0/24 192.168.1.5
[PS] 新增通往192.168.80.0網段經由192.168.1.5介面出去

新增路由表

已新增至路由表中

# 測試與虛擬主機的連線

可與192.168.80.0/24的虛擬主機聯通了

封包路徑

成功進行橋接網路的設定後，再來換試試NAT網路

進行路由表設定[NAT網路]

開始設定實體主機路由表
route -n delete 192.168.80.0/24     # 先刪除剛剛設定的路由表規則
netstat -r  #查看路由表
route -n add 192.168.80.0/24 10.211.55.5
[PS] 新增通往192.168.80.0網段經由10.211.55.5介面出去，和橋接網路不同的地方在於出去的介面IP

測試可ping通虛擬主機

經由10.211.55.5介面送往192.168.80.1主機

封包路徑

【Openvswitch vs Controller 】

本篇研究是探討使用openvswitch與Controller之間的關聯，前者主要是針對Openswitch所提供的OpenFlow協定介面去做設定，後者由Ryu所提供的API介面去做設定，以下分別針對這兩種模式來達到控制Data Flow的效果

[方式一]

由圖可知我們主要是針對Southbound的介面去做設定

# 簡單執行mininet拓墣
mn –topo=single,3 –mac –controller=remote

會發現無法Ping通，為什麼？

無法ping通host

# 操作Flow Table
sh ovs-ofctl dump-flows s1 查看s1的flow table

s1的flow table是空的

# 操作Flow Table
sh ovs-ofctl add-flow s1 “priority=0,action=normal" 新增s1的flow table

插入flow table後檢查有無正確被新增進去

此時就可以互相ping到其他host

h1 h2 h3 的主機可互相ping通了

# 新增flow 讓目的地IP是10.0.0.1的封包丟棄
sh ovs-ofctl del-flows s1   清除s1的flow table
sh ovs-ofctl add-flow s1 “priority=0,action=normal"
sh ovs-ofctl add-flow s1 “priority=100,eth_type=0x800,ip_dst=10.0.0.1,action=drop"

[PS]:
priority: 該flow的優先權，越高優先執行
eth_type: 採用何種通訊協定 0x800 表示TCP協定
ip_dst: 目的IP位址
action: 符合此規則的動作，drop表丟棄此封包

和h1有關的flow被block起來，因此不會通

# 新增flow 讓目的地MAC是00:00:00:00:00:02的封包丟棄
sh ovs-ofctl del-flows s1   清除s1的flow table
sh ovs-ofctl add-flow s1 “priority=0,action=normal"
sh ovs-ofctl add-flow s1 “priority=100,eth_type=0x800,dl_dst=00:00:00:00:00:02,action=drop"

和h2有關的flow被block起來，因此不會通

[方法二]

由圖可以本方法是針對northbound 的介面去做設定

# 執行POX Controller 和 Mininet
[POX]
./pox.py forwarding.l2_learning    # 執行L2的flow table學習機制

[Mininet]
mn –topo=single,3 –mac –controller=remote

# 由於有連接POX Controller且有flow table學習機制，故host可相互ping通

# 分析各flow，所有flow路徑都被記錄在flow table中

# ICMP/ IP / MAC  block實驗
複製l2_learning.py檔案，由該檔案進行更改程式碼
l2_learning.py 放置於pox/forwarding 目錄底下

# ICMP block 實驗
新增以下程式碼，並執行pox controller 和 mininet ，進行互ping實驗

# IP block 實驗
新增以下程式碼，並執行pox controller 和 mininet ，進行互ping實驗

python是很嚴格要求排版，注意同一個區塊的頭要對其，否則會被判定錯誤喔 ！！

# MAC block 實驗
新增以下程式碼，並執行pox controller 和 mininet ，進行互ping實驗

 

【玩轉路由器 — IP分享器串接模式】

曾經想過路由器能否進行串接，剛好最近在做SDN的實驗，也需要用到同一個網域下host間的互相通訊，因此就來試試看路由器的串接實驗吧

在進行實驗前，首先要先了解不同的串接方式，會有截然不同的效果，主要有以下兩種模式：

• IP分享器模式：兩台IP分享器各自管理所屬網段，例如：A分享器管理192.168.0.1~192.168.0.254，則B分享器管理192.168.1.1~192.168.1.254，注意到了嗎？A和B彼此間位於不同的網段，所以說等下在進行DHCP設定時，要避掉IP重疊的情況。
  通常會使用這樣的情況下，就是在租屋處，房東為每一戶設置了一個IP，但是你手邊卻有兩台以上的裝置必須連網，此時我們就會去購買IP分享器，將你要上網的設備透過IP分享器來獲得可以上網的IP位址
• AP(存取點)模式：兩台IP分享器共同服務同一個網段，也就是說A和B共同管理192.168.0.1~192.168.0.254或是192.168.1.1~192.168.1.254，當你隨意連上A或B其中一台時，你都會在同一個網域中。
  通常會使用這樣的情況下，就是假設你在一棟透天裡面，1樓和2樓的上網設備需要互相進行通訊，由於要能互相通訊所以就必須在同一個網段，這樣設備彼此間才能看得到對方

我們先來看看我們實驗的設備吧

 

---

大致了解差異和用途後，就開始進行串連的設定囉，首先先來研究第一種 — IP分享器模式
我們要接的方式如圖下所示

操作如下

首先把線接好，如下圖

設定A分享器WAN端，即外部網路，請依照ISP業者所提供的IP位址設定，這邊每個人的IP會是獨一無二不一樣的

設定A分享器LAN端，即內部網路的DHCP

 

設定B分享器DHCP，注意A和B分享器的DHCP範圍不可以重疊

進行MacBookPro(192.168.0.194)和MacBookAir(192.168.1.100)互Ping測試
192.168.1.100可ping通192.168.0.194，反之無法
代表下一層級的IP可以看到上一層級的IP，但反之則看不到

可以思考看看為何會只有單向可Ping通 ？

接著來設定第二種模式 — AP存取點模式(又可稱為橋接模式)，如下圖：

操作如下

接著A分享器的設定和第一種模式一樣
WAN外部IP，LAN內部的DHCP從192.168.0.100~192.168.0.199

B分享器設定如下：
採用固定IP => 手動設定在192.168.0.0網域(即A分享器所在網域)，本例子為192.168.0.2
停用DHCP

MacBookPro連接A分享器
MacBookAir連接B分享器
但都取得192.168.0.0這個網域

進行MacBookPro(192.168.0.107)和MacBookAir(192.168.0.102)互Ping測試
發先均可以互相Ping通，因為都位於同一層網域，可互相看到彼此