SMF は、UDP プロキシの高可用性（HA）をサポートしています。UDP プロキシの HA モデルは、キープアライブ仮想 IP の概念に基づいています。

UDP プロキシ冗長性に関する情報について、「ポッドとサービスの参考資料」章の「UDP プロキシの高可用性」セクションを参照してください。

SMF は、各 UPF の IPAM 冗長性とロード バランシングをサポートしています。ノード マネージャ マイクロサービスで実行されている IPAM には、各 UPF に関連付けられた 2 つの IPAM インスタンスがあります。1 つの IPAM インスタンスが非アクティブになると、もう 1 つの IPAM インスタンスが UPF のアドレス割り当て要求を管理します。

ノード マネージャ冗長性に関する情報については、「IP アドレス管理」章の「UPF ごとの IPAM 冗長性サポート」セクションを参照してください。

ラック内の高可用性は、サーバ レベルの冗長性を処理する配置です。このソリューションでは、1 つのサーバで障害が発生した場合、設計に応じたいくつかのポッドが利用可能な別のサーバに分散される場合があります。一方、他のポッドは、サーバが復帰するまで保留状態のままです。

このシナリオでは、外部トラフィックを処理する重要なポッドが、別のサーバのアクティブ/スタンバイ ペアで実行されます。ルーティング レイヤでの冗長性サポートは、リーフおよびスパイン レイヤによって提供されます。

ここでは、SMF ポッドとそのマイクロサービスの展開について説明します。

次の図は、SMF における 6 つの VM の導入モデルを示しています。

このモデルでは、ポッドは VM ペアに展開されます。各プロトコル ポッド（rest-ep、protocol-ep、gtp-ep など）に対して 2 つのレプリカを使用できます。各プロトコル VM に 1 つのインスタンスが展開されます。

同様に、サービス ポッドとセッション ポッドは、サービス VM とセッション VM の両方に均等に分散されます。このような分散は、VM にラベルを付け、ポッドのスケジューリング中に K8 アフィニティ ルールとアンチアフィニティルールを実装することによって制御されます。

このモデルにより、VM の再起動シナリオ中に、各 ポッドタイプの少なくとも 50% のレプリカがユーザー シグナリングの処理に使用可能になります。

ポッドのグレースフル再起動により、ポッドは進行中の処理を 30 秒以内に完了できます。ポッドの突然の再起動は、PDU セッションに影響を与えずに、進行中のトランザクションに影響を与えます。

次に、VM のラベル付けとレプリカの構成例を示します。

k8 label protocol-layer key smi.cisco.com/node-type value smf-proto
exit
k8 label service-layer key vm-type value smf-svc
exit
k8 label cdl-layer key smi.cisco.com/node-type value smf-cdl
exit
k8 label oam-layer key smi.cisco.com/node-type value oam
exit

endpoint pfcp
 replicas 1
 nodes    2
exit
endpoint service
 replicas 1
 nodes    2
exit
endpoint protocol
 replicas 1
 nodes    2
 vip-ip 209.165.201.28
exit
endpoint sbi
 replicas 1
 nodes    2

構成を確認するには、次の show コマンドを使用します。

show running-config instance instance-id instance_id endpoint 

以下は、この show コマンドの出力例です。

[unknown] smf# show running-config instance instance-id 1 endpoint 
instance instance-id 1
 endpoint nodemgr
  replicas 1
  nodes    2
 exit
 endpoint gtp
  replicas 1
  vip-ip 209.165.202.149
 exit
 endpoint pfcp
  replicas                2
  enable-cpu-optimization true
  interface n4
   heartbeat
    interval               0
    retransmission-timeout 3
    max-retransmissions    5
   exit
  exit
 exit
 endpoint service
  replicas 2
 exit
 endpoint protocol
  replicas 1
  vip-ip 209.165.202.149
 exit
exit 

このコマンド出力には、エンドポイント名、ポッド レプリカ、ノードなど、複数のエンドポイントに関連する構成が表示されます。

SMF は、トラフィックがないプロトコル ノード上のアクティブな L2 VIP を識別します。アクティブな L2 VIP の場合、ネットワーク接続の問題など、さまざまな理由によりトラフィックが存在しない場合があります。

アクティブな L2 VIP でトラフィックがないシナリオを検出すると、SMF はポッドの再起動を試みるか、CLI 構成アクションに基づいて GR をトリガーします。トラフィックの復元を容易にし、セッションの損失を最小限に抑えます。

この機能は、CLI を使用して有効または無効にすることができます。

• IPC L2 VIP でのトラフィックのモニタリングは定期的に行われ、構成可能な no-traffic-duration 時間と一致しています。

• 構成された時間内にアクティブ IPC L2 VIP にトラフィックがない場合、構成されたアクションに応じて、GR トリガーが発生し、他のラックがトラフィックを処理できるようにするか、ポッドが再起動され、VIP が他のポッドに切り替わります。トラフィックを復元します。

• ポッド再起動アクションが設定され、VIP スイッチオーバー後でもトラフィックが復元されない場合、IPC 接続モニタリング機能は、影響を最小限に抑えるように構成されていれば、GR シナリオをトリガーします。

• 次のチェックは定期的にモニターされます。チェックが条件を満たしている場合、トラフィックはモニターされます。

  • CLI 構成 no-traffic-duration は 10 秒より長くする必要があります。

  • CLI 構成 session-threshold は1000以上にする必要があります。デフォルト値は 1000 です。

  • GR インスタンス ID ロールのいずれかが PRIMARY であるかどうか。

  • 内部 VIP がプロトコル ノードに存在するかどうか。

  • セッション数が CLI を使用して設定したセッションしきい値以上の場合、トラフィック モニタリングがトリガーされます。ただし、セッション数が 1000 未満の場合、トラフィックの監視は停止します。

• 単一の IPC エンドポイントは、GR モードで両方の GR インスタンス ID のトラフィックを処理します。IPC エンドポイントでのトラフィック モニタリングは、GR インスタンス ID 固有ではありません。ただし、両方の GR インスタンス ID に対してチェックが実行されます。

HA（ポッド再起動）シナリオまたは GR（トリガ スイッチオーバー）シナリオをトリガするには、次の構成を使用します。

config 
   monitor 
      active-instance-traffic {  no-traffic-duration no_traffic_duration session-threshold session_threshold action { pod-restart | trigger-switch-over  } } 

注：

• active-instance-traffic ：このキーワードを指定して、アクティブ トラフィック モニタリングを有効または無効にします。

• no-traffic-duration no_traffic_duration ：アクティブ インスタンスでトラフィックが発生しない場合の最大許容時間（秒単位）。値の範囲は 10 ～ 300 です。この CLI に設定されているデフォルト値はありません。 no-traffic-duration の値は、max-conn-downtime の値よりも小さい値にする必要があります。

• session-threshold session_threshold ：アクティブ インスタンス トラフィック モニタリングを開始するために必要な最小セッション数。値の範囲は 10 ～ 10000000 です。デフォルト値は 1000 です。

• action { pod-restart | trigger-switch-over } ：条件を満たす際に実行するアクション。このコマンドに使用できる値は 、pod-restart および trigger-switch-over です。デフォルト値は pod-restart です。

このセクションでは、この機能でサポートされているさまざまな統計情報を定義します。

アクティブ - アクティブモード

• ラック間展開は、隣接する NF に対して透過的です。

• ラック間の展開には CCG 機能の 2 つのインスタンスが含まれ、各インスタンスは一連のインターフェイス IP で識別されます。

• 各インスタンスは一連のセッションをサポートし、セッションの一貫性のために同じ IP を使用し続けます。

• 特定の期間において、1つの CCG インスタンスは一方のラックでのみプライマリとして動作し、もう一方のラックではスタンバイとして動作します。

• CCG インスタンスに関連付けられている一連のインターフェイス IP は、インスタンスのプライマリ ラックにダイナミックにルーティングされます。

SMF は 、データがプライマリからスタンバイ インスタンスに複製されるプライマリ/スタンバイ冗長性をサポートします。通常の動作では、プライマリ インスタンスがサービスを提供します。プライマリ インスタンスで障害が発生すると、スタンバイ インスタンスがプライマリになり、動作を引き継ぎます。ラック間の冗長性を実現するために、2 つのプライマリ/スタンバイ ペアを設定できます。この場合は各ラックがアクティブにトラフィックを処理し、スタンバイ側がリモートラックのバックアップとして機能します。

