111-2 專題研究筆記 Week 1-2

SDN(Software Defined Networking)

Reference : Software-Defined Networks: A Systems Approach

Landscape

Market

被視為一種市場的轉變，過去電腦行業主要的類型為為了客戶的特定目的推出特定的Solution，這種模式被稱為Vertical market(垂直市場)，而SDN的目標是將市場改造為Horizontal ecosystem，即讓Hardware、OS、Application等都能分開，不需要相互依賴，以此來增加市場的豐富性，並將網路設備的控制權轉移回消費者手上，使得消費者能將其更貼近自身需求。

Technical

將網路設備的不同層級間拆開，並將各個單位間的介面開放並完善定義，這種行為被稱為disaggregation。這些層級包括：

• Control Plane
  根據現在使用的協定來決定網路行為，使用Routing table來協助考慮Path、Cost、Policy等條件並決定Route。
• Data Plane
  根據Control plane的決策來forward封包，使用forwarding table決定封包轉送方式。e.g. Control Plane決定了route順序：A-B-C，因此下一站應該到B，data plane就會接著判斷要將packet送至B的話需要將其從哪個port送出，並判斷新的destination。

不過，若是要將Control Plane與Data Plane完整分離，如何處理Control Plane給予Data Plane的instructions就變得格外重要，在2008年時一款知名的支援disaggregation的介面問世，其名為Open Flow。

OpenFlow

• 並不是第一個滿足disaggregation的協定，但其引出的Flow Rules很好的解決了forwarding的問題。
• Flow Rules是Match與Action的pair，Match會看到header field如MAC Type、IP Addr，Action決定packet是要："forward to one or more ports"、"drop"、"send up to controller"(Controller為switch中的Control Plane)。
• OpenFlow使用了Flow Table，可以想成是前述Forwarding table的abstraction。
• 定義了Controller與OpenFlow Switch間的TLS安全通訊，如下圖：

為了滿足SDN的定義，我們希望Control Plane與Data Plane是完全分離的–甚至是在cloud上運行Control Plane，並控制代表Data Plane的交換機。為了兼顧Scalability和availability，在雲端運行的Controller也可以是由多台server(vm)組成，來實現不同的Controller功能。所以，若是需要更多Data Plane，只需加入bare-metal的機器就行；若是需要更多功能，在cloud上增加Server(vm)就行。

Use Cases

從各個不同的實例中來觀察SDN的價值。

Network Virtualization

網路的虛擬化，包括常見的VPN(Virtual Private Network)、VLAN(Virtual Local Area Network)。

VLAN

• 定義在IEEE802.1q，位於OSI第二層。
• 透過邏輯劃分網路終端，不受地理、設備限定。
• 增加網路維護方便度、效能(同個VLAN下的廣播封包不會傳到其他VLAN)
• 通常在switch上設定將某幾個port規劃到同個VLAN，減少collision

VPN

• 將私人網路開放到WAN，已註冊的使用者能建立穿隧通道至VPN Server
• 與VPN server建立加密通道(大部分有加密，如L2TP、IPsec)
• 遠端使用者能以位於該私人網路的型態在網路上活動

雖然這兩者在實際應用上已行之有年，但離SDN真正的定義仍然有些差距。可以想成他們只是將地址空間虛擬化，但其他的性質仍可以be virtualized。
在VLAN還需要手動在Switch上手動配置時，通過在cloud上集中分布的Control Plane，創建、修改、刪除各種網路行為只需要通過單一API入口便可以辦到。

當網路變成這樣的programmatic，所有網路相關的行為都可以透過一系列的service來達成，那麼新的網路安全層級也要隨著上升。與其將更多的security feature塞進cloud，不如讓網路本身就具有安全的特徵，因此一種稱之為microsegmentation的行為出現，試著創建isolated的網路(microsegment)，如此便可以減少攻擊蔓延的情形發生。
那麼為了達到此目的，VLAN就顯得有些不足了，不只是只有4096個tag不符合公司的實際應用，在網路虛擬化後一個實體交換機port需要對應的mac位置大大增加，因此Data Plane上的address space便成為了限制，因此在2014年時，VXLAN(Virtual eXtensible Local Area Network)協議出現。

VXLAN

• 不同於VLAN將virtual第二層位址放在第二層標頭中，VXLAN將virtual ethernet frame整個放在一個udp封包中，實現了"透過Layer3滿足Layer2 subnet"
• 負責封裝和拆解這類udp封包的終端叫做VETP(VXLAN Tunnel EndPoint)，而該封包的外層IP address就是該VETP，通常一個物理主機就對應一個VETP
• 如下圖，Outer Mac header紀錄VETP間的通訊，Outer IP Header使得封包可以在第三層傳輸，而裡面用udp包著原始的第二層frame
• 當VM1欲向VM3發送ARP查址時，VETP1會將該封包封裝成VXLAN封包，丟給VETP2後由他進行解析，得知是要給VM3後再將內層封包遞給VM3，過程中VM2、VM4完全不知情，對Switch來說只是Host1、Host2之間在傳遞udp封包

