EGTPパス障害のトラブルシューティング
はじめに
このドキュメントでは、EGTPパス障害の問題をトラブルシューティングする方法について説明します。
概要
Evolved GPRSトンネリングプロトコル(EGTP)パスの障害は、モバイルネットワーク内のGTPノード間の通信パスに関する問題です。GTPは、異なるネットワーク要素間でのユーザデータやシグナリングメッセージの転送に使用されるプロトコルです。
EGTPパス障害の考えられる原因
1. 到達可能性の問題 – ネットワーク接続の問題
2. カウンタ値の変更を再開します
3. 大量の着信トラフィック要求 – ネットワーク輻輳
4. DSCP/QOSなどの設定の問題
5. EGTPCリンク上にサブスクライバ/セッションがない
必要なログ
1. SSD/syslogは、問題が発生する少なくとも2時間前から現在までの時間に関する問題があります。
2. パス障害が発生しているパスに対するpingおよびtracerouteなどのログを使用した、到達可能性の確認。
3. 問題のあるノードと問題のないノード間の設定チェック
4. 同じパスでトラフィックが突然増加したり、拒否が増加したりするかどうかを確認する必要があります。
5. 問題が発生する期間は、少なくとも問題が発生する2 ～ 3日前の期間を対象とするバルクステータス
注：問題のタイプによっては、前述のログが必要になる場合があります。すべてのログが毎回必要になるわけではありません。
トラブルシューティングのためのコマンド
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 related to above command refer doc as mentioned below
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/gateway-gprs-support-node-ggsn/119246-technote-ggsn-00.html
SNMP トラップ:
Sun Feb 05 03:00:20 2023 Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address x.x.x.x., peer address 10.0.219.57, peer old restart counter 4, peer new restart counter 4, peer session count 240, failure reason no-response-from-peer, path failure detection Enabled
Tue Jul 09 18:41:36 2019 Internal trap notification 1112 (EGTPCPathFail) context pgw, service s5-s8-sgw-egtp, interface type sgw-egress, self address x.x.x.x, peer address x.x.x.x, peer old restart counter 27, peer new restart counter 27, peer session count 1, failure reason no-response-from-peer, path failure detection Enabled
シナリオ/理由の概要
到達可能性の問題：ネットワーク接続の問題
到達可能性の問題は、ルートパスの問題がSGSN/MMEとSPGW/GGSNの間のルータエンドまたはファイアウォールにある場合に発生します。
ping <destination IP>
traceroute <destination IP> src <source IP>
注：到達可能性を確認するコマンドは、EGTPサービスが実行されているコンテンツから両方とも確認する必要があります。
再起動カウンタ値の変更
EGTPパスは、SGSN/MMEとGGSN/SPGW間のパスの両端で再起動カウンタを維持します。
このタイプの問題の詳細については、『https://www.cisco.com/c/en/us/support/docs/wireless/asr-5000-series/200026-ASR-5000-Series-Troubleshooting-GTPC-and.html』リンクを参照してください。
大量の着信トラフィック要求 – ネットワークの輻輳
トラフィック量が急増する突然のトランザクションでは、必ずEGTP TxおよびRxパケットがドロップする可能性があります。このシナリオを確認するための基本的なチェック：
1. egtpinmgrのCPU使用率が高いかどうかを確認する必要があります。
Mar 25 14:30:48 10.224.240.132 evlogd: [local-60sec48.142] [resmgr 14907 debug] [6/0/10088 <rmmgr:60> _resource_log.c:1391] [software internal system critical-info syslog] RM-60: rmmgr_collect_cpustats_coproc_done: ahm cpustats logged for egtpinmgr instance 2 in cpu warn state file <cpustats-5e7b40db-06-00-egtpinmgr-2-6192>
Mar 25 14:31:05 10.224.240.132 evlogd: [local-60sec5.707] [resmgr 14907 debug] [6/0/10088 <rmmgr:60> _resource_log.c:1391] [software internal system critical-info syslog] RM-60: rmmgr_collect_cpustats_coproc_done: ahm cpustats logged for egtpinmgr instance 2 in cpu warn state file <cpustats-5e7b40f9-06-00-egtpinmgr-2-6192>
2. エコー要求/応答が失敗しているかどうかを確認します（以前にコマンドを共有）。
3. demuxカードからパケットドロップがないかどうかを確認できること。
すべてのEGTP着信トラフィックは、同じegtpmgrを通過する必要があります。1つのノードでパス障害が発生した場合、着信トラフィックの量はおそらく増加します。また、egtpmgrプロセスレベルでトラフィックドロップが発生する可能性があります。同じ場所に配置されたプロセスでも、同じegtpmgrキューを経由して処理を進め、影響を受ける必要があります。
複数の反復で実行する必要があるパケット損失を確認する手順を次に示します
debug shell card <> cpu 0
cat /proc/net/boxer
******** card1-cpu0 /proc/net/boxer *******
Wednesday March 25 17:34:54 AST 2020
what total_used next refills hungry exhausted system_rate_kbps system_credits max_bhn
bdp_rld 4167990936249KB 094 51064441 292 1 3557021/65000000 7825602KB/7934570KB 793457KB
what bhn local remote ver rx rx_drop tx tx_drop no_dest no_src
total cpu 34 * * * * 3274522 59 60 0 1307242 0
total cpu 35 * * * * 6330639 46 121 0 1086591 0
total cpu 46 * * * * 5076520 27 15524 0 786982 0
total cpu 47 * * * * 4163101019 83922 133540922 0 886241 0
4. egtpinmgrのCPU使用率が高くなっている場合は、egtpinmgr CPUプロファイラの出力をキャプチャする必要があります。
上記のすべての条件が有効な場合は、上記の考えられる解決策を確認できます。
解決方法
1. EGTPエコータイムアウトの増加：5秒で解決しない場合は、15または25を試すことができます。これを調整するために、ASチームと話し合うことができます。
2. peer-savation timeoutを減らす：タイムアウト値が小さいほど、非アクティブなピアの数は少なくなるため、次のコマンドで時間値を変更できます。
gtpc peer-salvation min-peers 2000 timeout 24
3. 過負荷保護：過負荷保護の最適化は、egpinmgrが問題に遭遇する前に正確な着信トラフィックレートを知らなければ調整が困難なため、トラフィックの傾向に基づいて実行できます。また、誤った調整を行うと、サイレントドロップが原因で追加のシグナリングトラフィックが発生する可能性があります。
そのため、過負荷保護の最適化のために、前述のようにegtpinmgrとCPUプロファイラの出力に対してdemuxカードからパケットドロップを収集できます。
4. EGTPCリンク上にサブスクライバ/セッションがない：特定のトンネル上にセッションがない場合、GTPエコー機能は停止します。接続された加入者がゼロまたは存在しない場合、GTPCエコーは送信されません。
エコー機能が停止したときに表示されるエラーを次に示します。
2019-Jul-26+08:41:51.261 [egtpmgr 143047 debug] [1/0/4626 <egtpinmgr:2> egtpmgr_pm.c:798] [context: EPC, contextID: 2] [software internal system syslog] service : S5-S8-PGW - GTP-C Periodic ECHO timer stopped for peer address 10.2.1.51
2019-Jul-26+08:41:51.261 [egtpmgr 143048 debug] [1/0/4626 <egtpinmgr:2> egtpmgr_pm.c:818] [context: EPC, contextID: 2] [software internal system syslog] service : S5-S8-PGW - GTP-C ECHO stopped towards peer 10.2.1.51
回避策
回復するには、egtpinmgrタスクを再起動します。ただし、egtpinmgrを再起動すると、NPUフローが新しいタスクで再インストールされる間、エンドユーザが短期的な影響を受ける可能性があり、気付かないこともあります。
この操作の完了には1秒未満かかります。
1. パス障害検出を無効にします。
egtp-service S5-PGW
no gtpc path-failure detection-policy
2. egtpinmgrタスクを強制終了します。
task kill facility egtpinmgr all
3. パス障害検出を有効にします。
egtp-service S5-PGW
gtpc path-failure detection-policy
注：この回避策は、影響を与える可能性があるため、MWでのみ実装する必要があります。
構成変更
DSCP/QOS/EGTP IPパス/サービスマッピングの設定を確認できます。
注：これらはEGTPパス障害の主な原因ですが、いずれのシナリオも見つからない場合は、さらにトレースとデバッグログを収集できます。
ログのデバッグ
（必要な場合）
logging filter active facility egtpc level<critical/error/debug>
logging filter active facility egtpmgr level<critical/error/debug>
logging filter active facility egtpinmgr level<critical/error/debug>更新履歴
| 改定 | 発行日 | コメント |
|---|---|---|
1.0 |
04-Dec-2023 |
初版 |
フィードバック