アクティブ-アクティブのラック間冗長性展開で、同じデータセンターに 2 つのラックがあるとします（Rack-1 と Rack-2）。すべての NF が instance-1 と instance-2 に到達しようとしています。

NF の場合、両方のインスタンスがアクティブになります。しかし実際には、instance-1 と instance-2 はラックにまたがって分割されます。

Rack-1 には instance-1 と instance-2 があります。トリガー前のシナリオでは、instance-1 はローカルでプライマリとして機能し、instance-2 はスタンバイ モードになります。

Rack-2 には instance-1 と instance-2 も含まれています。トリガー前のシナリオでは、instance-2 はローカルでプライマリとして機能し、instance-1 はスタンバイ モードす。

Rack-1 がダウンすると、トラフィックは Rack-2 に移動します。ラック 2 では、instance-1 と instance-2 の両方がプライマリとして機能します。

この設定は、複数ラックのラック間冗長性構成を提供するために必要です。インスタンス ID を使用して、ラックごとにエンドポイントを構成する必要があります。

構成例 1

以下は、1 つのインスタンスにおけるエンドポイント VIP 構成の構成例です。

config 
  instance instance-id gr_instanceId 
    endpoint endpoint_name 
        vip-ip vip_ip_address 
  exit 
exit 

例：

config
instance instance-id 1
 endpoint sbi
  vip-ip 209.165.201.21
 exit
exit

構成例 2

次に、インスタンスのシステム ID、クラスタ ID、スライス名に関する情報を提供する構成例を示します。

config 
  instances instance instance_id 
   system-id system_id 
   cluster-id cluster_id 
   slice-name cdl_slice_name 
  exit 
exit 

例：

config
 instances instance 1
  system-id smf
  cluster-id smf
  slice-name 1
 exit
exit

（注）	インスタンスの system-id、 cluster-id 、および展開の app-name、 cluster-name に同じ値を使用することをお勧めします。

ローカル ラックとリモート ラックごとに 2 つの インスタンスのみを構成でき、対応するエンドポイントをインスタンス化できます。

ローカル インスタンス ID は、ラックが冗長かどうかに関係なく、ローカル ラックの ID です。

ローカル インスタンス ID の構成

ローカル インスタンスは、 local-instance コマンドを使用して構成されます。

local-instance instance 1

エンドポイント構成は、各一意のインスタンス ID で指定されたインスタンスの下にある必要があります。

エンドポイントの構成例

次の構成例を参照してください。

（注）	次の例では、 instance-id "1" がローカ ルインスタンス ID であり、その下に構成されたエンドポイントはローカル サイトに属しています。 必要に応じて、リモート ラック インスタンス ID 「2」をラックに属するエンドポイントに構成できます。

instance instance-id 1
 endpoint li
  replicas 1
  nodes    2
  vip-ip 209.165.201.6
  vip-ip 209.165.201.13
 exit
 endpoint gtp
  replicas 1
  nodes    2
  retransmission timeout 5 max-retry 4
  vip-ip 209.165.201.6
  vip-ip 209.165.201.4
  interface s5
   echo interval          60
   echo retransmission-timeout 5
   echo max-retransmissions 4
  exit
  interface s2b
   echo interval 60
   echo retransmission-timeout 5
   echo max-retransmissions 4
  exit
 exit
exit
instance instance-id 2
 endpoint li
  replicas 1
  nodes    2
  vip-ip 209.165.201.6
  vip-ip 209.165.201.13
 exit
exit
endpoint gtp
  replicas 1
  nodes    2
  retransmission timeout 5 max-retry 4
  vip-ip 209.165.201.6
  vip-ip 209.165.201.5
  interface s5
   echo interval 60
   echo retransmission-timeout 5
   echo max-retransmissions 4
  exit
  interface s2b
   echo interval 60
   echo retransmission-timeout 5
   echo max-retransmissions 4
  exit
 exit
exit

ローカルおよびリモート インスタンスに対応する PGW FQDN のインスタンスを追加します。

例

次に、構成例を示します。

（注）	次の例では、 instance-id 「1」がローカル インスタンス ID であり、その下に構成された SMF プロファイルがローカル ラックに属しています。 必要に応じて、リモート ラック インスタンス ID 「2」をラック間に属する FQDN に構成できます。

profile smf smf1
locality LOC1
allowed-nssai [ slice1 ]
instances 1 fqdn cisco.com.apn.epc.mnc456.mcc123
instances 2 fqdn cisco.com.apn.epc.mnc567.mcc123

NF インスタンスの起動により、BGP スピーカー K8s ポッドは、優先順位とルートとともに IP アドレスにサービスを提供するための代替ローカル アドレスを使用して、BGP ルータのネクストホップ属性を構成します。

地理的 HA がトリガされると、宛先サービスの IP アドレス、パスの接続性、および優先度の値に基づいてパスが選択されます。

Note	ポッド間の透過的な移行により、サブスクライバ セッションは影響を受けません。

SMF は、サービス IP アドレスを、対応するピア K8s クラスタ、コロケーションされたラック、または地理的に配置されたラックに透過的に移行することで、Geo スイッチオーバーを実現します。NF の起動時に、すべての K8s クラスタ名前空間はネクストホップの BGP ルータに登録し、サービス IP アドレスとローカル IP アドレス、優先順位とルート修飾値をアドバタイズします。

各論理 NF は、NRF または DNS に対する個別の NF インスタンス、個別の構成、および名前空間の個別 LCM を公開する。

マスター ノードとのサーバ通信の中断、BFD の障害、または K8s ポッドのネットワークの問題が原因で、機能している K8s クラスタに内部ネットワーク障害が発生した場合、K8s の稼働状態の障害に基づく K8s の依存関係チェックにより、Geo HA がトリガされます。

次の図に示した例では、AMF または MME が透過的に代替ラック サーバの使用を開始しています。N11/S11/S5 および N4/Sxa サービスアドレスはサイト B のラック B に移行されます。システムはラック A のラック B からのシグナリングを継続します。ラック B では、既存のサブスクライバ セッションに影響を与えることなくセッションが続行されます。

Note	UE が再接続する前にコールが終了される状態によっては、接続中のコールがほとんど失敗する場合があります。

SMF は、同じデータセンター内に配置されたピア K8s クラスタまたはラックにサービス IP アドレスを透過的に移行することで、Geo スイッチオーバーを実現します。NF の起動時に、すべての K8s クラスタ名前空間はネクストホップの BGP ルータに登録し、サービス IP アドレスとローカル IP アドレス、優先順位とルート修飾値をアドバタイズします。各論理 NF は、NRF または DNS に対する個別の NF インスタンス、個別の構成、および名前空間の個別 LCM を公開する。

シームレスなフェールオーバーとフェールバックのために、UE セッションと対応するサービス IP アドレスがグループ化されます。

次のシナリオでは、UE セッションのシームレスなフェールオーバーとフェールバックのメカニズムについて説明します。

• 通常：UE セッション セットは、最初のラックから作成、更新、または削除され、2 番目のラックに複製されます。

• 失敗：UE セッション セットは、2 番目のラックから作成、更新、または削除されますが、可用性が低いため、最初のラックには複製されません。

• リカバリ：すべての UE セッション データをリカバリするために、最初のラックの CDL が 2 番目のラックの CDL と自動同期を実行します。リカバリ中は、2 番目のラックはセッション セットからのトラフィックを処理し続けます。

ここでは、BGP を使用したダイナミック ルーティングの主要なコール フローについて説明します。

ここでは、BGP を使用してダイナミック ルーティングを構成する方法について説明します。

AS と BGP ルータの IP アドレスの構成

BGP ルータの AS と IP アドレスを構成するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

BGP サービス リスニング IP アドレスの構成

BGP サービス リスニング IP アドレスを構成するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      interface interface_name 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• interface interface_name ：インターフェイスの名前を指定します。

BGP ネイバーの構成

BGP ネイバーを構成するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      interface interface_name 
      neighbor neighbor_ip_address remote-as as_number 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• interface interface_name ：インターフェイスの名前を指定します。

• neighbor neighbor_ip_address ：ネイバー BGP ルータの IP アドレスを指定します。

• remote-as as_number ：AS の ID 番号を指定します。

ボンディング インターフェイスの構成

インターフェイスに関連するボンディング インターフェイスを構成するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      interface interface_name 
      bondingInterface interface_name 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• interface interface_name ：インターフェイスの名前を指定します。

• bondingInterface interface_name ：インターフェイスに関連するボンディングインターフェイスを指定します。ボンディング インターフェイスがアクティブである場合、BGP は、より低い MED 値を提供することで、インターフェイス サービスに高いプリファレンスを与えます。

