はじめに
このドキュメントでは、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の再起動を試すことができます。