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

はじめに

このドキュメントでは、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)と同じサブネットに持つことが許可されています。

注: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)に明示的に出て行くように設定されます。

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

    "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つのスニペットはXシリーズサーバのスニペットです。このスニペットでは、ADMINインターフェイスが、他のインターフェイスで示されているようなmoduleではなくipv4の下のmmpセクションに含まれていることが確認できます。

    "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要求が到着しますが、Success応答は取得されません

説明：

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

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

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

ソリューション：

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

ipv4 b add <IPアドレス>/<プレフィクス長> <デフォルトゲートウェイ>
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ドキュメント