学習デフォルト ルートの構成

システム上に特定のルートを構成し、すべてのルートをサポートする必要があるユーザーは、learnDefaultRoute を true に設定する必要があります。

Note	この設定は任意です。

デフォルト ルートの学習を構成するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      learnDefaultRoute true/false 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• learnDefaultRoute true/false ： learnDefaultRoute パラメータを有効または無効にするオプションを指定します。true に設定すると、BGP はデフォルト ルートを学習し、カーネル スペースに追加します。デフォルトは False です。

BGP ポートの構成

BGP サービスのポート番号を構成するには、次のコマンドを使用します。

config 
   router bgp local_as_number 
      loopbackPort port_number 
   exit 
exit 

注：

• router bgp local_as_number ：BGP ルータの AS の ID 番号を指定します。

• loopbackPort port_number ：BGP サービスのポート番号を指定します。デフォルト値は 179 です。

ポリシーの追加

BGP スピーカー ポッドは、ネイバーから多くのルート情報を学習します。ただし、発信トラフィックのサポートに使用されるのはそのうちのごく一部です。これは、 SMF が 外部の AMF/PCF に情報を送信している場合、出力トラフィックの処理にのみ必要です。ルートは、BGP スピーカーでインポート ポリシーを構成することでフィルタリングされ、学習したルートをプロトコルポッドに送信するために使用されます。

ポリシー追加用のサンプル CLI コードと、各パラメータに対応する説明を以下に示します。

$bgp policy <policy_Name> ip-prefix 209.165.200.225 subnet 16 masklength-range 21..24 as-path-set “^65100”

この構成は、展開内の BGP スピーカーポッドの数を制御します。BGP スピーカーは、両方のラックからの着信トラフィックのサービス IP 情報をアドバタイズします。

（注）	BGP ピアリングには、BGP スピーカーポッドで非結合インターフェイスを使用します。 Proto ノードごとの BGP ピアリングは、2 つの BGP ルータ/リーフのみでサポートされます。2 つの Proto ノードを考慮すると、最大 4 つの BGP ネイバーシップを設定できます。

instance instance-id  instance_id endpoint bgpspeaker interface { bgp | bfd } internal base-port start base_port_number 

config 
instance instance-id instance_id 
 endpoint bgpspeaker 
   replicas replica_id 
   nodes node_id 
   interface bgp 
     internal base-port start base_port_number  
   exit 
   interface bfd 
     internal base-port start base_port_number 
  exit 
exit 

注：

• instance instance-id instance_id ：GR インスタンス ID を指定します。

• base_port_number ：論理 NF が構成されている場合にのみ、ポート範囲を指定します。この範囲は、展開によって異なります。

例

次に、設定例を示します。

instance instance-id 1
endpoint bgpspeaker
   replicas 1
   nodes    2
   interface bgp
     internal base-port start {24000}
   exit
   interface bfd
     internal base-port start {25000}
 exit

この項では、BGP を使用したダイナミック ルーティング機能でサポートされている show コマンドについて説明します。

show bgp-kernel-route

BGP ルータのカーネル レベルのすべてのルートを表示するには、 show bgp-kernel-route コマンドを使用します。

以下の構成は、show bgp-kernel-route コマンドの出力例です。

kernel-route

-----bgpspeaker-pod-1 ----

 DestinationIP       SourceIP        Gateway

 209.165.200.235     209.165.200.239   209.165.200.239

-----bgpspeaker-pod-2 ----

 DestinationIP       SourceIP        Gateway

 209.165.200.235     209.165.200.229   209.165.200.244

show bgp-global

すべての BGP グローバル コンフィギュレーションを表示するには、 show bgp-global コマンドを使用します。

以下の構成は、show bgp-global コマンドの出力例です。

global-details

-----bgpspeaker-pod-1 ----
AS:        65000
Router-ID: 209.165.200.239
Listening Port: 179, Addresses: 209.165.200.239
AS:        65000
Router-ID: 209.165.200.232
Listening Port: 179, Addresses: 209.165.200.232

-----bgpspeaker-pod-2 ----
AS:        65000
Router-ID: 209.165.200.235
Listening Port: 179, Addresses: 209.165.200.235
AS:        65000
Router-ID: 209.165.200.246
Listening Port: 179, Addresses: 209.165.200.246

show bgp-neighbors

BGP ルータのすべての BGP ネイバーを表示するには、show bgp-neighbors コマンドを使用します。

以下の構成は、show bgp-neighbors コマンドの出力例です。

neighbor-details

-----bgpspeaker-pod-2 ----
Peer             AS  Up/Down State       |#Received  Accepted
209.165.200.244 60000 00:34:20 Establ      |       10        10
Peer           AS  Up/Down State       |#Received  Accepted
209.165.200.250 60000 00:34:16 Establ      |        3         3

-----bgpspeaker-pod-1 ----
Peer             AS  Up/Down State       |#Received  Accepted
209.165.200.244 60000 00:33:53 Establ      |       10        10
Peer           AS  Up/Down State       |#Received  Accepted
209.165.200.250 60000 00:33:53 Establ      |        3         3

show bgp-neighbors ip

BGP ルータのネイバーの詳細を表示するには、show bgp-neighbors ip コマンドを使用します。

以下の構成は、show bgp-neighbors ip コマンドの出力例です。

neighbor-details

-----bgpspeaker-pod-1 ----
BGP neighbor is 209.165.200.244, remote AS 60000
  BGP version 4, remote router ID 209.165.200.244
  BGP state = ESTABLISHED, up for 00:34:50
  BGP OutQ = 0, Flops = 0
  Hold time is 90, keepalive interval is 30 seconds
  Configured hold time is 90, keepalive interval is 30 seconds

  Neighbor capabilities:
    multiprotocol:
        ipv4-unicast:   advertised and received
    route-refresh:      advertised and received
    extended-nexthop:   advertised
        Local:  nlri: ipv4-unicast, nexthop: ipv6
    4-octet-as: advertised and received
  Message statistics:
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          2
    Keepalives:            70         70
    Route Refresh:          0          0
    Discarded:              0          0
    Total:                 72         73
  Route statistics:
    Advertised:             0
    Received:              10
    Accepted:              10

-----bgpspeaker-pod-2 ----
BGP neighbor is 209.165.200.244, remote AS 60000
  BGP version 4, remote router ID 209.165.200.244
  BGP state = ESTABLISHED, up for 00:35:17
  BGP OutQ = 0, Flops = 0
  Hold time is 90, keepalive interval is 30 seconds
  Configured hold time is 90, keepalive interval is 30 seconds

  Neighbor capabilities:
    multiprotocol:
        ipv4-unicast:   advertised and received
    route-refresh:      advertised and received
    extended-nexthop:   advertised
        Local:  nlri: ipv4-unicast, nexthop: ipv6
    4-octet-as: advertised and received
  Message statistics:
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          2
    Keepalives:            71         71
    Route Refresh:          0          0
    Discarded:              0          0
    Total:                 73         74
  Route statistics:
    Advertised:             0
    Received:              10
    Accepted:              10

show bgp-route-summary

BGP ルータのすべてのルートの詳細を表示するには、show bgp-route-summary コマンドを使用します。

以下の構成は、show bgp-route-summary コマンドの出力例です。

route-details

-----bgpspeaker-pod-1 ----
Table afi:AFI_IP safi:SAFI_UNICAST
Destination: 5, Path: 5

-----bgpspeaker-pod-2 ----
Table afi:AFI_IP safi:SAFI_UNICAST
Destination: 5, Path: 5

show bgp-routes

BGP ルータのすべてのルートを表示するには、show bgp-routes コマンドを使用します。

以下の構成は、show bgp-routes コマンドの出力例です。

bgp-route

-----bgpspeaker-pod-1 ----
   Network              Next Hop             AS_PATH       Age        Attrs
*> 209.165.200.235/24   209.165.200.250      60000         00:36:39   [{Origin: i} {Med: 0}]
*> 209.165.200.227/32   209.165.200.232                    00:36:44   [{Origin: e} {LocalPref: 220} {Med: 3220}]
*> 209.165.200.247/24   209.165.200.250      60000         00:36:39   [{Origin: i} {Med: 0}]
*> 209.165.200.251/24   209.165.200.250      60000         00:36:39   [{Origin: i} {Med: 0}]
*> 209.165.200.252/32   209.165.200.232                    00:36:44   [{Origin: e} {LocalPref: 220} {Med: 3220}]