Software-Defined WANs

待補

Access

待補

OVS(Open vSwitch)

Reference : Open vSwitch Documentation

Overview

一個multilayer的software switch，支援802.1QVLAN、VXLAN、Geneve(類似VXLAN的協定)、QoS(Quality of Service)、OpenFlow 1.0等等，forwarding function使用Linux的Kernel module，因此可實現高效率。

Components

• ovs-vswitchd，switch本體的daemon，透過Linux的Kernel Module來實現flow-based的forwarding
• ovsdb-server，輕量級的database伺服器，儲存了configuration與table等等的資料
• ovs-dpctl，用來configure switch的Kernel Module
• ovs-vsctl，用來query或更新ovs-vswitchd的configuration
• ovs-appctl，使用者介面，傳送指令到OVS daemon

Usage

Implement VLAN using ovs

OVS的虛擬交換機能處理虛擬機間的VLAN功能，在預設模式下port對應到一個VLAN tag，進入該port的封包將被vswitch打上該tag，離開時移除。

而OVS的端口VLAN還有其他模式能設置，如：

• trunk，滿足802.1q裡的VLAN trunk，能指定一系列的VLAN tag，負責相同VLAN但不同switch的終端溝通，因此該端口允許所有那些包含的tag傳輸，不在他負責的tag list裡面就drop。若收到不含有VLAN ID的封包，進入switch後該封包tag為0；若收到有tag則進入後仍保持該tag，而若發出沒有VLAN ID的封包則發出後將其802.1q header部分移除
• access，drop所有帶有VLAN ID的封包，只允許不帶有VLAN ID的封包進入，任何進入後的封包將被打上該端口的VLAN tag，而從其出去的封包也將被移除VLAN tag
• native-tagged，類似trunk，差別在若從此端口進入時不帶有VLAN header，將根據此端口的tag將其打上
• native-untagged，類似native-tagged，差別native的封包從此端口出去時將被去掉802.1q header

接下來將使用docker在Ubuntu server 20.05 LTS上實驗其VLAN功能，以下為架構圖：

先build docker image，參考這個Dockerfile來Build出可ssh的centos7 image。

​​​​sudo docker build --rm -t c7-systemd-sshd .

接著建立4個VM，網卡設定none，等等由OVS來為這些VM指定網卡。

​​​​docker run -t -i -d --name vm01 --net=none --privileged c7-systemd-sshd /bin/bash
​​​​docker run -t -i -d --name vm02 --net=none --privileged c7-systemd-sshd /bin/bash
​​​​docker run -t -i -d --name vm03 --net=none --privileged c7-systemd-sshd /bin/bash
​​​​docker run -t -i -d --name vm04 --net=none --privileged c7-systemd-sshd /bin/bash

接著建立兩個bridge。

​​​​ovs-vsctl add-br vswitch0
​​​​ovs-vsctl add-br vswitch1

使用ovs內建的docker工具給予VM1-4 vNIC以及ip位址等。

​​​​ovs-docker add-port vswitch0 eth0 vm01 --ipaddress=192.168.1.2/24
​​​​ovs-docker add-port vswitch1 eth0 vm02 --ipaddress=192.168.1.3/24
​​​​ovs-docker add-port vswitch0 eth0 vm03 --ipaddress=192.168.1.4/24
​​​​ovs-docker add-port vswitch1 eth0 vm04 --ipaddress=192.168.1.5/24

建立switch0到switch1的port，以及switch1到switch0的port

​​​​ovs-vsctl add-port vswitch0 patch_to_vswitch1
​​​​ovs-vsctl add-port vswitch1 patch_to_vswitch0
​​​​
​​​​ovs-vsctl set interface patch_to_vswitch1 type=patch
​​​​ovs-vsctl set interface patch_to_vswitch0 type=patch

​​​​ovs-vsctl set interface patch_to_vswitch0 options:peer=patch_to_vswitch1
​​​​ovs-vsctl set interface patch_to_vswitch1 options:peer=patch_to_vswitch0

patch port: A pair of virtual devices that act as a patch cable. A patch port only has a single option, and that single option is the name of the patch port at the opposite end.

這些端口預設是trunk模式，可以port所有VLAN。

使用VM1 ping看看VM2(192.168.1.3)，方法為使用docker ps後確認其ID，再使用 docker exec 來在該container上輸入指令。

可以看到目前VM1與VM2是互通的。

ping了VM3(192.168.1.4)和VM4(192.168.1.5)發現也可以互通。

