Start a New Journey

語本禮記·檀弓下：「晉獻文子成室，晉大夫發焉。張老曰：『美哉輪焉！美哉奐焉！歌於斯，哭於斯，聚國族於斯。』文子曰：『武也，得歌於斯，哭於斯，聚國族於斯，是全要領以從先大夫於九京也。』北面再拜稽首。君子謂之：『善頌善禱』。」 不知為什麼，我一直對禮記中的這一篇印象深刻，大概是小時候記憶力比較好，所以一直刻劃在心中吧。之前有天我弟要我把時間留下來，要參加他們家的家庭禮拜，結果到了以後才發現原來是新居感恩禮拜（我說，你們小倆口根本已經搬進去很久了吧），然後居然還要說些祝福的話（喂喂，下次這種事要先講，我本來抱定只聽只吃不說話的態度啊），在想要講什麼的時候，第一個浮出的念頭就是「善頌善禱」的這個故事 ... ㄜ ... 不是聖經經文啊，所以就想找找，在聖經中哪一段有「新居落成」的相關經節，可以作為分享，結果就是以下面這段文章來做分享： 王上9：1-10 所羅門建造耶和華殿和王宮，並一切所願意建造的都完畢了，耶和華就二次向所羅門顯現，如先前在基遍向他顯現一樣，對他說：「你向我所禱告祈求的，我都應允了。我已將你所建的這殿分別為聖，使我的名永遠在其中；我的眼、我的心也必常在那裡。你若效法你父大衛，存誠實正直的心行在我面前，遵行我一切所吩咐你的，謹守我的律例典章，我就必堅固你的國位在以色列中，直到永遠，正如我應許你父大衛說：你的子孫必不斷人坐以色列的國位。倘若你們和你們的子孫轉去不跟從我，不守我指示你們的誡命律例，去事奉敬拜別神，我就必將以色列人從我賜給他們的地上剪除，並且我為己名所分別為聖的殿也必捨棄不顧，使以色列人在萬民中作笑談，被譏誚。這殿雖然甚高，將來經過的人必驚訝、嗤笑，說：耶和華為何向這地和這殿如此行呢？人必回答說：是因此地的人離棄領他們列祖出埃及地之耶和華─他們的神，去親近別神，事奉敬拜他，所以耶和華使這一切災禍臨到他們。」所羅門建造耶和華殿和王宮，這兩所二十年才完畢了。 在列王記上的記載裏面，所羅門花了二十年的時間完成了聖殿和皇宮的建造，而現在上帝來參加這個「新居感恩禮拜」。上帝說：「 我已將你所建的這殿分別為聖，使我的名永遠在其中；我的眼、我的心也必常在那裡。 」感謝上帝，這是上帝同在的保證，這是基督徒最喜歡傳講平安的福音：「以馬內利，上帝與我們同在」，以上帝給的祝福來說，沒有比這更大的。可是等等，接下來的話是新居落成時所該給的祝福嗎？一開始還好，可...

