本文屬於論文導讀系列，這次針對的是SIGCOMM 2017所發表的論文中關於Data Center架構的論文。SIGCOMM這個 Conference裡面都有很多跟網路相關且高品質的論文，除了學界之外，也常常有很多業界會將相關的研究與產品設計投稿於此，因此是個滿好學習網路概念的一個資源。本篇文章針對的主題是 Re-architecting datacenter networks and stacks for low latency and high performance, 該文主旨希望重新打造一個有真正高傳輸效能的資料中心，其中涉及了非常多的面相，從交換機的實現到上層 TCP 協定的修正，從諸多面向來探討傳統的諸多協定為什麼沒有辦法達到真正的高效能傳輸，該論文非常精彩，可以學習到非常多的概念與知識，非常歡迎閱讀。
本篇文章主要的概念是閱讀筆記, 主要是針對 Google 於 2018 Sigcomm 所發表關於 SD-WAN 的相關論文,這篇論文非常直得一看的點是這篇論文算是 2013 Sigcomm B4 論文後的後續，講述了 SDN 概念引進 B4 帶來的好處以及這幾年因應環境變化而該 B4 資料中心的成長，其中包含了眾多的問題以及處理的方式，著實非常有趣，能夠學習到更多的想法與概念
Binomial Heap是由一群 Binomail Tree所組成的
這邊簡單紀錄一下一種QoS的使用方法，實驗流程如下
Introduction
本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以瞭解每個開放出來的 Restful API 該怎麼使用。相對於文件的更新速度，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。
這篇文章用來介紹在 Fllodlight 中是如何去完成下列事情, 1)不使用 Spanning Tree Protocol 的方式也能夠正確的在有迴圈的網路拓樸中來傳輸封包，2) 針對任意兩個點對點的網路節點，能夠找到一條最短的路徑用來傳輸封。 這些事情在該控制器中，其實是透過計算一個 Tree 的方式來完成所謂的 Broadcast Tree, 藉此避免廣播風暴的問題，同時透過 Djikstra 的演算法來在拓樸中找到一個最短路徑來傳輸封包。
問題來源:
Floodlight把module分成core跟application兩個方向為主
在floodlight這個openflow controller中，對於module之間的執行順序是如何決定的，這部分很重要
本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以學習到其內部是如何轉送封包的，藉由 Topology 模組提供的 Global Topology 資訊, Floodlight 可以從該資訊中對於任何一個點到點的之間的連線找到一條傳送路徑。接者針對這傳送路徑上所有的交換機輸入對應的 Openflow 規則來幫忙轉送封包。相對於文件的更新，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。
本文基於 SDN Controller Floodlight 的原始碼進行了一次簡單的分析，藉由分析這些原始碼更可以學習到其內部關於網路拓樸的處理，這些拓樸除了影響 Controller 怎麼看待整個網路之外，也會間接的影響該 Controoler 要如何去正確的轉送封包。相對於文件的更新，程式碼本身的迭代速度更為敏捷，因此常常會發生文件跟不上實際運行功能的案例。藉由學習閱讀原始碼，我們可以更快也更清楚的掌握當前這些開源軟體的發展狀態，甚至也能夠貢獻社群幫忙補齊文件。
Introduction
上一篇mininet-and-network-subnet中提到如何在mininet中創造不同subnet的網路，並且透過手動下flow的方式讓不同subnet的hosts可以互相溝通。
Introduction
Purpose
對於 SDN Controller 來說，最基本的功能就是要可以傳輸封包，然而在這種集中式管理的情況下，傳統的 Spanning Tree Protocol 不會運行。因此 Controller 本身要有辦法判斷當前的網路拓墣中是否有迴圈以避免產生廣播風暴。本文會透過觀察原始碼的方式來研究在 NOX Conroller 是如何實現的。
探討如何運行 ONOS Trellis
本文基於 Openflow 1.0 的規則書，跟大家分享一下在 Openflow 的規範裡到底什麼叫做 Port, 以及有多少種相關的 Port，在使用上要注意些什麼。
在Openflow的協定中，有時候會想要知道每條`link`的`capacity`,然後就可以藉由當前的rate來判斷這個Link是否壅塞。 本文嘗試使用 `Floodlight` Controller 作為範例來展示如何使用透過預設的 API 來取得每個 Port 的資訊，並且從中計算出當前這條 Link 是否屬於壅塞或是閒置。 這類型的機制與資訊對於想要完成 Traffic Engineering 的開發者來說非常重要，畢竟這是其中一種可以幫每條連線加上權重的一種方式
ovs-vsctl add-port br eth1
Environment
hmap 是一種hash bucket的資料結構，在 OpenvSwitch 中到處都可以看到其身影，，譬如 kernel space 中的 flow_key 就是透過這種結構來存放的。本文會檢視一下該 hamp 的結構，並且稍微看一下關於插入這個動作的原始碼
This post shoes about what the system do when we install the OpenvSwitch in your system. The architecture of OpenvSwitch covers both user-space and kernel-space and we can see functions of each part in this porsts.
In this post, I try to study the soruce code of openvswitch to learn how does the openvswitch kernel module works.
這篇文章中，我們決定透過閱讀原始碼的方式，來瞭解 OpenvSwitch 操作上最常使用的指令，也就是 add-port 這個指令每次運行時，整個系統到底怎麼運行的。藉由閱讀原始碼的方式來釐清整個 OpenvSwitch 的架構，從 User-space 的程序到 Kerenel Space 的 Module, 這中間到底是怎麼處理的。
這篇文章帶領大家透過閱讀原始碼的方來學習如何 OpenvSwitch 是如何處理封包的，當底層的 Kernel Switch(datapath) 沒有辦法轉發封包時，要如何將該封包送到上層的 User Space Table 進行 Openflow 規則的查詢。這部份牽扯到資料如何橫跨於 User-Space 以及 Kernel-Space.
本文介紹了一種將 Contaienr 創建於 OpenvSwitch 與 DPDK 整合的網路拓墣下所遇到的連線問題。開頭先闡述了拓墣架構以及相關的軟體版本，接者介紹是如何搭建起整個測試環境，並且在測試環境中遇到了網路連線的問題，眾多的測試組合中，卻只有一種組合能夠正常的在 Container 間建立起能夠傳輸的 TCP 連線。最後透過 AB 測試的方法歸納出一些會造成問題出現的環境。
本文延續前篇文章關於 Docker/OpenvSwitch/DPDK 整合遇到的連線問題，此文章會專注於這個連線問題，從問題發生的原因到如何解決，以及該問題為什麼會在上述的組合中發生都進行一些研究與分析，雖然最後還沒有找到真正造成封包損壞的原因，但是至少也把問題範圍給縮小到 OpenvSwitch/DPDK 上.
Question
Introduction
Introduction
這篇文章要跟大家分享在 OpenvSwitch 裡面內建的 Bonding 模式，相對於傳統 Linux Kernel 自帶的六種模式，OpenvSwitch 只有提供三種模式。這三種模式的用途以及分配的方式都完全不同，完全取決於使用者本身的環境需求，來判斷自行的環境需要採用哪種模式，有單純的 Active-backup 模式，也有 Active-Active 的模式。再 Active-Active 的模式中要如何去分配封包，可以針對 Layer2 也可以針對 Layer3/4 的環境來使用，這部份就是依賴管理員去思考的。
這篇文章主要分享如何於 Wireshark 中安裝額外的模組使得其有能力去解析 OpenFlow 的封包結構，對於研究 Openflow 的人來說這是一個很好使用的工具，能夠觀察 Switch to Controller, Controller to Switch 等各種封包.
相信不少開始學習 SDN 的人一定都有聽過 mininet 這套軟體，甚至大量使用過。