Dante マルチキャスト帯域: トラフィックの測定・制御・検証

TL;DR — Dante のマルチキャスト帯域は、送信元デバイスだけでなく、通過するすべてのリンクで評価する必要があります。マルチキャストフローとリスナーを把握し、Dante Controller で Primary と Secondary の Tx/Rx 帯域を確認し、スイッチの uplink、trunk、低速ポート、無線境界をたどってください。適切に設計された IGMP snooping は、リスナーのいないポートからメディアを除外できます。そうでない場合、マルチキャストは広く flood されると考えるべきです。不要なフローを削除し、経路を絞り込み、各変更後に実際の音声、clock、discovery、フェイルオーバーを検証してください。

マルチキャストはトラフィックの流れる場所を変える

Dante のマルチキャストフローは、複数の受信側が参加できる 1 つのメディアストリームを送ります。リスナーが多いソースでは送信側のフロー使用量を抑えられる一方で、ネットワークの多くのリンクで帯域を消費することがあります。マルチキャスト制御が正しく機能しない場合、トラフィックは購読済みの受信側だけでなく、broadcast domain 全体に flood されると考えてください。

つまり、マルチキャスト帯域は 経路の問題 です。送信元だけを見ても、100 Mbps のエッジ、スイッチ間 trunk、Secondary ネットワーク、Wi-Fi uplink のどこが過負荷になっているかは分かりません。

Dante の unicast と multicast のガイド では、どちらのフロー方式が適切かを説明しています。この記事では、その次の問い、つまり選んだマルチキャストトラフィックが実際のネットワークで適切に収まり、正しく動作しているかを扱います。

1 つの共通帯域値を使わない

フローの帯域は、メディア形式、サンプルレート、チャンネル数、パケット化、実装によって変わります。動画が入ると規模は大きく変わります。ネットワークリンクは control、clock、management、その他のアプリケーショントラフィックも運ぶため、理論上の line rate いっぱいで設計すべきではありません。

記憶に残っている「1 チャンネルあたり何 Mbps」という近道ではなく、Dante Controller の実測値と最新のデバイスドキュメントを使ってください。測定値は現在の経路の観測結果として扱い、将来のフロー数やリスナー数が増えたショーでの保証とは考えないでください。

Dante Controller の帯域証拠を読む

Network Status では、個別の Primary および Secondary インターフェースのおおよその送受信トラフィックを確認できます。Primary Tx、Primary Rx、Secondary Tx、Secondary Rx の帯域列を並べ替えるか確認し、最も大きいエンドポイントと予期しないトラフィックを見つけてください。

列はトポロジーと合わせて解釈します。

• 送信元で高い送信帯域が出るのは、複数のフローを生成している場合には想定どおりかもしれません。
• 購読数が少ないデバイスで受信帯域が高い場合、flood されたマルチキャストを示している可能性があります。
• Secondary のトラフィックは、冗長設計では物理的に分離された Secondary 経路上で評価しなければなりません。
• エンドポイントの値が低くても、共有 uplink に余裕があるとは限りません。
• 現在のトラフィックだけでは packet drop は分からないため、スイッチとデバイスの error と比較してください。

Dante ネットワークヘルスのガイド では、利用率、error、latency、clock 履歴の関係をより広く扱っています。

リンク単位でマルチキャスト予算を組む

1. すべてのマルチキャストフローを一覧化する

送信元、フロー名、チャンネル、メディア種別、サンプルレート、想定受信側、Primary か Secondary か、運用上の目的を記録してください。廃止予定のテストフローは、どの本番先も必要としていないことを確認してから削除します。

2. 物理経路を描く

送信元ポート、アクセススイッチ、すべての uplink または trunk、受信側スイッチ、受信側ポートをマッピングしてください。制御用コンピュータ、無線アクセスポイント、ルーター、そして経路内で他と速度が異なるすべてのリンクも含めます。

3. 容量と現在負荷を記録する

ポートの公称最大値を前提にせず、ネゴシエートされたリンク速度を確認してください。代表的な公演条件で、デバイスの帯域、スイッチポート利用率、discard、error、マルチキャストカウンターを記録します。

4. リンクごとにフローを加算する

各リンクについて、そのリンクを実際に通過するすべてのトラフィックを合計します。リンクの先にリスナーがいるマルチキャストフローや、flood されたフローも含めます。Primary と Secondary は分けて管理してください。インフラを共有している場合は、Dante 以外のトラフィックも含めます。

5. 運用マージンを確保する

機材、トラフィックの混在、バースト特性、会場ポリシーに合ったエンジニアリング上の閾値を選んでください。すべてのネットワークに共通する安全な利用率は存在しません。受入テストは、想定される最悪条件で、文書化されたマージンのもと、安定したメディア、clock、control、復旧ができることです。

IGMP snooping を設計された仕組みとして使う

IGMP snooping により、スイッチは multicast グループの参加を監視し、登録された multicast メディアを必要なポートにのみ転送できます。正しく pruning できれば、高帯域のメディアを無関係なエンドポイントや Wi-Fi link から遠ざけられます。

しかし、スイッチのチェックボックスを 1 つ入れるだけでは不十分です。完全な設計には、IGMP querier、一貫した VLAN 設定、対応しているスイッチ動作、そして multicast を通過させるすべてのスイッチでの正しい設定が必要になる場合があります。用語や初期値はベンダーごとに異なるため、スイッチと Dante の設計ドキュメントに従ってください。

設定後は、カウンターで動作を証明します。

