最近アメリカ自宅に NTT のひかり TV チューナーを導入したのに合わせ、自宅の EdgeSwitch 8 150W で MLD Snooping / スヌーピングを設定しました。
ひかり TV などで利用されている IP マルチキャストの設定は比較的情報が少なく、また IGMP / MLD Snoopingのしくみを理解しないで設定していろいろ失敗しました。なので、戒めのためにマルチキャストおよびスヌーピングの説明と、ひかり TV でのマルチキャスト関連トラブル対策、そして EdgeSwitch での設定例を載せてみます。
ひかり TV とは
NTT ぷららが提供する、日本で唯一地上波デジタル放送の IP 再送信に対応した IPTV サービスです。基本的には NTT のフレッツ (NGN / IPv6) 網でのサービスで、地デジやひかり TV のチャンネルは IPv6 マルチキャスト、オンデマンドのビデオは IPv6 / IPv4 ユニキャストで配信されているようです。
フレッツ光ネクスト、およびそれ相当の光コラボのプロバイダに加入していれば対応しています。ただ、フレッツ光ネクストでも、マンションタイプ (プラン2B) などの旧Ｂフレッツ由来の一部のプランでは地デジ再送信だけ対応してなかったりします。
最近 Nuro 光がフレッツ外のプロバイダとしてひかり TV に対応しました。Nuro はもともと NTT のダークファイバーを利用するサービスなので、対応しやすかったのではないかと思います。
マルチキャストとは
インターネットのようなパケットベースのネットワークにおいて、複数の端末に効率的に情報を送信するやりかたです。
普通の通信（ユニキャスト）で、例えば３つの端末にビデオをストリーミングする場合を考えてみましょう。
ユニキャストは１：１の通信なので、たとえその３端末が同時に同じビデオを観ていたとしても、サーバーは同じパケットを３つ分送信しなければなりません。そのため、配信する端末が多いければ多いほどサーバーのリソースやネットワークの帯域を消費します。
しかしマルチキャストでは、サーバはパケットを１つだけ送信すればよく、パケットはその送信を受けようとする端末の直前のスイッチングハブでコピーされます。このため、サーバーのリソースや帯域の消費が抑えられます。
このように、マルチキャストは効率的に１：多の通信をおこなうしくみです。マルチキャストがきちんと動作するためには、サーバーや端末、途中のスイッチングハブ等がすべてマルチキャスト対応である必要があります。また一方的な配信は得意ですが、 TCP など双方向通信には向きません。
そしてマルチキャストには大きく２つの種類があります。マルチキャスト対応端末を管理する制御メッセージ（ IGMP / MLD ）と、それ以外のマルチキャストデータです。
IGMP / MLD とは
インターネット上で、マルチキャストに参加する端末の管理や、通知を行うプロトコルです。 IGMP / MLD の制御メッセージ自体もマルチキャストで送信されます。
Internet Group Management Protocol – RFC 2236
Multicast Listener Discovery – RFC 4604
IGMP は IPv4 用のプロトコルですが、どうも日本ではあまり普及せず、見かけるのは LAN 内での利用が多い気がします。
MLD は IPv6 で IGMP と同様の機能を担うプロトコルです。 IPv6 対応のネットワークでは MLD 対応が必須なこともあり、こちらはインターネット上で普及しています。
IGMP / MLD スヌーピングとは
スイッチングハブで IGMP / MLD のやりとりを学習し、必要な端末にのみマルチキャストパケットを届け、必要のない端末には送らないようにする機能です。
マルチキャストは、何もしないとスイッチングハブや WiFi アクセスポイントに繋がっている、サブネット内のすべての端末に送信されてしまいます。これは、処理速度の遅いスマート家電や、大量のパケットをコピーしなければならない WiFi アクセスポイントでは重荷です。
このマルチキャストが DLNA / SSDP や mDNS のように端末を発見するときにちょっとだけ使われるならまだなんとかなりますが、ひかり TV などはストリーミング自体をマルチキャストデータで送信しつづけます。そうすると大量のマルチキャストパケットの処理や破棄をしなければならない WiFi アクセスポイントは、フリーズしたようになったりします。「ひかり TV を観ていると WiFi でインターネットができない」などのトラブルは、これが原因だったりします。
IGMP / MLD スヌーピングを使うことで、不必要なスマート家電や WiFi アクセスポイントにマルチキャストを送らないようにできます。
ただスヌーピングは完璧な規格ではなく、スイッチングハブの製造元が便利機能として個々に実装したのが発祥です。そのため各対応機器で、マルチキャストの解釈や対応具合にバラツキがあったりします。その問題を解決するため、 RFC 4541 がリリースされましたが、これも規格でなく推奨なので、スイッチングハブの製造元によって動作に差異がある状況は変わっていません。
マルチキャストのふるまい
では、実際にマルチキャストが LAN 内でどのように動作するか見てみましょう。下記では簡単な家庭用 LAN を想定していて、マルチキャストルーターはいないものとします。
下記が今回のネットワーク構成例です。
| ルーター | １台 |
| スイッチ | ２台 |
| 端末 | ３台 |
LAN 内の端末１ 192.168.0.1 がブロードキャストアドレス 255.255.255.255 宛にパケットを送信すると、 LAN 内のすべての端末に送信されます。実際にはスイッチングハブが、ブロードキャストパケットをコピーして、送信元ポート以外のすべてのポートに送る flooding を行っています。
LAN 内のすべての端末にブロードキャストパケットが届いてますね。
実はマルチキャストも、通常 LAN 内ではブロードキャストと同じ動作をします。LAN 内の端末 192.168.0.1 がマルチキャストアドレス 239.0.0.X にパケットを送信すると、 LAN 内のすべての端末に送信されます。
これもやはりスイッチングハブが、マルチキャストパケットをコピーして、送信元ポート以外のすべてのポートに送る flooding を行っています。
このマルチキャストの通信をやり取りすることによって、 LAN 内の端末はどこにどんなマルチキャストグループに所属する端末がいるか「見える」ようになります、またマルチキャストアドレス宛のパケットがすべての端末に届きます。この基本的なブロードキャスト・マルチキャスト機能は普通のスイッチングハブでも対応しています。
IGMP のはたらき
さて、それでは LAN 内で IGMP のパケットが送られた場合を見てみましょう。 IGMP の主要な制御メッセージは次の３つです。繰り返しまずが、 IGMP 自体もマルチキャストです。
Join Request
端末のアプリケーションが、何かのマルチキャスト通信を始めようとするとき、あるマルチキャストアドレスに membership report を送ります。この一番最初の membership report を特別に join request と呼んだりします。この場合のマルチキャストアドレスはアプリケーションやプロトコルによって予め決まっています。今回は端末２ 192.168.0.2 がマルチキャストアドレス 239.0.0.X に membership report パケットを送ります。
これでこの端末２がマルチキャストグループ 239.0.0.X の一員だと宣言したことになります。この join request は端末１にも届くので、端末１と端末２はマルチキャスト 239.0.0.X を使うアプリケーションでお互いを認識し、通信できるようになります。 join request マルチキャストを使うアプリケーションを起動した時や、マルチキャスト配信を受けるセットトップボックスなどを起動した時に１回だけ送信されるのが通常です。
Membership Query
membership query は LAN 内にどんなマルチキャストグループがあり、どんな端末が参加しているのかを調べるために定期的に送るパケットです。通常は LAN 外のマルチキャストルーターが送出し、マルチキャストアドレス 224.0.0.1 宛に送ります。これも LAN 内であればマルチキャスト＝ブロードキャストされます。
またマルチキャストルーターが不在の場合、 LAN 内のスイッチングハブに代理で membership query を送出させるよう設定することもできます。この場合、そのスイッチングハブを「 IGMP クエリア」と呼んだりします。
Membership Report
membership report は、マルチキャストグループに所属する端末が、 membership query を受信した際に、自分の IP アドレスと自分の所属するマルチキャストアドレスを報告するパケットです。その所属するマルチキャストアドレス宛に送信され、これも LAN 内であればマルチキャスト＝ブロードキャストされます。
これが超ざっくりとした IGMP の説明です。ちなみに leave は簡単のため省略します。
IGMP スヌーピング
さて、それではここで、スイッチングハブでの IGMP スヌーピング機能を考えてみます。
スヌーピングは、基本的には不要な端末にマルチキャストを送らないようにする機能です。いい機能ですね。ですが、設定する時に少し注意が必要です。 LAN 内にスイッチングハブが１つの場合は何も考えずオンにしてしまっても問題なかったりします。 LAN 内に IGMP スヌーピングをオンにしたスイッチングハブが２つ以上あると、 下記の場合はトラブルになります。
membership queryを出せるマルチキャストルーターがいないmembership queryを出せるクエリアがいない- マルチキャストルーターポートが設定されてない
どういうことでしょうか。
ヒントは IGMP スヌーピングの実装にあります。だいたいのスヌーピング対応スイッチングハブは、こんな感じの実装になってるようです。
- マルチキャストデータ
- マルチキャストグループに所属してる端末がいないポートにはマルチキャストデータを送らない
- マルチキャストデータは、そのマルチキャストアドレスのグループに所属している端末がいるポートにだけ送る
224.0.0.0/24宛のマルチキャストは常にfloodingする- マルチキャストルーターポートには、常にマルチキャストを転送する
- マルチキャスト制御メッセージ
membership reportを受信したら、そのポートとマルチキャストアドレスを覚えるmembership reportは、マルチキャストルーターポートだけに転送するmembership queryを受信したら全ポートにfloodingするmembership queryを受信したら、受信したポートをマルチキャストルーターポートと覚える224.0.0.0/24宛のマルチキャストアドレスは常にfloodingする- マルチキャストルーターポートには、常にマルチキャストを転送する
はい、ややこしいですね。なので、簡単な例を見てみましょう。 LAN 内のスイッチ２つで IGMP スヌーピングをオンにしてみました。
さきほど書いたように IGMP スヌーピングがオンになったスイッチは、マルチキャスト端末からの membership report で初めてどのポートにマルチキャスト端末がいるかを学習します。なので、 membership report が来ない限り、そのポートにはマルチキャストを転送しなくなります。
端末２は、マルチキャストグループ 239.0.0.X に参加したいと思い、 join request を出しました。ですが、スイッチ２にとっては端末２が初めてのお客さんなので、そのポートを覚えるだけです。他にはマルチキャスト端末がいないので、 IGMP スヌーピングの実装通り、他のポートには join request をマルチキャストしません。
またこの状態で端末１が join request を出したとしても、スイッチ１へは端末２から join request が届いてないので、スイッチ１も join request をどこへも転送しません。つまり端末１と端末２の間でマルチキャストが届かなくなります。
ここで端末３が 239.0.0.X に参加したらどうでしょうか。
この場合はスイッチ２は、ポート２とポート３に 239.0.0.X 所属のマルチキャスト端末がいると気づきます。なので端末３が 239.0.0.X 宛にデータを送信すると、スイッチ２はそれをポート２に転送し、端末２に届きます。
ですが、端末１とはマルチキャスト通信できないままです。もちろんユニキャストであれば問題なく通信できますが、マルチキャストで端末の発見を行うアプリケーションでは、端末１は見えません。また端末２や端末３が 239.0.0.X 宛にマルチキャストで送るデータは、端末１には届きません。
では例えばマルチキャストを利用するアプリケーションの１例として、 DLNA / SSDP で考えてみます。
端末１と端末２が SSDP に対応している場合です。 SSDP はマルチキャストを利用したプロトコルで、アプリケーションを起動するとまずは IGMP で 239.255.255.250 宛に join request を送って通信を始めます。その後 SSDP では 239.255.255.250:1900 宛にマルチキャストデータとして様々な SSDP のメッセージを送って、同じ LAN 内の SSDP 対応の端末を発見したり、データを送受信したりします。
IGMP スヌーピングが有効になっているスイッチ２は、やはり IGMP スヌーピングが有効になっているスイッチ１からのマルチキャストが届きません。なのでスイッチ２は SSDP をスイッチ１にマルチキャストせず、端末１と端末２は SSDP を介してはお互いが見えません。
AirPlay / HomeKit で使われる mDNS の場合はどうでしょうか。
mDNS は実はマルチキャストアドレスに 224.0.0.251 を使います。これは 224.0.0.0/24 の範囲内ですので、常に flooding され、問題なく動作してしまいます。そのかわり IGMP スヌーピングのマルチキャスト削減機能は働きません。
というわけで、 mDNS 以外は困りましたね。実は IGMP クエリアを設定すると、うまく動作するようになります。
IGMP クエリア
IGMP クエリアとはマルチキャストルーターが不在の LAN で、 IGMP の membership query を定期的に送るように設定された端末です。 IGMP スヌーピングに対応しているスイッチングハブはわりとクエリアにもなれるようです。下記ではスイッチ１に membership query を出すよう設定してみました。
membership query は 224.0.0.1 宛に送信されるので、常に flooding されます。そして IGMP スヌーピングがオンになっているスイッチ２は、 membership query が届いたポート１を「マルチキャストルーターポート」として学習し、以降マルチキャストをつねにポート１に転送するようになります。
ちなみにスイッチ１をクエリアとして設定する代わりに、スイッチ２のポート１をマルチキャストルーターポートとして手動で設定しても同じ効果になります。
そして membership query を受信した端末は、今度は membership report として所属のマルチキャストグループを報告します。
これでスイッチ１もスイッチ２も、ともにポート２に 239.0.0.X に所属する端末がいることに気がつきます。 membership report は IGMP スヌーピングにより、マルチキャストルーターポートにしか転送されません。が、それで十分で、スイッチ１はポート８側にも 239.0.0.X 所属のマルチキャスト端末がいることにも気がつきます。
クエリアは membership query を定期的に送信するので、 membership report も定期的に返信されます。これにより２つのスイッチが、どこのポートにどのマルチキャストグループ所属の端末がいるのか、常に最新情報を持つようになります。そして 239.0.0.X 宛のマルチキャストは必要なポートだけ、つまりスイッチ１のポート２・８と、スイッチ２のポート２のみ送られるようになります。
さて、ここで端末３が 239.0.0.X に参加してきたらどうでしょう。
この通り、端末３の 239.0.0.X 宛の membership report は無事にスイッチ１に転送されます。なので 239.0.0.X 宛のマルチキャスト通信は、端末１〜３に届くようになります。
というわけでここまでのまとめは、
- IGMP スヌーピングはマルチキャストを効率的にしてくれる
- が、クエリアかマルチキャストルーターポートを一緒に設定しないとうまく動かない
という感じです。
ひかり TV と MLD
それでは MLD がどのように動作するか見てみましょう。まったく同じ家庭内 LAN での join request の例です。 MLD なので、アドレスが IPv6 になっていますが、コンセプトは同じです。
まだ MLD スヌーピングはオンにしていません。そして今回はひかり TV を使っている家庭を想定し、 WAN 側にひかり TV の動画を配信するマルチキャストサーバーがあり、またルーターは MLD のわかるひかり TV 対応のルーターだとします。
IGMP と同じように MLD も LAN 内の端末に行き渡ります。これもスイッチングハブがマルチキャストを flooding してくれるおかげです。
MLD スヌーピングだけオンにすると
IGMP スヌーピングの時と同じように、マルチキャストがうまく行き渡らなくなってしまいます。
またひかり TV を使用していると、 LAN 外のマルチキャストルーターから定期的に membership query が送信されてくるようになります。が、これも LAN 内にマルチキャスト端末がいない場合は送られてきません。なので、 membership query が LAN 内に行き渡ることもありません。
ヤマハのルーターは、きっちり MLD プロキシ機能として実装していて設定例もあります。
MLD マルチキャストルーターポートを設定する
この場合、もう membership query を送ってくれるマルチキャストルーターがいることがわかっているので、 MLD 用のマルチキャストルーターポートを手動でスイッチ１と２に設定してみます。
スイッチ１と２のポート１をそれぞれマルチキャストルーターポートとして設定しました。これでルーターのポート１に membership report が届き、 LAN 側に ff3e::x:5 のマルチキャスト端末がいることを学習します。また外部のマルチキャストルーターに LAN 内にマルチキャスト端末がいたことを MLD プロキシを通じて伝えます。その後 membership query が外部のマルチキャストルーターから送信されると・・
ご覧のように、晴れて LAN 内に行き渡るようになり、これで LAN 内のマルチキャスト端末の存在が適切に維持・管理されることになります。めでたし、めでたし。
MLD スヌーピングをオンにするとひかり TV が観られない問題
もう、おわかりですね。せっかく MLD スヌーピング対応スイッチングハブを買ったのに、それをオンにしたらひかり TV が観られなくなってしまった場合、たぶん原因はスイッチが２台以上（もしくは MLD スヌーピング対応のスイッチ内蔵ルーター＋スイッチ１台以上）あって、マルチキャストルーターポートを設定してないためです。 MLD スヌーピングがマルチキャスト membership report をどこにも転送しなくなってしまうわけですね。
そして membership report がルーターに届かなくなると、その LAN にはひかり TV のマルチキャスト端末がいない、と見なされて、 membership query も、そもそものひかり TV のマルチキャストでの放送データも届かなくなってしまいます。
というわけで、 MLD スヌーピングをオンにしたら、そのスイッチングハブで忘れずにルーター（ホームゲートウェイ）の接続されているポートを、マルチキャストルーターポートとして設定するようにしましょう。しかしマルチキャストルーターポートって長い名前すね・・。
ひかり TV を使用中に WiFi でインターネットが使えなくなる場合
前に述べたように、マルチキャストが WiFi に流れ込み、 WiFi アクセスポイントがマルチキャストパケットを大量にコピーしなければならないことで、処理能力を超えてしまうことが原因のようです。フレッツや Nuro でホームゲートウェイをレンタルしている場合は多分 MLD スヌーピングが最初から有効になっているので、この問題は起こらないと思います。
フレッツでひかり電話を契約していない場合などは ONU だけのことが多いようで、その場合は自前でルーターを用意する必要があります。ひかり TV 対応のホームゲートウェイでなく、自前のルーターを使う場合は、下記のことに気をつけると WiFi が使えなくなるのを防げると思います。
- ひかり TV 対応かつ「 Snooping 機能」等のある市販のルーターを買って、 MLD スヌーピングをオンにし、ひかり TV チューナーとそのほかの機器がつながる LAN ポートを分ける
- ひかり TV 対応かつスヌーピング非対応の市販ルーターに MLD スヌーピング対応のスイッチングハブをつなぐ
- この場合、ルーターの他の LAN ポートやルーター内蔵の WiFi は使わない
- マルチキャストルーターポートはルーターが接続されたポートに設定
- スイッチングハブの配下に改めて WiFi アクセスポイントをつなぎ、 WiFi はそっちを使う
- もしくは、 ONU に直接 MLD スヌーピング対応スイッチングハブをつなぎ、そこにひかり TV チューナーと、自前のルーターをつなぐ
- マルチキャストルーターポートは ONU が接続されたポートに設定
ひかり TV のチューナーは、フレッツ網に IPoE で繋がっていれば、必ずしもルーターがなくても動作します。要は、ひかり TV チューナーと WiFi アクセスポイントが、必ず MLD スヌーピング機能を持つスイッチングハブの配下に入るようにすればよいわけです。
ただ、３番目のやり方の場合、ひかり TV チューナーと他の LAN のサブネットが分かれてしまうので、「ひかり TV どこでも」アプリなどホームサーバー機能 (DTCP-IP) を使った視聴はできなくなってしまいます。
MLD スヌーピングと EdgeSwitch
さて、それでは、 EdgeSwitch 8 150W で実際に MLD スヌーピングとマルチキャストルーターポートを設定してみます。これがこの設定例のネットワーク構成です。
この中の EdgeSwitch １台に MLD スヌーピングと MLD でのマルチキャストルーターポートを設定してみます。
VLAN はデフォルトのまま、つまり VLAN 1 を使っています。 MLD の機能はファームウェア 1.7.4 から実装されましたが、とくにヘルプやマニュアルはなく、設定できるのは CLI 経由のみです。まず ssh で EdgeSwitch にログインし、そして下記のコマンドを入力します。
ssh で EdgeSwitch にログイン # privilege mode に入る enable # global config mode に入る configure # MLD snooping を有効にする set mld # MLD snooping をすべてのポートで有効にする set mld interfacemode # global config mode から出る exit # vlan mode に入る vlan database # MLD snooping を VLAN 1 で有効にする set mld 1 # vlan mode 出る exit # global config mode に入る configure # port config mode でポート１に入る interface 0/1 # マルチキャストルーターポートを vlan 1 に設定する set mld mrouter 1 # global config mode から出る exit # privilege mode から出る exit # 設定を保存する write memory # MLD snooping のステータスをチェックする show mld show mldsnooping mrouter interface 0/1 show mldsnooping mrouter vlan 0/1
とこんな感じです。 MLD / IGMP スヌーピングのステータスは、 Legacy GUI の Switching > Multicast Forwarding Database > Summary でも確認できます。
MLD スヌーピングの代わりに VLAN を使う
実家では Nuro 光を使っていますが、
- ついてくるルーター F660A はお馬鹿さんなので、 EdgeRouter を使いたい
- さらに ひかり TV のマルチキャストの通る VLAN をメインの LAN と分けたい
等を考えて、こんな感じにしています。ご参考まで。
この例では、
- メインの LAN = VLAN 1
- ひかり TV 用の LAN = VLAN 101
にしています。 VLAN 101 は F660A 配下のサブネット 192.168.1.0/24 になっています。
VLAN を分け、マルチキャストが必要なポートのみその VLAN を有効にすることによって、マルチキャストが不必要な端末に送られてしまうのを防げます。 VLAN さえ使えれば、 MLD スヌーピングのないスイッチでも、 WiFi アクセスポイントにマルチキャストが流れるのを防ぐことができます。ホームゲートウェイが NLD スヌーピング対応でなくても、ルーターにはマルチキャストが流れてしまいますが、ルーター配下は無傷です。
この場合、ひかり TV どこでもや Dixim など DTCP-IP アプリケーションが使えるのは VLAN 101 内のみになります。
EdgeSwitch の IGMP / MLD スヌーピングのバグ
Ubiquiti の Community スレッドみると、現状 EdgeSwitch のバグはこんなものがありそうです。
- IGMP スヌーピングがオンで MLD スヌーピングをオンにしないと IPv6 マルチキャストがブロックされる
- MLD スヌーピングがオンで IGMP スヌーピングをオンにしないと IPv4 マルチキャストがブロックされる
実家の LAN で VLAN 1 と VLAN 101 を分けているのは、 IPv6 マルチキャストが通る VLAN 101 でこのバグを避けるため、 IGMP スヌーピングをオフにするためでもあります。
参考にしたスレッドは下記の通りです。
IGMP Snooping blocks IPv6 router advertisements
おわりに
頑張って書きましたが、もし間違いがあったらこっそり教えてください・・。
yabe.jp » Gadgets »