-----bgpspeaker-pod-2 ----
   Network              Next Hop             AS_PATH        Age        Attrs
*> 209.165.200.235/24   209.165.200.250      60000          00:37:02   [{Origin: i} {Med: 0}]
*> 209.165.200.227/32   209.165.200.246                     00:37:11   [{Origin: e} {LocalPref: 220} {Med: 3220}]
*> 209.165.200.228/24   209.165.200.234      60000          00:37:02   [{Origin: i} {Med: 0}]
*> 209.165.200.229/24   209.165.200.234      60000          00:37:02   [{Origin: i} {Med: 0}]
*> 209.165.200.230/32   209.165.200.246                     00:37:11   [{Origin: e} {LocalPref: 220} {Med: 3220}]

KPI

以下の KPI は、この機能でサポートされます。

次のセクションでは、IPAM の構成例を示します。

SMF-1 の例

SMF-1 の構成例を次に示します。

ipam
 instance 1
  address-pool pool-1
  vrf-name ISP
   tags
   dnn dnn-1
  exit
  ipv4
    address-range 209.165.201.1 209.165.201.31
 exit
instance 2
 address-pool pool-2
  vrf-name ISP
  tags
   dnn dnn-2
  exit
  ipv4
    address-range 209.165.202.129 209.165.202.159
 exit
exit

SMF-2 の例

次に、 SMF-2の構成例を示します。

ipam
 instance 1
 address-pool pool-1
  vrf-name ISP
  tags
   dnn dnn-1
  exit
  ipv4
    address-range 209.165.201.1 209.165.201.31
 exit
 instance 2
 address-pool pool-2
  vrf-name ISP
   tags
   dnn dnn-2
  exit
  ipv4
    address-range 209.165.202.129 209.165.202.159
 exit
exit

エンドポイントは、インスタンス下で構成する必要があります。各ラックには 2 つの Geo 冗長ポッドが必要です。また、ETCD/CachePod レプリケーショのために、内部および外部の地理的インターフェイスに VIP を構成する必要があります。

instance instance-id  instance_id endpoint geo interface { geo-internal | geo-external } vip-ip { vip_ip_address } vip-port { vip_port_number }
 

config 
instance instance-id instance_id 
 endpoint geo 
  replicas replica_id 
  nodes node_id 
  internal base-port start base_port_number 
  interface geo-internal 
   vip-ip vip_ip_address vip-port vip_port_number 
  exit 
  interface geo-external 
   vip-ip vip_ip_address vip-port vip_port_number 
  exit 
exit 
exit 

注：

• instance instance-id instance_id ：GR インスタンス ID を指定します。1 つのインスタンス ID はローカル ラック用、もう 1 つは別のラック用です。

• vip-ip vip_ip_address ：内部/外部の地理的インターフェイスの VIP IP アドレスを指定します。

• vip-port vip_port_number ：VIP ポート番号を指定します。

• internal base-port start base_port_number ：論理 NF が構成されている場合にのみ、ポート範囲を指定します。

例

次に、設定例を示します。

instance instance-id 1
endpoint geo
  replicas 1
  nodes 2
  internal base-port start 25000
  interface geo-internal
   vip-ip 209.165.201.8 vip-port 7001
  exit
  interface geo-external
   vip-ip 209.165.201.8 vip-port 7002
  exit
exit

ラック間セットアップでポッド モニタリングおよびフェールオーバーしきい値を設定するには、次の構成例を使用します。地理ポッドは、構成されたポッド名をモニタします。

config 
 geomonitor 
  podmonitor pods pod_name 
   retryCount value 
   retryInterval interval_value 
   retryFailOverInterval failover_interval 
   failedReplicaPercent percent_value 
  exit 
 exit 

注：

• pods pod_name ：モニタされるポッドの名前を指定します。たとえば、Cache-pod、rest-ep などです。

• retryCount value ：ポッドが ping に失敗した場合に再試行する再試行カウンタ値を指定します。その後、ポッドはダウンとしてマークされます。1 〜 10 の範囲の整数である必要があります。

• retryInterval interval_value ：ポッドが ping に成功した場合の再試行間隔をミリ秒単位で指定します。200 ～ 10000 の範囲の整数である必要があります。

• retryFailOverInterval failover_interval ：ポッドが ping に失敗した場合の再試行間隔をミリ秒単位で指定します。200 ～ 10000 の範囲の整数である必要があります。

• failedReplicaPercent percent_value ：ラック間冗長性フェールオーバーがトリガされるまでの、失敗したレプリカのパーセント値を指定します。10 ～ 100 の範囲の整数である必要があります。

設定例

次に、設定例を示します。

geomonitor podmonitor pods cache-pod
 retryCount 3
 retryInterval 5
 retryFailOverInterval 1
 failedReplicaPercent 40
exit

リモート クラスタ モニタリングは、トラフィックのトラフィックフローが中断されないように、ロール（リモート ラックが STANDBY_ERROR 状態の場合はセルフ プライマリになります）を自動修正します。ただし、このロールの自動修正は、特定のロールに対してのみ実行されます。

この機能を構成するには、次の構成例を使用します。

config 
    geomonitor 
        remoteclustermonitor 
            retryCount value 
            retryInterval interval_value 
            end 

注：

• retryCount value ：現在のラックを PRIMARY にする前の再試行回数を指定します。1 〜 10 の範囲の整数で指定する必要があります。デフォルト値は 3 です。

• retryInterval interval_value ：リモートラックのステータスが取得されるまでの再試行間隔をミリ秒単位で指定します。200 ～ 50000 の範囲の整数である必要があります。デフォルト値は 3000 です。

設定例

次に構成例を示します。

geomonitor remoteclustermonitor
retryCount 3
retryInterval 3000

次のコマンドを使用して、トラフィックをモニタします。

config 
 geomonitor 
  trafficMonitor 
   thresholdCount value 
   thresholdInterval interval_value 
  exit 
 exit 

注：

• thresholdCount value ：スタンバイ インスタンスの受信コール数を指定します。0 〜 10000 の範囲の整数である必要があります。デフォルト値は 0 です。カウンタ値として、UDP プロキシと REST-EP の両方を考慮する必要があります。

• thresholdInterval interval_value ：しきい値カウント値に達するまでの最長時間をミリ秒単位で指定します。100 〜 10000 の範囲の整数である必要があります。デフォルト値は 3000 です。

設定例

次に構成例を示します。

geomonitor trafficmonitor
thresholdCount 3
thresholdInterval 3000

強化された Geo レプリケーション ポッドの次の領域は、地理的冗長性強化機能の一部です。

• システムは、正常に動作すると、GRPC レプリケーションと管理ストリームを使用できるようになります。

• システムは、すべてのシナリオで両方のインスタンスに正しいロールがあることを保証します。

• システムは、ラック 1 とラック 2 の Geo レプリケーション ポッド間のデータ レプリケーションを同期状態に維持します。

• システムは、チェックサムとチェックポイント データが両方のラックで常に正しいことを確認して、データの整合性を確保します。

• システムは、レプリケーション データが同期されなくなったときにユーザーが同期するメカニズムを提供しますが、手動による介入が必要です。

  このコマンドの詳細については、「Geo レプリケーションのプル データ」セクションを参照してください。

• システムは、Geo レプリケーション ポッド間での Geo VIP 移動が機能に影響しないようにします。

• システムは、依存するプロセスの障害がユーザーの機能に影響を与えないようにするための対策を講じています。

ここでは、この機能の操作、管理、およびメンテナンス サポートについて説明します。

CDL GR を展開する前に、ユーザーは次を構成する必要があります。

• CDL セッション データベースを削除し、基本構成を定義します。

• CDL 用の Kafka。

• CDL 用の Zookeeper。

CDL では、既存の GR 関連パラメータとともに、すべてのラックで機能フラグを使用して GR インスタンス認識を有効にする必要があります。また、この機能をすべてのラックで機能させるには、システム ID からスライス名へのマッピングも提供する必要があります。

CDL には Geo レプリケーション（GR）フェールオーバー通知も用意されていているため、セッション データのタイマーの期限切れ、および現在アクティブなラックへの一括通知を通知できます。CDL は GR フェールオーバー通知のために、App-Infra を介してボーダー ゲートウェイ プロトコル（BGP）を使用します。

CDL は両方の GR ラックのキー値を登録します。登録したキー値に変更があると、App-Infra は CDL に通知を送信します。キー値は、CDL システム ID または GR インスタンスの状態を示します。GR インスタンスは、 キーの CDL システム ID または GR インスタンス ID を使用して CDL スライスにマップされます。

