1:1 冗長性

機能の概要と変更履歴

要約データ

該当製品または機能エリア 5G-UPF
該当プラットフォーム

VPC-SI

SMI
機能のデフォルト設定 無効：設定が必要
このリリースでの関連する変更点 N/A
関連資料 該当なし

マニュアルの変更履歴

改訂の詳細

リリース

L2 ICSR のサポートが追加されました。

2023.01.0

次の機能のサポートが追加されました。

  • ユーザープレーン機能の会計上のゼロ損失

  • 早期 PDU リカバリ

  • リカバリ中のセッションの優先順位付け

  • UPF の状態を Pending-Active から Active に変更するための構成

2021.02.0

最初の導入。

2020.02.0

機能説明

5G デプロイメント向けの 1:1 UPF 冗長化機能は、障害が発生したユーザープレーン機能（UPF）を検出し、障害が発生した UPF の機能をシームレスに処理します。各アクティブ UPF には専用のスタンバイ UPF があります。1:1 UP 冗長化アーキテクチャは、UPF から UPF へのシャーシ間セッションリカバリ（ICSR）接続に基づいています。

機能の仕組み

次の図に示すように、5G-UPF デプロイメントは、UPF ノードの チェックポイント指定とスイッチオーバ―に ICSR フレームワーク インフラストラクチャを使用します。アクティブ UPF は、UPF 間でプロビジョニングされた Service Redundancy Protocol（SRP）リンク経由で専用のスタンバイ UPF と通信します。

図 1. SRP を使用した UPF の 1:1 冗長化

セッション管理機能（SMF）ノードには、UPF グループ構成で使用可能なスタンバイ UPF 情報がありません。このため、SMF は、UPF の冗長性構成と UPF 間のスイッチオーバーイベントを認識しません。

アクティブ UPF は、UPF で構成された N4 インターフェイスアドレス経由で SMF と通信します。スタンバイ UPF は、スイッチオーバーイベント中に Active に移行する際に、同じ Sx インターフェイスアドレスを引き継ぎます。これは、Sx/N4 インターフェイスが SRP によってアクティブ化され、既存の設定メソッドに準拠していることを意味します。したがって、UPF スイッチオーバーは SMF に対して透過的です。

図 2. UPF の 1:1 冗長化スイッチオーバー

1:1 の冗長性に完全に準拠するため、5G 環境の SRP ベースの ICSR に対する次の依存関係に対応します。

  • 構成の同期（または、スタンバイ UPF でのレプリカ構成）

  • Sx/N4 アソシエーション チェックポイント

  • Sx/N4 リンクモニタリング

上記の依存関係に加えて、UPF は UPF ノードに固有の Data Collection 手順および Checkpoint 手順を実装します。たとえば、IP プールチャンクのチェックポイント指定などです。UPF は、これらの手順を既存の ICSR チェックポイント指定フレームワークに統合します。

スタンバイ UPF の独立した構成

UPF が基本構成（サービス、コンテキスト、インターフェイスなど）で起動した後、残りの構成（たとえば、ACS やポリシー関連の構成）は、Ops-Center または冗長化および構成マネージャ（RCM） Pod 経由で行われます。この構成は、SMF ポリシーと UPF ポリシーの両方に共通です。SRP の冗長性を機能させるため、アクティブ UPF とスタンバイ UPF の間で SRP 接続が確立される SRP 関連の設定を除き、アクティブ UPF とスタンバイ UPF の設定は同じです。RCM は、アクティブ UPF とスタンバイ UPF を個別に設定します。

アクティブ UP とスタンバイ UP 間の BFD モニター

Bidirectional Forwarding Detection（BFD）は、迅速にエラー検証とスイッチオーナーを行うために、アクティブ UPF とスタンバイ UPF 間の SPR リンクを監視します。スタンバイ UPF がこのリンクで BFD 障害を検出すると、アクティブ UPF を引き継ぎます。

BFD リンクは、シングルホップまたはマルチホップが可能です。

アクティブ UP と スタンバイ UP 間に BFD モニターを構成するには、「アクティブ UPF と スタンバイ UPF 間に BFD モニタリングを構成する」を参照してください。

マルチホップ BFD モニタリングの設定例

プライマリ UPF：

config
  context srp
    bfd-protocol
      bfd multihop-peer 209.165.200.225 interval 50 min_rx 50 multiplier 20
    #exit
    service-redundancy-protocol
      monitor bfd context srp 209.165.200.225 chassis-to-chassis
      peer-ip-address 209.165.200.225
      bind address 209.165.201.1
    #exit
    interface srp
      ip address 209.165.201.1 255.255.255.224
    #exit
    ip route static multihop bfd bfd1 209.165.201.1 209.165.200.225
    ip route 209.165.201.1 255.255.255.224 209.165.201.1 srp
  #exit
end

バックアップ UPF：

