AcanoおよびCisco Meeting Server(CMS)のIPルーティングルール

はじめに

このドキュメントでは、Acano(ACANO)サーバまたはCisco Meeting Server(CMS)サーバのIPルーティングルールについて説明します。AcanoサーバまたはCMSサーバには、それぞれ独自のデフォルトゲートウェイを持つ複数のインターフェイスを設定できます。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• CMSコンポーネント： 
  • WebBridge(WB)
  • NAT(TURN)サーバ周辺のリレーを使用したトラバーサル
  • CallBridge(CB)
• 基本的な IP ルーティング

使用するコンポーネント

このドキュメントの情報は、バージョン2.3.xのCisco Meeting Serverに基づくものです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

ここでの唯一の制限は、4ポートスイッチ上の異なるインターフェイスを異なるサブネットに配置する必要がある点です。そうしないと、設定でルーティングの問題が発生する可能性があります。例外として、ADMINインターフェイスを持つハードウェアXサーバでは、『CMSインストールガイド』で説明されているように、このADMINインターフェイスを他のインターフェイス(A/B/C/D)の1つと同じサブネットに持つことができます。

注:Cisco Meeting Serverの2つのインターフェイスを同じサブネットに配置することはできません。唯一の例外は、物理的なAcano Xシリーズサーバの管理インターフェイスが他のインターフェイス(A ～ D)と同じサブネット上に存在できる点です。これは一般的な導入です。

たとえば、どのインターフェイスから応答が送信されたかを確認するために、TURNサーバコンポーネントでバインディング要求を受信する場合、ルーティングロジックを知る必要がある状況が発生する可能性があります。

Acano/CMSサーバに適用されるIPルーティングルールはどれですか。

IPルーティングロジックは、接続がユーザデータグラムプロトコル(UDP)か伝送制御プロトコル(TCP)かによって異なります。
TCPの場合は、新しい接続であるか、着信への応答であるかに関係なく、図のフローチャートを使用して、どのIPルーティングロジックがこのケースに該当するかを調べることができます。

着信TCP接続応答

Acano/CMSサーバは、（すでにTCP接続が存在するため）要求が受信されたインターフェイス自体の着信TCP接続に応答します。

アウトバウンドTCP接続またはアウトバウンドUDPパケット

どちらのシナリオでも、このフローチャートに従って、これらのIPルーティングルールに従います（および着信TCP接続応答の最初のステップ）。

注：このロジックは、新しい発信UDPパケットの作成、または受信パケットへの応答として送信されるUDPパケットに適用されます。

すべてのIPルーティングテーブルを表示する方法（インターフェイスごと）

メインボード管理プロセッサ(MMP)でipv4 <interface>コマンドを使用する。

これにより、設定されているIPアドレスとプレフィクス長、およびこのインターフェイスに対して設定されているすべてのスタティックルートを、次の図に示すように確認できます。

たとえば、8.8.8.8/32および8.8.4.4/32へのルートは、この特定のインターフェイス(a)で明示的に発信するように設定されます。

eth4にマッピングされている各インターフェイス(A)のlive.json ファイルに追加されたルートを確認することもできます。

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"
                        }
                    }