システム ID は両方のラックで必須です。NF 構成の GR インスタンス ID が CDL システム ID と一致している必要があります。

CDL には、インスタンス固有のデータ スライスがあります。また、ユーザーは起動時にインスタンス固有のスライス情報を構成できます。

• CDL は、有効期限切れ時またはアクティブなスライスからの一括通知要求時にデータを通知します。

• CDL は、app-infra memory-cache からの通知に基づいてアクティブインスタンスを決定します。

• CDL スライスは、異なる種類のデータを保存する CDL インスタンス内のパーティションです。この場合、NF はデータの別のインスタンスを保存します。

（注）	CDL スライス名は、GR で構成されているスライス名と一致する必要があります。

次のサンプル構成では、Geo レプリケーションのプル データを設定します。これらのコマンドは、誤動作シナリオが発生した場合に、レプリケーション データ同期アクティビティを支援および実行します。GR ロールに移行し、システムでのレプリケーション データの不一致を最小限に抑えるためには、次のコマンドを開始して、アクセス可能なすべてのラック間でデータを同期することができます。

geo replication-pull instance-id gr_instanceId 

注：

• geo replication-pull ：ピア ラックからレプリケーション データをプルして、ローカル ラックと同期します。

• instance-id gr_instanceId ：GR インスタンス ID を指定します。

GR インスタンスのロール（たとえば、 STANDBY_ERROR から STANDBY 、 PRIMARYのロール）をリセットするには、次のコマンド例を使用します。

geo reset-role role role instance-id gr_instanceId 

注：

• role role ：指定のラックの新しいロールを指定します。

  ロールは PRIMARY または STANDBYです。

• instance-id gr_instanceId ：GR インスタンス ID を指定します。

重要	geo reset-role コマンドは、 ローカル ラックの特定のインスタンスのロールの変更をトリガします。リモート ラックは、同じコマンドのメッセージを受信しません。指定されたインスタンス ID のロールを STANDBY_ERROR から STANDBY に、および STANDBY から PRIMARYに変更することのみが可能です。別のロールの変更はできません。

GR ロールを切り替えるには、プライマリ ラックで コマンドを開始し（たとえば、ロール PRIMARY を STANDBY のみに）、次のコマンドを使用します。

geo switch-role { role primary | standby  instance-id gr_instanceId [ failback-interval  failback_interval ] } 

注：

• role role ：指定のラックの新しいロールを指定します。

  ロールは、 primary または standby にできます。特定の GR インスタンス ID のプライマリ ロールから手動スイッチオーバーをトリガする必要があります。

• instance-id gr_instanceId ：GR インスタンス ID を指定します。

• failback-interval は、リリース間のアップグレードの後方互換性を提供するオプションのコマンドです。 failback-interval の推奨値は 0 です。

重要	geo switch-role コマンドは、特定のインスタンス ID について、あるラックから別のラックへの手動フェールオーバーをトリガします。フェールオーバーをトリガするラックが PRIMARY ロールから STANDBY_ERROR ロールに変更されます。その間、フェールオーバーをトリガしたラックは、別のラックにフェールオーバー（Trigger GR）メッセージを送信します。フェールオーバー メッセージを受信した他のラックは、 STANDBY ロールから PRIMARY ロールに変更されます。

（注）	failback-interval は現在のリリースで廃止され、後続のリリースでは廃止されます。

ここでは、問題のデバッグに役立つ show/clear コマンドについて説明します。

サブスクライバのメッセージをキャプチャするには（GR インスタンス対応）、次のコマンドを使用します。

monitor subscriber [ capture-duration duration  | gr-instance gr_instance_id  | imei imei_id | imsi imsi_value | internal-messages [ yes ] | namespace [ sgw | smf ] | nf-service [ sgw | smf ] | supi supi_id | transaction-logs [ yes ] ] 

（注）	2021.02 以降のリリースでは、 namespace キーワードは廃止され、 nf-service キーワードに置き換えられました。

注：

• capture-duration duration ：モニタ サブスクライバを有効にする期間を秒単位で指定します。デフォルトは 300 秒（5 分）です。これは省略可能なパラメータです。

• gr-instance gr_instance_id ：GR インスタンス ID を指定します。インスタンス ID 1 はローカル インスタンス ID を示しています。

• imei imi_id ：サブスクライバ IMEI を指定します。例：123456789012345、*

• imsi imsi_value ：サブスクライバ IMSI を指定します。たとえば、123456789、* などです。

• internal-messages [ yes ] ：yes に設定されている場合、内部メッセージを有効にします。デフォルトでは、無効になっています。これは省略可能なパラメータです。

• namespace [ sgw | smf ] ：指定した名前空間を有効にします。デフォルトでは、名前空間は none に設定されています。これは省略可能なパラメータです。

  重要	このキーワードはリリース 2021.02.0 で廃止され、 nf-service キーワードに置き換えられました。

• nf-service [ sgw | smf ] ：指定した NF サービスを有効にします。デフォルトでは、nf-service は none に設定されています。これは必須パラメータです。

  重要	nf-service キーワードは、リリース 2021.02 以降では namespace キーワードに置き換わります。

• supi supi_id ：サブスクライバ ID を指定します。例：imsi-123456789、imsi-123*

• transaction-logs [ yes ] ：yes に設定されている場合はトランザクション ログを有効にします。デフォルトでは、無効になっています。これは省略可能なパラメータです。

  トランザクション履歴ログを表示するには、dump transactionhistory コマンドを使用します。

  （注）	最新のトランザクション ログは、トランザクション ログ サイズが 1024 の循環キューに保存されます。

例

次に、設定例を示します。

monitor subscriber imsi 123456789 gr-instance 1
supi: imsi-123456789
captureDuration: 300
enableInternalMsg: false
enableTxnLog: false
namespace(deprecated. Use nf-service instead.): none
nf-service: none
gr-instance: 1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   295  100    98  100   197  10888  21888 --:--:-- --:--:-- --:--:-- 29500
Command: --header Content-type:application/json --request POST --data 
{"commandname":"mon_sub","parameters":{"supi":"imsi-123456789","duration":300,
"enableTxnLog":false,"enableInternalMsg":false,"action":"start","namespace":"none",
"nf-service":"none","grInstance":1}} http://oam-pod:8879/commands
Result start mon_sub, fileName ->logs/monsublogs/none.imsi-123456789_TS_2021-04-09T09:59:59.964148895.txt
Starting to tail the monsub messages from file: logs/monsublogs/none.imsi-123456789_TS_2021-04-09T09:59:59.964148895.txt
Defaulting container name to oam-pod.
Use 'kubectl describe pod/oam-pod-0 -n smf' to see all the containers in this pod.

異なるインターフェイスでパケットをキャプチャするには（gr インスタンス対応）、次のコマンドを使用します。

monitor protocol { interface interface_name [ capture-duration duration  | gr-instancegr_instance | pcacp yes | | ] | list [ | ] }  

注：

• interface interface_name ：PCAP がキャプチャされるインターフェイス名を指定します。この CLI では、1 つの CLI コマンドで複数のインターフェイス名を設定できます。

• capture-duration duration ：pcap がキャプチャされる期間を秒単位で指定します。デフォルトは 300 秒（5 分）です。

• 構成されたインターフェイス名は show endpoint 、 CLI コマンドを使用して取得できます。

• gr-instance gr_instance_id ：GR インスタンス ID を指定します。インスタンス ID 1 はローカル インスタンス ID を示しています。

• pcap yes ：このオプションを構成すると、PCAP ファイルの生成が有効になります。デフォルトでは、このオプションは無効になっています。

• list ：プロトコル リスト ファイルをモニタします。

例

次に、設定例を示します。

monitor protocol interface sbi gr-instance 1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   220  100    95  100   125   8636  11363 --:--:-- --:--:-- --:--:-- 20000
Command: --header Content-type:application/json --request POST --data 
{"commandname":"mon_pro","parameters":{"interface":"sbi","duration":300,"action":
"start","enable_pcap":false,"grInstance":1}} http://oam-pod:8879/commands
Result start mon_pro, fileName ->logs/monprologs/sessintfname_sbi_at_2021-04-30T05:26:22.712229347.txt
Starting to tail the monpro messages from file: logs/monprologs/sessintfname_sbi_at_2021-04-30T05:26:22.712229347.txt
Defaulting container name to oam-pod.
Use 'kubectl describe pod/oam-pod-0 -n cn' to see all of the containers in this pod.

次のセクションでは、GR セットアップの正常性チェックに関する情報を提供します。

