• 放送・映像へのIP技術の適用 (8)

 
 
Print Friendly, PDF & Email

放送の現場でもIP技術を活用した働き方の見直しが着実に広がっているようです。IP技術を活用すれば、遠隔地にある装置(スイッチ)を操作することが可能になります。では、遠隔地でトラブルが発生した場合、その調査は、どうすれば良いのでしょうか?遠隔地から調査できなければ、十分にIPのメリットを享受しているとは言えません。では、どのような方法でトラブル調査が可能なのでしょうか。今回は、ある事例を紹介しながら、調査方法を紹介していきます。

遠隔地とスタジオを接続、両拠点間に送信機と受信機が配置されています。この送信機と受信機の間で音声の送受信ができないという事象を振り返ってみましょう。

パケットキャプチャ

送受信機の間には、IPの到達性がある (pingの疎通ができる)、送信機、受信機が接続されるFirst Hop Router (FHR)、Last Hop Router (LFR)のマルチキャストテーブルには、送信機が送信するストリーム情報 ( { source, group })、受信機が受信したいストリーム情報 (igmp) が確認できる。それにもかかわらず、音声通信ができないというケースがありました。ユニキャストが中心のIT系ネットワークでは、お目にかかることのない状況です。このような状況を打開するのが、パケットキャプチャです。今回の事象でもパケットキャプチャが活躍しました。

スイッチでキャプチャ

EOSは、スイッチのフロントパネルポートを流れるパケットをスイッチのCPUにコピーして、tcpdumpでキャプチャ、解析することが可能です。(コピーすることをミラーリングと呼びます) (tcpdumpの利用方法は、tcpdumpを利用したトラブルシューティング例 をご覧ください) 早速、送受信機の間に介在するスイッチでtcpdumpを実行してみました。今回は、送信機が接続するFHRの入力ポートをパケットキャプチャしました。調査の対象になるマルチキャストアドレスは、239.202.29.2 です。(音声送受信機の登録に左記のグループアドレスが利用されているとのことでした) スイッチでパケットキャプチャを実行すると、以下のとおり、239.202.29.2 がキャプチャできていました。

239.202.29.2のパケットの内容を確認してみました。IPのTTLフィールドが、”1″になっていることが確認できました。TTLは、当該のパケットがネットワーク上に存在できる時間です。TTLは、通過するホストによって減らされますから、このパケットは、FHRからフォワーディングされることはありません。

送受信機の間にIPの到達性はある、送信機、受信機が接続されるFirst Hop Router (FHR)、Last Hop Router (LFR)のマルチキャストテーブルには、送信機が送信するストリーム情報 ( { source, group })、受信機が受信したいストリーム情報 (igmp) が確認できる。それにもかかわらず、受信機で送信機のストリームが受信できない。この事象の原因は、当該ストリームのパケットのTTLと考えることができそうです。

業界特有のデバイス

IT系のシステムでTTL=1といえば、OSPFをはじめとしたネットワーク制御のプロトコルに利用されています。これらのプロトコルは、隣接するデバイス同士でプロトコルパケットを交換しますので、そのIPヘッダのTTLが、”1″でも問題は生じません。放送用のデバイス、特にインカムのような音声サービスを提供するデバイスでは、古くからIPアドレスとネットワークが活用されてきました。プラグアンドプレイの観点から、IPアドレス割り当てにリンクローカルアドレスを利用し、ユーザにIPネットワークを意識させることなく音声サービスを実現していたようです。このため、音声サービスは、レイヤ2のネットワーク上で実現されてきました。このシリーズでも紹介してきましたが、映像信号のIP活用には、レイヤ3ネットワークを利用することが一般的です。レイヤ3ネットワークに従来から現場で活躍してきた音声システムを統合すると、今回ご紹介したようなケースが散見されるでしょう。(音声システムもSMPTE2110対応を進める中で、ルーティングネットワークへの適用を考慮してTTLの値も見直されているようです。) 今回のケースでは、音声の送受信機の登録用の通信にTTL=1のマルチキャストが利用されていました。この結果、送受信機の登録に影響が生じ、音声の送受信ができなかったと考えられます。

データのリモート転送

トラブルシューティングにおいてパケットキャプチャは、有効な手段です。では、遠隔地にあるスイッチでパケットをキャプチャし、そのデータを手元に転送することはできるのでしょうか?遠隔地のスイッチにログインしてパケットキャプチャ、ローカルの端末にファイル転送して解析することも可能です。解析を始めるまでの手順が煩雑になります。EOSでは、遠隔地のスイッチに流れるデータをミラーリングして、目的の場所まで転送することが可能です。目的の場所まデータ転送するため、ミラーリングしたデータをIPルーティング可能な状態にします。(GREと呼ばれるパケット=ヘッダにカプセリングします。これをGREトンネリングと呼びます) GREトンネリングを利用することで、データは、ルーティング可能なIPパケットとして扱うことが可能になります。ミラーリングの転送先に遠隔地のデバイスのIPアドレスを指定します。ここで、GREのヘッダを外し、解析可能なデータにします。それでは、データの遠隔地への転送設定を紹介しましょう。ミラーリング設定の送信先をGREトンネルに指定、GREカプセリングしたパケットの転送先を指定します。

hostname(config)#monitor session 1 source <source> rx 
hostname(config)#monitor session 1 destination tunnel mode gre source <source ip address> destination <dest ip address>[ ttl <value> ][ dscp <value> ][ protocol <value> ]

転送先でGREヘッダを外すには、いくつかの方法が検討できます。(1) GREヘッダの削除: Tap Aggregation モードで動作するスイッチのTapポートでGREヘッダを削除します。(Tap Aggregationについては、selective-packet-truncation-in-tap-aggregationを参照ください) TapポートでGREヘッダを削除、オリジナルのパケットは、Toolポートに転送されます。詳しくは、monitor session header removalを参照ください。 (2) GREの終端:転送先のTap AggregationスイッチがGREの終端先として機能します。

今回は、放送ネットワークにおける事例とパケットキャプチャを利用した原因特定のステップを紹介してきました。さらに、遠隔地のスイッチから、データ転送する方法も紹介しました。これらの手法は、遠隔地で発生する不測の事態を解決するためのパワフルな手段になることは間違いありません。

Follow

Get every new post on this blog delivered to your Inbox.

Join other followers: