GTPC および Sx パスの管理

機能の概要と変更履歴

要約データ

表 1. 要約データ

該当製品または機能エリア

cnSGW-C

該当プラットフォーム

SMI

機能のデフォルト設定

GTPC および Sx パス管理：無効 - 有効にするには構成が必要

GTPC パス障害：有効 - 常時オン

Sx パス障害：有効 - 常時オン

パス障害検出のカスタマイズ：無効 - 有効にするには構成が必要

関連資料

該当なし

マニュアルの変更履歴

表 2. マニュアルの変更履歴

改訂の詳細

リリース

IPv6 のサポートが導入されました。

2022.04.0

最初の導入。

2021.02.0

機能説明

GTPC および Sx パス管理機能は次をサポートしています。

  • エコー要求およびエコー応答メッセージを使用した GTPC パス管理。

  • PFCP ハートビート要求とハートビート応答を使用した Sx パス管理。SGW-C と UPF 間のノードレベルのハートビート手順。

  • S11 および S5 インターフェイスでの GTPC パス障害の検出。

  • Sx インターフェイスでの Sx パス障害の検出。

  • パス障害検出機能を設定するためのパス障害検出ポリシーの設定。

GTPC および Sx パスの管理

機能説明

GTPC および Sx パス管理は次をサポートしています。

  • ピアの稼働状態をチェックするために、S5 および S11 インターフェイスを介したエコー要求およびエコー応答の交換を使用した GTPC パス管理。

  • ピアの稼働状態を確認するために、Sx インターフェイスを介したパケット転送制御プロトコル（PFCP）ハートビート要求とハートビート応答の交換を使用した Sx パス管理。

機能設定

この機能の設定には、次の手順が含まれます。

エコーパラメータの構成

エコーパラメータを構成するには、次の構成を使用します。

エコー要求の有効化

エコー要求を有効にするには、次の構成を使用します。

config 
   instance instance-id instance_id 
      endpoint endpoint_name 
         interface [ s11 | s5e ]  
           echo interval interval_value 
           echo max-retransmissions max_retransmissions_count 
           echo retransmission-timeout retransmission_timeout_count 
           end

注：

  • interval interval_value ：エコー間隔を秒単位で指定します。60 〜 3600 の範囲の整数である必要があります。デフォルト値は 60 秒です。

  • max-retransmissions max_retransmissions_count ：GTP エコー要求の最大再試行回数を指定します。0 ～ 15 の範囲の整数で指定する必要があります。デフォルト値は 3 です。

  • retransmission-timeout retransmission_timeout_count ：エコー要求の再送信タイムアウト時間を秒単位で指定します。1 ～ 20 の範囲の整数で指定する必要があります。デフォルト値は 5 です。

エコー要求の無効化

エコー要求を無効にするには、次の構成を使用します。

config 
   instance instance-id instance_id 
      endpoint endpoint_name 
         replicas replicas_count 
         interface interface_name 
            no echo 
            end

ハートビートの設定

ハートビートパラメータを設定するには、次の設定を使用します。

ハートビートの有効化

ハートビートを有効にするには、次の設定を使用します。

config 
   instance instance-id instance_id 
      endpoint pfcp 
         interface sxa 
            heartbeat 
            interval interval 
            retransmission-timeout timeout 
            max-retransmissions retransmission_count 
            end

注：

  • interval heartbeat_interval ：ハートビート間隔を秒単位で指定します。0 ～ 3600 の範囲の整数で指定する必要があります。無効にするには、0 に設定します。

  • max-retransmissions max_retransmissions ：PFCP ハートビート要求の最大再試行回数を指定します。0 ～ 15 の範囲の整数で指定する必要があります。デフォルト値は 4 です。

  • retransmission-timeout retransmission_timeout ：ハートビート再送信のタイムアウト期間を秒単位で指定します。1 ～ 20 の範囲の整数で指定する必要があります。デフォルト値は 5 です。

ハートビートの無効化

ハートビートを無効にするには、次の設定を使用します。

config 
   instance instance-id instance_id 
      endpoint pfcp 
         interface sxa 
            heartbeat 
            interval interval 
            end