• すべての重要なポッドは、ユーザー トラフィックを処理できる良好な状態です。

  GR および CDL に関連するポッドが実行状態にあるかどうかを確認するには、次のコマンドを使用します。

  kubectl get pods -n cn-cn1 -o wide | grep georeplication-pod
  kubectl get pods -n cn-cn1 -o wide | grep cdl
  kubectl get pods -n cn-cn1 -o wide | grep mirror-maker

• キープアライブ ポッドは正常な状態になり、check-interface/check-port 用に構成されたすべての VIP をモニタリングします。

  次のコマンドを使用して、「smi-vips」名前空間のキープアライブ ポッドが「実行」状態であるかどうかを確認します。

  kubectl get pods -n smi-vips

• CDL に関連するポッドの正常性チェック：CDL DB エンドポイント、スロット、およびインデックスのステータスを確認します。システム ID 1 と 2 の両方で、すべてのが STARTED または ONLINE 状態になっている必要があります。

  cdl show status 
  message params: {cmd:status mode:cli dbName:session sessionIn:{mapId:0 limit:500 key: purgeOnEval:0 filters:[] nextEvalTsStart:0 nextEvalTsEnd:0 allReplicas:false maxDataSize:4096} sliceName:}
  db-endpoint {
      endpoint-site {
          system-id 1
          state STARTED
          total-sessions 4
          site-session-count 2
          total-reconciliation 0
          remote-connection-time 66h37m31.36054781s
          remote-connection-last-failure-time 2021-07-13 11:24:10.233825924 +0000 UTC
          slot-geo-replication-delay 2.025396ms
      }
      endpoint-site {
          system-id 2
          state STARTED
          total-sessions 4
          site-session-count 2
          total-reconciliation 0
          remote-connection-time 66h58m49.83449066s
          remote-connection-last-failure-time 2021-07-13 11:02:51.759971655 +0000 UTC
          slot-geo-replication-delay 1.561816ms
      }
  }
  slot {
      map {
          map-id 1
          instance {
              system-id 1
              instance-id 1
              records 4
              capacity 2500000
              state ONLINE
              avg-record-size-bytes 1
              up-time 89h38m37.335813523s
              sync-duration 9.298061ms
          }
          instance {
              system-id 1
              instance-id 2
              records 4
              capacity 2500000
              state ONLINE
              avg-record-size-bytes 1
              up-time 89h39m11.1268024s
              sync-duration 8.852556ms
          }
          instance {
              system-id 2
              instance-id 1
              records 4
              capacity 2500000
              state ONLINE
              avg-record-size-bytes 1
              up-time 89h28m38.274713022s
              sync-duration 8.37766ms
          }
          instance {
              system-id 2
              instance-id 2
              records 4
              capacity 2500000
              state ONLINE
              avg-record-size-bytes 1
              up-time 89h29m37.934345015s
              sync-duration 8.877442ms
          }
      }
  }
  index {
      map {
          map-id 1
          instance {
              system-id 1
              instance-id 1
              records 4
              capacity 60000000
              state ONLINE
              up-time 89h38m16.119032086s
              sync-duration 2.012281769s
              leader false
              geo-replication-delay 10.529821ms
          }
          instance {
              system-id 1
              instance-id 2
              records 4
              capacity 60000000
              state ONLINE
              up-time 89h39m8.47664588s
              sync-duration 2.011171261s
              leader true
              leader-time 89h38m53.761213379s
              geo-replication-delay 10.252683ms
          }
          instance {
              system-id 2
              instance-id 1
              records 4
              capacity 60000000
              state ONLINE
              up-time 89h28m29.5479133s
              sync-duration 2.012101957s
              leader false
              geo-replication-delay 15.974538ms
          }
          instance {
              system-id 2
              instance-id 2
              records 4
              capacity 60000000
              state ONLINE
              up-time 89h29m11.633496562s
              sync-duration 2.011566639s
              leader true
              leader-time 89h28m51.29928233s
              geo-replication-delay 16.213323ms
          }
      }
  }

• CDL レプリケーション ステータス

  [CDLレプリケーション統計（CDL Replication Stats）] Grafana ダッシュボードの [GRPC_Connections_to_RemoteSite] パネルのラック全体で、（各名前空間の）CDL EP セッションポッド間で 4 つの gRPC 接続が確立されているかどうかを確認します。両方のラックで Grafana をチェックします。

  

• Geo レプリケーション用のラック間の管理ポート ステータス。

  [GR 統計情報（GR Statistics）] Grafana ダッシュボードの [Periodic_Heartbeat_to_Remote_Site] パネルで、ラック全体の Geo レプリケーション ポッド間のハートビート メッセージを確認します。

  

• ラック上の BGP/BFD リンク ステータス

  BGP ピアとの隣接関係が確立されているかどうかを、 [BGP、BFD 統計情報（BGP, BFD Statistics）] Grafan ダッシュボードの [BGP ピア（BGP Peers）] パネルで確立しているかどうかを確認します。

  

  BFD リンクが接続状態であるかどうかを、[BGP、BFD 統計情報（BGP, BFD Statistics）] Grafana ダッシュボードの [BFD リンク ステータス（BFD Link Status）] パネルで確認します。

  

• 各インスタンスのロールが正常な状態である

  各ラックのロールがどの時点においても STANDBY_ERROR 状態でないことを確認します。

  • アクティブ/スタンバイ モデル：ロールは各ラックで次の状態である必要があります。

    Rack-1：

    show role instance-id 1
    result "PRIMARY"
    show role instance-id 2
    result "PRIMARY"

    Rack-2：

    show role instance-id 1
    result "STANDBY"
    show role instance-id 2
    result "STANDBY"

  • アクティブ/アクティブ モデル：ロールは、各ラックで次の状態になっている必要があります。

    Rack-1：

    show role instance-id 1
    result "PRIMARY"
    show role instance-id 2
    result "STANDBY"

    Rack-2：

    show role instance-id 1
    result "STANDBY"
    show role instance-id 2
    result "PRIMARY"

Rack-1 上

1. Rack-1 の両方のインスタンスのロールが STANDBY_ERROR であることを確認します。

   show role instance-id 1
   result "STANDBY_ERROR"

   show role instance-id 2
   result "STANDBY_ERROR"

2. Rack-1 の両方のインスタンスのロールの STANDBY へのリセットを開始します。このステップにより、ロールが STANDBY_ERROR/STANDBY_ERROR から STANDBY/STANDBY に移行します。

   geo reset-role instance-id 1 role standby
   geo reset-role instance-id 2 role standby

3. ラック 1 両方のインスタンスのロールがの STANDBY に変わったことを確認します。

   show role instance-id 1
   result "STANDBY"

   show role instance-id 2
   result "STANDBY"

4. フェールバック間隔を 0 秒にして、Rack-2 で instance-id 1 のインスタンスのロールの STANDBY への切り替えを開始します。このステップにより、Rack-2 のロールが PRIMARY/PRIMARY から STANDBY_ERROR/PRIMARY に、Rack-1 のロールが STANDBY/STANDBY から PRIMARY/STANDBY に移行します。

   geo switch-role instance-id 1 role standby [failback-interval 0]

5. Rack-2 の両方のインスタンスのロールが STANDBY_ERROR/PRIMARY にあることを確認します。

   show role instance-id 1
   result "STANDBY_ERROR"

   show role instance-id 2
   result "PRIMARY"

6. Rack-1 の両方のインスタンスのロールが PRIMARY/STANDBY であることを確認します。

   show role instance-id 1
   result "PRIMARY"

   show role instance-id 2
   result "STANDBY"

7. STANDBY への Rack-2 の instance-id 1 のロールのリセットを開始します。このステップにより、Rack-2 のロールが STANDBY_ERROR/PRIMARY から STANDBY/PRIMARY に移行します。

   geo reset-role instance-id 1 role standby

8. Rack-2 のロールが STANDBY/PRIMARY であることを確認します。

   show role instance-id 1
   result "STANDBY"

   show role instance-id 2
   result "PRIMARY"

Rack-2 上

1. Rack-2 の両方のインスタンスのロールが STANDBY_ERROR であることを確認します。

   show role instance-id 1
   result "STANDBY_ERROR"

   show role instance-id 2
   result "STANDBY_ERROR"

2. Rack-2 の両方のインスタンスのロールの STANDBY へのリセットを開始します。このステップにより、ロールが STANDBY_ERROR/STANDBY_ERROR から STANDBY/STANDBY に移行します。

   geo reset-role instance-id 1 role standby
   geo reset-role instance-id 2 role standby