於是接下來我們開始為端口加上VLAN tag，先確認先前在show指令中出現的幾個port分別是接在哪個VM上：

接著照架構將VLAN tag設好：

​​​​ovs-vsctl set port 3bf3a0432f004_l tag=100 //VM1
​​​​ovs-vsctl set port e3008375bc014_l tag=100 //VM2
​​​​ovs-vsctl set port c402ab7f04e94_l tag=200 //VM3
​​​​ovs-vsctl set port e22224266c7c4_l tag=200 //VM4

接著重新從VM1測試到其他人的聯通性，會發現除了與他同個VLAN tag(100)的VM2，VM3與VM4都無法從VM1 ping到了。

這次從VM3來做測試：

我們發現VM3仍只能ping到與其同個VLAN下的VM4，VM1、VM2均無法ping到。

後續改動了trunk的範圍，讓trunk port只負責tag 100的封包，之後VM3和VM4也無法正常互ping了。

How to read a paper

The Three-Pass Approach

不要從第一個字看到最後一個字，會浪費太多時間且沒有效率，掌握Three-Pass的方法：

• The First Pass，讓自己對這篇paper的主題有個大致上的認識
• The Secoend Pass，開始對paper的內容有掌握與認識，但還不到細節上
• The Third Pass，有深度的讀懂論文的內容

The first pass

快速地將整篇論文掃過一遍，藉此對論文有初步的大略認識，大概需要五到十分鐘。

• Title、abstract、introduction為重點
• 讀其他幾個section的標題，但不要看其內容
• conclusions為重點
• 掃一眼references區，在心中記下當中你曾經看過的論文

經過the first pass之後，應該對該篇paper有著初步的了解，不管是它的分類、上下文、假設是否為真、貢獻及文筆等，可以使自己決定要不要繼續讀下去。若以後自己要撰寫paper時，也可以想像自己的paper的大部分讀者都會使用the first pass，因此對於以上幾點就必須重點去滿足讀者，在abstract等等的區域顧好可讀性及讓人一目了然該篇paper主題。

The second pass

第二遍閱讀時，開始細心地閱讀，但必須忽略某些細節如某些proof。這會幫助我們找到paper的關鍵重點，也可以在空白處將筆記記上。這大概需要1小時。

• 必須仔細的看過出現的圖片、圖表，還有他們的label、橫軸及縱軸。觀察圖表是否有低級錯誤，可以幫助我們判斷paper的優劣
• 將reference區域沒看過的paper記起來，將來去讀

之後我們應該能將整篇paper的主旨summarize出來，有些時候就算過了第二遍你仍然不能太明白整篇paper的主旨，這可能是該篇論文的文筆，又或是你對這篇論文的背景資料並不熟悉，又或是他使用的proof技巧是必要的（稍早前跳過的），這時候有三個選項可以給你選：

• 放下paper去睡覺
• 先去做好背景知識的補充，再重回paper
• 進行The third pass

The third pass

第三遍的重點是virtually re-implement，意思是設想該篇paper的作者的研究情境，想像自己與該作者做出同樣的假設，並且重新開始進行該研究，同時將自己的想法與paper上真正的研究相比較，這可以幫助我們找到隱藏在paper後的某些失敗與假設。
這次閱讀需要極端的對細節的掌握，了解及對paper出現的每個想法與假設提出質疑，試想自己面對相同問題時會如何應對，這會給我們對於這些presentation與proof一些犀利的、獨到的看法，不只是對閱讀paper有幫助，同時也可幫助我們未來的研究。
這次閱讀對初學者來說需要4到5個鐘頭，但對有經驗的人來說大概只需要一個小時，經過這次閱讀後我們可以從記憶中將整篇論文的結構組合起來，並可以判斷該paper的優缺點，忽略不完整的假設及找到該研究的某些隱藏問題。

Literature Survey

以文獻的調查來說，從Google Scholar或CiteSeer使用較合適的關鍵字來找到3到5篇最近的paper。對每篇paper進行one-pass，接著讀他們的related work區塊，我們應該會找到一個recent work的集合，若幸運的話可以找到recent的survey paper。
若沒有的話，找到引文及相關的重複出現作者姓名，這將會是該主題中關鍵的研究人員，並以他們為關鍵字觀察他們是否有新的paper出現，這會幫助我們找到這個主題的top conferences。
最後，在這些conference網站上觀察他們最新的近況，以及新出的paper。和我們之前找到的paper一起，對這些paper進行second pass，找到他們引用的、之前沒看過的paper，並重複這些步驟。

Related work

• "Writing reviews for systems conferences"-Timothy Roscoe
• Henning Schulzrinne's comprehensive website
• George Whitesides's overview
• Simon Peyton Jones's website