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
- 進入sFlow-RT底下目錄,並安裝mininet-dashboard 介面 app
cd sflow-rt
./get-app.sh sflow-rt mininet-dashboard
[PS] 相關關於sFlow-RT的app套件參考如下,可使用./get-app.sh flow-rt [app套件名稱] 來進行安裝
- 啟動執行 sFlow-RT套件
./start.sh
- 執行mininet
mn –custom slow-rt/extras/sflow.py –topo tree,depth=2,fanout=2
- 打開瀏覽器,並切到mininet-dashboard介面
- 執行pingall 指令讓各個 host 彼此間進行封包交換
【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的連線狀態(連接還是斷線)等
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的交換訊息
接著在mininet中執行 pingall 指令
- 程式運作原則
- 初次建立連接時,新增table-miss flow entry,作為前置作業
- 使用Flooding機制得知host MAC address 對應的port,並存入mac_to_port table中
- 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 封包過濾與負載平衡問題,有許多第三層網路與防火牆裝置無法解析。
在實作前先看看待會我們要實作的架構
現在就開始準備實作吧!!首先準備兩個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 2 配置]
開啟terminal執行Mininet
[ Mininet ]
# mn –topo=single,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
設定完gre tunnel 後host間可以進行通訊了
【Gogobee 機車衛星導航實測】
對有關交通相關議題充滿興趣的阿寬,偶然在一次滑facebook,被一個商品廣告所吸引,於是就不小心點進去了商品頁面,抱持著好奇姑且一試的心態,而且現在官網正好特價,在這樣的因緣際會下,這台「小黃」成為了我的新寵
gogobee 來看鏡頭
好啦!本篇的重點在於Gogobee的導航實測,好像花太多的時間在開箱了,事不宜遲,我們就開始實測吧
這次的實測路線為 新北市新店區溪園路389號 —-> 台北市文山區指南路二段64號(政治大學)
- 起點出發
- 拯救「小黃」大作戰:
才出發沒多久我就看到「小黃」隨著機車後照鏡震動的很劇烈,主人深怕他摔落地面,於是暫且停在路邊重新調整鬆緊度,讓他不至於震動的太劇烈
- 新人難免會緊張嘛!!
大概到了考試院附近 ( 可能怕考試吧 XD ),就發現「小黃」緊張的一直跟我說靠右前方走,但其實這條路 ( 木柵路一段 )是直線的,有點不懂它想要幹嘛,好拉!念在你的「第一次」,我就原諒你這次的小失誤
- 這次這樣就對了
剛好前方就是「Y」字路口,依照路徑規劃的確是要往右前方 ( 木柵路二段 ) 移動,這次「小黃」叫的特別賣力,在等紅燈的同時,隔壁的騎士都紛紛被「小黃」所吸引,彷彿好像是要彌補上次所犯下的錯誤
- 最後一哩路:
下了道南橋後其實就到了政大的校區了,蠻好奇定位的準度,於是我就繼續騎到政大的校門口看看會有什麼結果呢?
使用心得:
以下分「外表」和「內在」來做分享,外型方面的設計感很有簡約的風格,運用外框的燈號表示方向,中間數字表示要轉彎的剩下距離,介面上讓人淺顯易懂,且操作上不會有太多繁雜的步驟,其操作主要都是在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>
系統預設有兩條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)
介面設定如下
執行過程
# 執行Controller 和 Mininet
利用ipbase指令來分派host的IP
進行路由表設定[橋接網路]
未設定前,無法ping通虛擬主機
開始設定實體主機路由表
netstat -r #查看路由表
route -n add 192.168.80.0/24 192.168.1.5
[PS] 新增通往192.168.80.0網段經由192.168.1.5介面出去
# 測試與虛擬主機的連線
成功進行橋接網路的設定後,再來換試試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
【Openvswitch vs Controller 】
本篇研究是探討使用openvswitch與Controller之間的關聯,前者主要是針對Openswitch所提供的OpenFlow協定介面去做設定,後者由Ryu所提供的API介面去做設定,以下分別針對這兩種模式來達到控制Data Flow的效果
[方式一]
由圖可知我們主要是針對Southbound的介面去做設定
# 簡單執行mininet拓墣
mn –topo=single,3 –mac –controller=remote
會發現無法Ping通,為什麼?
# 操作Flow Table
sh ovs-ofctl dump-flows s1 查看s1的flow table
# 操作Flow Table
sh ovs-ofctl add-flow s1 “priority=0,action=normal" 新增s1的flow table
此時就可以互相ping到其他host
# 新增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表丟棄此封包
# 新增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"
[方法二]
由圖可以本方法是針對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實驗
# 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通,因為都位於同一層網域,可互相看到彼此