注：

  • interval heartbeat_interval ：ハートビート間隔を 0 にして、ハートビートを無効にします。

ピア構成の表示

ピアの再起動カウンタを表示するには、次の構成を使用します。

次のコマンドは、ピア構成を表示します。

show peers all [ endpoint ] [ local addr ] [ peer addr ] 
show peers all SXA 209.165.201.12:8805 209.165.201.18:8805 POD CONNECTED
ENDPOINT LOCAL ADDRESS PEER ADDRESS DIRECTION INSTANCE TYPE TIME RPC ADDITIONAL DETAILS
----------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------
SXA 209.165.201.12:8805 209.165.201.18:8805 Inbound nodemgr-0 Udp 4 hours SGW-U Capacity: 65535,
LoadMetric: 0,LoadSeqNo: 0,Mode: Online,OverloadMetric: 0,OverloadSeqNo: 0,Priority: 65535
show peers all S11 209.165.201.4:2123 209.165.201.7:2123 LOCAL POD CONNECTED 
ADDITIONAL ENDPOINT ADDRESS PEER ADDRESS DIRECTION INSTANCE TYPE TIME RPC DETAILS
----------------------------------------------------------------------------------
----------------- 
S11 209.165.201.4:2123 209.165.201.7:2123 Inbound nodemgr-0 Udp 25 seconds MME Recovery: 10
show peers all S5E 209.165.201.4:2123 209.165.201.21:2123 LOCAL POD CONNECTED 
ADDITIONAL ENDPOINT ADDRESS PEER ADDRESS DIRECTION INSTANCE TYPE TIME RPC DETAILS 
-----------------------------------------------------------------------------------
---------------- 
S5E 209.165.201.4:2123 209.165.201.21:2123 Inbound nodemgr-0 Udp 25 seconds PGW Recovery: 10
show peers all POD CONNECTED
ENDPOINT LOCAL ADDRESS PEER ADDRESS DIRECTION INSTANCE TYPE TIME RPC ADDITIONAL DETAILS
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
<none> 209.165.201.29 209.165.201.18:8001 Outbound rest-ep-0 Rest 17 hours UDM <none>
<none> 209.165.201.29 209.165.201.18:8002 Outbound rest-ep-0 Rest 17 hours AMF <none>
<none> 209.165.201.29 209.165.201.18:8003 Outbound rest-ep-0 Rest 17 hours PCF <none>
<none> 209.165.201.29 209.165.201.18:8004 Outbound rest-ep-0 Rest 17 hours CHF <none>
<none> 209.165.201.29 209.165.201.18:9040 Outbound rest-ep-0 Rest 17 hours CHF <none>
S11 209.165.201.4:2123 209.165.201.6:2123 Inbound nodemgr-1 Udp 18 minutes MME Recovery: 10
S5E 209.165.201.12:2123 209.165.201.24:2123 Inbound nodemgr-1 Udp 5 hours PGW Recovery: 65535
SXA 209.165.201.12:8805 209.165.201.18:8805 Inbound nodemgr-0 Udp 22 minutes SGW-U Capacity: 65535,LoadMetric: 0,LoadSeqNo: 0,Mode: Online,OverloadMetric: 0,OverloadSeqNo: 0,Priority: 65535

設定例

エコーを有効にする設定例を次に示します。

config
   instance instance-id 1
      endpoint gtp
         interface s11
            echo interval 60
            echo max-retransmissions 5
            echo retransmission-timeout 4  
            end

エコーを無効にする設定例を次に示します。

config
   instance instance-id 1
      endpoint gtp
         replicas 1
         interface s5e
            no echo
            exit
         interface s11
            no echo 
            end

OAM サポート

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

アラート

[Peer Up] と [Peer Down] のアラートを設定するには、『Cisco Ultra Cloud サービング ゲートウェイ コントロール プレーンの機能 - メトリックリファレンス』の「重要業績評価指数」の章を参照してください。

バルク統計サポート

Node Manager

次に、エコー送信メッセージおよびエコー再送信メッセージの例を示します。