3. 両方のインスタンスのロールが Rack-2 の STANDBY に移動することを確認します。

   show role instance-id 1
   result "STANDBY"

   show role instance-id 2
   result "STANDBY"

4. ラック 1 の instance-id 2 のロールの STANDBY への切り替えを開始します。このステップでは、Rack-1 のロールを PRIMARY/PRIMARY から PRIMARY/STANDBY_ERROR に、Rack-2 のロールを STANDBY/STANDBY から STANDBY/PRIMARY に移行します。

   geo switch-role instance-id 2 role standby [failback-interval 0]

5. Rack-1 の インスタンスのロールが PRIMARY/STANDBY_ERROR モードであることを確認します。

   show role instance-id 1
   result "PRIMARY"

   show role instance-id 2
   result "STANDBY_ERROR"

6. Rack-2 の インスタンスのロールが STANDBY/PRIMARY モードであることを確認します。

   show role instance-id 1
   result "STANDBY"

   show role instance-id 2
   result "PRIMARY"

7. Rack-1 の instance-id 2 の STANDBY へのロールのリセットを開始します。この手順では、Rack-1 のロールを PRIMARY/STANDBY_ERROR から PRIMARY/STANDBY に移行します。

   geo reset-role instance-id 2 role standby

8. Rack-1 の インスタンスのロールが PRIMARY/STANDBY であることを確認します。

   show role instance-id 1
   result "PRIMARY"

   show role instance-id 2
   result "STANDBY"

次の項では、KPI について説明します。

ETCD/Cachepod の複製 KPI

次の表に、ETCD/Cachepod 複製 KPI のリストを記載します。

地理的なロール変更拒否の KPI

次の表に、地理的なロール変更拒否の KPI のリストを記載します。

KPI のモニタリング

次の表に、KPI のモニタリングを示します。

BFD KPI

次の表に、BFD KPI を示します。

GR インスタンス情報

Geo メンテナンス モード

次のセクションでは、GR 固有のバルク統計情報について詳しく説明します。

bulk-stats query GR-BGP-Incoming-Failed-Routes
 expression "sum(bgp_incoming_failedrouterequest_total) by (namespace, interface, service_IP, next_hop, instance_id)"
 labels     [ instance_id interface next_hop service_IP ]
 alias      gr-bgp-routes-in
exit
bulk-stats query GR-Geo-Monitoring-Failure
 expression "sum(geo_monitoring_total{ControlActionNameType=~'MonitorPod|RemoteMsgHeartbeat|
RemoteMsgGetSiteStatus|RemoteSiteRoleMonitoring|RemoteClusterPodFailure|RemoteMsgNotifyFailover|
RemoteMsgNotifyPrepareFailover|MonitorVip',status!~'success|monitoring.*'}) by (namespace, 
AdminNode, ControlActionType, ControlActionNameType,  pod, status, status_code)"
 labels     [ pod AdminNode ControlActionNameType status status_code ]
 alias      gr-geo-monitoring-failure
exit
bulk-stats query GR-Geo-Monitoring-Success
 expression "sum(geo_monitoring_total{ControlActionNameType=~'MonitorPod|RemoteMsgHeartbeat|
RemoteMsgGetSiteStatus|RemoteSiteRoleMonitoring|RemoteClusterPodFailure|RemoteMsgNotifyFailover|
RemoteMsgNotifyPrepareFailover',status=~'success|monitoring.*'}) by (namespace, AdminNode, 
ControlActionType, ControlActionNameType,  pod, status)"
 labels     [ pod AdminNode ControlActionNameType status ]
 alias      gr-geo-monitoring
exit
bulk-stats query GR-Geo-Monitoring-Total
 expression "sum(geo_monitoring_total{ControlActionNameType=~'MonitorPod|RemoteMsgHeartbeat|
RemoteMsgGetSiteStatus|RemoteSiteRoleMonitoring|RemoteClusterPodFailure|RemoteMsgNotifyFailover
|RemoteMsgNotifyPrepareFailover|MonitorVip'}) 
by (namespace, AdminNode, ControlActionType, ControlActionNameType,  pod, status)"
 labels     [ pod AdminNode ControlActionNameType status ]
 alias      gr-geo-monitoring
exit
bulk-stats query GR-Geo-Replication-Failure
 expression "sum(geo_replication_total{ReplicationNode=~'CACHE_POD|ETCD|PEER',status!='success',
ReplicationRequestType='Response'}) by (namespace, ReplicationNode, ReplicationSyncType,
ReplicationReceiver,ReplicationRequestType,status,status_code)"
 labels     [ pod ReplicationNode ReplicationReceiver ReplicationRequestType ReplicationSyncType status status_code ]
 alias      gr-geo-replication-failure
exit
bulk-stats query GR-Geo-Replication-Success
 expression "sum(geo_replication_total{ReplicationNode=~'CACHE_POD|ETCD|PEER',
status='success',ReplicationRequestType='Response'}) by (namespace, ReplicationNode, 
ReplicationSyncType,ReplicationReceiver,ReplicationRequestType,status)"
 labels     [ pod ReplicationNode ReplicationReceiver ReplicationRequestType ReplicationSyncType status ]
 alias      gr-geo-replication-success
exit
bulk-stats query GR-Geo-Replication-Total
 expression "sum(geo_replication_total{ReplicationNode=~'CACHE_POD|ETCD|PEER'}) 
by (namespace, ReplicationNode, ReplicationSyncType,ReplicationReceiver,
ReplicationRequestType,pod)"
 labels     [ pod ReplicationNode ReplicationReceiver ReplicationRequestType ReplicationSyncType ]
 alias      gr-geo-replication-total
exit
bulk-stats query GR-Trigger-ResetRole-Api
 expression "sum(geo_monitoring_total{ControlActionNameType=~'TriggerGRApi|ResetRoleApi'}) 
by (namespace, AdminNode, ControlActionType, ControlActionNameType,  pod, status, status_code)"
 labels     [ pod AdminNode ControlActionNameType status status_code ]
 alias      gr-api
exit
bulk-stats query GR-CDL-Index-Replication
 expression "sum(consumer_kafka_records_total) by (pod, origin_instance_id)"
 labels     [ origin_instance_id pod ]
 alias      gr-cdl-index-replication
exit
bulk-stats query GR-CDL-Inter-Rack-Replications-Failures
 expression "sum(datastore_requests_total{local_request='0',errorCode!='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-inter-rack-replications
exit
bulk-stats query GR-CDL-Inter-Rack-Replications-Success
 expression "sum(datastore_requests_total{local_request='0',errorCode='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-inter-rack-replications
exit
bulk-stats query GR-CDL-Inter-Rack-Replications-Total
 expression "sum(datastore_requests_total{local_request='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-inter-rack-replications
exit
bulk-stats query GR-CDL-Intra-Rack-Operations-Failures
 expression "sum(datastore_requests_total{local_request='1',errorCode!='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-intra-rack-operations
exit
bulk-stats query GR-CDL-Intra-Rack-Operations-Success
 expression "sum(datastore_requests_total{local_request='1',errorCode='0'}) by (operation,sliceName,errorCode)"
 labels     [ sliceName operation errorCode ]
 alias      gr-cdl-intra-rack-operations
exit
bulk-stats query GR-CDL-Intra-Rack-Operations-Total
 expression "sum(datastore_requests_total{local_request='1'}) by (operation,sliceName,errorCode)"
 labels     [ errorCode operation sliceName ]
 alias      gr-cdl-intra-rack-operations
exit
bulk-stats query GR-CDL-Session-Count-Per-Slice
 expression sum(avg(db_records_total{namespace=~'$namespace',session_type='total'})by(systemId,sliceName))by(sliceName)
 labels     [ sliceName ]
 alias      gr-cdl-session-count-per-slice
exit
bulk-stats query GR-CDL-Session-Count-Per-System-ID
 expression sum(avg(db_records_total{namespace=~'$namespace',session_type='total'})
by(systemId,sliceName))by(systemId)
 labels     [ systemId ]
 alias      gr-cdl-session-count-per-system-id
exit
bulk-stats query GR-CDL-Slot-Records-Per-Slice
 expression "sum(slot_records_total{pod=~'.*',systemId!=''}) by (pod, sliceName)"
 labels     [ pod sliceName ]
 alias      gr-cdl-slot-records-per-slice
exit
bulk-stats query GR-CDL-Slot-Records-Per-System-ID
 expression "sum(slot_records_total{pod=~'.*',systemId!=''}) by (pod, systemId)"
 labels     [ pod systemId ]
 alias      gr-cdl-slot-records-per-system-id
