MLD スヌーピングとひかり TV

最近アメリカ自宅に 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) などの旧Bフレッツ由来の一部のプランでは地デジ再送信だけ対応してなかったりします。

最近 Nuro 光がフレッツ外のプロバイダとしてひかり TV に対応しました。Nuro はもともと NTT のダークファイバーを利用するサービスなので、対応しやすかったのではないかと思います。

ひかり TV は、番組の配信にマルチキャスト、その制御に MLDv2 を利用でしています。マルチキャストや IGMP / MLD Snooping は、きっちり理解しないで設定するとひかり TV が映るまで時間がかかったり、映らなくなったり、また WiFi でインターネットが使えなくなったりします。なのでこの記事ではマルチキャストや IGMP / MLD のしくみをしっかり解説しています。

マルチキャストとは

インターネットのようなパケットベースのネットワークにおいて、複数の端末に効率的に情報を送信するやりかたです。

普通の通信(ユニキャスト)で、例えば3つの端末にビデオをストリーミングする場合を考えてみましょう。

ユニキャストは1:1の通信なので、たとえその3端末が同時に同じビデオを観ていたとしても、サーバーは同じパケットを3つ分送信しなければなりません。そのため、配信する端末が多いければ多いほどサーバーのリソースやネットワークの帯域を消費します。

しかしマルチキャストでは、サーバはパケットを1つだけ送信すればよく、パケットはその送信を受けようとする端末の直前のスイッチングハブでコピーされます。このため、サーバーのリソースや帯域の消費が抑えられます。

このように、マルチキャストは効率的に1:多の通信をおこなうしくみです。マルチキャストがきちんと動作するためには、サーバーや端末、途中のスイッチングハブ等がすべてマルチキャスト対応である必要があります。また一方的な配信は得意ですが、 TCP など双方向通信には向きません。

そしてマルチキャストには大きく2つの種類があります。マルチキャスト対応端末を管理する制御メッセージ( IGMP / MLD )と、それ以外のマルチキャストデータです。

IGMP / MLD とは

インターネット上で、マルチキャストに参加する端末の管理や、通知を行うプロトコルです。 IGMP / MLD の制御メッセージ自体もマルチキャストで送信されます。

Internet Group Management ProtocolRFC 2236

Multicast Listener DiscoveryRFC 4604

IGMP は IPv4 用のプロトコルですが、どうも日本ではあまり普及せず、見かけるのは LAN 内での利用が多い気がします。

MLD は IPv6 で IGMP と同様の機能を担うプロトコルです。 IPv6 対応のネットワークでは MLD 対応が必須なこともあり、こちらはインターネット上で普及しています。

IGMP / MLD スヌーピングとは

スイッチングハブで IGMP / MLD のやりとりを学習し、必要な端末にのみマルチキャストパケットを届け、必要のない端末には送らないようにする機能です。

マルチキャストは、何もしないとスイッチングハブや WiFi アクセスポイントに繋がっている、サブネット内のすべての端末に送信されてしまいます。これは、処理速度の遅いスマート家電や、大量のパケットをコピーしなければならない WiFi アクセスポイントでは重荷です。

このマルチキャストが DLNA / SSDPmDNS のように端末を発見するときにちょっとだけ使われるならまだなんとかなりますが、ひかり TV などはストリーミング自体をマルチキャストデータで送信しつづけます。そうすると大量のマルチキャストパケットの処理や破棄をしなければならない WiFi アクセスポイントは、フリーズしたようになったりします。「ひかり TV を観ていると WiFi でインターネットができない」などのトラブルは、これが原因だったりします。

IGMP / MLD スヌーピングを使うことで、不必要なスマート家電や WiFi アクセスポイントにマルチキャストを送らないようにできます。

ただスヌーピングは完璧な規格ではなく、スイッチングハブの製造元が便利機能として個々に実装したのが発祥です。そのため各対応機器で、マルチキャストの解釈や対応具合にバラツキがあったりします。その問題を解決するため、 RFC 4541 がリリースされましたが、これも規格でなく推奨なので、スイッチングハブの製造元によって動作に差異がある状況は変わっていません。