config
  context srp
    bfd-protocol
      bfd multihop-peer 209.165.201.1 interval 50 min_rx 50 multiplier 20
    #exit
    service-redundancy-protocol
      monitor bfd context srp 209.165.201.1 chassis-to-chassis
      peer-ip-address 209.165.201.1
      bind address 209.165.201.1
    #exit
    interface srp
      ip address 209.165.201.1 255.255.255.224
    #exit
    ip route static multihop bfd bfd1 209.165.200.225 209.165.201.1 
    ip route 209.165.201.1 255.255.255.224 209.165.200.225 srp
  #exit
End

プライマリ UPF とバックアップ UPF 間のルータ：

config
  context one
    interface one
      ip address 209.165.201.1 255.255.255.224
    #exit
    interface two
      ip address 209.165.200.225 255.255.255.224
    #exit
  #exit
end

シングルホップ BFD モニタリングの構成例

プライマリ UPF：

config
  context srp
    bfd-protocol
    #exit
    service-redundancy-protocol
      monitor bfd context srp 209.165.201.1 chassis-to-chassis
      peer-ip-address 209.165.201.1
      bind address 209.165.201.4
    #exit
    interface srp
      ip address 209.165.201.1 255.255.255.224
      bfd interval 50 min_rx 50 multiplier 10
    #exit
    ip route static bfd srp 209.165.201.4
  #exit
end

バックアップ UPF：

config
  context srp
    bfd-protocol
    #exit
    service-redundancy-protocol
      monitor bfd context srp 209.165.200.225 chassis-to-chassis
      peer-ip-address 209.165.201.4
      bind address 209.165.201.7
    #exit
    interface srp
      ip address 209.165.201.4 255.255.255.224
      bfd interval 50 min_rx 50 multiplier 10
    #exit
    ip route static bfd srp 209.165.201.7
  #exit
end

VPP モニター

SRP VPP モニターが構成されている場合、UPF シャーシは SRP アクティブであり、VPP サブシステムに障害が発生すると、SRP はスタンバイ UPF へのスイッチオーバーを開始します。現在、VPP ヘルスモニタリングは、NPUMgr タスクと VPP プロセス間のハートビートメカニズムに限定されています。

VPP モニターを構成するには、「アクティブ UPF および スタンバイ UPF に VPP モニターを構成する」を参照してください。

Sx/N4 アソシエーション チェックポイント

アクティブ UPF が、SMF に対して Sx/N4 アソシエーションを開始すると、スタンバイ UPF は、このデータをチェックポイントします。これにより、UPF スイッチオーバー後もアソシエーション情報が保持されます。

Sx/N4 Heartbeat メッセージが送信され、アクティブ UPF 、連続して UPF のスイッチオーバーが発生した後も応答します。

Sx/N4 モニター

UPF と SMF 間の Sx/N4 インターフェイスを監視することは重要です。SRP モニタリングは Sx/N4 インターフェイスで有効になり、既存の Sx/N4 ハートビートメカニズムを利用してモニター障害を検出します。アクティブ UPF の Sx/N4 モジュールは、障害を検出すると、SRP VPNMgr に UPFスイッチオーバーイベントをトリガーし、スタンバイ UPF が引き継ぐようにします。


（注）  

Sx/N4 モニタリングは UPF でのみ使用できます。

SMF Sx/N4 ハートビートタイムアウトが、UPF Sx/N4 ハートビートタイムアウトと UPF ICSR スイッチオーバ―タイムとり高いことが重要です。これは、UPF Sx/N4 監視エラーが原因で、SMF が、UPF スイッチオーバ―中に Sx/N4 パスを検出しないためです。

スタンバイ UPF 自体に SMF との独立した接続はありません。アクティブ UPF Sx/N4 コンテキストが スタンバイ UPF に複製されることで、SRP スイッチオーバー時のテイクオーバー準備が整います。これは、Sx/N4 監視エラーが原因でアクティブ UPF がスタンバイに切り替わった場合、新しいスタンバイは UPF から SMF へのリンクが機能しているかどうかを把握できないことを意味します。新しいアクティブ UP での Sx モニター障害が原因で、新しい スタンバイ UP が再びアクティブ状態にスイッチバックされないようにするには、新たな monitor sx CLI コマンドで disallow-switchover-on-peer-monitor-fail キーワードを使用します。

Sx/N4 監視エラーが原因でシャーシがスタンバイになった後、Sx/N4 チェックポイントが新しいアクティブ UPF から受信されても、Sx/N4 監視エラーはリセットされません。これは、前回のスイッチオーバーを引き起こしたそもそもの原因が Sx/N4 監視エラーであった場合に、Sx/N4 監視エラーによって、再び新しいアクティブの計画外のスイッチバックが起こるのを防ぐためです。これにより、SMF の停止時に、連続したスイッチオーバーが起こるのを防ぎます。Sx/N4 監視エラー状態は、ネットワーク接続が正常であるという確信が得られたら、オペレータが手動でリセットする必要があります。リセットするには、スタンバイシャーシで新しい srp reset-sx-fail CLI コマンド（「Sx モニター障害のリセット」を参照）を使用します。

