S11 KPI降級故障排除
簡介
本檔案將說明如何疑難排解S11主要效能指標(KPI)降低問題。
概觀
S11是連線長期演化(LTE)網路中的行動化管理實體(MME)和服務閘道(SGW)的介面。該介面使用Gn或GPRS隧道協定控制(GTP-C)。
S11介面中的消息
- 建立階段作業要求/回應
- 修改會話請求/響應
- 刪除階段作業要求/回應
EPS會話建立：
- 與其CSR嘗試相比，當您看到更多的「建立階段作業要求(CSR)」拒絕時，會發現S11 KPI降低，這必須是根本原因。
您可以瞭解用於測量KPI的公式，並記下公式中包含的所有計數器，並確定導致效能下降的確切計數器。
S11 ASR (SPGW) = ((tun-sent-cresessrespaccept+ggsn_tun-sent-cresessrespdeniedUserAuthFailed+tun-sent-cresessrespdeniedPrefPdnTypeUnsupported+tun-sent-cresessrespdeniedCtxtNotFound)/EGTPC-ggsn_tun-recv-cresess)*100
PDN Connectivity Success Rate (MME) : ((%esmevent-pdncon-success%) + (%esm-msgtx-pdncon-rej%))*) / (%esmevent-pdncon-attempt%) *100)
註：公式可能會因測量方式而異。
初始級別所需的日誌：
- 描述效能衰退的重要績效指標趨勢。
- 已使用KPI公式。
-
原始批次統計資料計數器和原因代碼趨勢從問題開始計算。
- 在問題期間內，以30分鐘間隔從節點擷取兩個顯示支援詳細資訊(SSD)執行個體。
- 系統日誌的範圍從降級開始之前的兩小時到當前時間。
mon sub/pro traces和logging monitor msid <imsi>。
疑難排解順序
疑難排解順序-
透過分析批次統計資料，評估S11 KPI公式中涉及的每個計數器的重要績效指標趨勢。
-
比較有問題的時間線期間的KPI趨勢和非有問題的時間線。
-
檢查如何根據流量定義辨識出的有問題的批次統計資料計數器，並建立任何模式。
-
以3到5分鐘的間隔透過多次迭代從節點收集斷開原因。
您可以分析在不同時間戳收集的兩個SSD之間的斷開原因差異。顯示增量值顯著增加的斷開原因可以視為KPI降級的原因。有關所有斷開原因的詳細說明，請參閱思科統計資訊和計數器參考手冊，網址：https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-23/Stat-Count-Reference/21-23-show-comman...
show session disconnect-reasons verbose5. 根據節點型別檢查egtp統計資料：
--- SGW end -----
show egtpc statistics interface sgw-ingress path-failure-reasons
show egtpc statistics interface sgw-ingress summary
show egtpc statistics interface sgw-ingress verbose
show egtpc statistics interface sgw-ingress sessmgr-only
show egtpc statistics interface sgw-egress path-failure-reasons
show egtpc statistics interface sgw-egress summary
show egtpc statistics interface sgw-egress verbose
show egtpc statistics interface sgw-egress sessmgr-only
---- PGW end -----
show egtpc statistics interface pgw-ingress path-failure-reasons
show egtpc statistics interface sgw-ingress summary
show egtpc statistics interface sgw-ingress verbose
show egtpc statistics interface sgw-ingress sessmgr-only
--- MME end -----
show egtpc statistics interface mme path-failure-reasons
show egtpc statistics interface mme summary
show egtpc statistics interface mme verbose
show egtpc statistics interface mme sessmgr-only 6.確定導致問題的特定計數器後，必須捕獲mon-sub/mon-pro呼叫跟蹤，以進一步分析和確定導致KPI降低的特定呼叫流。此外，您還可以使用外部工具來獲取Wireshark跟蹤以進行更詳細的分析。
用於捕獲Mon子蹤跡的命令如下：
monitor subscriber with options 19, 26,33, 34, 35, 49,A,S, X, Y, verbosity +5 during the issue.
mon-pro with options 19, 26,33, 34, 35, 49,A,S, X, Y, verbosity +5 during the issue if no mon-sub is present.
More options can be enabled depending on the protocol or call flow we need to capture specifically如果由於KPI降級百分比很小而捕獲跟蹤資料（如mon-sub）不可行，則必須捕獲系統級別的調試日誌。這包括捕獲sessmgr和egptc的調試日誌，並在必要時捕獲網關特定的流。
logging filter active facility sessmgr level debug
logging filter active facility egtpc level debug
logging filter active facility sgw level debug
logging filter active facility pgw level debug
logging active ----------------- to enable
no logging active ------------- to disable
Note :: Debugging logs can increase CPU utilization so need to keep a watch while executing debugging logs7. 分析除錯日誌後，如果您確定問題的原因，則可以繼續捕獲觀察錯誤日誌的特定事件的核心檔案。
logging enable-debug facility sessmgr instance <instance-ID> eventid 11176 line-number 3219 collect-cores 1
For example :: consider we are getting below error log in debug logs which we suspect can be a cause of issue
and we don;t have any call trace
[egtpc 141027 info] [15/0/6045 <sessmgr:93> _handler_func.c:10068] [context: INLAND_PTL_MME01, contextID: 6] [software internal user syslog] [mme-egress] Sending reject response for the message EGTP_MSG_UPDATE_BEARER_REQUEST with cause EGTP_CAUSE_NO_RESOURCES_AVAILABLE to <Host:x.x.x.x, Port:31456, seq_num:82011>
So in this error event
facility :: sessmgr
event ID = 141027
line number = 10068
警告：每當請求收集日誌（如調試日誌、日誌記錄監控器、mon-sub或mon-pro）時，必須確保這些日誌在維護時段內收集。此外，監控這段時間的CPU負載也非常重要。
症狀的分析和鑑定
症狀的分析和鑑定- 首先，檢查SSD在系統中是否檢測到任何頻繁崩潰。
show crash list
- 請驗證是否遇到任何許可證問題。在某些情況下，當服務分組資料網關(SPGW)的許可證過期時，它將不再接受新呼叫，從而導致呼叫失敗並導致S11降級或dip。
show resource info
- 請驗證是否存在由於記憶體或CPU使用率高而處於警告/超時狀態的多個sessmgr例項。如果找到此類例項，請檢查新呼叫是否由於這些條件而被拒絕。
- 從調試日誌中，您可以檢查哪個介面上是否出現呼叫拒絕錯誤。
如果特定使用者在「sgw-egress」上下文中發生大量呼叫拒絕錯誤，然後在「sgw-ingress」上下文中被拒絕的同一使用者，則可以推斷來自資料包資料網關(PGW)的拒絕被傳送到S11上下文中的SGW-> MME。要從PGW端進行進一步確認和故障排除，您現在可以為此IMSI選擇一個mon-sub。
2022-Nov-26+00:20:51.763 [egtpc 141018 unusual] [7/0/16871 <sessmgr:579> _handler_func.c:3227] [context: gwctx, contextID: 2] [software internal user syslog] [sgw-egress] For IMSI: 427021600263284, create session request is rejected by the peer with cause EGTP_CAUSE_NO_RESOURCES_AVAILABLE
2022-Nov-26+00:20:51.763 [egtpc 141018 unusual] [7/0/16871 <sessmgr:579> _handler_func.c:2505] [context: gwctx, contextID: 2] [software internal user syslog] [sgw-ingress] For IMSI: 427021600263284, create session request is rejected by the SAP user with cause EGTPC_REASON_UNKNOWN
- 有時，KPI分佈可能有多個拒絕原因，因此您需要分別檢查每個原因並相應地繼續。
例如，對於漫遊使用者國際移動使用者身份(IMSI)系列可能增加no_resource_available/user_auth_failure，因此需要從PGW檢查這些錯誤。可能存在remote peer not responding等原因，即建立會話請求在SGW超時，這可能導致S11 KPI的效能下降。此建立會話可能因從SGW到MME被拒絕No_resource_available。可以從監控協定日誌中觀察到這些拒絕原因代碼，您可以檢查Create Session Request和Create Session Responses以確定從中傳送這些拒絕原因代碼的特定IP地址。
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
18-Jun-2023 |
初始版本 |
意見