1. 既知のマルチキャスト送信元と受信側を 1 つ用意する
2. 正確な ingress、uplink、受信側、無関係ポートを特定する
3. 必要な経路でトラフィックが増えることを確認する
4. 無関係なポートがメディアストリームを運んでいないことを確認する
5. リスナーを追加または削除し、membership と forwarding の変化を観察する
6. discovery、clock、control、実際のメディアが安定していることを確認する

解決策としてすべての multicast を block しないでください。Dante の discovery と control も multicast の仕組みを使います。無差別な filter は、元のメディアトラフィック問題を隠しつつデバイスを見えなくしてしまうことがあります。

ワイヤレス control 経路を保護する

Dante メディアは、Wi-Fi 上で通常の有線トラフィックのように動くと考えるべきではありません。アクセスポイントの uplink に到達した multicast メディアは、コンピュータが Dante Controller を実行しているだけでも、ワイヤレスの control 性能を低下させる可能性があります。

検証済みの設計によって、メディアを無線分岐から遠ざけてください。具体的には、正しい IGMP pruning、対応機器で利用できる適切な filtered control port、または他のメーカー承認済みの境界を使います。設計が必要な discovery と control トラフィックを引き続き通せることを確認してください。実際のアクセスポイントとスイッチでテストしてください。wireless の multicast 動作は機器ごとに異なり、万能の安全トラフィック上限はありません。

最も狭い原因からトラフィックを減らす

Dante の flow limit を確認せずに、すべてを unicast に変換しないでください。トラフィックを移動すると 1 つのリンク問題は解決しても、別の場所で送信元フローを使い切ることがあります。

マルチキャスト帯域の問題を診断する

1. 現在の経路、トポロジー、Controller の表示、スイッチカウンターを保持します。
2. 最初に影響を受けた受信側と、その送信元までの正確な経路を特定します。
3. 経路順に、すべてのリンクのネゴシエート速度、利用率、discard、error を確認します。
4. 想定されたリスナーと、観測されたマルチキャスト forwarding を比較します。
5. 制御された時間帯に、非必須のフローを一時的に 1 つ削除または分離します。
6. 利用率、packet error、latency 警告、control 応答、音声が一緒に改善するかを確認します。
7. 最小限の恒久対策を適用し、その後に復旧して完全な公演状態をテストします。

相関が重要です。error のない高帯域値は正常かもしれませんし、エンドポイント合計がきれいでもクリックや遅延パケットは oversubscribed な uplink が原因かもしれません。QoS、latency、multicast を同時に変更するのではなく、証拠に従ってください。

冗長性と障害状態を検証する

冗長 Dante システムでは、Primary と Secondary ネットワークが別のインフラ上で並行した役割を担います。予算管理と確認は独立して行ってください。Primary 経路が健全でも、Secondary 経路の速度、pruning、容量が正しいとは限りません。

通常状態のテストの後で、承認された障害テストを実行します。リンクまたはスイッチ障害によって、無関係なトラフィックが制約のある管理経路へ予期せず移動しないこと、またメディアの継続性、clock、control の可視性、復旧が設計どおりに動作することを確認してください。Dante の redundant モードと switched モードのガイド では、port-mode の境界を説明しています。

マルチキャスト帯域チェックリスト

• すべてのマルチキャストフローに owner、目的、チャンネル、想定リスナーがある。
• 物理経路、VLAN、trunk、Wi-Fi 境界、リンク速度がマッピングされている。
• Primary と Secondary の Tx/Rx 帯域が Dante Controller で取得されている。
• スイッチの利用率、error、discard、マルチキャストカウンターが記録されている。
• IGMP snooping と querier の動作が経路全体で検証されている。
• 無関係なポートと無線分岐がマルチキャストメディアを受信していない。
• 低速リンクと共有 uplink に、文書化された最悪ケースのマージンがある。
• マルチキャストを unicast に変える前に、flow capacity への影響を確認している。
• 実際の音声、clock、discovery、control、冗長性、復旧が合格している。

FAQ

Dante のマルチキャスト帯域はどれくらい使う？

単一の値はありません。メディア形式、サンプルレート、チャンネル数、パケット化、そしてフローの数と配置によって変わります。現在のエンドポイントを測定し、それらが通るすべてのネットワークリンクを予算化してください。

Dante の帯域はどうやって確認する？

Dante Controller の Network Status で Primary と Secondary インターフェースのおおよその Tx/Rx 値を確認し、スイッチポートの速度、利用率、discard、error、物理トポロジーと突き合わせます。

Dante には IGMP snooping が必要？

小規模な audio network ではなくても動作しますが、マルチキャストは広く flood される可能性があります。十分なマルチキャスト、特に動画や無線 control 境界を含むネットワークでは、意図的で完全に検証された multicast 設計が必要です。最新の Audinate とスイッチベンダーのガイダンスに従ってください。

なぜ Dante のマルチキャストは Wi-Fi に影響するの？

マルチキャストメディアが access-point の link に到達すると、無線 airtime を消費したり、Controller の接続性を低下させたりすることがあります。必要な discovery と control トラフィックを残しつつ、無線分岐の前でメディアを pruning してください。

Dante のマルチキャストトラフィックを減らすには？

未使用のフローを削除し、受信側数と送信元容量に合う場合は unicast を使い、IGMP pruning を修正し、メディア負荷を減らすか経路変更し、制約のあるリンクはアップグレードしてください。各変更後に検証します。

トラフィック計画を rider に入れる

緑色の route matrix だけではネットワーク容量は文書化できません。マルチキャストフロー一覧、リスナーマップ、スイッチ経路、リンク速度、観測されたピーク負荷、pruning の証拠、変更の責任者、障害テスト結果を Techrider.live に残しておくと、招待された協力者が同じテクニカルライダーを編集し、承認済みプランを保存し、load-in 前に履歴を確認できます。