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(CMS)に基づくものです。

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

背景説明

ここでの唯一の制限は、4ポートスイッチのさまざまなインターフェイスが異なるサブネットに存在する必要があることです。そうしないと、セットアップでルーティングの問題が発生する可能性があります。例外として、ADMINインターフェイスを持つハードウェアXサーバは、CMSインストールガイドに記載されているとおり、他のインターフェイス(A/B/C/D)と同じサブネットにこのADMINインターフェイスを持つことが許可されます。

注：Cisco Meeting Serverの2つのインターフェイスを同じサブネットに配置することはできません。唯一の例外は、物理Acano XシリーズサーバのADMINインターフェイスは、他のインターフェイス（AからD）と同じサブネット上に配置でき、一般的な導入である可能性があることです。

TURNサーバコンポーネントでバインディング要求を受信する際に、ルーティングロジックを知る必要がある状況に遭遇することがあります。たとえば、応答が送信されるインターフェイスを確認できます。

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

IPルーティングロジックは、接続がUser Datagram Protocol（UDP；ユーザデータグラムプロトコル）またはTransmission Control Protocol（TCP；伝送制御プロトコル）のどちらであるかによって異なります。
TCPの場合、新しい接続か着信への応答かにかかわらず、図のフローチャートを使用して、どのIPルーティングロジックがケースに適用されるかを確認できます。

着信TCP接続応答

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

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

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

注：このロジックは、新しい送信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つのスニペットは、モジュールの代わりにmmp4の項にありますを参照してください。

    "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がデフォルトです。

この図で強調表示されているデフォルトのパラメータを使用して、インターフェイスでこれを確認できます。

次に、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台のエッジサーバを使用した1台のスプリットサーバの設定例を示しています。

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

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

状況：

• WebRTCクライアントはログインできますが、コールは失敗します
• CBからTURNサーバへの要求のバインドと割り当ては、成功の応答を受け取ります
• 外部WebRTCクライアントからTURNサーバに要求をバインドして割り当てますが、成功の応答を取得できません

説明：

• WBとロードバランサ(LB)は着信TCP接続にのみ応答し、発信TCP接続そのものを開始しないため、このルーティングは問題になりません。

注：両方のサービスが同じサーバ上にあるため、WBは引き続きLBへの発信接続を行うことができますが、これは内部的に行われます。

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

ソリューション：

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

ipv4 b add <IP-address>/<prefix length> <default-gateway>
ipv4 b enable

無効にする
Turn Listen d b
Turn Enable

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

注：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 default

確認 

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

トラブルシュート 

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

関連情報 

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