【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

Screenshot from 2018-05-08 20-20-40.png
使用wget指令下載 sFlow-RT 套件

Screenshot from 2018-05-08 20-21-20.png
解開壓縮檔案

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

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

Screenshot from 2018-05-08 20-22-28.png
安裝完mininet-dashboard後,系統提示請重新啟動來生效

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

螢幕快照 2018-05-08 下午11.09.37.png
擷取自sFlow-RT官方網站

  • 啟動執行 sFlow-RT套件

./start.sh

Screenshot from 2018-05-08 20-22-50.png
啟動後http協定在port 8008進行監聽,所以等等瀏覽器的網址列必須指名http://[your host IP]:8008才能看到介面

  • 執行mininet

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

Screenshot from 2018-05-08 20-25-28.png

Screenshot from 2018-05-08 20-26-00.png
mininet缺少 requests 套件以至於報錯,故下pip install requests 指令來安裝所需但缺少的套件

Screenshot from 2018-05-08 20-26-17
待系統提示安裝成功後,我們進行下一步

Screenshot from 2018-05-08 20-26-25.png
再次執行mininet已成功執行

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

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

Screenshot from 2018-05-08 20-26-58.png
看到流量介面了,但由於還沒有封包流經,故無流量顯示曲線

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

Screenshot from 2018-05-08 20-27-14.png
在mininet底下pingall

Screenshot from 2018-05-08 20-27-32.png
剛剛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的連線狀態(連接還是斷線)等

Screenshot from 2018-04-07 03-02-41.png
新增 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 事件,也就是此段程式區塊所做的事情

Screenshot from 2018-04-07 03-02-59.png

Screenshot from 2018-04-07 03-03-23.png

Screenshot from 2018-04-07 03-03-40.png

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

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

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

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

  • 程式實作

執行Ryu和Mininet

Screenshot from 2018-04-07 03-37-36.png

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

Screenshot from 2018-04-07 03-37-59.png
當初次建立連接時,分別會在每個switch上新增預設的「table-miss flow entry」,該規則中將所有封包都先往Controller送

接著在mininet中執行 pingall 指令

Screenshot from 2018-04-07 03-38-38.png

Screenshot from 2018-04-07 03-38-49.png

Screenshot from 2018-04-07 03-38-58.png

Screenshot from 2018-04-07 03-39-09.png

Screenshot from 2018-04-07 03-39-18

Screenshot from 2018-04-07 03-39-28.png

  • 程式運作原則
  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 封包過濾與負載平衡問題,有許多第三層網路與防火牆裝置無法解析。

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

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

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

[ VM 1 配置]

Screenshot from 2018-04-07 22-32-57.png

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

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

Screenshot from 2018-04-07 22-36-11.png
VM 1 執行  Ryu Controller 和 Mininet

[ VM 2 配置]

Screenshot from 2018-04-07 22-38-32

開啟terminal執行Mininet

[ Mininet ]
# mn –topo=single,1

Screenshot from 2018-04-07 22-39-26
VM 2 只執行 Mininet,和 VM 1 不一樣喔 !! 

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

ifconfig h1-eth0 inet 10.0.0.2

Screenshot from 2018-04-07 22-41-29.png

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

Screenshot from 2018-04-07 22-42-55-2.png

Screenshot from 2018-04-07 22-42-29.png

#設定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

Screenshot from 2018-04-07 22-44-21-2.png
VM 1 host1 的gre tunnel 配置

Screenshot from 2018-04-07 22-45-10.png
VM 2 host2 的gre tunnel 配置

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

Screenshot from 2018-04-07 22-45-37.png

Screenshot from 2018-04-07 22-45-21

 

 

 

 

 

 

 

【Gogobee 機車衛星導航實測】

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

螢幕快照 2018-04-05 上午8.28.25.png
官方網站打折頁面

螢幕快照 2018-04-05 上午8.28.33.png
我選購了「重機超值包」的版本

gogobee 來看鏡頭

20180405_014324.jpg

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

20180405_014801.jpg
現在將機器和固定支架合體吧

 

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

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

螢幕快照 2018-04-05 上午10.33.38
平常都是走這條,不知道「小黃」想怎麼走

Screenshot_20180405-071943.png
「小黃」想走的路線,和我預估的路線一模一樣,我們還真有“默契”呢 !!

  • 起點出發

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

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