最近上班時間都會聽些講道，畢竟塞車實在是太嚴重了一點，也希望女兒可以在耳濡目染之下接觸到正統神學信仰的內容（這個可能太早了點）。前陣子下載了林慈信老師的「 章力生 神學講座：基督教與（西方）哲學的相遇 」，如果不是因為有讀過相關的內容，我想就我一個沒受過哲學和神學訓練的人大概聽不了多少吧。 不過裏面林慈信老師有一個很重要的提醒。林慈信老師說：「被歸正神學吸引的人通常會有兩種發展，一種是愈來愈順服在上帝的主權和帶領之下；另一種則是會離歸正神學愈來愈遠。」這裡林慈信老師所說的歸正神學指得是傳統加爾文的改革宗神學。其實這句話就邏輯上來說就和「動物可以分成兩類，一類是人，另一類不是人」一樣毫無意義，但卻讓我頗授震憾也讓我進行了反思。 我開始接觸歸神學是從聽唐崇榮牧師的講道開始，只是為了聽聽什麼叫作講了七八年的希伯來書。聽了以後發現，有好多的問題是我沒有想過的，有好多的經文是我沒有好好思考的，原來當個基督徒不是做一個世人所以為的「好人」外加相信耶穌從死裡復活就好了。我開始對神學以及這個和神學糾纏不清的哲學產生了興趣。插一句題外話，我認為唐牧師常常從哲學的角度切入信仰在現在並不是什麼好方式，因為現在的人愈來愈不讀書，也愈來愈缺乏哲學思辨的訓練（是說我也好不到哪裡去就是了）。被吸引後，開始去讀了神學以後才發現，天啊，這世界上充斥的理論也太驚人了吧 ... 以前許多在教會主日學完全不會被提到、或是被一般基督徒認為是錯誤的理論都有，不是像各種千禧年理論那樣不一定要確信的理論而已，而是像是聖經是不是神的話，因信稱義是不是正確的這些關乎就恩的知識。這些被包裝在學術的外衣之下，雖以神學為名，卻遠離了上帝，把上帝的話當成人類的作品來分析與討論而不以上帝為上帝，這就叫作被吸引進來，卻又被吸引離開吧，而我或多或少，也感受到了有這樣的人存在。 至於我，我只能說：「感謝上帝的保守」。我信上帝，是出於祂的恩，除此以外，我再也想不到任何理由。 弗2:8 你們得救是本乎恩，也因著信。這並不是出於自己，乃是神所賜的。 追根究底， 耶穌愛我我知道，因有聖經告訴我。

話先說在前面，這篇文章完全不會提到任何和 mininet架設、操作有關係的內容，因為這部份我都請同事代勞了（明明就是威脅加恐嚇還不給胡蘿蔔，誰叫我沒有胡蘿蔔） ，也因為這樣所以我沒有寫任何相關的文章，反正網路上已經一大堆了。 會想寫這篇文章是因為一個學生跟我說的一句話：「我的老師覺得 mininet 只是模擬器，不是很真實，所以他要我們參考網路上的文章，把 openvswitch（縮寫為 ovs）放到 AP 上來進行實驗。」聽到這句話我我第一時間完全不知道該怎麼回答。mininet 是不是模擬器？是！mininet 算是模擬器，既是模擬就有一定程度的不真實性，但是那個老師知道 mininet 的運作原理嗎？ mininet 是 Stanford 大學 Brandon Heller 的研發成果，它的概念很單純，就是利用 Linux Kernel 所提供的 network namespace 概念來建制虛擬環境，而每一台的 openflow switch 或是 host，其實就是一個獨立的 namespace。相關的概念可以參考我之前寫過的文章 linux network namespace 。而在 mininet 裏面，OpenFlow switch 的部份就是直接使用 openvswitch ，也就是說，使用 mininet 和把 openvswitch porting 到 AP 上是幾乎一樣的效果。知道這些細節以後，我在使用 mininet 上就會比較放心了。畢竟最後的問題就是一台主機的運算資源能不能負擔這麼多個 namespace 的問題，而這 performance 的議題難道會因為 porting 到 AP 上就不存在嗎？ 我在意的地方到不是老師的質疑，而是大部份我看過的學生，在 mininet 的使用上都不會去深入了解它的原理。為什麼被老師問一下就回答不出來，為什麼報告 mininet 只會停留在操作的層及而不會進一步去釐清它的實作技術？只會照著文件一步一步的操作，是很難做到舉一反三。其實我也不是多勤勞的傢伙，會去研究這東西只是因為在某次報告中要介紹相關技術，為了不要讓自己講的很心虛所以就稍微研究了一下。但盼望不要因為當工程師愈來愈久之後，就忘記了最初研究的樂趣。 ... 總的來說，這是我對自己提醒的文章。

