- ライター：細谷 典弘
- 2008年ぐらいからデータセンターネットワークの調査・検証を行っていたが、ここ数年は、マルチクラウド基盤に用いられるハードウェアとソフトウェアの最先端テクノロジーに関する調査・検証と、案件の技術支援をする業務に従事している。
特に Kubernetes に注目している。
また最近では、放送システムの IP 化に向けた技術調査・検証も行っている。
【主な保有資格】
CCIE Routing and Switching (#16002)
CCIE Data Center (#16002)
Red Hat Certified System Administrator in Red Hat OpenStack（RHCSA） (EX210)
電気通信主任技術者（伝送交換）
目次
放送システムの IP 化を進めると、すべのネットワーク機器をシングルベンダーで設計・構築することが難しく、マルチベンダー環境になる可能性が高くなります。
例えば、マスターとスタジオでネットワークを設計するベンダーが違う場合もありますし、新たに放送 IP 化を検討するスタジオと過去に放送 IP 化をしたスタジオでベンダーが変わることもありえます。
本ブログでは、マルチベンダー環境でのネットワークの設計法を紹介します。
マルチベンダー環境のネットワーク設計
最初のパターンとして、各ベンダーが実装している帯域制御の機能を使わない場合を考えてみたいと思います。
この場合は、OSPF や PIM など標準化されているプロトコルだけを使用しているため、比較的容易に設計・構築が可能になります。
しかしながら、帯域の設計などは大変重要になります。
帯域制御は ECMP(Equal Cost Multi Path) とよばれるロードバランスで行うことしかできないため、帯域の有効活用には限界があります。
また、オーバーサブスクリプションによる映像や音声などのドロップを 100% 防ぐことはできません。
放送システムでのマルチキャストの ECMP 問題に関しては、「Video over IP：放送システム IP 化で押さえておくべきネットワーク冗長の落とし穴」で紹介しています。
最近は昔ほど問題は発生しなくなりましたが、標準プロトコルでもマルチベンダーでの接続に問題が起こる可能性はありますので、事前に検証を行ったほうが安全です。
次に、帯域制御の機能を使用したときの、マルチベンダー環境に関して考えたいと思います。
各社いろいろな帯域制御の仕組みを持っていますが、今回は Cisco の NBM (Non-Blocking Multicast) と一般的なマルチキャストを使用したときの接続方法を紹介したいと思います。
NBM に関しては、「放送システム IP 化に向けたネットワーク技術」で紹介しています。
NBM 環境と非 NBM 環境をどのように接続するかですが、特に難しいことはありません。NBM と非 NBM が接続されている NBM 側のインタフェースで、nbm external-link の設定を追加するだけです。
ここからは、図1のような NBM ファブリックの SpineA と非 NBM ファブリックの SpineB を 40Gbps のリンク２本で接続した環境での動作を確認します。
NBM の設定は、図1のように１つの Video 映像に 25Gbps の帯域を確保するような設定をしています。
25Gbps に設定している理由は、1リンクあたりに１つの Video 映像しか流せないようにし、mroute の状況を確認するためです。
（今回は検証環境の都合上、SpineB に直接 IP GW が接続されています）
まずは図２のような、NBM 側が Receiver で、非 NBM 側に Sender がある場合に、どのような動作になるかを見ていきます。
このパターンでは、NBM の環境と同じ動作になります。
SpineA は帯域の空いているリンクに pim join を投げるため、NBM と 非NBM の接続環境においても、NBM 環境と同じように帯域が確保され、帯域が足りなくなった場合は pim join を投げず、帯域があふれることはありません。
次に図３のような NBM 側が Sender で、非 NBM 側に Reciver がある場合に、どのような動作になるかを見ていきます。
このパターンでは、非 NBM 側の機器のロードバランスの仕組みに影響を受けます。
NBM 側から映像などのデータを非 NBM 側に送信する際に複数リンクがあるとき、どのリンクを使用して送信するかは、非 NBM 側から来た pim join に基づいて選択します。
つまり、複数リンクがあったとしても pim join が偏っていれば、リンクの有効活用度は低くなってしまいます。
しかし、すでに帯域に空きの無いリンクに pim join が来たときには mroute が作成されないため、リンクの帯域があふれ、ドロップが発生することはないため、既存の映像などには影響を与えません。
図４のように、SpineB 側の mroute にある (10.3.11.100/32, 232.0.1.17) が、SpineA 側には作成されていません。
まとめ
標準化プロトコルのみのマルチベンダー環境であれば、接続することで問題が起こる可能性は極めて低いです。
しかし、ベンダー毎の帯域を制御するような機能を使った場合は、ベンダー毎の接続ポイントでどのような動作になるかの確認が必要になります。
今回紹介した NBM は、比較的容易にマルチベンダー環境でも使用することが可能です。
※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。