この記事では EdgeSwitch 8 150W を前提にしています。他にも様々な MLD スヌーピング対応のスイッチングハブがあります。

BS-GS2008

T1500G-8T (TL-SG2008)

BSH-GMBシリーズ

ギガビットスマートスイッチ シリーズ

マルチキャストのふるまい

では、実際にマルチキャストが LAN 内でどのように動作するか見てみましょう。下記では簡単な家庭用 LAN を想定していて、マルチキャストルーターはいないものとします。

下記が今回のネットワーク構成例です。

ルーター 1台
スイッチ 2台
端末 3台

LAN 内の端末1 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 の主要な制御メッセージは次の3つです。繰り返しまずが、 IGMP 自体もマルチキャストです。

Join Request

端末のアプリケーションが、何かのマルチキャスト通信を始めようとするとき、あるマルチキャストアドレスに membership report を送ります。この一番最初の membership report を特別に join request と呼んだりします。この場合のマルチキャストアドレスはアプリケーションやプロトコルによって予め決まっています。今回は端末2 192.168.0.2 がマルチキャストアドレス 239.0.0.Xmembership report パケットを送ります。

これでこの端末2がマルチキャストグループ 239.0.0.X の一員だと宣言したことになります。この join request は端末1にも届くので、端末1と端末2はマルチキャスト 239.0.0.X を使うアプリケーションでお互いを認識し、通信できるようになります。 join request マルチキャストを使うアプリケーションを起動した時や、マルチキャスト配信を受けるセットトップボックスなどを起動した時に1回だけ送信されるのが通常です。

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 内にスイッチングハブが1つの場合は何も考えずオンにしてしまっても問題なかったりします。 LAN 内に IGMP スヌーピングをオンにしたスイッチングハブが2つ以上あると、 下記の場合はトラブルになります。

  • membership query を出せるマルチキャストルーターがいない
  • membership query を出せるクエリアがいない
  • マルチキャストルーターポートが設定されてない

どういうことでしょうか。

ヒントは IGMP スヌーピングの実装にあります。だいたいのスヌーピング対応スイッチングハブは、こんな感じの実装になってるようです。

  1. マルチキャストデータ
    • マルチキャストグループに所属してる端末がいないポートにはマルチキャストデータを送らない
    • マルチキャストデータは、そのマルチキャストアドレスのグループに所属している端末がいるポートにだけ送る
    • 224.0.0.0/24 宛のマルチキャストは常に flooding する
    • マルチキャストルーターポートには、常にマルチキャストを転送する
  2. マルチキャスト制御メッセージ
    • membership report を受信したら、そのポートとマルチキャストアドレスを覚える
    • membership report は、マルチキャストルーターポートだけに転送する
    • membership query を受信したら全ポートに flooding する
    • membership query を受信したら、受信したポートをマルチキャストルーターポートと覚える
    • 224.0.0.0/24 宛のマルチキャストアドレスは常に flooding する
    • マルチキャストルーターポートには、常にマルチキャストを転送する

はい、ややこしいですね。なので、簡単な例を見てみましょう。 LAN 内のスイッチ2つで IGMP スヌーピングをオンにしてみました。

さきほど書いたように IGMP スヌーピングがオンになったスイッチは、マルチキャスト端末からの membership report で初めてどのポートにマルチキャスト端末がいるかを学習します。なので、 membership report が来ない限り、そのポートにはマルチキャストを転送しなくなります。

端末2は、マルチキャストグループ 239.0.0.X に参加したいと思い、 join request を出しました。ですが、スイッチ2にとっては端末2が初めてのお客さんなので、そのポートを覚えるだけです。他にはマルチキャスト端末がいないので、 IGMP スヌーピングの実装通り、他のポートには join request をマルチキャストしません。

またこの状態で端末1が join request を出したとしても、スイッチ1へは端末2から join request が届いてないので、スイッチ1も join request をどこへも転送しません。つまり端末1と端末2の間でマルチキャストが届かなくなります。

ここで端末3が 239.0.0.X に参加したらどうでしょうか。

この場合はスイッチ2は、ポート2とポート3に 239.0.0.X 所属のマルチキャスト端末がいると気づきます。なので端末3が 239.0.0.X 宛にデータを送信すると、スイッチ2はそれをポート2に転送し、端末2に届きます。

ですが、端末1とはマルチキャスト通信できないままです。もちろんユニキャストであれば問題なく通信できますが、マルチキャストで端末の発見を行うアプリケーションでは、端末1は見えません。また端末2や端末3が 239.0.0.X 宛にマルチキャストで送るデータは、端末1には届きません。

では例えばマルチキャストを利用するアプリケーションの1例として、 DLNA / SSDP で考えてみます。

端末1と端末2が SSDP に対応している場合です。 SSDP はマルチキャストを利用したプロトコルで、アプリケーションを起動するとまずは IGMP で 239.255.255.250 宛に join request を送って通信を始めます。その後 SSDP では 239.255.255.250:1900 宛にマルチキャストデータとして様々な SSDP のメッセージを送って、同じ LAN 内の SSDP 対応の端末を発見したり、データを送受信したりします。

IGMP スヌーピングが有効になっているスイッチ2は、やはり IGMP スヌーピングが有効になっているスイッチ1からのマルチキャストが届きません。なのでスイッチ2は SSDP をスイッチ1にマルチキャストせず、端末1と端末2は 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 スヌーピングに対応しているスイッチングハブはわりとクエリアにもなれるようです。下記ではスイッチ1に membership query を出すよう設定してみました。

membership query224.0.0.1 宛に送信されるので、常に flooding されます。そして IGMP スヌーピングがオンになっているスイッチ2は、 membership query が届いたポート1を「マルチキャストルーターポート」として学習し、以降マルチキャストをつねにポート1に転送するようになります。

ちなみにスイッチ1をクエリアとして設定する代わりに、スイッチ2のポート1をマルチキャストルーターポートとして手動で設定しても同じ効果になります。

そして membership query を受信した端末は、今度は membership report として所属のマルチキャストグループを報告します。

これでスイッチ1もスイッチ2も、ともにポート2に 239.0.0.X に所属する端末がいることに気がつきます。 membership report は IGMP スヌーピングにより、マルチキャストルーターポートにしか転送されません。が、それで十分で、スイッチ1はポート8側にも 239.0.0.X 所属のマルチキャスト端末がいることにも気がつきます。

クエリアは membership query を定期的に送信するので、 membership report も定期的に返信されます。これにより2つのスイッチが、どこのポートにどのマルチキャストグループ所属の端末がいるのか、常に最新情報を持つようになります。そして 239.0.0.X 宛のマルチキャストは必要なポートだけ、つまりスイッチ1のポート2・8と、スイッチ2のポート2のみ送られるようになります。

さて、ここで端末3が 239.0.0.X に参加してきたらどうでしょう。

この通り、端末3の 239.0.0.X 宛の membership report は無事にスイッチ1に転送されます。なので 239.0.0.X 宛のマルチキャスト通信は、端末1〜3に届くようになります。

というわけでここまでのまとめは、

  • 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 内に行き渡ることもありません。

ちなみにひかり TV 対応のレンタルするタイプのルーター(ホームゲートウェイ)は、大抵 MLD スヌーピング(というか WAN 側で受信する MLD / マルチキャストを LAN 側に転送しているので、実際には MLD プロキシ)に対応していると思います。
ヤマハのルーターは、きっちり MLD プロキシ機能として実装していて設定例もあります。

MLD マルチキャストルーターポートを設定する

この場合、もう membership query を送ってくれるマルチキャストルーターがいることがわかっているので、 MLD 用のマルチキャストルーターポートを手動でスイッチ1と2に設定してみます。

スイッチ1と2のポート1をそれぞれマルチキャストルーターポートとして設定しました。これでルーターのポート1に membership report が届き、 LAN 側に ff3e::x:5 のマルチキャスト端末がいることを学習します。また外部のマルチキャストルーターに LAN 内にマルチキャスト端末がいたことを MLD プロキシを通じて伝えます。その後 membership query が外部のマルチキャストルーターから送信されると・・

