Multicast簡介及在 OpenStack 環境上的實作

Unsplash

Multicast 在網路上並不是個很常見的應用，不過在一些領域如多媒體、以及其他的應用上很常見，亦用於一些測試環境，這邊將會簡單介紹何謂Multicast 以及其在 OpenStack 私有雲上的實作方式。

Multicast 簡介：何謂 Multicast？

在路由的形式中，主要有 Broadcast (廣播)、Anycast (任播)、Unicast (單播)、本篇介紹的 Multicast (多播)、以及地域性廣播 (Geocast)。其中Unicast、Anycast、及 Broadcast 是很常見的傳輸種類，他們大多是配合 IP 以及區網的形式進行傳遞。比如一般的網路連接，比如上網連到網站等，多數都是透過 Unicast 進行路由連接；而比如家中路由器常會使用 DHCP 進行家中設備的 IP 配發，也有部分採用了 Broadcast。

Multicast 從表面上看起來與 Broadcast 相似，但後者是將資訊傳遞到同一個網域內的所有節點，而前者則是有被納入進廣播群組內的節點才能收到封包。而 Multicast 可以做一對多或者是多對多的傳輸，因此只要是在群組內的節點或是區域，都可以接收到 Multicast 封包。

Multicast 簡介：常見應用與麻煩之處

而 Multicast 的最大優點，就在於傳遞過程中間的路由器、交換器等設備，在接收到 Multicast 封包資訊時，會自動複製並分發到下一層在群組內的設備，因此能夠減少來源端的傳輸頻寬；若為使用 Unicast，則會大幅增加來源端的頻寬傳輸，因爲來源端都需要為每一個連線傳輸資料，接收者一旦增加，也會加重來源端的網路負擔。

也因此，Multicast 很常被使用在視訊方面的應用，比如 IPTV、視訊會議、網路直播等，因為這類應用所使用的網路頻寬相當大；有資訊即時同步或者協同處理需求的相關應用也多少會使用 Multicast 技術，不過這些通常都是在內部網路所使用的範圍居多。

在台灣，目前最耳熟能詳的 Multicast 應用，即為中華電信的 MOD 服務。其服務建立的方式是在中華電信的 Hinet/光世代上網網路中，另外增加一個大型區網，這個大型區網有設定給 MOD 機上盒所使用的IP位址，一旦 MOD 機上盒開始收看特定節目時，來源端就會透過 Multicast 的方式，將該頻道的影音內容傳到 MOD 機上盒。

上圖簡單解釋了 MOD 的建立影音資料傳輸的簡圖，每一個頻道都是獨立的 RTSP 傳輸網址，而 MOD 機上盒轉台時，其實是切換串流 IP，並且同時也會發送加入 Multicast 群組的請求封包到串流伺服器；而串流伺服器接收到機上盒的串流請求時，串流伺服器端的路由便會將該機上盒的 IP 加入進Multicast 群組之中，並且發送串流封包到所有在群組清單內的機上盒。簡單來說，MOD 採用的 Multicast 做法，不但不會增加串流伺服器端的流量，同時也穩定了收看的品質。

但這同時也給收看者帶來了一些麻煩，首先由於 MOD 機上盒的 IP 屬於架構在 Hinet ADSL/光世代上的一個龐大區網，因此機上盒都必須要直接接數據機，或者是與數據機之間只能有一般交換器，否則會導致用戶無法收看，這就失去了給用戶的裝機彈性，畢竟並不是每家每戶的數據機與機上盒放置的位置都能夠直接連接。

其次也是很大的問題，前面有提到 Multicast 可以做一對多的多播，但在沒有支援 Multicast 的設備下會直接變成 Broadcast 封包往下傳遞。假設數據機與 MOD 機上盒之間有接一般的交換器，若該交換器上面還有連接其他的設備，縱使不是 MOD 機上盒也會一直收到 MOD 來的串流封包。這樣的現象，除了會導致其他設備的網路頻寬被虛耗外，一些設計上本就不適合做大量廣播封包傳輸的連線方式也會因此被癱瘓 (比如 Wi-Fi)，這個現象一般被稱為廣播風暴 (Broadcast Storming)。

Multicast 簡介：IGMP Snooping

