- ホーム
- /
- 投稿記事
ローカルゲートウェイ(LGW)は、Cisco Webex Calling のお客様にオンプレミスのPSTNアクセスを提供するための独占的なソリューションです。このドキュメントでは、アクティブコールのステートフルフェールオーバーを保証するために、アクティブまたはスタンバイのCUBEを使用して、CUBEの高可用性を使用してローカルゲートウェイを設定する方法について説明します。
ファンダメンタルズ
前提条件
のローカルゲートウェイとしてCisco Unified Border Element(CUBE)ハイアベイラビリティ(HA)を導入する前にWebex Calling、 次の概念を深く理解していることを確認してください。
-
ステートフルコール保存のためのCUBE Enterpriseによるレイヤー2のボックスツーボックス冗長性
この記事に記載されている設定ガイドラインは、既存の音声設定がない専用のローカルゲートウェイプラットフォームを想定しています。 既存のCUBEエンタープライズ環境がローカルゲートウェイ機能も利用するように変更されている場合はCisco Webex Calling、適用されている設定に細心の注意を払って、既存のコールフローや機能が中断されないようにし、CUBE HAの設計要件に従っていることを確認してください。
ハードウェアとソフトウェアのコンポーネント
ローカルゲートウェイとしてのCUBE HAには、IOS-XEバージョン17.9.1以降と、 CUBE HAとLGWの両方の機能をサポートするプラットフォームが必要です。
この記事で紹介しているshowコマンドとログは、vCube(CSR 8000v)Cisco IOSに実装された-XE 17.9.1の最小ソフトウェアリリースに基づいています。
参考資料
さまざまなプラットフォームの詳細なCUBE HA構成ガイドは次のとおりです。
-
シスコプリファードアーキテクチャ Cisco Webex Calling — https://www.cisco.com/c/dam/en/us/td/docs/solutions/CVD/Collaboration/hybrid/AltDesigns/PA-WbxCall.pdf
Webex Callingソリューションの概要
Cisco Webex Callingは、複数のPSTNオプションを備えたオンプレミスのPBX電話サービスに代わるマルチテナント型のクラウドベースの代替サービスを顧客に提供するコラボレーション製品です。
この記事では、ローカルゲートウェイの導入(下記参照)に焦点を当てています。 ローカルゲートウェイ (構内ベースのPSTN)Webex Callingトランクインにより、顧客所有のPSTNサービスに接続できます。 また、次のようなオンプレミスのIP PBX環境への接続も提供します。Cisco Unified CM クラウドとのすべての通信は、SIPの場合はTLS転送、メディアの場合はSRTPを使用して保護されます。
下の図は、既存のIP Webex Calling PBXがない展開を示しており、単一サイトまたは複数サイトの展開に適用できます。 この記事で概説されている設定は、この展開に基づいています。
レイヤー2のボックスツーボックス冗長性
CUBE HAレイヤー2のボックスツーボックス冗長性は、冗長グループ(RG)インフラストラクチャプロトコルを使用して、アクティブ/スタンバイのルーターのペアを形成します。 このペアは、それぞれのインターフェイスで同じ仮想IPアドレス(VIP)を共有し、ステータスメッセージを継続的に交換します。 CUBEセッション情報は、ルータのペア間でチェックポイントされ、アクティブルータがサービスを停止した場合でも、スタンバイルータがすべてのCUBEコール処理をすぐに引き継ぐことができるため、シグナリングとメディアがステートフルに保持されます。
チェックポインティングは、メディアパケットを含む接続された通話に限られます。 転送中のコールはチェックポイントされません(たとえば、送信中または呼び出し中の状態)。
この記事では、CUBE HAはステートフルコール保存のためのCUBEハイアベイラビリティ(HA)レイヤー2のボックスツーボックス(B2B) 冗長性について言及します。
IOS-XE 17.9.1以降、CUBE Cisco Webex Calling HAはトランク導入(構内ベースのPSTN)用のローカルゲートウェイとして導入できます。 この記事では、 設計上の考慮事項と構成について説明します。 この図は、Cisco Webex Callingトランク導入のローカルゲートウェイとしての典型的なCUBE HA設定を示しています。
リダンダンシー・グループ・インフラストラクチャー・コンポーネント
冗長グループ(RG)インフラコンポーネントは、2つのCUBE間のボックスツーボックス通信インフラストラクチャサポートを提供し、最終的な安定した冗長状態をネゴシエートします。 このコンポーネントは以下も提供します:
-
2つのキューブ間で(制御インターフェイスを介して)キープアライブメッセージとハローメッセージを交換することにより、各ルーターの最終的な冗長状態をネゴシエートするHSRPのようなプロトコルです。上の図のGigabitEthernet3です。
-
アクティブルータからスタンバイルータへ(データインターフェイスを介して)各コールのシグナリングとメディア状態をチェックポイントする転送メカニズム。上の図のGigabitEthernet3です。
-
トラフィックインターフェイス用の仮想IP(VIP)インターフェイスの構成と管理(同じRGグループを使用して複数のトラフィックインターフェイスを設定できます)— GigabitEthernet 1と2はトラフィックインターフェイスと見なされます。
このRGコンポーネントは、音声B2B HAをサポートするように特別に設定する必要があります。
シグナリングとメディアの両方の仮想IP(VIP)アドレス管理
B2B HAは冗長性を実現するためにVIPに依存しています。 CUBE HAペアの両方のCUBEのVIPと関連する物理インターフェイスは、同じLANサブネット上にある必要があります。 音声B2B HAサポートには、VIPの設定と特定の音声アプリケーション(SIP)へのVIPインターフェイスのバインディングが必須です。 Webex CallingアクセスSBC Unified CM、サービスプロバイダー、プロキシなどの外部デバイスは、CUBE HAルーターを通過する通話の宛先IPアドレスとしてVIPを使用します。 したがって、Webex Calling観点から見ると、CUBE HAペアは単一のローカルゲートウェイとして機能します。
確立されたコールのコールシグナリングとRTPセッション情報は、アクティブルーターからスタンブルーターにチェックポイントされます。 アクティブルーターがダウンすると、スタンバイルーターが引き継ぎ、最初のルーターで以前にルーティングされていたRTPストリームを転送し続けます。
フェールオーバー時に一時的な状態のコールは、切り替え後も保存されません。 たとえば、まだ完全に確立されていない通話や、転送機能や保留機能で変更中の通話などです。 確立された通話は、切り替え後に切断される場合があります。
CUBE HAをコールのステートフルフェールオーバーのローカルゲートウェイとして使用するには、次の要件があります。
-
CUBE HAでは、TDMやアナログインターフェイスを同じ場所に配置することはできません
-
Gig1とGig2はトラフィック(SIP/RTP)インターフェイスと呼ばれ、Gig3は冗長グループ(RG)制御/データインターフェイスと呼ばれます
-
同じレイヤー2のドメインに配置できるCUBE HAペアは2つまでです。1組はグループID 1、もう1組はグループID 2です。 同じグループIDで2つのHAペアを設定する場合、RG制御/データインターフェイスは異なるレイヤー2ドメイン(VLAN、個別のスイッチ)に属している必要があります
-
ポートチャネルは、RG制御/データインターフェイスとトラフィックインターフェイスの両方でサポートされています
-
すべてのシグナリング/メディアは仮想IPアドレスから/に送信されます
-
プラットフォームがCUBE-HA関係でリロードされると、常にスタンバイとして起動します
-
すべてのインターフェイス(Gig1、Gig2、Gig3)の下位アドレスは同じプラットフォーム上にある必要があります
-
冗長インターフェイス識別子、riiは、同じレイヤー2のペア/インターフェイスの組み合わせに固有のものでなければなりません
-
両方のCUBEの構成は、物理的な構成を含めて同一でなければならず、同じタイプのプラットフォームとIOS-XEバージョンで実行されている必要があります
-
ループバックインターフェイスは常に稼働しているので、バインドとして使用することはできません
-
複数のトラフィック(SIP/RTP)インターフェイス(Gig1、Gig2)には、インターフェーストラッキングを設定する必要があります
-
CUBE-HAは、RGコントロール/データリンク(Gig3)のクロスオーバーケーブル接続ではサポートされていません
-
CUBE HAが機能するには、両方のプラットフォームが同一で、物理スイッチを介してすべての同様のインターフェースに接続されている必要があります。 CUBE-1とCUBE-2のGE0/0/0は同じスイッチなどで終端する必要があります。
-
WANをCubeで直接終端したり、データHAをどちらかの側で終端したりすることはできません
-
アクティブ/スタンバイの両方が同じデータセンターにある必要があります
-
冗長性のために個別のL3インターフェイス(RG制御/データ、Gig3)を使用することが必須です。つまり、トラフィックに使用されるインターフェイスは、HAキープアライブとチェックポインティングには使用できません
-
フェイルオーバー時には、以前アクティブだったCUBEが意図的にリロードされ、シグナリングとメディアが保持されます
両方のCUBEに冗長性を設定してください
仮想IPを起動するためにHAペアで使用することを目的として、両方のCUBEにレイヤー2のボックスツーボックス冗長性を設定する必要があります。
| 1 |
インターフェイスの状態を追跡するために、グローバルレベルでインターフェーストラッキングを設定してください。
Track CLIはRGで音声トラフィックインターフェイスの状態を追跡し、トラフィックインターフェイスがダウンした後もアクティブルートがアクティブな役割を果たすようにします。 | ||
| 2 |
アプリケーション冗長サブモードで、VoIP HAで使用するようにRGを設定します。
この設定で使用されるフィールドの説明は次のとおりです。
| ||
| 3 |
CUBEアプリケーションのボックスツーボックス冗長性を有効にします。
redundancy-group 1 — このコマンドを追加したり削除したりするには、更新された設定を有効にするためにリロードする必要があります。 すべての設定が適用されたら、プラットフォームをリロードします。 | ||
| 4 |
以下に示すように、Gig1とGig2のインターフェースをそれぞれの仮想IPで設定し、冗長インターフェース識別子(rii)を適用します
この設定で使用されるフィールドの説明は次のとおりです。
| ||
| 5 |
最初のCUBEの設定を保存してリロードしてください。 最後にリロードするプラットフォームは常にスタンバイです。
VCUBE-1が完全に起動したら、VCUBE-2の設定を保存してリロードしてください。
| ||
| 6 |
ボックスツーボックスの構成が期待どおりに機能していることを確認してください。 関連する出力は太字で強調表示されています。 VCUBE-2を最後にリロードしましたが、設計上の考慮事項によると、最後にリロードするプラットフォームは常にスタンバイです。
次に、両方のHA Cubeでローカルゲートウェイの設定( 登録ベースまたは証明書ベース)に進みます。 については、「Cisco IOSXEでのローカルゲートウェイの設定」を参照してくださいWebex Calling。 |