會寫這篇文章最主要的理由在於，我發現很多人（包含我自己的長官以及眾多的指導委員）對於 OpenFlow APP的看法和我不一樣（這是客氣的說法，其實是 我認為他們的想法是錯誤 的）。所以囉，我決定整理一下自己的想法並寫在這裡，希望有興趣的人可以一起參與討論（雖然沒多少人看吧），一方面可以檢討自己的想法；二方面可以宣傳自己的理念。在這邊要先說明一件事，SDN 是一個概念而非實作上的技術，因此幾乎所有的東西都可以套入 SDN 的概念，因此我在這裡不談 SDN APP，而只單單著重在 OpenFlow APP。 很多人都期待 OpenFlow 可以帶來新的網路應用服務，well ... 單單這件事就有點問題，OpenFlow 算是一種 網路基礎建設的新型態架構 ，那麼我要問問，網路基礎建設所負責最主要的功能是什麼？答案很簡單，就是確保網路中的用戶端設備彼此之間能夠順利的連通，不管是 L2 switching 或是 L3 routing，那我們回到最基本的問題，請問目前的網路設備（我是指 L2/L3 的 switch 和 router）沒有辦法達成這一類的功能嗎？答案是，當然可以，不然我們現在用的網路是假的嗎？既然如此，那使用 OpenFlow 到底有什麼好處？使用 OpenFlow 最大的價值在於，我可以用新的想法來處理 L2 switching 和 L3 routing，藉由新的巧思，來達到比過去更好的網路效能或是使用率。有沒有例子？最簡單的一個例子就是 Broadcast 的封包處理概念，相關的細節可以參考下面的連結。 如何利用 OpenFlow 打造一個「無廣播」的網路環境 在這裡我可以斷言， 如果使用了 OpenFlow 的架構卻在思考網路問題上停留在傳統網路的思維，下場是網路的效能只會變得比過去還差。 現在面對的問題是，很多人問說，我可以不可以用 OpenFlow 來做到一些網路應用服務功能，如 Firewall、IDS/IPS 等，然後說用 OpenFlow Switch 會比較便宜，他們的理由是硬體規統、功能統一化，而且不用被網路大廠所把持。事實上，我也看到有台灣廠商投入在這一塊的發展（如果他們問我的話，我一定會加以勸阻），為了不想惹麻煩上身，姑且保留公司名稱不提。我為什麼認為這種發展方向是有問題的呢？第一， 你會期待網路基礎建設中每台設備都...

我個人比較喜歡的 IPC 技術是 Unix Domain Socket，因為可以 統一透過 File Descriptor 的處理機制來進行管理 ，如 epoll 或是 select 等。但即便是這樣，還是很多人會跟我說：「你有考慮過 Shared Memory 的方法嗎？效能應該會比較好唷。」我當然知道囉，不過隨著年紀增長，已經不再像以前一樣汲汲於效能上微小的差異（I mean ... 人的感受程度），而會把開發、維護的容易程度放在考量的第一位。所以我的第1選項目前都是：Unix Domain Socket，不但如此，之後也很 容易直接改成網路的 socket 程式 ，何樂而不為。但因為以後可能還是有遇到必須使用 Shared Memory 的情況，所以還是寫篇文章來紀錄相關的資訊。 Shared Memory 的 IPC 方式，顧名思義，就是兩個 Process 直接存取同樣一塊的記憶體空間。一般來說，兩個獨立的 Process 都會有各自的 Virtual Memory 位址管理，彼此之間是無法互相存取到的。而使用了 Shared Memory 的機制，系統核心就會準備一塊記憶體位置並讓兩個 Process 都能互相存取。用下圖可以表示 Shared Memory 和 Unix Domain Socket 的不同： 上圖左邊雖然是寫 Unix Domain Socket，但其實用 lo 來做 UDP socket communication 也是同一類。我個人認為上圖很明顯的說明了兩種方式的效率差異。在網路上看到一篇很不錯的效能比較文章，連結如下： Tcp Socket vs. Unix Domain Socket vs. Pipes vs. Shared Memory 這個網頁只有一個小缺點， 他不應該用 TCP Socket 來比較而應該採用 UDP Socket ，理由是 TCP 的 Overhead 大於 UDP，而本機端的溝通應該用不到那些機制。考量到外部網頁連結不一定會持續存在，因此我將相關的圖節錄如下： 接下來就是撰寫範例程式了。在這裡會撰寫兩隻程式，一支負責傳送資料，另外一支負責接受資料。範例的參考連結在下面： http://www.cs.cf.ac.uk/Dave/C/node27.html...

