内容

はじめに

トラブルシューティングのためのコマンド

分析

StarOSの観点

回避策

はじめに

このドキュメントでは、SGSN/MMEとGGSN/Serving Gateway(GGSN)またはPDN Gateway(SPGW)間の再起動カウンタ値の不一致が原因で発生するEvolved-GPRSトンネリングプロトコル(EGTP)パス障害のトラブルシューティングについて説明します。

トラブルシューティングのためのコマンド

show egtpc peers interface

show egtpc peers path-failure-history

show egtpc statistics path-failure-reasons

show egtp-service all

show egtpc sessions

show egtpc statistics

egtpc test echo gtp-version 2 src-address <source node IP address>  peer-address <remote node IP address>

For more details about this commands refer this mentioned link

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/gateway-gprs-support-node-ggsn/119246-technote-ggsn-00.html

分析

ログと統計情報から、Mobility Management Entity(MME)側のrestartカウンタ値が11、EPG側のrestartカウンタ値が12であることがわかります。

トラップは次のように表示されます。

Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 4,  peer new restart counter 4,  peer session count  240, failure reason no-response-from-peer,  path failure detection Enabled.

Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 54,  peer new restart counter 12,  peer session count  1107240, failure reason restart-counter-change

Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 12,  peer new restart counter 54,  peer session count  1107207, failure reason create-sess-restart-counter-change

再起動カウンタが変更されると、ベンダーゲートウェイ(GW)で、Serving GPRS Support Node(SGSN)からより小さい値を受け取るという問題が発生します。ベンダーGWが大きい値（古い値）を保存していて、ノードのリロード後にCisco SGSNが小さい値を送信すると、ベンダーGWはそれを受け入れません。

注:TS 29.060準拠：

1. SGSNがゲートウェイGPRSサポートノード(GGSN)と初めて通信する場合、または新しい再起動カウンタ値を示さずにGGSNを最近再起動した場合、SGSNはポリシー決定ポイント(PDP)コンテキスト要求の作成にリカバリ情報要素(RIE)を組み込みます。この要素は、必要に応じてSGSNによって組み込まれます。Create PDP Context Requestメッセージ要素のRecovery情報要素を受信するGGSNは、エコー応答メッセージを受信するときと同様に、この要素を処理します。Create PDP Context Requestメッセージは、メッセージに含まれるPDPコンテキストの有効なアクティブ化要求と見なされます。

2. GGSNが初めてSGSNに接続したとき、またはGGSNが最近再起動し、新しい再起動カウンタ値がまだSGSNに示されていない場合、GGSNではRecovery情報要素がPDPコンテキストの作成応答に含まれます。リカバリ情報要素を受信するSGSNは、エコー応答メッセージを受信したときのように処理します。ただし、応答がGGSNでのコンテキストのアクティブ化の成功を示す場合、作成されるPDPコンテキストはアクティブと見なされます。

3. GTPインターフェイスは、再起動カウンタを使用して再起動回数を追跡します。TS 23.060によると、GTPノードはローカルGTP再起動カウンタを追跡するために永続記憶域を使用する必要があります。これにより、これらの再起動カウンタが常に上位に向かって上昇することが予想されます。ただし、ピアノードが再起動カウンタの減少を検出した場合のGTPノードの動作については、TS 23.007のセッション「18 GTP-Cベースの再起動手順」で詳しく説明しています。整数ロールオーバーを考慮して、ピアに対して以前に保存された再起動カウンタの値が、エコー応答メッセージまたはGTP-Cメッセージで受信した再起動カウンタの値よりも大きいと仮定します。その場合、これは競合状態（古いメッセージの前に新しいメッセージが到着する）の可能性を示します。受信した新しい再起動カウンタ値は廃棄され、エラーがログに記録される可能性があります。つまり、GTPノードがピアから低い再起動カウンタを検出しても、その新しい再起動カウンタは記録されません。

StarOSの観点

StarOS側から、アップグレード時に行われたパスからStarOSのRC値を明示的に変更できます(パス/flash/restart_file_cntr.txtの変更)。