nodemgr_gtpc_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_req_retx", gtpc_peer_ip="209.165.201.11",instance_id="1",interface_type="S5E",service_name="nodemgr"} 3
nodemgr_gtpc_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_req_tx", gtpc_peer_ip="209.165.200.230",instance_id="1",interface_type="S11",service_name="nodemgr"} 2
nodemgr_gtpc_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_req_tx", gtpc_peer_ip="209.165.201.11",instance_id="1",interface_type="S5E",service_name="nodemgr"} 4
nodemgr_gtpc_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_req_tx_initial", gtpc_peer_ip="209.165.200.230",instance_id="1",interface_type="S11",service_name="nodemgr"} 2
nodemgr_gtpc_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_req_tx_initial", gtpc_peer_ip="209.165.201.11",instance_id="1",interface_type="S5E",service_name="nodemgr"} 1
nodemgr_gtpc_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_res_rx", gtpc_peer_ip="209.165.200.230",instance_id="1",interface_type="S11",service_name="nodemgr"} 2
GTPC-EP ポッド

次に、受信したエコー要求メッセージと送信されたエコー応答メッセージの例を示します。

gtpc_echo_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_req_rx", gtpc_peer_ip="209.165.200.230",instance_id="0",service_name="gtpc-ep"} 1
gtpc_echo_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_req_rx", gtpc_peer_ip="209.165.200.231",instance_id="0",service_name="gtpc-ep"} 1
gtpc_echo_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_req_rx", gtpc_peer_ip="209.165.201.11",instance_id="0",service_name="gtpc-ep"} 1
gtpc_echo_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_res_tx", gtpc_peer_ip="209.165.200.230",instance_id="0",service_name="gtpc-ep"} 1
gtpc_echo_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_res_tx", gtpc_peer_ip="209.165.200.231",instance_id="0",service_name="gtpc-ep"} 1
gtpc_echo_msg_stats{app_name="smf",cluster="cn",data_center="cn",gtpc_msg_type="gtpc_echo_res_tx", gtpc_peer_ip="209.165.201.11",instance_id="0",service_name="gtpc-ep"} 1
プロシージャレベル

次に、ハートビート要求、ハートビート応答、およびハートビート要求の再試行の増分値を確認する方法の例を示します。

nodemgr_up_hb_msg_stats{app_name="smf",cluster="Local",current_nodemgr_id="0",data_center="DC", instance_id="0",interface_type="SXA",primary_nodemgr_id="0",service_name="nodemgr",up_ep_key= "209.165.201.1:209.165.201.21",up_msg_type="up_heartbeat_req_retx"} 3
nodemgr_up_hb_msg_stats{app_name="smf",cluster="Local",current_nodemgr_id="0",data_center="DC", instance_id="0",interface_type="SXA",primary_nodemgr_id="0",service_name="nodemgr",up_ep_key= "209.165.201.1:209.165.201.21",up_msg_type="up_heartbeat_req_tx"} 5
nodemgr_up_hb_msg_stats{app_name="smf",cluster="Local",current_nodemgr_id="0",data_center="DC", instance_id="0",interface_type="SXA",primary_nodemgr_id="0",service_name="nodemgr",up_ep_key= "209.165.201.1:209.165.201.21",up_msg_type="up_heartbeat_rsp_rx"} 5

GTPC パス障害

機能説明

GTPC パス障害では、次の場合に S11 および S5 インターフェイスでピアレベルの GTPC パス障害が検出されます。

  • エコー応答に新しい再起動カウンタ値が含まれている場合。

  • エコー要求に新しい再起動カウンタ値が含まれている場合。

  • エコー応答を受信できない場合。

  • Create Session Request または Modify Bearer Request に、新しい再起動カウンタ値が含まれている場合。

  • Create Session Response または Modify Bearer Response に、新しい再起動カウンタ値が含まれている場合。

次の場合、異なるパス障害が原因で接続が切断される可能性があります。

  • s11_path_failure

  • s5e_path-failure

  • s11_path_failure_local_purge

  • s5e_ path_failure_local_purge

  • s5e_recovery

  • s11_recovery

  • s5e_recovery_local_purge

  • s11_recovery_local_purge

機能の仕組み

ここでは、この機能の仕組みを説明します。

GTPC パス障害検出