最近請人協助架設環境，但似乎進度不如預期。所以一怒之下（ 開玩笑的，我這人一向與人為善，您說是吧 ... ），就自己來架設NAT64的實驗環境，而這篇教學就是自己架設的過程紀錄。所以本篇文章告訴我們，少發脾氣比較好 ... （ 畫錯重點了吧 ） 在紀錄相關實驗步驟的時候，先來說明一下什麼是NAT64。Wikipedia上的描述是：「 NAT64 is a mechanism to allow IPv6 hosts to communicate with IPv4 servers. 」簡單來說，就是讓IPv6的設備能夠連上傳統IPv4網路設備的機制。怎麼做呢？看到NAT這幾個字眼應該用猜的也猜的到， 就是把封包的IPv6 Header替換成某個預先設定的IPv4 Header就完成了 。這裡要特別強調的一點，這個技術是 讓IPv6的設備能夠連上IPv4的設備，並不是讓IPv4的設備能夠連上IPv6的設備 ！理由呢？下面這個解釋是從 TAYGA 的網站上抄下來的： It is technically impossible for a translation system operating purely at the IP layer to allow IPv4 hosts to establish connections to any arbitrary IPv6 server. Such a system would need to represent every IPv6 server on the Internet with a unique IPv4 address, which is clearly infeasible given the size of the IPv6 address space. 當然我個人有另外非技術的解釋，NAT64是為了讓過去已經存在的IPv4 Server可以繼續提供服務，而如果連Server都已經是IPv6了，現在的client大部份都有IPv6的介面了啊，直接用IPv6來溝通不就好了。 這邊的紀錄著重在於架設環境以及實驗，相關工具的程式碼解析不在範圍內（因為我沒有這麼多時間）。 1. 實驗環境 實驗環境的圖如下： 在這邊解釋一下NAT64的設定。IPv4和IPv6是指NAT64自己的I...

上次介紹的部份是利用 openvswitch 來打造 OpenFlow switch，這也是大部份目前市面上買的到的 OpenFlow switch 所使用的軟體。問題是，它的傳輸效率不太好，畢竟它是透過 Linux kernel 來處理 Flow Entry。有人可能會說：「不會啊，我買的 switch 傳輸速度沒有問題啊，幾乎都可以達到 line rate」，OK，這是因為這些市面上賣的 switch 大部份都移植 Flow Entry 到處理程序到硬體平台上（像是 Broadcom 的晶片），所以傳輸速度當然不差， 可是！很多 OpenFlow 的功能就不支援了 ，畢竟那些晶片本來就沒有提供這些功能啊（通常是Set Field）。我們可以將目前 OpenFlow switch 的狀況大概整理如下： Software-based OpenFlow switch 功能支援度高，容易升級，但傳輸速度慢 Hardware-based OpenFlow switch 傳輸速度快，但功能並不完善 有沒有能夠兼顧兩者的設備呢？今天要介紹的這套 Lagopus 就是一個可能的選項。 Lagopus 是 NTT 所開發的 Software OpenFlow switch。Software？那傳輸速率呢？為了解決這個問題，Lagopus 採用了 Intel 所推出的 Data Plane Development Kit (DPDK) 技術。下面我們就先來介紹什麼是 DPDK。 DPDK簡介 DPDK 這個技術的概念可以用下圖來表達： DPDK（資料來源：Intel） 這張圖說明了 Intel 的 DPDK 技術是如何加速封包的處理。大概解釋一下。傳統 Linux 封包處理流程，是硬體收到封包後觸發 interrupt 後導到 Linux Kernel，如果還要進入 user space，就要通過 copy_to_user/copy_from_user 這樣的機制，而這會牽扯到記憶體拷貝的問題，這是因為不能讓 user space 直接讀到 kernel space 的記憶體管理，免得造成系統錯誤，所以作業系統會用一塊虛擬化的記憶體位置來給 user space 的 process，而這種記憶體保護機制以及拷貝很吃系統資源，這也是為什麼傳統上在處...