為了避免 Multicast 封包從 Internet 傳入到 LAN 時所造成的廣播風暴問題，目前不少無線分享器或者是交換器都開始支援了所謂的 IGMP Snooping 功能。

所謂 IGMP Snooping，是建立在 Multicast 傳輸協議之一的 IGMP 協議中，其功能是在 IP 層 (Layer 3)所實作的功能。該功能的實現方式是，每一台接收Multicast 封包的終端都會有一個多播位址，這個多播位址會記錄在路由器/交換器上並且標註是來自哪一個連接埠。當設備收到 Multicast 封包時，會去比對廣播封包上的多播位址，確認後只會將封包傳輸到列在同一個多播位址上的連接埠，沒有列在名單內的連接埠則不會發送。

透過此功能，便能將 Multicast 封包發往相關聯的機器上，除了降低其他設備的網路頻寬被虛耗外，也能夠防止廣播風暴的產生；缺點是要接收 Multicast 的終端，若上層有好幾層路由器/交換器設備，這些也都要支援 IGMP Snooping 的設備，才能夠避免某一層發生廣播風暴。

OpenStack 實作 Multicast (1)：網路架構須知

知道了關於 Multicast 相關的知識後，接著就來看要怎麼在 OpenStack 上實作Multicast。

OpenStack Neutron 本身支援好幾種網路管理底層，包括 Linux Bridge、Open vSwitch(OvS) 等，而由於 OvS 能夠支援較多的 Neutron 功能(如Neutron DVR)，因此大多數都是以 OvS 作為網路底層，這篇也同樣會以 OvS為主。

在 OpenStack 的私人網路建立上則比較多樣，分為 VLAN、VXLAN、GRE 等等，其中 VLAN 與 VXLAN 是較為常見建立方式：

VLAN：優點

容易設定，出狀況時較容易排除
不需使用 Provider Network 就能夠設定 Multicast 應用

VLAN：缺點：

只有 1~4093 組 VLAN 可使用，且需要在交換器上規劃一段 VLAN 範圍給私人網路使用，對 VLAN 分配錙銖必較的環境而言不友善
只要知道 VLAN ID 並在交換器上開通就能連到該私人網路中的 VM，安全性較低

VXLAN：優點

有 1~65535 組 ID 可以使用，不用擔心 VLAN 分配問題
使用 L2 in L3 這種類似VPN的形式運作，安全性較高

VXLAN：缺點

私人網路出問題時，檢查難度較高
Neutron 在 VXLAN 上不支援 Multicast，需要配合 Provider Network。

而在本篇，是會以 Provider Network 的形式講解設定 Multicast 的部分，在設定上不論是單純 VLAN 還有用 Provider Network 的方式，原理都是一樣的，只有步驟在細節上的差異。

OpenStack 實作 Multicast (2)：建立Provider Network

本篇範例所使用的 Openstack 環境是透過 Kolla 進行部署，Kolla 是採用多個容器所建立起來的 Openstack 環境，每一個容器就是一個 Openstack component，因此在修改設定還有修復上都比傳統部署方式還來得簡單容易。

要建立 Provider Network，我們首先得在交換器上建立一組給該 Network 所使用的 VLAN ID，這邊我們假設 VLAN ID 是1500。接著修改一下 OpenStack 的設定，必須分別在 Kolla 部署節點上，新增或修改檔案內的相關設定文字

* 啟用Provider Network功能
/etc/kolla/globals.yml
enable_neutron_provider_networks: yes

* 將Neutron External Network設定可加入進VLAN類型
/etc/kolla/config/neutron/ml2_conf.ini
[ml2_type_vlan]
network_vlan_ranges = *

* 為OvS啟用IGMP Snooping功能
/etc/kolla/config/neutron.conf
[ovs]
igmp_snooping_enable = true

完畢後即可更新當前Openstack的設定檔

kolla-ansible -i <inventory> reconfigure

接著就可以透過 Horizon 建立一個新的 External Network

Name：Network 名稱
Project：要建立給哪一個 Project 使用，一般來說會透過設為 admin 後再Shared 出去，要指定也可以
Provider Network Type：設定此 Network 的連接類型，由於上面已經指定為 VLAN，因此設為 VLAN 模式
Physical Network：此 OpenStack Network 是採用哪一個實體網路。在OvS 下，若沒有特別設定，一般都是 physnet1。
Segmentation ID：VLAN ID 號碼，前面有設定過因此是 1500。
Enable Admin State：是否啟用此網路，打勾
Shared：是否分享此網路，若設定 Project 為 Admin 則建議，其他的Project則依需求選擇。
External Network：定義此 Network 是否為對外，打勾
Create Subnet：是否建立網段，打勾