20180405_071615.jpg
調整完後真的有好很多,原來是固定支架沒有緊緊貼牢後照鏡

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

20180405_072126.jpg
一直叫我靠右前方走,但我沒有要右轉啊!!

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

20180405_072445.jpg
Good Job !!

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

20180405_073622.jpg
加油「小黃」,目的地就在前面了

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

 

使用心得:

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

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

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

[ 小提醒 ]

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

20180405_074514.jpg
緊貼照正面

20180405_074653.jpg
緊貼照側面

20180405_074711.jpg
緊貼照背面

 

 

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

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

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

    Screenshot from 2018-04-03 23-00-48.png
    自定義環狀拓樸語法如上
  • 同時執行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

    Screenshot from 2018-04-03 23-00-57.png

    Screenshot from 2018-04-03 23-01-49.png
    環狀拓樸圖形介面
  • 進行ping測試,兩主機間彼此不相通,為什麼?Screenshot from 2018-04-03 23-02-32
  • 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;

    Screenshot from 2018-04-03 23-03-36.png
    Screenshot from 2018-04-03 23-03-44.png

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

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

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

    Screenshot from 2018-04-04 01-40-10.png
    比對switches 和 interface 便可得知其關係

    Screenshot from 2018-04-03 23-01-49-5.png
    其對應 port 關係如圖所示
  • 開始新增flow entry至switch

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

    Screenshot from 2018-04-03 23-14-51.png
    新增6比flow entry至switch 1

    Screenshot from 2018-04-03 23-01-49
    分別加入的這6筆封包流向

    Screenshot from 2018-04-03 23-17-27
    新增2筆flow entry 至 switch 2

    Screenshot from 2018-04-03 23-01-49-2.png

    Screenshot from 2018-04-03 23-18-42.png

    Screenshot from 2018-04-03 23-01-49-3.png

    Screenshot from 2018-04-03 23-19-22.png

    Screenshot from 2018-04-03 23-01-49-4

  • ping 測試

    Screenshot from 2018-04-03 23-21-11.png
    h1 ping h2 成功

    Screenshot from 2018-04-03 23-22-28.png
    h2 ping h1 成功
  • 上述已成功完成flow entry雙向設定,也就是說h1和 h2 之間有兩條路徑可走,接下來我們只設定單向的路由(順時針方向)

    Screenshot from 2018-04-04 01-44-47
    switch 1 設定

    Screenshot from 2018-04-04 01-45-23.png
    switch 2 設定

    Screenshot from 2018-04-04 01-46-54.png
    switch 3 設定

    Screenshot from 2018-04-04 01-47-17.png
    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)"

    Screenshot from 2018-04-03 07-27-11

    Screenshot from 2018-04-03 07-34-53.png
    OpenState會自動安裝缺少的套件
  • 下載MiniNam主程式並解壓縮

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

    Screenshot from 2018-04-03 07-40-01.png

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

    sudo chmod +x paping
    sudo chmod +x MiniNAM

    Screenshot from 2018-04-03 07-42-16.png

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

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

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

    Screenshot from 2018-04-03 07-43-48.png

    Screenshot from 2018-04-03 07-44-09.png
    執行MiniNam後會自動跳出網路拓墣出來
  • MiniNam偏好設定

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

    Screenshot from 2018-04-03 07-44-31.png

  • MiniNam介面統計

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

    Screenshot from 2018-04-03 07-44-57.png

  • pingall封包測試

    Screenshot from 2018-04-03 07-45-58.png
    將Start CLI打勾後按下OK

    Screenshot from 2018-04-03 07-46-51.png
    執行pingall指令後可以看到封包的動畫

 

 

 

 

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

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

環境建置如下
routing_002.png

  • 實體主機(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)

介面設定如下

螢幕快照 2017-12-07 上午12.57.56.png
橋接介面(實體端)

Screenshot from 2017-12-06 08-52-53.png
橋接介面(虛擬端)

螢幕快照 2017-12-07 上午1.08.21.png
NAT網路(實體端)

Screenshot from 2017-12-06 08-51-46.png
NAT網路(虛擬端)

Screenshot from 2017-12-06 08-57-16.png
Mininet host的IP從192.168.80.1 ~ 192.168.80.10

執行過程

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

Screenshot from 2017-12-06 08-56-20.png

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

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

