EGTPパス障害のトラブルシューティング

はじめに

このドキュメントでは、EGTPパス障害の問題をトラブルシューティングする方法について説明します。

概要

Evolved GPRS Tunneling Protocol(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パスは、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

構成変更

DSCP/QOS/EGTP IPパス/サービスマッピングの設定を確認できます。

デバッグログ

（必要な場合）

logging filter active facility egtpc level
    
    
      logging filter active facility egtpmgr level 
     
       logging filter active facility egtpinmgr level