Sx/N4 モニターを構成するには、「アクティブ UPF およびスタンバイ UPF での Sx/N4 モニタリングの構成」を参照してください。

Sx/N4 モニター：Pending-Active

UPF シャーシは、次のいずれかの理由で Pending-Active 状態になることがあります。

  • SMF アップグレード中に Sx/N4 ハートビートがタイムアウトすると、Sx/N4 接続は終了します。したがって、Sx/N4 監視エラーにより、UPF で ICSR スイッチオーバーがトリガーされます。このスイッチオーバーにより、古いスタンバイ UPF が Pending-Active 状態に移行します。Pending-Active 状態の UPF は、SMF から Sx/N4 ハートビートもサブスクライバ通信も受信しません。その結果、UPF は無期限に Pending-Active 状態のままになり、手動での介入なしでは使用できません。

  • UPF をアップグレードするための適切な手順に従わない場合、UPF の 1 つが Pending-Active 状態になる可能性があります。また、UPF のアップグレード中に SMF が停止した場合、または UPF のスイッチオーバーに SMF ハートビートタイムアウトよりも長い時間がかかる場合、UPF の 1 つが無期限に Pending-Active 状態のままになります。

  • ネットワークの問題が原因で SMF と UPF の間で Sx/N4 セッションがタイムアウトし、UPF ICSR スイッチオーバーがほぼ同時に発生した場合（二重障害シナリオ）、Pending-Active 状態の UPF はアクティブ状態に移行しません。

UPF シャーシが Pending-Active 状態になるたびに、UPF を Pending-Active 状態から Active 状態に強制的に移行するコールバックでタイマーを開始します。移行を強制する前に、SRP リンクが稼働していて、SRP ピアがスタンバイ状態であるかを確認します。そうでない場合は、タイマーを再起動します。タイマーの期間は、force-pactv-to-actv-timeout value_seconds CLI コマンドを使用すると構成できます（構成の詳細については、「Pending-Active 状態から Active 状態に UPF 状態を変更する」項を参照してください。）。この CLI コマンドが構成されていない場合、UPF は無期限に Pending-Active 状態のままになります。

BGP モニター

UPF（Gi 側と Gn 側の両方）からネクストホップルータの BGP ピアモニターとピアグループモニターを構成します。これは既存の ICSR 設定です。BGP は、迅速な BGP ピア障害の検出のため、BFD によるサポートと併せて実行できます。

図 3. BGP ピアグループと回送

BGP モニタリングを設定し、BPG モニタリング障害にフラグを立てるには、「各 UP とネクストホップルータ間の BGP 状態モニタリングを構成する」を参照してください。

UPF セッションチェックポイント

アクティブシャーシは、次のシナリオで、UPF データのコレクションをチェックポイントとしてピアスタンバイシャーシに送信します。

  • 新しいコールのセットアップ時

  • コールの状態が変化するたびに

  • アカウンティングバケット用に定期的に

これらのチェックポイントを受信すると、スタンバイシャーシはデータに基づいて動作し、コール、ノードまたはインスタンスレベルで必要な情報を更新します。

VPN IP プールのチェックポイント

Sx/N4 アソシエーション中に、各 UPF に割り当てられた IP プールは、SMF によってそれぞれの UPF に送信されます。VPNMgr はこのメッセージを UPF で受信して、SRP が構成された場合、スタンバイ UPF で同じ情報をチェックポイントします。

IP プール情報は、SRP VPNMgrR の再起動中、および SRP リンクのダウンおよびアップシナリオ中にも送信されます。

スイッチオーバーの前に、スタンバイに IP プール情報が存在することを検証することが重要です。IP プール情報が存在しない場合、ルートアドバタイズメントができないため、通信は UPF に到達しません。

外部監査と PFD 設定監査のインタラクション

外部監査管理は、アクティブ UPF で行われます。セッションマネージャが、構成監査の開始通知と完了通知を受け取ります。構成監査が進行していない場合、セッションマネージャは、外部監査を開始しません。外部監査の実行中に構成監査の開始通知が到着した場合、セッションマネージャはフラグを設定し、外部監査の完了後に外部監査が再開されるようにします。構成監査がすでに実行中の場合、外部監査を実行しても目的を達成できないため、外部監査を再開する必要があります。

ユーザープレーン機能における会計上のゼロ損失

ユーザープレーン機能（UPF）に会計上のゼロ損失機能が実装されました。これにより会計データまたは請求ロスを、Active UPF から Standby UPF へのデフォルトのチェックポイント時間である 18 秒、または構成された課金チェックポイント時間から削減します。

これは、Gz、Gy、VoGx、および RADIUS URR をサポートするために UPF で変更されました。会計上のゼロ損失/URR データカウンタ損失では、計画的スイッチオーバーのみがサポートされます。この機能は、現行の ICSR フレームワークや、チェックポイント指定およびリカバリ方法には影響しません。

Sx/N4 使用状況レポートは、シャーシが Pending Active 状態からアクティブになるまでブロックされます。

UPF セッションリカバリに向けた早期 PDU リカバリ