注:live.jsonファイルでは、インターフェイスA ～ D（MMPから）はeth4-eth1にマップされるため、インターフェイスAはeth4にマップされ、インターフェイスDはeth1にマップされます。もう1つのスニペットは、ADMINインターフェイスが、他のインターフェイスで示されているようなmoduleではなくipv4の下のmmpセクションにあることが確認できるXシリーズサーバのスニペットです。

    "ipv4": {
        "mmp": {
            "interfaces": {
                "eth0": {
                    "macaddress": "44:4A:65:00:13:00",
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "address": "10.48.79.72",
                    "prefixlen": "24",
                    "gateway": "10.48.79.200"
                }

特定のインターフェイスへのスタティックルートを追加または削除するには、コマンドipv4 <interface> route (add | del) <address>/<prefix length>を使用できます。

デフォルトインターフェイスを確認して変更する方法

空白の設定で開始した場合、デフォルトではインターフェイスAがデフォルトになります。

次の図で強調表示されているように、インターフェイスのdefaultパラメータでこれを確認できます。

これは、MMP上のコマンドipv4 <interface>の出力です。

注：この値をtrueに設定すると、これは図に示すようにデフォルトのインターフェイスになります。

また、live.jsonから、インターフェイスA（eth4にマッピング）がデフォルトインターフェイスとして設定されているかどうかも確認できます。

    "ipv4": {
        "module": {
            "interfaces": {
                "eth4": {
                    "dhcp": "false",
                    "enabled": "true",
                    "default": "true",
                    "macaddress": "00:50:56:99:5A:5B",
                    "address": "10.48.54.160",
                    "prefixlen": "24",
                    "gateway": "10.48.54.200",
                    "routes": {
                        "8=8=8=8-32": {
                            "address": "8.8.8.8",
                            "prefixlen": "32"
                        },
                        "8=8=4=4-32": {
                            "address": "8.8.4.4",
                            "prefixlen": "32"

デフォルトインターフェイスを変更するには、ipv4 <interface> defaultコマンドを使用できますが、この変更に対応する正しいスタティックルートが設定されていることを確認してください。そうしないと、ルーティングに影響が及びます。

例：

この図は、次の要件を持つ1つのコアサーバと1つのエッジサーバを持つ単一のスプリットサーバ設定の例を示しています。

• コアサーバはDMZインターフェイス(A)にのみ接続でき、パブリックインターフェイス(C & D)には接続できません。
• TURNサーバコンポーネントは、WebBridgeと同様に443でリッスンする必要があります（したがって、ポートの衝突を避けるために異なるインターフェイスが必要です）。

この例では、特別なルーティングは設定されておらず、別のデフォルトインターフェイスも指定されていないため、エッジサーバのインターフェイスAがデフォルトになります。

状況：

• WebRTCクライアントはログインできるが、コールが失敗する
• CBからTURNサーバへのBindingおよびAllocate Requestsは「Success」応答を取得します。
• 外部WebRTCクライアントからTURNサーバへのバインディングとAllocate Requestsが到着しますが、Success応答は取得されません

説明：

• WBおよびロードバランサ(LB)は、着信TCP接続にのみ応答し、それ自体は発信TCP接続を開始しないため、このルーティングによって問題が生じることはありません。

注：両方のサービスが同じサーバにあるため、WBは引き続きLBへのアウトバウンド接続を確立できますが、これは内部的に発生します。

• また、CBからTURNサーバDMZ IPへのバインディング要求と割り当て要求にも、同じサブネット内にあるため（エッジインターフェイスAとコアインターフェイスA）、またはスタティックルートが設定されておらずデフォルトインターフェイス（この場合はインターフェイスA）上に送信されるだけのために、応答が返されます。
• 外部のBinding要求とAllocate要求の場合、スタティックルートがないため、デフォルトのインターフェイスAを使用してトラフィックをルーティングします（これにより外部クライアントに到達できなくなります）。

ソリューション：

• エッジサーバにインターフェイスBを追加し、内部WB接続にインターフェイスA（およびLB）を使用し、内部TURNサーバ接続にインターフェイスBを使用します（443のポートの衝突を避けるため、TURNとWBの両方に使用されます）。 MMPで次のコマンドを使用して、これを設定します（さらに、インターフェイスBの新しいserverAddressに応じて、callbridgeのTURN設定を修正します）。

ipv4 b add <IP-address>/<prefix length> <default-gateway>
ipv4 bの有効化

無効にする
聞き取りd bを回す
有効にする

• 次のコマンドを使用して、エッジサーバから内部コアサーバにトラフィックをルーティングするためのスタティックルートを追加します。
    
    ipv4 b route add <アドレス>/<プレフィックス長>

注:LBとWBは着信TCP接続だけに反応するため、必要な操作はTURNのUDPパケットのルーティングだけです。したがって、この操作はインターフェイスBで行います。また、当然のことながら、インターフェイスBのゲートウェイがCBにルーティングできることを確認します。

たとえば、コアサーバのIPアドレスが192.168.0.100/24の場合、コマンドはipv4 b route add 192.168.0.100/24またはipv4 b route add 192.168.0.100/32のいずれかにする必要があります。

• 外部TURNサーバインターフェイス(D)をトラフィックのデフォルトインターフェイスにします。

ipv4 dデフォルト

確認 

現在、この設定に使用できる確認手順はありません。

トラブルシュート 

現在、この設定に関する特定のトラブルシューティング情報はありません。

関連情報 

• テクニカル サポートとドキュメント - Cisco Systems
• Collaboration Solutions Analyzerツール 
• CMSドキュメント