我很喜歡聽唐崇榮牧師講道，從信友堂時期的希伯來書查經開始，他的講道刺激了我更花時間去研究上帝的話，也好好地反省自身的信仰。有一次，我問一個朋友廳唐牧師講道的感想，他回答：「聽的很過癮。」聽上帝的道覺得很過癮，那很好啊，可是對他來說，這是一場演講，內容精彩，外加唐牧師那種「橫眉冷對千夫指」的氣勢（是說近幾年實在是溫柔多了），就算作為一場收費演講演講也絕對值回票價。但，這是對於聽上帝的道的正確態度嗎？ 靈修經文： 使徒行傳17:21 雅典人和住在那裡的客人都不顧別的事，只將新聞說說聽聽。 使徒行傳24:24-27 過了幾天，腓力斯和他夫人─猶太的女子土西拉─一同來到，就叫了保羅來，聽他講論信基督耶穌的道。保羅講論公義、節制，和將來的審判。腓力斯甚覺恐懼，說：你暫且去吧，等我得便再叫你來。腓力斯又指望保羅送他銀錢，所以屢次叫他來，和他談論。過了兩年，波求非斯都接了腓力斯的任；腓力斯要討猶太人的喜歡，就留保羅在監裡。 靈修分享： 在使徒行傳裏面描述了兩種人很喜歡聽保羅講道。第一種是雅典人，他們一向很喜歡研究哲學的思辨（或許對現在的人來說是無用的清談？），他們去聽保羅講道，對他們來說，基督的救恩是很新鮮的學問。另外一種人則是腓力斯。他想向保羅收錢（他是憑什麼覺得保羅會有錢啊？），但我相信他也是覺得保羅的談話很有一些趣味，不然也不用談論了（一直關著不就好了）。這兩群人都很常聽到保羅的信息，但，他們有得救嗎？ 答案應該很明顯，因為他們和他們所聽到的道一點關係也沒有，只是當成是另外一種學問罷了。 那我呢？ 我印象中聽過（還是看過）康來昌牧師的一篇講道，他說他本來只想在神學院教書，並不想牧會，因為不想和人建立太深厚的關係，也因為覺得不夠有愛心，後來才被教會長輩半勸半強迫加入信友堂的教牧團隊。聽到這裡，我也在反省我自己。人家以為我對聖經、神學有點熟（真是天大的誤解！），會不會只是我自己認為「這道很有趣」、「研究學問很有趣」，所以比一般信徒多花了點時間在這些事情上面（當然和神學家、神學生還是不能比啦），但這樣的心態跟我打電動有啥兩樣？還是要顯示我比其他的人厲害、多懂一些看起來很神聖的知識？這只不過是成就自己的驕傲罷了（恩，但其實看過了太多更厲害的人，所以大概驕傲不起來吧） 唐牧師講過一句話：「 當你在研究神學時，要把神當作主體，不能當作研究的客...

有沒有試過在實驗室網路或是公司網路內打開 wireshark 來收收看封包？就算自己什麼網路行為都沒做，還是會發現收到一大堆不是自己該收到的封包。為什麼？因為網路上充斥太多的廣播訊息了！什麼是廣播封包？首先，我們先將目光集中在同一個 subnet 中（一般來說，目前的網路設備通常不會讓廣播封包傳到 subnet 的外面），廣播封包就是一種讓同一個 subnet 裏面所有的成員都要收到的封包。常見的封包有 IP 位置為 255.255.255.255 或是 192.168.1.255 這一類的封包以及 MAC 位置為 FF:FF:FF:FF:FF:FF 的訊框。 一般來說，廣播封包的存在有兩個意義： 我不知道我想溝通的對象在哪裡，所以我只好大聲的呼喊希望那個對象會來回應我。 造成這種情況的主因是因為當初網路在設計時是採用分散式的架構。因為分散，所以沒有人知道整個網路的狀況。既然不知道，就只好所有人都去問一遍，這個行為就是廣播。常見的例子是 ARP 以及 DHCP DISCOVER 等。 所有人注意，下面是關於我的資訊 ... 這種情況通常是要招告天下關於我的資訊，所以本來就會廣播給所有人知道。常見的例子是 NetBios 以及 IPv6 Neighbor Discovery 等。 因為過去網路發展的因素，廣播信息似乎是必要的。但其實大部分的人都很討厭廣播，因為在大多數的情況下廣播信息根本不是自己要收的啊，就像是一開始提到的例子。網管人員一般來說也很討厭廣播，因為只會白白佔掉網路頻寬而已。 現在來想想 OpenFlow 的架構，OpenFlow 是一個邏輯上集中式的網路架構，並且在這網路上有個神一般的角色：OpenFlow Controller。那麼，還需要廣播信息的存在嗎？ 我不知道要溝通的對象在哪裡？沒關係，Controller 應該知道 ； 招告天下，不用，告訴 Controller 就好了 。當然要改變 Host 的行為是不可能的事情，但我們可以透過 OpenFlow Entry 的設定來 透過非廣播的方式來處理廣播封包 。 在額外多討論一件事情。當網路上不存在廣播封包時， 請問一個 Loop-Free 的網路是否還是必須的？換句話說，我們還需要 Spanning Tree Protocol 嗎？ 歡迎大家提出自己的意見（有人會留言嗎？） ...