早期 PDU リカバリ機能は、これまでのセッションリカバリ機能が抱えていた、リカバリ対象として選択された CRR に優先順位が行われないという制限を克服します。これまでは、すべての CRR が AAAMgr から取得され、コールが順番に回復されていました。すべての CRR を取得するのにかかる時間が、セッションリカバリ中に認識される遅延の主な要因でした。障害が発生した際に、セッションマネージャに多数のセッションがあると、遅延が非常に長くなることがありました。また、コールのリカバリに特定の順序がないため、アクティブセッションよりも前にアイドルセッションが回復されることもありました。


（注）  

早期 PDU リカバリ機能は、最大 5% のセッションを回復できます。

リカバリ中のセッションの優先順位付け

この機能がないと場合、セッションリカバリ機能はリカバリ対象として選択されたセッションに優先順位を付けず、コールリカバリリスト内のすべてのコールをループ処理し、セッションリカバリがトリガーされると順番に回復していました。

リカバリにおけるセッション優先の一環として、優先コールのみを対象に別途スキップリストを保持します。該当するレコードがループ処理によらず、AAAMgr からすぐに送信できるようにするためです。その結果、優先コールの迅速なリカバリとデータ停止時間の短縮につながります。

ユーザープレーンには、優先セッションと通常セッションの 2 種類のセッションがあります。セッションが優先セッションかどうかは、SMF から受信したメッセージの優先順位フラグに基づいて判別され、優先セッションがまず回復され、その後に通常のコールが続きます。これらの優先セッションは、早期 PDU 処理でも優先されます。通常コールの早期 PDF のリカバリは、すべての優先セッションがリカバリされてから、開始されます。

クリティカルフラッシュ（GR）の場合、まず優先セッションのチェックポイントが送信され、その後に通常のコールが送信されます。スイッチオーバー中は、すべてのコール（通常コールと優先コールの両方）のデータが許可されます。


（注）  

SMF がすべてのコールに優先順位フラグを設定します。UPF は、SMF から受信した優先コールの詳細を、セッション優先機能に使用します。

1:1 UPF 冗長性を構成する

次の項では、この機能のサポートで利用可能な CLI コマンドの情報について説明します。

アクティブ UPF とスタンバイ UPF 間の BFD モニタリングを構成する

アクティブ UPF とスタンバイ UPF で Bidirectional Forwarding Detection（BFD）の 監視を構成するには、次の構成を使用します。このコマンドは、SRP 構成モードで構成します。

configure 
   context context_name 
      service-redundancy-protocol 
         [ no ] monitor bfd context context_name { ipv4_address | ipv6_address } { chassis-to-chassis | chassis-to-router } 
         end

注：

  • no ：アクティブ UPF とスタンバイ UPF で BFD 監視を無効にします。

  • context context_name ：使用するコンテキストを指定します。BFD ピアが設定されているコンテキスト（SRP コンテキスト）を参照します。

    context_name は、1 ～ 79 文字の英数字で表される既存のコンテキストである必要があります。

  • ipv4 _address | ipv6_address ：モニターする BFD ネイバーの IP アドレスを定義します。これは、IPv4 ドット付き 10 進表記または IPv6 コロン区切り 16 進表記を使用して入力します。

    設定された BFD（ICSR）ピアの IP アドレスを参照します。

  • chassis-to-chassis | chassis-to-router ：

    chassis-to-chassis ：非 SRP リンク上のプライマリシャーシとバックアップシャーシの間で BFD を実行できるようにします。

    chassis-to-router ：BFD はシャーシとルータの間で動作します。


    注意    
    アクティブ UPF とスタンバイ UPF 間の SRP リンクで BFD 監視に対して chassis-to-router キーワード 使用しないでください。

  • このコマンドはデフォルトでは無効になっています。

各 UPF とネクストホップ ルータ間の BGP 状態モニタリングを構成する

次のコマンドを使用して、各 UPF とネクストホップルータ間にボーダー ゲートウェイ プロトコル（BGP）を構成します。このコマンドは、SRP 構成モードで構成されます。

configure 
   context context_name 
      service-redundancy-protocol 
         [ no ] monitor bgp context bgp-session-context-name [ nexthop-router-ipv4-address | nexthop-router-ipv6-address ] { vrf bgp-session-vrf-name } { group group-number  } 
         end

注：

  • no ：UPF で BGP 状態モニタリングを無効にします。

  • bgp context bgp-session-context-name ：BGP ピアが構成されているコンテキストを指定します。bgp-session-context-name は、コンテキスト文字列を指定します。

  • nexthop-router-ipv4-address | nexthop-router-ipv6-address ：監視する構成済みの BGP ピア IPv4 または IPv6 アドレスを指定します。

  • vrf bgp-session-vrf-name ：BGP VPN Routing and Forwarding (VRF) インスタンスを指定します。bgp-session-vrf-name は、VRF 名を指定します。

  • group group-number ：BGP ピアを含める BGP ピアグループを指定します。group-number は、グループ番号を指定します。

    このキーワードを実装すると、動作は次のようになります。

    • そのグループの BGP ピアが稼働すると、BGP ピアグループも稼働します。

      BGP モニターのグループ構成を省略すると、そのモニターはグループ 0 に含まれます。

      BGP グループ 0 は、暗黙的なグループからのコンテキストでモニターされました。各コンテキストは、個別の BGP グループ 0 の暗黙的モニターグループを形成します。

      いずれかの BGP ピアグループが停止している場合、BGP モニターは停止します。

  • このコマンドは、デフォルトでディセーブルになっています。