螢幕快照 2017-12-07 上午12.59.15.png
無法ping通192.168.80.1

螢幕快照 2017-12-07 上午12.59.35
routing_003.png

螢幕快照 2017-12-07 上午1.13.18.png
路由表中沒有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介面出去

螢幕快照 2017-12-07 上午12.59.35-2.png

螢幕快照 2017-12-07 上午1.01.37
新增路由表

螢幕快照 2017-12-07 上午1.01.51.png
已新增至路由表中

# 測試與虛擬主機的連線

螢幕快照 2017-12-07 上午1.03.40.png
可與192.168.80.0/24的虛擬主機聯通了

Routing_004
封包路徑

成功進行橋接網路的設定後,再來換試試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

螢幕快照 2017-12-07 上午1.04.33.png

螢幕快照 2017-12-07 上午1.09.39.png

螢幕快照 2017-12-07 上午1.10.54.png
測試可ping通虛擬主機

螢幕快照 2017-12-07 上午1.13.59
經由10.211.55.5介面送往192.168.80.1主機

Routing_005
封包路徑

【Openvswitch vs Controller 】

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

[方式一]
SDN_002

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

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

Screenshot from 2017-12-07 08-14-53.png

會發現無法Ping通,為什麼?

Screenshot from 2017-12-07 08-15-52
無法ping通host

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

Screenshot from 2017-12-07 08-16-52.png
s1的flow table是空的

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

Screenshot from 2017-12-07 08-17-46.png
插入flow table後檢查有無正確被新增進去

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

Screenshot from 2017-12-07 08-17-58.png
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表丟棄此封包

Screenshot from 2017-12-07 08-21-32.png

Screenshot from 2017-12-07 08-22-35.png
和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"

Screenshot from 2017-12-07 08-34-05.png
和h2有關的flow被block起來,因此不會通

[方法二]

SDN_003

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

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

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

Screenshot from 2017-12-07 08-41-31.png

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

Screenshot from 2017-12-07 08-41-43.png

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

Screenshot from 2017-12-07 08-42-26
Screenshot from 2017-12-07 08-42-26-2
Screenshot from 2017-12-07 08-42-26-3
Screenshot from 2017-12-07 08-42-26-4
Screenshot from 2017-12-07 08-42-26-5
Screenshot from 2017-12-07 08-42-26-6

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

Screenshot from 2017-12-07 08-45-56.png

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

Screenshot from 2017-12-07 08-49-39.png
Screenshot from 2017-12-07 08-52-20.png
Screenshot from 2017-12-07 08-52-53.png

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

Screenshot from 2017-12-07 09-00-39.png

Screenshot from 2017-12-07 09-05-26.png
python是很嚴格要求排版,注意同一個區塊的頭要對其,否則會被判定錯誤喔 !!

Screenshot from 2017-12-07 09-07-41

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

Screenshot from 2017-12-07 09-09-49.png
Screenshot from 2017-12-07 09-12-48.png
Screenshot from 2017-12-07 09-16-15.png

 

【玩轉路由器 — 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樓的上網設備需要互相進行通訊,由於要能互相通訊所以就必須在同一個網段,這樣設備彼此間才能看得到對方

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

20171204_204113

20171204_210037

20171204_204137

20171204_211524

 


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

ip_001

操作如下

首先把線接好,如下圖

20171204_211147

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

螢幕快照 2017-12-04 下午9.03.08

螢幕快照 2017-12-04 下午9.03.29

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

螢幕快照 2017-12-04 下午9.10.01

 

螢幕快照 2017-12-04 下午9.19.52

螢幕快照 2017-12-04 下午9.21.09

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

螢幕快照 2017-12-04 下午9.16.21

螢幕快照 2017-12-04 下午9.17.55

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

螢幕快照 2017-12-04 下午9.25.26

螢幕快照 2017-12-04 下午9.27.22

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

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

ip_002

操作如下

20171204_214301

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

螢幕快照 2017-12-04 下午9.33.51

螢幕快照 2017-12-04 下午9.10.01

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

螢幕快照 2017-12-05 上午5.44.47
螢幕快照 2017-12-05 上午5.47.48

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

螢幕快照 2017-12-04 下午9.49.53

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

螢幕快照 2017-12-04 下午9.51.44

螢幕快照 2017-12-04 下午9.52.42