ご覧のように、晴れて LAN 内に行き渡るようになり、これで LAN 内のマルチキャスト端末の存在が適切に維持・管理されることになります。めでたし、めでたし。

MLD スヌーピングをオンにするとひかり TV が観られない問題

もう、おわかりですね。せっかく MLD スヌーピング対応スイッチングハブを買ったのに、それをオンにしたらひかり TV が観られなくなってしまった場合、たぶん原因はスイッチが2台以上(もしくは MLD スヌーピング対応のスイッチ内蔵ルーター+スイッチ1台以上)あって、マルチキャストルーターポートを設定してないためです。 MLD スヌーピングがマルチキャスト membership report をどこにも転送しなくなってしまうわけですね。

そして membership report がルーターに届かなくなると、その LAN にはひかり TV のマルチキャスト端末がいない、と見なされて、 membership query も、そもそものひかり TV のマルチキャストでの放送データも届かなくなってしまいます。

というわけで、 MLD スヌーピングをオンにしたら、そのスイッチングハブで忘れずにルーター(ホームゲートウェイ)の接続されているポートを、マルチキャストルーターポートとして設定するようにしましょう。しかしマルチキャストルーターポートって長い名前すね・・。

ひかり TV を使用中に WiFi でインターネットが使えなくなる場合

前に述べたように、マルチキャストが WiFi に流れ込み、 WiFi アクセスポイントがマルチキャストパケットを大量にコピーしなければならないことで、処理能力を超えてしまうことが原因のようです。フレッツや Nuro でホームゲートウェイをレンタルしている場合は多分 MLD スヌーピングが最初から有効になっているので、この問題は起こらないと思います。

フレッツでひかり電話を契約していない場合などは ONU だけのことが多いようで、その場合は自前でルーターを用意する必要があります。ひかり TV 対応のホームゲートウェイでなく、自前のルーターを使う場合は、下記のことに気をつけると WiFi が使えなくなるのを防げると思います。

  1. ひかり TV 対応かつ Snooping 機能」等のある市販のルーターを買って、 MLD スヌーピングをオンにし、ひかり TV チューナーとそのほかの機器がつながる LAN ポートを分ける
  2. ひかり TV 対応かつスヌーピング非対応の市販ルーターに MLD スヌーピング対応のスイッチングハブをつなぐ
    • この場合、ルーターの他の LAN ポートやルーター内蔵の WiFi は使わない
    • マルチキャストルーターポートはルーターが接続されたポートに設定
    • スイッチングハブの配下に改めて WiFi アクセスポイントをつなぎ、 WiFi はそっちを使う
  3. もしくは、 ONU に直接 MLD スヌーピング対応スイッチングハブをつなぎ、そこにひかり TV チューナーと、自前のルーターをつなぐ
    • マルチキャストルーターポートは ONU が接続されたポートに設定

ひかり TV のチューナーは、フレッツ網に IPoE で繋がっていれば、必ずしもルーターがなくても動作します。要は、ひかり TV チューナーと WiFi アクセスポイントが、必ず MLD スヌーピング機能を持つスイッチングハブの配下に入るようにすればよいわけです。

ただ、3番目のやり方の場合、ひかり TV チューナーと他の LAN のサブネットが分かれてしまうので、「ひかり TV どこでも」アプリなどホームサーバー機能 (DTCP-IP) を使った視聴はできなくなってしまいます

MLD スヌーピングと EdgeSwitch

さて、それでは、 EdgeSwitch 8 150W で実際に MLD スヌーピングとマルチキャストルーターポートを設定してみます。これがこの設定例のネットワーク構成です。

この中の EdgeSwitch 1台に 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 でポート1に入る
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 マルチキャストがブロックされる

参考にしたスレッドは下記の通りです。

Optimizing IPv6 – MLDv2?

IGMP Snooping blocks IPv6 router advertisements

おわりに

頑張って書きましたが、もし間違いがあったらこっそり教えてください・・。


yabe.jp » Gadgets » MLD スヌーピングとひかり TV