パス障害は、次の条件で検出されます。

  • エコー障害：ピアがエコー要求や再試行に対して応答しない場合、エコー障害が発生します。

  • エコー応答または制御メッセージでのカウンタの再起動：GTPC エンティティは、エコー応答内、またはピア GTPC メッセージからリカバリ IE を受信すると、受信した再起動カウンタ値を、そのピアエンティティに以前保存されていた再起動カウンタ値と比較し、次の操作を実行します。

    • 以前保存されていた値が使用できない場合、ピアの受信した再起動カウンタ値を保存します。

    • max-remote-rc-change パラメータが設定されていない場合、GTPC が再起動カウンタの変更を検出します。

    • max-remote-rc-change が設定されている場合、再起動カウンタのロールオーバーを考慮して、再起動カウンタ値の差を計算します。新しい再起動カウンタと古い再起動カウンタの差が、max-remote-rc-change の値よりも小さい場合、パス障害が検出されます。


    （注）  

    max-remote-rc-change の詳細については、パス障害検出のカスタマイズを参照してください。

パスの障害の処理

パスの障害を検出すると、ネットワークノードは運用および保守システムを介して障害を通知し、次の処理を実行します。

  • PDN 接続（EPS ベアラーコンテキスト）またはピア IP アドレスを持つ関連する PDP コンテキストを削除します。

  • 選択したインターフェイスに対して次のアクションを指定します。

    • [Local Purge]：cnSGW-C は、ピアに通知せずに、影響を受けるベアラー（またはデフォルトのベアラーがパスの障害を受信した場合は PDN）をクリアします。このアクションは、すべてのインターフェイスに対してデフォルトです。


      （注）  

      cnSGW-C は、パス障害の検出時に Sx セッション削除要求を UPF に送信してセッションをクリアします。

    • [Signal-Peer]：cnSGW-C はピア MME と P-GW に向けて制御信号を送信します。

      信号送信時：

      • PDN の削除の場合、SGW は PGW にセッション削除要求メッセージを送信し、MME にベアラー削除要求（LBI を使用）メッセージを送信します。

      • SGW は、S11 または S5 インターフェイス上で削除要求を送信し、ピアに通知します。


（注）  

ピアが削除されると、エコー要求の交換が停止します。

機能設定

この機能の設定には、次の手順が含まれます。

パス障害検出時のアクションの構成

パス障害検出のアクションを構成するには、次の構成を使用します。

config 
   profile sgw sgw_name 
    path-failure [ s11 | s5e ] [ local-purge | signal-peer ] 
    end

ピアノードを更新する通知の設定

cnSGW-C が再起動するたびに、再起動カウンタを更新する必要があります。この機能を実装する場合は、Ops Center で Kubernetes の use-volume-claims パラメータ値が true に設定されていることを確認します。

この設定により、CLI システムモードがシャットダウンされ、システムモードが実行中の状態で cnSGW-C が再起動すると、再起動カウンタが更新されます。

設定例

次に、パス障害検出の設定例を示します。

config
profile sgw sgw1
 path-failure s11 local-purge
 path-failure s5e local-purge
exit

OAM のサポート

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

バルク統計サポート

次に、GTPC パス障害の例を示します。

nodemgr_gtpc_pathfail_reasons{app_name="smf",cluster="cn", data_center="cn",instance_id="1",pathfail_reason="pathfail_no_echo_rcv", service_name="nodemgr"} 2
nodemgr_gtpc_pathfail_reasons{app_name="smf",cluster="cn",data_center="cn", instance_id="0",pathfail_reason="pathfail_echo_res_rc_change", service_name="nodemgr"} 1

Sx パス障害

機能説明

Sx パス障害では、次の場合に Sx インターフェイスでパス障害が検出されます。

  • ハートビート要求に高い値のリカバリタイムスタンプが含まれている。

  • ハートビート応答に高い値のリカバリタイムスタンプが含まれている。

  • ハートビート応答を受信していない。

  • Sx 関連付け要求を受信した。

  • cnSGW-C は、ピアを解放するための Sx 関連付け更新要求を受信します。

機能の仕組み

ここでは、この機能の仕組みを説明します。

