- ホーム
- /
- 投稿記事
ローカル ゲートウェイとして CUBE の高可用性を実装
ローカル ゲートウェイ (LGW) は、Cisco Webex Calling 顧客に オンプレミス PSTN アクセスを提供する排他的なソリューションです。このドキュメントでは、アクティブ コールまたはスタンバイ CUBE を使用して、 CUBE の高可用性を使用して、 アクティブ コールのステートフル フェールオーバーを確実にするためのローカル ゲートウェイの設定について説明します。
基本
前提条件
Webex Calling のローカル ゲートウェイとして Cisco Unified Border Element (CUBE) ハイ アベイラビリティ (HA) を展開する前に、次の概念を深く理解していることを確認してください。
-
ステートフルコール保持のための CUBE Enterprise とのレイヤ 2 ボックス間冗長性
この記事に記載されている設定ガイドラインは、既存の音声設定がない専用のローカル ゲートウェイ プラットフォームを想定しています。既存の CUBE エンタープライズ展開が、Cisco Webex Calling のローカル ゲートウェイ機能も利用するように変更されている場合は、既存のコール フローと機能が中断されないようにし、CUBE HA 設計要件に準拠するように適用されている構成に細心の注意を払ってください。
ハードウェアとソフトウェアのコンポーネント
ローカル ゲートウェイとして CUBE HA には IOS-XE バージョン 17.9.1 以降と CUBE HA と LGW 機能の両方がサポートされているプラットフォームが必要です。
この記事のコマンドとログの表示は、vCUBE(CSR 8000v)に実装された Cisco IOS-XE 17.9.1 の最小ソフトウェア リリースに基づいています。
参考資料
さまざまなプラットフォーム向けの詳細な CUBE HA 設定ガイドを次に示します。
-
Cisco ISR 4K および Cisco Catalyst 8K シリーズ: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-isr-g3.html
-
CSR 8000v (vCUBE): https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m-cube-ha-csr.html
-
Cisco Webex Calling の Cisco 優先アーキテクチャ— 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 電話サービスにマルチテナントクラウドベースの代替手段を提供するコラボレーションサービスです。
この記事の焦点は、ローカル ゲートウェイの展開(以下を参照)です。Webex Calling のローカル ゲートウェイ (プレミスベースの PSTN) トランクにより、顧客が所有する PSTN サービスへの接続が可能になります。また、Cisco Unified CM などのオンプレミス IP PBX 展開への接続も提供します。クラウド間のすべての通信は、メディアの SIP および SRTP の TLS トランスポートを使用して保護されます。
次の図は、既存の IP PBX なしの Webex Calling 展開を示しています。単一またはマルチサイト展開に適用されます。この記事で説明されている構成は、この展開に基づいています。
レイヤー 2 ボックス間冗長性
CUBE HA レイヤ 2 ボックス間冗長性は、冗長グループ(RG)インフラストラクチャ プロトコルを使用して、ルータのアクティブ/スタンバイ ペアを形成します。このペアは、それぞれのインターフェイスで同じ仮想 IP アドレス (VIP) を共有し、常にステータス メッセージを交換します。CUBE セッション情報は、ルータのペアにわたってチェックポイントで確認され、アクティブ ルータがサービスから外れた場合、スタンバイ ルータがすべての CUBE コール処理の責任をすぐに引き継ぐことが可能になり、シグナリングとメディアのステートフル保持になります。
チェックポイントは、メディア パケットを使用した接続されたコールに限定されます。転送中のコールは、チェックポイントではありません(たとえば、試行中または呼び出し状態など)。
この記事では、CUBE HA はステートフルコール保持のための CUBE ハイ アベイラビリティ(HA)レイヤー 2 ボックスツボックス(B2B)冗長性を参照します。
IOS-XE 17.9.1 では、CUBE HA は Cisco Webex Calling トランク展開(プレミスベースの PSTN)のローカル ゲートウェイとして展開できます。この記事では、設計に関する考慮事項と構成について説明します。この図は、Cisco Webex Calling トランク展開のローカル ゲートウェイとして典型的な CUBE HA セットアップを示しています。
冗長グループインフラ コンポーネント
冗長グループ(RG)インフラ コンポーネントは、2 つの CUBE 間のボックス間通信インフラストラクチャサポートを提供し、最終的な安定した冗長性をネゴシエートします。このコンポーネントは、次の機能も提供します。
-
2 つの CUBE 間でキープアライブ メッセージと hello メッセージを交換することによって、各ルータの最終的な冗長状態をネゴシエートする 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 インターフェイスのバインドが必須です。Unified CM、Webex Calling アクセス SBC、サービス プロバイダー、プロキシなどの外部デバイスは、CUBE HA ルータを経由するコールの宛先 IP アドレスとして VIP を使用します。そのため、Webex Calling の観点から、CUBE HA ペアは単一のローカル ゲートウェイとして機能します。
確立されたコールのコール シグナリングおよび RTP セッション情報は、アクティブなルータからスタンバイ ルータにチェックポイントされます。アクティブ ルータがダウンすると、スタンバイ ルータが引き継ぎ、最初のルータによって以前にルーティングされた RTP ストリームを転送し続けます。
フェールオーバー時に一時的な状態のコールは、切り替え後の保存されません。たとえば、まだ完全に確立されていないコールや、転送または保留機能を使用して変更が行われているコールなどです。確立されたコールは、切り替え後に切断される可能性があります。
コールのステートフル フェールオーバー用のローカル ゲートウェイとして CUBE HA を使用するには、次の要件があります。
-
CUBE HA は TDM またはアナログ インターフェイスを共存できません
-
Gig1 および Gig2 はトラフィック (SIP/RTP) インターフェイスと呼ばれ、Gig3 は冗長グループ (RG) コントロール/データ インターフェイスと呼ばれます。
-
グループ ID を持つ同じレイヤー 2 ドメインには 2 つ以上の CUBE HA ペアを配置できません。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 は同じスイッチ上で終了する必要があります。
-
CUBE で直接、または両側のデータ HA で WAN を終了することはできません
-
アクティブ/スタンバイの両方が同じデータセンターにある必要があります
-
冗長性(RG Control/data、Gig3)に別の L3 インターフェイスを使用することが必須です。トラフィックに使用されるインターフェイスは、HA キープアライブおよびチェックポイントには使用できません。
-
フェールオーバー時に、以前アクティブな CUBE は設計によって再読み込みされ、シグナリングとメディアを保持します
両方の CUBE で冗長性を設定
仮想 IP を作成するために、HA ペアで使用することを意図した両方の CUBE で、レイヤー 2 ボックス間冗長性を構成する必要があります。
1 |
インターフェイスのステータスを追跡するために、グローバル レベルでインターフェイス トラッキングを設定します。
トラッキング 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 のローカル ゲートウェイ設定(登録ベースまたは証明書ベース)に進みます。「Webex Calling のために Cisco IOS XE でローカル ゲートウェイを構成する」を参照してください。 |