Control Groups （簡稱 cgroups ）是 Linux Kernel的一個功能。會開始注意到它是因為上次在研究 Linux Network Namespace 時第一次看到這個名詞。簡單來說，在 Linux Kernel 裏面，對資源的分配採用了 group 的概念，每一個 process 都會屬於某個 group，而每個 group 之間資源是彼此獨立的（isolation），並且也可以針對每個 group 進行資源限制以及計費。看到上面的描述大概就知道它要幹嘛了吧 ... 恩，這個計劃的初始提案人是 Google ... 完全不讓人意外。 在每個 group 裏面，Linux Kernel 提供了各種 Namespace 來進行資源的獨立： PID namespace Network namespace UTS namespace Mount namespace IPC namespace User namespace 因為並沒有深入研究，所以就不寫太多了。但可以從 docker 的專案看到，這樣的設計有什麼好處。

因為工作的緣故，需要去監聽無線網路的封包，特別是IEEE802.11的管理控制訊框（frame ... 其實我還是比較喜歡直接叫作封包）。同事直接打開 wireshark 卻擷取 wifi 介面，卻發現聽到了一堆 ethernet 的訊框而聽不到 wifi 的訊框。為什麼呢？來看看 wireshark 的官網 怎麼說： If you're trying to capture network traffic that's not being sent to or from the machine running Wireshark or TShark, i.e. traffic between two or more other machines on an Ethernet segment , or are interested in 802.11 management or control packets , or are interested in radio-layer information about packets , you will probably have to capture in " monitor mode ". This is discussed below. Without any interaction, capturing on WLAN's may capture only user data packets with "fake" Ethernet headers . In this case, you won't see any 802.11 management or control packets at all, and the 802.11 packet headers are "translated" by the network driver to "fake" Ethernet packet headers.  答案揭曉，原來這是因為 wifi driver 會自動把 wireless frame 轉成 ethernet frame 後再給 kernel，這樣 kernel 裏面的 proto...

今天要介紹的東西是 Linux Network Namespace。為什麼會知道這東西呢？主要是因為在研究 SDN 模擬器 mininet （正確來說是 OpenFlow 模擬器）時，發現它是透過 Linux Network Namespace 這個技術，將每個 Host 以及 Switch 獨立開來（Isolation），並在當中建立起虛擬的連線，藉這個概念在一台電腦內打造出虛擬的網路拓樸。所以就想說花點時間來看看如何使用這個技術。 我們先來看看在 Wikipedia 上關於 cgroups 的介紹： cgroups (abbreviated from control groups) is a Linux kernel feature to limit , account , and isolate resource usage (CPU, memory, disk I/O, etc.) of process groups. Namespace isolation While not technically part of the cgroups work, a related feature of the Linux kernel is namespace isolation , where groups of processes are separated such that they cannot "see" resources in other groups. For example, a PID namespace provides a separate enumeration of process identifiers within each namespace. Also available are mount, UTS, network and SysV IPC namespaces. 簡單來說，就是透過 group 這樣的觀念，讓每個 process group 間所使用的資源能夠獨立開來而不會互相影響。而這樣的 group 就被稱做是 namespace。而今天要看的是 Network Namespace。用例子來看或許會比較容易了解，下面的例子主要是參考 這個網頁 所建立出來的。 1. 建立 N...

