發表文章

目前顯示的是 7月, 2014的文章

如何利用 OpenFlow 打造一個「無廣播」的網路環境

有沒有試過在實驗室網路或是公司網路內打開 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 in the Linux Kernel

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 的專案看到,這樣的設計有什麼好處。

如何利用 Wireshark 來監聽 IEEE 802.11 的管理封包

因為工作的緣故,需要去監聽無線網路的封包,特別是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

今天要介紹的東西是 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