Subnet Name：網段名稱
Network Address：此 Subnet 的 IP 網段，需根據上層建立的網段去設定，我們這邊假設是 10.111.0.0/16
IP Version：IP 版本，一般都是 IPv4
Gateway IP：此 Subnet 的 Gateway IP，一樣假設是 10.111.0.254

Enable DHCP：是否為此網段啟用 DHCP Server 功能，由於 DHCP 牽涉到VM 連到網路時的初始化設定，因此這邊需要打勾
Allocation Pools：指定要配發的 IP 網段範圍，假設為10.111.90.1~10.111.90.255，實際格式為把坡浪弧改為一般逗點
DNS Name Servers：網段所要配發使用的 DNS IP。

建立完成後，便可以直接開一個 VM，綁定這個 Network 並測試看看是否可以在 VM 內取得 IP 以及對外雙向連線，確認完成後就可以來設定 IGMP 啦！

OpenStack 實作 Multicast (3)：在 Provider Network 上設定 Multicast

這部分會分為三項要做的項目：

設定 Security Group 允許 IGMP Protocol 通過
Openstack 在 Security Group 上本身具有啟用 IGMP 的功能，但在Horizon 上是找不到選項的，因此需要透過指令去達成，其指令如下：

openstack security group rule create <security group ID> — ingress — protocol igmp

同樣的指令，將 ingress 改為 egress 後再打一次，另外由於 Multicast 封包是建立在 UDP 為基礎，因此也需要在 Security Group 上開通雙向 UDP。

設定 OvS 對相關 Bridge 啟用 IGMP Snooping 功能
OvS 會為 OpenStack 建立 br-ex 以及 br-int 這兩個 OvS Bridge，前者是能夠對外，後者是讓私人網路能夠互通，而由於透過 Provider Network 連線的 VM 不會建立 VXLAN 連線，而是會直接連通到 br-int，因此需要為這兩個 Bridge 啟用 IGMP Snooping 功能：

ovs-vsctl set Bridge <bridge名稱> mcast_snooping_enable=true
ovs-vsctl set Bridge <bridge名稱> other_config:mcast-snooping-disable-flood-unregistered=true
* 備註：每一台 Compute 節點都要設定

交換器上對指定的 VLAN 啟用並設定 IGMP Snooping：這點比較麻煩，因為每家的交換器對於 IGMP Snooping 設定的項目都不相同，可以很簡單也可以很複雜，有些還會考量到所謂的廣播風暴因素而限制 Multicast 存在的最長時間，因此要設定的話請參閱該交換器的說明書。這邊只講幾個重點:
- 最好是能夠支援 IGMPv3 的交換器
- 若可以設定 IGMP Querier 的 IP，則請設定一組。IP 不需要和 Provider Network 或 OpenStack 上的網段相同，但不可以是用來作為 Multicast Group 所使用的 IP 段。
- 部分高級交換器如 Cisco N3K 會有 IGMP Group Timeout 的設定，請設為永不到期。
- 有些還會有比如 IGMP Interval 還有 Querier Interval 等設定，需要根據Multicast軟體的特性下去做調整。

總結

本篇講解了 Multicast 上的一些應用與問題，以及簡單說明在 OpenStack上的實作。儘管這部分在私有雲的應用上會是較少見的，還是作為一個有需求時可以參考的一種方式。

關於我們

雙子星雲端具有多年 OpenStack 管理經驗，現也為 CNCF 會員，是 CNCF 所認證的 Kubernetes 服務提供商，在雲端 VM 與容器技術擁有十多年以上的經驗，為台灣雲端技術早期領先者。目前為國家級 AI 雲的軟體及 Kubernetes 技術與服務提供商，更是諸多企業與單位導入虛擬機/容器與管理平台的最佳夥伴。

Gemini AI Console 已發布最新版本，歡迎各界有興趣的朋友跟我們索取最新的產品資訊，也可以立刻預約 Demo，我們的產品顧問將向您示範，並免費提供線上的試用！