這邊是 2014.06.23 在元智大學介紹  SDN 所使用的簡報。這幾份簡報基本上已經覆蓋了 SDN 的技術研究以及實際開發所需要的背景，很適合當作入門的簡報。當中還缺少一份關於 OpenFlow 的介紹，因為那是我同事製作的，不方便放到我自己的 Blog 上面，所以之後我自己補上那一份的自行製作的投影片。另外，我很討厭我公司的簡報背景，所以我換了自己喜歡的 template 才放上來。 如果有人需要我去簡介的話，歡迎隨時跟我聯絡，我很樂意唷！ 01.Introduction.to.SDN 這份投影片是從故事入手，幫助大家輕鬆學習 SDN 的概念，也同時帶出業界不同公司的不同看法。 02.SDN.Research.Tools SDN 很紅，但如果要做研究，應該要從何上手？OpenFlow Switch 很貴，我該怎麼辦？這份投影片介紹目前 SDN可使用的相關工具，並給了自己的 Comments。 03.SDN.APPs 軟體定義網路，關鍵當然在軟體（智能），該怎麼設計自己的網路才是 SDN 的真正關鍵。本份投影片介紹了 SDN App 的設計概念，透過實際的例子來帶出 SDN 創新思維。

Netfilter 是 Linux Kernel 裏面對於網路封包處理一個非常有趣的設計，它在 Linux Kernel 的封包處理路徑上安插了許多的 Hook Point，這樣使用者可以隨自己的高興在這些 Hook Point 上安插自己的封包處理行為（使用註冊 callback function的方式），常見的應用如防火牆檢查、NAT等。在這邊稍微提一下，很多人會說 Linux 是用 iptables 來做防火牆的，我不太喜歡這個說法（但我不會說它是錯的），因為 iptables 不過是設定 netfilter 的 user space 工具，當你使用 iptables 時，不過就是將那些功能模組配合上使用者輸入的參數，然後掛載到對應的 Hook Point。下面是來自官網的描述： netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack . A registered callback function is then called back for every packet that traverses the respective hook within the network stack . 至於有哪些 Hook Point 可以參考下面這張來自 Wiki 的圖：  這個概念是從 Linux Kernel 2.4 以後就內建在核心的機制。基本上我在研究所很常利用 iptables 這個設定工具來使用 netfilter，但一直沒有實際寫這 callback 的機會（之前工作上沒碰到，外加人懶）。但現在因為工作上有特殊的需求（來自一個莫名其妙的設計），所以就請（逼迫？）我同事撰寫了一個 Netfilter Callback 的模組範例出來（從程式裡可以找到作者），下面就是這個範例： # include < linux/module.h > # include < linux/kernel.h > # include < linux/init.h > # include ...

今天要介紹的，不是什麼新技術，只是之前沒碰過，而現在工作有用到，所以做個私人紀錄。 問題描述以及過去的解決方案 工作上面遇到的問題，如何建立一張虛擬的網路介面，並且讓封包經過該介面後額外封裝一個新的 Header。建立虛擬網路介面不難，但要如何去撈封包（使封包經過該介面）呢？並且之後封包的處理又是如何？之前在公司曾經用過幾種招數： 第一個作法是透過 Bridge 來將網卡綁在一起，然後去修改 Bridge 的程式碼做自己想做的事情。第二個作法是透過 Netfilter 來攔截封包，做完事情以後再硬導到正確的網卡。這兩個作法很 亂來 ，我的亂來指的是不理會 Linux 內部封包處理流程，隨意的處理並安插封包，但我可沒說這樣做不到啊。第3種方法很好，完全符合 Linux 核心的封包處理程序，代表的例子就是 GRE，問題是現在的封裝技術亂七八糟（這個詞純粹是為了抱怨用），並不一定是單純的 IP-in-IP ，所以這個架構不一定適用。正當決定來亂搞的時候，有人提供了一個新的方向（應該是說自己孤陋寡聞）：TUN/TAP。 TUN/TAP: Virtual Network Kernel Device 我們先抄一下 Wiki 上的說明： In computer networking, TUN and TAP are virtual-network kernel devices . Being network devices supported entirely in software, they differ from ordinary network devices which are backed up by hardware network adapters. TUN (namely network TUNnel) simulates a network layer device and it operates with layer 3 packets like IP packets . TAP (namely network tap) simulates a link layer device and it operates with layer 2 packets like Ethernet frames . TUN is used...