BGP モニタリングのエラーにフラグを立てるための代替アルゴリズム

このリリースでは、代替（新規）アルゴリズムが導入され、BGP 監視エラーにフラグを立てられるようになりました。

次のコマンドを使用して、単一 BGP ピア（ユーザープレーン機能）エラーが発生した際に BGP 監視エラーにフラグを立てます。このコマンドは、SRP 構成モードで設定します。

configure 
   context context_name 
      service-redundancy-protocol 
         [ no ] monitor bgp exclusive-failover  
         end

注：

  • no ：単一の BGP ピア障害時の BGP モニター障害のフラグ設定を無効にします。

  • 新しい exclusive-failover キーワードを実装すると、動作は次のようになります。

    • BGP ピアグループ内のいずれかの BGP ピアが稼働している場合、BGP ピアグループは稼働します。

    • BGP ピアをグループ 0 に含めることは、非グループ化（グループを省略する）と同じです。

    • いずれかの BGP ピアグループまたは非グループ BGP ピアがダウンすると、BGP モニターはダウンします。

  • このコマンドはデフォルトでは無効になっています。

アクティブ UPF およびスタンバイ UPF で Sx/N4 モニタリングを構成する

アクティブ UPF およびスタンバイ UPF で Sx/N4 モニタリングを構成するには、次の構成を使用します。このコマンドは、SRP 構成モードで設定します。

