午前2時のユニキャストの悪夢
モニタリング画面を見つめる目はかすみ、デスクの3杯目のコーヒーはとっくに空。会社の4Kカメラストリーミングシステムは「虫の息」でした。サーバーのCPU使用率は95%に急上昇し、コアスイッチの帯域は8Gbpsを超えて真っ赤なアラート。犯人は？500台以上のワークステーションにユニキャストでリアルタイムデータを送信していたスクリプトです。クライアントが接続するたびに、サーバーは15Mbps的データストリームをコピーして送り出さなければなりません。どんなにハイスペックな32コアサーバーでも、これではあっという間に焼き切れてしまいます。
その時の唯一の解決策は、すぐにマルチキャストに切り替えることでした。500個のコピーを作る代わりに、サーバーはたった1つのストリームを送信するだけで済みます。ネットワークインフラ側が、必要なポートにデータを複製する役割を担ってくれるのです。株価データの配信やビデオ会議、あるいは大量のHDDイメージ展開を行う場合、マルチキャストはシステムを延命させるための鍵となります。
マルチキャストは単なる「送受信」ではない
多くのエンジニアがマルチキャストをブロードキャストと混同しがちです。ブロードキャストはいわば「街頭スピーカー」のようなもので、ネットワーク内の全員が望むかどうかにかかわらず聞かされます。一方、マルチキャストは「購読（サブスクリプション）」メカニズムに基づいたスマートな仕組みです。「受信したい」という信号を送ったデバイスに対してのみ、スイッチやルーターがデータを転送します。このアプローチにより、無関係なエンドデバイスへの負荷を劇的に軽減できます。
特殊なIPアドレス範囲
マルチキャストアドレスは、クラスDの 224.0.0.0 から 239.255.255.255 の範囲にあります。内部環境では、プライベートネットワーク用に割り当てられた 239.0.0.0/8 （Administratively Scoped）を使用するのが最も安全な選択です。
異なるマルチキャストグループにIP範囲を割り当てる際、パケットの重複を避けるためのサブネット計算が重要になります。私はネットワーク範囲やホスト数を素早く確認するために、よく IP Subnet Calculator を使います。同じインフラ上で数十もの独立したデータストリームを管理する場合、このツールは非常に役立ちます。
IGMPとPIM-SM：連携する2つのプロトコル
- IGMP (Internet Group Management Protocol): 受信機（ホスト）とルーター間の通信言語。VLCでストリームを開くと、マシンは最寄りのルーターに対して「参加」を知らせる IGMP Join パケットを送信します。
- PIM-SM (Sparse Mode): ルーター間で動作するプロトコル。インテリジェントな配信ツリー（Distribution Tree）を構築し、ソースから宛先まで、最短かつ最もリソース消費の少ない経路でデータを導きます。
実践：Linuxサーバーでのマルチキャスト設定
このシナリオでは、Ubuntuサーバーを配信ソースとして設定し、異なるサブネット間でデータストリームをルーティングします。
1. カーネルでのフォワーディング有効化
デフォルトでは、Linuxカーネルはセキュリティのためにマルチキャストパケットを勝手に転送しません。sysctl を操作してこれを許可する必要があります。設定ファイルを開きます：
sudo nano /etc/sysctl.conf転送機能を有効にするために、以下の行を追加します：
net.ipv4.ip_forward=1
net.ipv4.conf.all.mc_forwarding=1
net.ipv4.conf.default.mc_forwarding=1再起動せずに設定を即座に反映させます：
sudo sysctl -p2. pimdのインストールと設定
LinuxでPIM-SMを動作させるには、pimd が現在最も安定しており使いやすいデーモンです。apt経由ですぐにインストールできます：
sudo apt update && sudo apt install pimd重要なポイントは /etc/pimd.conf ファイルにあります。配信元と受信機が出会う中間地点である ランデブーポイント (RP) を定義する必要があります。中小規模のネットワーク構成では、RPをメインルーターのIPに直接向けることができます。
# 参加するインターフェースの設定
phyint eth0 enable
phyint eth1 enable
# RP（ランデブーポイント）のアドレスを定義
rp-address 192.168.1.1新しい設定を読み込むためにサービスを再起動します：
sudo systemctl restart pimd3. iperf3による実地テスト
設定を鵜呑みにせず、実際の数値でテストしましょう。iperf3 は、こうした測定に最適な標準ツールです。
受信側 (Receiver): マルチキャストグループ 239.0.0.1 でリスンします。
iperf3 -s -B 239.0.0.1送信側 (Source): グループに対して 10Mbps の UDP ストリームを送信します。
iperf3 -c 239.0.0.1 -u -b 10M -t 60受信側で帯域幅が安定して10Mbpsを示していれば、システムは正常に疎通しています。
マルチキャストが「切れる」3つの典型的な罠
何晩もデバッグを繰り返した末の苦い経験から言えるのは、エラーの90%はコマンドのミスではなく、ネットワークの仕組みに起因するということです。
TTL値が低すぎる
多くのアプリケーションでは、マルチキャストパケットのTTL (Time To Live) のデフォルト値が1に設定されています。これは、パケットが最初のルーターを越えた瞬間に破棄されることを意味します。受信機が別のサブネットにある場合は、TTLを32または64に増やす必要があります。iperf3 の場合は、--ttl 32 オプションを追加してテストしてください。
IGMPスヌーピング「あだ」となる
最近のレイヤー2スイッチは、マルチキャストの氾濫を防ぐためにIGMPスヌーピングが有効になっています。しかし、定期的に問い合わせを行う「IGMPクエリア (Querier)」がネットワーク内に存在しない場合、スイッチは受信者がもういないと判断し、約2〜3分後に自動的にポートをブロックしてしまいます。ルーターでクエリア機能が有効になっているか確認してください。
RPF (Reverse Path Forwarding) チェック
Linuxには非常に厳格なRPFセキュリティメカニズムがあります。マルチキャストパケットが eth0 から入ってきたのに、ルーティングテーブル上のソースIPへの経路が eth1 を指している場合、Linuxはそのパケットを即座にドロップします。素早くデバッグするために、一時的にRPFを無効にすることも可能です：
sudo sysctl -w net.ipv4.conf.all.rp_filter=0
sudo sysctl -w net.ipv4.conf.eth0.rp_filter=0結びに代えて
マルチキャストの実装は、コマンド自体は難しくありません。難しいのはデータの流れを理解することです。PIM-SMとIGMPをマスターすれば、システムの運用は劇的に楽になります。サーバーがデータのコピー作業に追われることはなくなり、ネットワーク帯域も常に安定した状態を保てます。マルチキャストのデバッグは時計職人のような緻密さが求められることもあるので、いつでも tcpdump を使えるように準備しておくのを忘れないでください。