exit
bulk-stats query GR-CDL-Total-Session-Count
 expression "sum(db_records_total{namespace=~'$namespace',session_type='total'}) by (systemId,sliceName)"
 labels     [ sliceName systemId ]
 alias      gr-cdl-total-session-count
exit

GR 関連の統計の詳細については、次を参照してください。

• RADIUS 統計では、grInstId ラベルを使用して GR 固有の統計をフィルタリングできます。

  詳細については、「UCC 5Gセッション管理機能 - メトリック参照」を参照してください。

• GTP エンドポイント統計情報で、gr_instance_id ラベルを使用して GR 固有の統計情報をフィルタリングできます。

  詳細については、「UCC 5Gセッション管理機能 - メトリック参照」を参照してください。

• SMF 統計では、gr_instance_id label を使用して GR 固有の統計をフィルタリングできます。

  詳細については、「UCC 5Gセッション管理機能 - メトリック参照」を参照してください。

• REST エンドポイント統計情報で、gr_instance_id ラベルを使用して GR 固有の統計情報をフィルタリングできます。

  詳細については、「UCC 5Gセッション管理機能 - メトリック参照」を参照してください。

• IPAM 関連の統計では、grInstId ラベルを使用して GR 固有の統計をフィルタリングできます。

  詳細については、「UCC 5Gセッション管理機能 - メトリック参照」を参照してください。

ここでは、GR アラートについて詳しく説明します。

BFD アラート

次の表に、 interval-seconds が 60 に設定されたルールグループ BFD のアラートを示します。

GR アラート

次の表に、interval-seconds が 60 に設定されているルールグループ GR のアラートを示します。

CDL アラート

次の表に、 interval-seconds が 60 に設定されたルールグループ CDL のアラートを示します。

サイト間冗長性展開では、非推移的な BGP 属性である Multi-Exit Discriminator（MED）属性を使用して、アクティブなサービス VIP に到達するための最適なパスを隣接ルータに通知します。ただし、MED 値は、隣接ルータとその eBGP ピア間では共有されません。

ラック間導入モデルでは、AS パス前に付加する技術が BGP で使用され、他の BGP ルータにアドバタイズされるルートのパス選択に影響を与えます。AS パス プリペンド技術では、BGP ルート アドバタイズメントで AS パスを操作することにより、特定のルートを他のルートよりも推奨します。ソフトウェア ロジックによって先頭に追加される AS パスの数の違いは、アップストリーム ルータが最適なルーティング可能なパスを選択するためのガイダンスを提供するのに役立ちます。

次の表に、サービス VIP とインターフェイス ボンディング ステータスのさまざまな組み合わせに必要な AS パスプリペンドの数を示します。

サイト間展開を有効にするには、BGP 構成で AS パス前に付加フラグを構成する必要があります。

いかに構成例を示します。

config 
  router local_as_number 
    bfd bfd_configuration 
    interface bgp_local_interface 
    prepend as-path { false | true } 
    exit 
   exit 

注：

• interface bgp_local_interface ：BGP ローカル インターフェイスを指定します。

• prepend as-path { false | true } ： true を選択して、サイト間展開を有効にします。デフォルトでは、このオプションは無効になっています。

  このオプションが false に設定されている場合、論理 SMF の展開はラック間モデルに従います。

ラック間ソリューションでは、リーフ サーバーとスパイン サーバーが同じ AS パスに組み込まれ、VxLAN 技術の利用が可能になりました。この展開モデルでは、ラック間の到達可能性を維持しながら、さまざまなポッド間での冗長性データとイベントのサポート、監視、および交換が可能です。具体的には、両方のラックの Geo ポッドの外部 IP アドレスが共通のサブネットに統合され、同じ VLAN を共有しているため、ルート検出を必要とせずにデータ交換を行えるようになりました。さらに、ラック間の通信はリーフ サーバーとスパイン サーバーの境界内に残り、パケットがそれらを超えて通過する必要はありませんでした。

次のポッドには、サイト間の外部接続が必要です：

• ジオポッド

• CDL-ep（秒）

• CDL-Kafka-server

サービス VIP とは異なり、これらの IP アドレスはサイト間でのフローティングを必要としません。ルーティングの決定は、実稼働展開中に 1 回だけ行う必要があります。したがって、これらの外部 IP アドレスを BGP を介してアドバタイズする代わりに、スタティック ルーティングが使用されました。

静的ルートは、リモート CDL/Kafka/Geo ネットワークに到達するために、ローカル K8S クラスタ プロトコル ノードに追加されます。リーフは、接続されているすべてのローカル CDL/Kafka/Geo ネットワークをスパインに自動的にアドバタイズします。スパインはこれらのルートを Arg ルータに再配布します。Arg ルータは、両方のサイトの CDL/Kafka/Geo ネットワークに到達する方法を認識しています。パケットの宛先がリモート CDL/Kafka/Geo ネットワークの場合、ローカル K8S プロトコル ノードには、ローカル リーフを指すスタティック ルートがあります。その後、パケットはスパインに送られます。スパインには、Arg ルータを指すデフォルト ルートがあります。Arg ルータには、パケットをリモートサイトに送信するための適切なルートがあります。

さらに、Arg ルータは「default-originate」キーワードを使用して構成されます。これは、ARG ルータをスパインのデフォルト ゲートウェイとして指定します。その結果、スパインはルーティング パスがスパインで利用できないすべてのトラフィックを Arg ルータにリダイレクトします。

このセクションでは、サイト間冗長性の展開がさまざまなシナリオでどのように機能するかについて説明します。

2 つのサイトがあり、両方が動作しているシナリオでは、各サイトに 1 つのプライマリ/アクティブ GR（ゲートウェイ ルータ）インスタンスがあります。各サイトに構成されたエンドポイントは、アクティブなインスタンスに対応するトラフィックを伝送します。集約ルータ（ARG）がサイトに直接接続されていない可能性があり、ARG とサイトの間に複数の自律システムが存在する可能性があります。ARG ルータは、両方のサイトからのルートをまとめます。

サイトの冗長性に関するさまざまなシナリオを次に示します：

• 設定された気象条件では、サイト A は GR1 の最適なルートと、GR2 に関連付けられたエンドポイントのあまり好ましくないルートをアドバタイズします。

  ARG では、ルートは次のようになります：

  • サイト A からのルート

    • 209.165.200.225 AS-Path 65000 65000 65000 65000

    • 209.165.200.235 AS-Path 65000 65000 65000 65000 65000 65000 65000

  • サイト B からのルート

    • 209.165.200.225 AS-Path 64000 64000 64000 64000 64000 64000

    • 209.165.200.235 AS-Path 64000 64000 64000 64000

  • ベスト パス：

    • Site-A 209.165.200.225 AS-path 65000 65000 65000 65000

    • Site -B 209.165.200.235 AS-path 64000 64000 64000 64000

ここで、サイト A がダウンした場合は次のようになります：

ARG ルータの BGP セッションは BGP コンバージェンス時間後にダウンし、サイト A から学習したルートが取り消されます。ARG でのルートの現在の状態は次のとおりです。

• サイト B からのルート：

  • 209.165.200.225 AS-Path 64000 64000 64000 64000 64000 64000 64000

  • 209.165.200.235 AS-Path 64000 64000 64000 64000

  これで、エンドポイントの 209.165.200.225 と 209.165.200.225 の両方のトラフィックがサイト B に向けて送信されます。

• サイト B のトラフィック モニタリング機能は、IP アドレス 209.165.200.225 のトラフィックを識別しています。この IP アドレスのパケットしきい値を超えると、GeoReplication ポッドは、スタンバイ モードからアクティブ モードへの GR-1 インスタンスの移行をトリガーします。

• Geo-pod が GR1 のプライマリ インスタンスへの移行を BGPSpeaker-pod に通知した後、BGPSpeaker-pod は最も望ましいルーティング パスを使用して GR1 エンドポイントのルートを再アドバタイズします。

• これで、ARG 内のルートは次の情報で更新されます：

  • サイト B からのルート：

    • 209.165.200.225 AS-Path 64000 64000 64000 64000

    • 209.165.200.235 AS-Path 64000 64000 64000 64000

この機能の一部として、次の重要業績評価指標（KPI）がスプリット ブレインのサポートに関連付けられます。

Geoスプリット ブレイン検出合計KPI

Geo スプリット ブレイン解決の合計

地域ロール理由変更の合計