configure 
   context context_name 
      service-redundancy-protocol 
         [ no ] monitor sx [ { context context_name | bind-address {ipv4_address |ipv6_address } | { peer-address { ipv4_address | ipv6_address } } ] 
         end

注：

  • no ：アクティブおよび スタンバイ UPF で Sx/N4 モニタリングを無効にします。

  • contextcontext_name ：Sx/N4 サービスのコンテキストを指定します。

    context_name は、1 ～ 79 文字の英数字で表される既存のコンテキストである必要があります。

  • bind-address { ipv4 _address | ipv6_address } ：Sx/N4 サービスのサービス IP アドレスを定義します。IPv4 ドット付き 10 進表記または IPv6 コロン区切り 16 進表記を使用して入力します。


    （注）  
    bind-address および peer-address の IP アドレスファミリは同じである必要があります。

  • peer-address { ipv4 _address | ipv6_address } ：Sx/N4 ピアの IP アドレスを定義します。IPv4 ドット付き 10 進表記または IPv6 コロン区切り 16 進表記を使用して入力します。

  • disallow-switchover-on-peer-monitor-fail :

    UPF から SMF へのリンクの動作状態が不明な場合に、UPF が [アクティブ（Active）] 状態にスイッチバックされるのを防止します。

  • 複数の Sx/N4 接続をモニタリングする場合には、この CLI コマンドを複数回実装できます。

  • モニター対象の Sx/N4 接続のいずれかが停止すると、Sx/N4 のモニター状態も停止します。

  • このコマンドは、デフォルトでディセーブルになっています。

  • 最大 18 のピアノードを構成できます。

アクティブ UPF およびスタンバイ UPF で VPP モニターを構成する

次の構成を使用して、Vector Packet Processing（VPP）を構成し、VPP が停止した場合に、アクティブ UPF で UPF スイッチオーバーがトリガーされるようにします。このコマンドは、SRP 構成モードで設定します。

configure 
   context context_name 
      service-redundancy-protocol 
         monitor system vpp delay-period seconds 
         end

注：

  • 以前に構成されている場合は、no monitor system vpp CLI コマンドを使用して、アクティブおよびスタンバイ UPF で VPP モニタリングを無効にします。

  • vpp delay-period seconds ：VPP 障害後のスイッチオーバーの遅延時間を秒単位で指定します。seconds は、0 ～ 300 の値を指定する必要があります。

    遅延時間が 0 より大きい値の場合、VPP に障害が発生すると、指定された遅延時間の後にスイッチオーバーが開始されます。遅延時間内の最後の VPP ステータス通知が、スイッチオーバーアクションの最終トリガーです。デフォルト値は 0 秒で、すぐにスイッチオーバーが開始されます。

    遅延は、VPP が一時的にダウンし、回復が進行中のシナリオに対処するために必要です。これは、スイッチオーバーが不要な場合があることを意味します。

  • このコマンドはデフォルトでは無効になっています。

ユーザープレーンのスイッチバックを防止する

次の構成を使用して、新しいアクティブ UPF で Sx/N4 の監視に失敗したことによって、新しいスタンバイ UPF が再びアクティブ状態にスイッチバックするのを防ぎます。 

configure 
   context context_name 
      service-redundancy-protocol 
         monitor sx disallow-switchover-on-peer-monitor-fail timeout seconds  
         end

次のいずれかの CLI を使用して、新しいスタンバイ UPF からアクティブ状態へのスイッチバックを許可します。


no monitor sx disallow-switchover-on-peer-monitor-fail

または


monitor sx disallow-switchover-on-peer-monitor-fail timeout 0

注：

  • no ：スイッチオーバー防止を無効にします。

  • disallow-switchover-on-peer-monitor-fail [ timeout seconds ] ：UPF から SMF へのリンクの動作状態が不明な場合に、UPF がアクティブ状態にスイッチバックされるのを防止します。

    timeout seconds： スタンバイピアで Sx/N4 エラー状態がリセットされない場合でも、このタイムアウトの経過後にスイッチバックを許可します。有効な値の範囲は、0 ～ 2073600（24 日）です。


    （注）  
    タイムアウトを 0 秒に指定すると、計画外のスイッチオーバーが可能になります。

    timeout キーワードが指定されていない場合、アクティブシャーシはスタンバイピアで Sx/N4 エラー状態がリセットされるまで無期限に待機します。

  • デフォルト設定では、あらゆる条件において、Sx/N4 モニターエラーによる計画外のスイッチオーバーが許可されます。


    （注）  
    手動による計画的スイッチオーバーは、この CLI が設定されているかどうかに関係なく許可されます。

デュアル アクティブ エラー シナリオの防止

CP で次の CLI 設定を使用して、UPF 1:1 冗長性のデュアル アクティブ エラー シナリオを回避します。 

configure 
     user-plane-group  group_name 
         sx-reassociation disabled  
         end

注：

  • sx-reassociation disabled ：CP との関連付けがすでに存在する場合、UP Sx の再関連付けを無効にします。

Sx/N4 モニター障害をリセットする

次の構成は、Service Redundancy Protocol (SRP) Sx/N4 モニター障害情報をリセットする際に、スタンバイシャーシのみで使用します。このコマンドは、EXEC モードで設定します。 

srp reset-sx-fail

UPF 状態を保留アクティブからアクティブに変更する

次の構成を使用して、UPF シャーシの状態を Pending-Active から Active に変更します。

configure 
   context context_name 
      service-redundancy-protocol 
         force-pactv-to-actv-timeout value_seconds

注：

  • value_seconds ：タイムアウト値を秒単位で指定します。1 ～ 300 の範囲で指定する必要があります。

  • show config context context-name CLI コマンドを使用知って、構成を確認します。

モニタリングおよびトラブルシューティング

この項では、機能のモニタリングとトラブルシューティングのサポートに使用できる CLI コマンドに関する情報を提供します。

show コマンドや出力

この項では、この機能のサポートにおける show コマンドまたはその出力について説明します。

show srp monitor bfd

この CLI コマンドの出力には、5G UPF 1:1 UP 冗長性機能に関する次のフィールドが含まれます。

  • 次のように入力します。

    • (A) - Auth. probe

    • (B) - BGP

    • (D) - Diameter

    • (F) - BFD

    • (E) - EGQC

    • (C) - Card

    • (V) - VPP

  • 状態：

    • (I) - Initializing

    • (U) - Up

    • (D) - Down

  • GroupId

  • IP Addr

  • Port

  • Context (VRF Name)

  • Last Update

show srp monitor bgp

この CLI コマンドの出力には、5G UPF 1:1 UPF 冗長性機能に関する次のフィールドが含まれます。

  • 次のように入力します。

    • (A) - Auth. probe

    • (B) - BGP

    • (D) - Diameter

    • (F) - BFD

    • (E) - EGQC

    • (C) - Card

    • (V) - VPP

    • (S) - Sx

  • 状態：

    • (I) - Initializing

    • (U) - Up

    • (D) - Down

  • GroupId

  • IP Addr

  • Port

  • Context (VRF Name)

  • Last Update

show srp monitor sx

この CLI コマンドの出力には、Sx/N4 監視状態をサポートする次のフィールドが含まれます。

  • 次のように入力します。

    • (A) - Auth. probe

    • (B) - BGP

    • (D) - Diameter

    • (F) - BFD

    • (E) - EGQC

    • (C) - Card

    • (V) – VPP

    • (S) - SX

  • 状態：

    • (I) - Initializing

    • (U) - Up

    • (D) - Down

  • GroupId

  • IP Addr

  • Port

  • Context (VRF Name)

  • Last Update

show srp monitor vpp

この CLI コマンドの出力には、5G UPF 1:1 UPF 冗長性機能に関する次のフィールドが含まれます。

  • 次のように入力します。

    • (A) - Auth. probe

    • (B) - BGP

    • (D) - Diameter

    • (F) - BFD

    • (E) - EGQC

    • (C) - Card

    • (V) - VPP

  • 状態：

    • (I) - Initializing

    • (U) - Up

    • (D) - Down

  • GroupId

  • IP Addr

  • Port

  • Context (VRF Name)

  • Last Update

show srp statistics

この CLI コマンドの出力には、Sx/N4 モニター - Pending-Active 機能の次のフィールドが含まれます。

  • Pending-active タイマーの開始

  • Pending-active タイマーの停止

  • Pending-active から Active forced

  • Pending-active から Active force-failed

  • Pending-active から Active force-skipped - peer-not-sby

  • Pending-active から Active force-skipped - not-PActv

L2 ICSR のサポート

機能説明

UPF は、アクティブ UPF とスタンバイ UPF 間のパケット転送を明確にするために、2 サーバーアーキテクチャでレイヤ 2 ベース（L2）ICSR をサポートします。UPF は、Gratuitous Address Resolution Protocol（GARP）Unsolicited Neighbor Advertisement メッセージを使用して L2 ICSR を実現します。

SRP ピア間の L2 ICSR は、SRP コンテキストで設定できます。UPF は、物理インターフェイスと同じサブネットの下にループバック インターフェイスも設定します。UPF は、アクティブからアクティブへのシナリオを回避するために SRP BFD モニタリングをサポートしています。

SRP ループバック インターフェイス

SRP ループバック インターフェイスは、サービス IP（N3）のループバック インターフェイスまたは IP プール（N6）のネクストホップ IP です。これらのループバック インターフェイスの IP アドレスは、コンテキストのイーサネット インターフェイスと同じサブネットにある必要があります。SRP ループバック インターフェイスは、アクティブおよびスタンバイの両方の UPF で同じ IP アドレスを持ちます。

  • UPF が Standby の場合、SRP ループバック インターフェイスは ARP 応答または GARP パケットを送信しません。IPv6 の場合、UPF は Solicited または Unsolicited Neighbor Advertisement メッセージで応答しません。

  • UPF がスタンバイの場合、SRP ループバック インターフェイスは、Boxer 内で IP アドレスが接続された状態で有効になります。これにより、これらのインターフェイスにバインドされた UPF サービスは、実行状態のままになります。

  • UPF が別の状態からアクティブ状態に移行する際、SRP ループバック インターフェイスは、GARP パケットを送信します。IPv6 の場合、UPF は Unsolicited Neighbor Advertisement メッセージを送信します。

次の図は、非結合インターフェイスの 3RU 配線図を示しています。

図 4. 非結合インターフェイスの 3RU 配線

機能の仕組み

UPF は、同じサブネット内の N3 ルータ上の gNB または N6ルータ上のサーバーに直接接続します。UPF ICSR は、gNB/N3 およびサーバー/N6 には表示されません。

L2 スイッチは、BFD をサポートします。すべての N3 および N6 サブネットで、スイッチには IP アドレスが必要です。

UPF は、L2 ICSR ソリューションを機能させるために、Chassis-Chassis (C-R) BFD および Chassis-Router (C-R) BFD を必要とします。Active-Active 状態を回避するには、C-C および C-R 間で BFD を実行します。BFD には、C-R BFD より高いタイムアウト値を設定する必要があります。

2 リーフネットワーク設計および非結合 UPF インターフェイスの場合、各 UPF は個別のリーフに接続します。L2 スイッチの IP アドレスは、リーフの一部です。

次の図は、非結合インターフェイスの L2 スイッチ配線の概要を示しています。

図 5. 非結合インターフェイスの L2 スイッチ配線

ステートマシン

この表には、UPF の状態に関する情報が表示されています。

表 1. ステートマシン

番号

前の状態

内部障害

C-R BFD

C-C BFD

SRP リンク状態

次の状態

BFD のプルダウン

1

X

はい

X

X

X

スタンバイ

はい

2

X

X

Any-Down

X

X

スタンバイ

はい

3

X

いいえ

All-Up

Any-Down

X

アクティブ

いいえ

4

X

いいえ

All-Up

All-Up

ダウン

No-Change

いいえ

5

X

いいえ

All-Up

All-Up

アップ

SRP-Protocol

-Decided

いいえ

注：

  • C-R BFD が「Not-All-Up」から「All-Up」に移行する場合、SRP 状態処理に遅延が発生し、すべての C-C BFD が安定した状態になります。

  • デュアルアクティブシナリオを回避するには、上記の表の 3 行目の状態が両方の UPF で発生しないようにします。これは、正しく動作し構成されたシステムでは発生しません。

SRP コンテキストで L2 ICSR を構成する

SRP ピア間で L2 ICSR を有効または無効にするには、次の構成を使用します。 

configure 
   context context_name 
      service-redundancy-protocol 
         l2-icsr [ disable | enable ]   
         end

注：

  • disable ：SRP ピア間の L2 ICSR を無効にします。これがデフォルト設定です。

  • enable ：SRP ピア間の L2 ICSR を有効にします。

プライマリシャーシとバックアップシャーシからの C-C および C-R BFD を構成する

次の手順を実行して、プライマリシャーシとバックアップシャーシからの C-C および C-R BFD を構します。C-C BFD は、マルチホップを構成して、C-R BFD とは異なるタイムアウト値を指定します。

context SAEGW
bfd-protocol
  bfd multihop-peer 209.165.200.227 interval 50 min_rx 50 multiplier 6
#exit
interface S5_SGW_PGW
  ip address 209.165.200.226 255.255.255.0
  ipv6 address 2001:DB8:A:B::1/64 secondary
  bfd interval 50 min_rx 50 multiplier 3
#exit
ip route static bfd S5_SGW_PGW 209.165.200.225
ip route static multihop bfd bfdcc 209.165.200.226 209.165.200.227
ip igmp profile default
#exit

L2 ICSR 構成を検証する

設定を確認するには、次のコマンドを使用します。

  • show config context srp

  • show srp monitor all

  • show srp info

次に、show config context srp コマンドの出力例を示します。 

[local]upf# show config context srp
    context srp
    bfd-protocol
    #exit
    service-redundancy-protocol
      checkpoint session duration non-ims-session 0 
      checkpoint session duration ims-session 0
      force-pactv-to-actv-timeout 1
      l2-icsr enable
      [output truncated]

次に、show srp monitor all コマンドの出力例を示します。 

[local]upf# show srp monitor all
+----- Type: (A) - Auth. probe (B) - BGP (D) - Diameter (F) - BFD (E) - EGQC (C) - Card
| (V) - VPP (S) - Sx
|
|+---- State: (I) - Initializing (U) - Up (D) - Down
||
||+--- GroupId
|||
vvv IP Addr Port Context(VRF Name) Last Update
-------------------------------------------------------------------------------
FU0 209.165.200.225 3785 SAEGW Thu Jan 05 01:13:08 2023
FU0 209.165.200.227 3785 SAEGW Thu Jan 05 01:13:08 2023
FU0 209.165.200.230 3785 ISP Thu Jan 05 01:13:08 2023
FU0 209.165.200.231 3785 ISP Thu Jan 05 01:13:08 2023
------------------------------------------------------------------------------
[local]upf#
[local]upf# context SAEGW
[SAEGW]upf# show bfd neighbors >>>>>
All the time intervals are in ms
OurAddr NeighAddr LD/RD DtctTime State Intf
209.165.200.226 209.165.200.225 1/1090519046 150 Up S5_SGW_PGW
209.165.200.226 209.165.200.227 2/1 300 Up
Total Sessions 2
Sessions in UP state 2

次に、show srp info コマンドの出力例を示します。 

sample o/p:
[local]l10-ru34-up1# show srp info
Service Redundancy Protocol:
-------------------------------------------------------------------------------
Context: srp
Local Address: 209.165.201.234
Chassis State: Active
Chassis Mode: Primary
Chassis Priority: 47299
Local Tiebreaker: 00-50-56-AE-EE-8D
Route-Modifier: 33

Peer Remote Address: 209.165.201.235
Peer State: Standby
Peer Mode: Backup
Peer Priority: 1673325643
Peer Tiebreaker: 00-00-00-00-00-00
Peer Route-Modifier: 0
Last Hello Message received: Tue Jan 10 04:40:43 2023 (2 seconds ago)
Peer Configuration Validation: Complete
Last Peer Configuration Error: None
Last Peer Configuration Event: Tue Jan 10 04:32:31 2023 (494 seconds ago)
Last Validate Switchover Status: None
Connection State: Connected
Next Peer Audit Scheduled:
Periodicity Audit Scheduled : -
Daily-Start-time Audit Scheduled : -
Cron-Job Audit Scheduled : -
Peer Audit State: Unknown
Last Peer Audit Type: Unknown
Last Peer Audit Successful: -
DSCP Configuration:
Control flow : be
Session flow : be
Feature Configured-status Operational-status
allow-volte-data-traffic: Disabled Enabled
allow-all-data-traffic: Disabled Enabled

[local]l10-ru34-up1#

OAM のサポート

ここでは、この機能の操作、管理、およびメンテナンスに関して説明します。

show コマンドのサポート

show ip interface または show ipv6 interface を使用して、GARP 統計を表示します。

次に、このコマンドの出力例を示します。
[EPC2]l10-ru32-up1# show ip interface 
Interface Name                   : S5_SGW_PGW
Interface Type                   : Broadcast
Description                      :
VRF                              : None
IP State                         : UP (Bound to 1/10 vlan id 2141, 802.1P prior 0, ifIndex 17432595)
IP Address                       : 209.165.200.226
Subnet Mask                      : 255.255.255.0
Bcast Address                    : 209.165.200.255
MTU                              : 1500
Resoln Type                      : ARP
ARP timeout                      : 1200 secs
L3 monitor LC-port switchover    : Disabled
Number of Secondary Addresses    : 1
    IPv6 Address: 2001:DB8:A:B::1/64
GARP sent through this interface : 45
GARP sent for this interface     : 0
GARP sent for/through this interface successfully: 45
Last GARP sent for/through this interface: Tue Dec 06 18:40:26 2022