ハートビート要求

cnSGW-C または UPF は、ピアノードへのパスでハートビート要求を送信して、ノードが動作しているかどうかを調べます。ハートビート要求メッセージは、PFCP 制御アソシエーションが確立されている各ピアに送信されます。 cnSGW-C または UPF は、ハートビート要求を受信する準備が整っており、ハートビート応答で応答します。ハートビート要求は、ピアとの新しいセッションが確立されるとピアで開始し、最後のセッションがピアから解放されると停止します。

cnSGW-C と UPF は、構成された間隔に基づいてハートビート要求を送信します。ピアが応答しない場合、メッセージは、再試行間隔内で構成された回数だけ再試行されます。応答を受信すると、対応するピアに関連付けられたコールに対して定義されたアクションが実行されます。

リカバリタイムスタンプは、ピアノードの開始時刻を含む IE です。ハートビート要求には、ピアに送信される自己回復タイムスタンプ値が含まれています。


（注）  

ハートビート要求は、ピアが削除された場合にのみ停止します。

ハートビート応答

ハートビート応答メッセージは、受信したハートビート要求への応答として送信されます。

リカバリタイムスタンプは、ノードの開始時刻を含むIEです。ハートビート応答には、ピアのリカバリタイムスタンプ値が含まれています。

Sx パス障害の検出

Sx パス障害は、次の条件で検出されます。

  • ハートビート障害：ピアが、送信されたハートビートおよび再試行に応答しない場合。

  • ハートビートのリカバリタイムスタンプの変更：ハートビート応答に新しいリカバリタイムスタンプ値がある場合は、以前に受信した値になります。受信したリカバリタイムスタンプの値が以前に受信した値よりも小さい場合、パス障害は検出されません。

  • Sx 関連付けメッセージ：ピアから Sx 関連付けメッセージを再受信した場合。この場合、すべてのコールがクリアされ、通知が eGTP ピアに送信されます。

  • Sx 関連付けリリースメッセージ：Sx 関連付けリリースメッセージを受信した場合。この場合、すべてのコールがクリアされ、通知が eGTP ピアに送信されます。

パスの障害の処理

受信したリカバリタイムスタンプの値が以前に受信した値より大きい場合、ピアの再起動が検出されます。タイムスタンプが以前に受信した値よりも小さい場合、その値は無視され、ピアの再起動は検出されません。

ピアのパス障害を示すピアの再起動が検出されると、そのピアに接続されているすべてのコールがクリアされます。このようなコールで使用される切断理由は、Sx パス障害です。

Sx パス障害が検出されると、Sx 関連付けも削除されます。

ハートビート処理

PFCP エンティティは、（不明なピアからの場合でも）ハートビート要求メッセージを受信するたびに、ハートビート応答メッセージで応答します。

No response to peer エラーが原因のパス障害が検出されると、関連付けが再確立されるまで、そのピアにハートビート要求は送信されません。コールは、パス障害検出ポリシーの設定に基づいてクリアされます。


（注）  

Sx の関連付けが削除された後、Sx パス障害が検出されると、ハートビートが停止します。

OAM のサポート

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

バルク統計サポート

次に、ハートビート要求、ハートビート応答、およびハートビート要求の再試行で増分されるプロシージャレベルの統計情報の例を示します。

nodemgr_up_hb_msg_stats{app_name="smf",cluster="Local",current_nodemgr_id="0", data_center="DC",instance_id="0",interface_type="SXA",primary_nodemgr_id="0",service_name= "nodemgr",up_ep_key="209.165.201.5:209.165.201.28",up_msg_type="up_heartbeat_req_retx"} 3
nodemgr_up_hb_msg_stats{app_name="smf",cluster="Local",current_nodemgr_id="0", data_center="DC",instance_id="0",interface_type="SXA",primary_nodemgr_id="0",service_name= "nodemgr",up_ep_key="209.165.201.5:209.165.201.28",up_msg_type="up_heartbeat_req_tx"} 5
nodemgr_up_hb_msg_stats{app_name="smf",cluster="Local",current_nodemgr_id="0", data_center="DC",instance_id="0",interface_type="SXA",primary_nodemgr_id="0",service_name= "nodemgr",up_ep_key="209.165.201.5:209.165.201.28",up_msg_type="up_heartbeat_rsp_rx"} 5

