EGTP路徑故障排除

簡介

本文說明如何排除EGTP路徑故障問題。

概觀

演化的GPRS隧道協定(EGTP)路徑故障是指行動網路中GTP節點之間的通訊路徑問題。GTP是一種協定，用於在不同網元之間傳輸使用者資料和信令消息。

EGTP路徑失敗的可能原因

1.可達性問題 — 網路連線問題

2.重新啟動計數器值更改

3.巨大的傳入流量請求 — 網路擁塞

4、DSCP/QOS等配置問題

5. EGTPC鏈路上沒有訂戶/會話

需要日誌

1. SSD/syslogs涵蓋問題時間範圍，在問題開始前至少兩小時到當前時間。

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。如果觀察到一個節點的路徑故障，入站流量可能會增加。而且，您可能會遇到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.減少對等體救贖超時 — 超時值越小，非活動對等體的數量就越少，因此，您可以使用以下命令更改時間值：

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