EGTP路徑故障排除

簡介

本文檔介紹如何對EGTP路徑故障問題進行故障排除。

概觀

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

EGTP路徑失敗的可能原因

1. 連通性問題-網路連線問題

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

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

4. 關於DSCP/QOS等的配置問題

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

需要日誌

1. SSD/系統日誌涵蓋問題時間範圍，從問題開始前至少兩小時一直持續到目前時間。

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分析器輸出的解複用卡中收集一些資料包丟棄，如前所述。

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<critical/error/debug>
logging filter active facility egtpmgr level<critical/error/debug>
logging filter active facility egtpinmgr level<critical/error/debug>