パス障害検出のカスタマイズ

機能説明

cnSGW-C により、パス障害検出ポリシーを設定できます。デフォルトでは、パス障害検出ポリシーは有効になっています。

  • GTPC パス障害検出のカスタマイズ：GTPC パス障害は、次の場合に検出されます。

    • エコー要求の再試行回数が上限に達した。

    • エコー要求または応答の再起動カウンタが変更された。

    • 制御メッセージ応答の再起動カウンタが変更された。

    • 新しい再起動カウンタと古い再起動カウンタの絶対差が、max-remote-rc-change で設定された値よりも小さい場合。


    （注）  

    GTPC パス障害検出のカスタマイズにより、ユーザーは最大リモート再起動カウンタ（max-remote-rc-change）変更機能を使用して、ピアの誤った再起動を無視できます。

  • Sx パス障害検出のカスタマイズ：PFCP パス障害は、次の場合に検出されます。

    • ハートビート要求の再試行回数が上限に達した。

    • ハートビート要求または応答のリカバリタイムスタンプが変更された。

機能設定

この機能の設定には、次の手順が含まれます。

Sx パス障害のカスタマイズの設定

Sx パス障害のカスタマイズを設定するには、次の設定を使用します。

config 
  policy sx-path-failure-detection policy 
   ignore heartbeat-retry-failure 
   ignore heartbeat-recovery-timestamp-change 
exit 
 instance instance-id instance_id 
   endpoint pfcp 
     replicas replica_count 
     sx-path-failure sx-detection-policy policy 
     interface sxa 
     sx-path-failure sx-detection-policy policy 
     end

GTPC パス障害のカスタマイズの構成

GTPC パス障害のカスタマイズを構成するには、次の構成を使用します。

config 
   policy path-failure-detection policy_name 
     max-remote-rc-change maximum_remote 
     ignore echo-rc-change 
     ignore control-rc-change  
     ignore echo-failure  
   exit 
 exit 
 instance instance-id instance_id 
   endpoint gtp  
     replicas replica_count 
     vip-ip ipv4_address vip-port ipv4_port_number 
     vip-ipv6 ipv6_address vip-ipv6-port ipv6_port_number 
     dual-stack-transport { true | false } 
     path-failure detection-policy policy 
     interface [ s11 | s5e ]  
     end

注：

  • GTPC パス障害検出ポリシーがインターフェイスレベルで構成されていない場合、エンドポイントレベルのパス障害検出ポリシーを適用できます。

  • max-remote-rc-change 構成は、S11 または S5 がピアの再起動を検出するまでのカウンタの変更を指定します。新しい再起動カウンタと古い再起動カウンタの絶対差が構成された値よりも小さい場合にのみ、ピアの再起動が検出されますたとえば、max-remote-rc-change が 10 で、現在のピアの再起動カウンタが 251 の場合は、新しい再起動カウンタが 252 ～ 255 または 0 ～ 5 の場合にのみ、eGTP はピアの再起動を検出します。同様に、保存された再起動カウンタが 1 の場合は、新しい再起動カウンタが 2 ～ 11 の場合にのみ、eGTP はピアの再起動を検出します。

  • 有効な設定値は、1 ～ 255 です。推奨設定値は 32 です。

OAM サポート

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

バルク統計サポート

GTPC パス障害

エコー要求/応答メッセージや、コントロール要求/応答メッセージにおける再起動カウンタの変化によってパス障害が検出された回数を示す統計情報を保持します。