この理論によると、現在の設定と比較すると、MME RC値はVendor GW RC値よりも低くなっています。この問題に対処するために、ベンダーのGWノードのRC値が変更されました。

RC値を変更すると、EGTPCパス障害は停止しましたが、セッションは増加せず、EGTPCリンクは引き続き非アクティブを示します。

トラブルシューティング時に使用したコマンドは次のとおりです。

show sgtp-service all | grep "restart"  ----------------- to check RC value

[local]Nodename# show egtp-service all | more

Service name                          : egtpc_sv_service

Service-Id                            : 5

Context                               : SGs

Interface Type                        : mme

Status                                : STARTED

Restart Counter                       : 11   ----------------- RC value to verify

Max Remote Restart Counter Change     : 255

Message Validation Mode               : Standard

GTPU-Context                          :

GTPC Retransmission Timeout           : 5000 (milliseconds)

GTPC Maximum Request Retransmissions  : 4

GTPC IP QOS DSCP value                : 10

GTPC Echo                             : Enabled

GTPC Echo Mode                        : Default

[local]Nodename# show egtpc peers           ------------ To check link status

Sunday February 05 15:31:00 IST 2023

+----Status:                 (I) - Inactive  (A) - Active

|

|+---GTPC Echo:              (D) - Disabled  (E) - Enabled

||

||+--Restart Counter Sent:   (S) - Sent      (N) - Not Sent

|||

|||+-Peer Restart Counter:   (K) - Known     (U) - Unknown

||||

||||+-Type of Node:          (S) - SGW       (P) - PGW

|||||                        (M) - MME       (G) - SGSN

|||||                        (L) - LGW       (E) - ePDG

|||||                        (C) - CGW       (B) - MBMS

|||||                        (U) - Unknown

|||||

|||||  Service                       Restart--------+  No. of

|||||  ID                            Counter        |  restarts

|||||   |                                           |   |   Current       Max

vvvvv   v              Peer Address                 v   v   sessions    sessions  LCI OCI

-----  --- --------------------------------------- --- --- ----------- ------------------

IDSKS  10                           X.X.X.X         91   0           0           0   X   X

IDNKS  11                           Y.Y.Y.Y          4  95           0       34005   X   X

IDNKS  11                           Z.Z.Z.Z         10 103           0       16805   X   X

IDNKS  11                           A.A.A.A        104  95           0        7250   X   X

AESKS  11                           B.B.B.B          0   0        4004       47649   X   X

AESKS  11                           C.C.C.C          0   0        4053       46571   X   X

AESKS  11                           D.D.D.D          0   0        4026       46734   X   X

ABove output peers if you see no sessions on this peer and also link are inactive

さらに、エコー要求/応答をチェックします（隠しモードでチェックされます）。

egtpc test echo gtp-version 2 src-address <MME end IP> peer-address <EPG end IP>

これは、Restart Counterの値を修正し、影響を受けるEGTPピアのS11インターフェイスのMMEと同じ値に設定した場合、エコー要求/応答は正常ですが、リンクが非アクティブなままの出力です。

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>

Sunday February 05 16:22:42 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                          Tx/Rx:  1/1  RTT(ms): 1    (COMPLETE) Recovery: 10 (0x0A)

ただし、問題のある他の影響を受けるGWでは想定どおりに動作しません。ここで説明したエコー要求/応答の失敗が引き続き表示されます。

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>

Sunday February 05 16:46:11 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                         Tx/Rx:  1/0  RTT(ms): 0    (FAILURE)

回避策

1. この問題を修正するには、VNFの非アクティブ化の前に、/flash/restart_file_cntr.txtの現在の再起動カウンタをメモします。その後、新しいソフトウェアでアクティブになったときにCFにログインし、古い再起動カウンタでファイル/flash/restart_file_cntr.txtを更新します。次に、通常のアップグレード手順として、Day-N設定でVNFをリロードします。

2. cat/flash/restart_file_cntr.txtを必要な値に変更し、現在の設定でノードをリロードします。

注：最初の手順と同様に、SGTPCの再起動を試すことができます。