這是一個在網路上很常見的問題，因為自己碰到了，所以就留下紀錄囉。 用 Linux 開發網路設備的人，應該很常使用下面的這命令： echo 1 > /proc/sys/net/ipv4/ip_forward 想當然，這是 root 才能做的事情，那麼，在 ubuntu 裏面，很自然就會用下面的指令執行： sudo echo 1 > /proc/sys/net/ipv4/ip_forward 實際執行結果居然是 Permission Denied ？？ 其實會出現這個問題， 主要的原因在於 shell 在執行 redirect 的流程 。上面的指令對 shell 來說其實等於下面兩個指令： "sudo echo 1" 以及 redirect to "/proc/sys/net/ipv4/ip_forward" 很明顯，真正需要 root 權限的第二個步驟反而沒有 root 的權限。所以系統當然會說 Permission Denied。解決的方法如下： sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" 這就不用說明了吧

好久沒寫了 ... 人果然是懶惰的，但願能有始有終，把整個列王給完成。下一個登場的王是以色列王約蘭。聖經中叫約蘭的王還有另外一位，這位是北國的王，在列王記下佔了眾多的篇幅唷，可見他的重要性（才怪，大部份是以利沙的紀錄，這篇是不是應該改名叫以利沙啊）。那，開始了！ 姓名： 約蘭 國家：北國以色列 對應的南國君王：約沙法、約蘭、亞哈謝 （取名有創意一點吧 ...） 聖經記載： 1. 以利亞升天（王下2:1-18） 2. 醫治耶利哥的泉水（王下2:19-22） 3. 以利沙與童子（王下2:23-25） 4. 三王戰摩押（王下3） 5. 以利沙與寡婦和書念婦人（王下4:1-37） 6. 以利沙的食物神蹟（王下4:38-44） 7. 乃縵得醫治（王下5） 8. 失而復得的斧頭（王下6:1-7） 9. 與我們同在的比與他們同在的更多（王下6:8-23） 10. 撒馬利亞解圍（王下6:24-7:20） 11. 歸鄉的書念婦人（王下8:1-6） 12. 哈薛篡位（王下8:7-15） 13. 耶戶叛變（王下9:1-26） 1. 以利亞升天（王下2:1-18） 以利亞的工作要結束了，神要將他接去。他對以利沙說：「耶和華差我往伯特利去，你可以在這裡等候。」很明顯，他其實不想帶以利沙去，康來昌牧師對這一段有些有趣的解釋，他認為以利亞其實不太喜歡以利沙，因為以利亞去撿選以利沙的時候，以利沙跟他說：「求你容我先與父母親嘴，然後我便跟隨你。」而沒有直接來跟從以利亞。Well ... 也許吧，但聖經也沒明顯這樣說，所以我也不知道是不是，但毫無疑問，以利亞三次試圖要把以利沙拋下，但以利沙的立場非常堅定：「我指著永生的耶和華，又敢在你面前起誓，我必不離開你。」（王下：2:3、5、6） 為什麼以利沙這麼不聽話？看到以利沙的行為，讓我想到了聖經中的另外兩個人：雅各、路得。雅各在毘努伊勒和上帝摔跤（創32:24-30），並堅決不讓上帝離開，堅持要上帝的賜福；當拿俄米對俄珥巴和路得說：「你們各人回娘家去吧。」雖然一開始兩個人都拒絕，不過最後只有路得一個人和拿俄米回去。以利沙在以利亞身上、雅各在那個人身上、路得在拿俄米身上，我覺得他們都從這些人背後看到了上帝，他們也很了解「 神啊，你的慈愛何其寶貴！世人投靠在你翅膀的蔭下。 」（詩36:7），所以他們才會做出這...