nodemgr_gtpc_msg_stats{app_name="smf",cluster="Local",data_center="DC", gtpc_msg_type="gtpc_false_peer_restart_cfg_ctrl_rc_change",gtpc_peer_ip= "209.165.201.17",instance_id="0",interface_type="S11",service_name="nodemgr"} 1
nodemgr_gtpc_msg_stats{app_name="smf",cluster="Local",data_center="DC", gtpc_msg_type="gtpc_false_peer_restart_cfg_echo_rc_change",gtpc_peer_ip= "209.165.201.17",instance_id="0",interface_type="S11",service_name="nodemgr"} 1
nodemgr_gtpc_msg_stats{app_name="smf",cluster="Local",data_center="DC", gtpc_msg_type="gtpc_false_peer_restart_cfg_echo_rc_change",gtpc_peer_ip= "209.165.201.27",instance_id="0",interface_type="S5E",service_name="nodemgr"} 1
nodemgr_gtpc_msg_stats{app_name="smf",cluster="Local",data_center="DC", gtpc_msg_type="gtpc_ignore_echo_timeout",gtpc_peer_ip="209.165.201.27", instance_id="0",interface_type="S5E",service_name="nodemgr"} 1
nodemgr_gtpc_msg_stats{app_name="smf",cluster="Local",data_center="DC", gtpc_msg_type="gtpc_false_peer_restart_ignore_echo_rc_cfg",gtpc_peer_ip= "209.165.201.27",instance_id="0",interface_type="S5E",service_name="nodemgr"} 1
nodemgr_gtpc_msg_stats{app_name="smf",cluster="Local",data_center="DC", gtpc_msg_type="gtpc_false_peer_restart_ignore_ctrl_rc_cfg",gtpc_peer_ip= "209.165.201.27",instance_id="0",interface_type="S5E",service_name="nodemgr"} 1
表 3. GTPC パス障害の統計情報の説明

統計

説明

gtpc_false_peer_restart_cfg_echo_rc_change

エコー再起動カウンタの変更が設定済みの max-remote-rc-change の範囲内にないために無視された GTPC パス障害の数。

gtpc_false_peer_restart_ignore_echo_rc_cfg

エコー再起動カウンタが変更されたために無視された GTPC パス障害の数。

gtpc_false_peer_restart_cfg_ctrl_rc_change

制御メッセージ再起動カウンタの変更が設定済みの max-remote-rc-change の範囲内にないために無視された GTPC パス障害の数。

gtpc_false_peer_restart_ignore_ctrl_rc_cfg

制御メッセージ再起動カウンタが変更されたために無視された GTPC パス障害の数。

gtpc_ignore_echo_timeout

エコー要求のタイムアウトによって無視された GTPC パス障害の数。
Sx パス障害

次のメッセージで、リカバリタイムスタンプの変化によってパス障害が検出された回数を示す統計情報を保持します。 

nodemgr_up_pathfail_reasons{app_name="smf",cluster="cn",data_center="cn", instance_id="0",service_name="nodemgr",up_pathfail_reason="up_pathfail_ignored_hb_retry"} 1
nodemgr_up_pathfail_reasons{app_name="smf",cluster="cn",data_center="cn", instance_id="1",service_name="nodemgr",up_pathfail_reason="up_pathfail_ignored_hb_rt_change"} 1
nodemgr_up_pathfail_reasons{app_name="smf",cluster="cn",data_center="cn", instance_id="1",service_name="nodemgr",up_pathfail_reason="up_pathfail_reason_association_release"} 1
nodemgr_up_pathfail_reasons{app_name="smf",cluster="cn",data_center="cn", instance_id="1",service_name="nodemgr",up_pathfail_reason="up_pathfail_reason_hb_retry"} 8
nodemgr_up_pathfail_reasons{app_name="smf",cluster="cn",data_center="cn", instance_id="1",service_name="nodemgr",up_pathfail_reason="up_pathfail_reason_hb_rt_change"} 1
表 4. Sx パス障害の統計情報の説明

統計

説明

up_pathfail_ignored_hb_retry

ハートビート要求のタイムアウトによって無視された Sx パス障害の数。

up_pathfail_reason_hb_retry

ハートビート要求のタイムアウトによって検出された Sx パス障害の数。

up_pathfail_ignored_hb_rt_change

ハートビート要求のリカバリタイムスタンプの変更によって無視された Sx パス障害の数。

up_pathfail_reason_hb_rt_change

ハートビート要求のリカバリタイムスタンプの変更によって検出された Sx パス障害の数。

up_pathfail_reason_association_release

Sx の関連付けの解除が原因で検出された Sx パス障害の数。