解決由於重新啟動計數器值不匹配而導致的EGTP路徑故障

簡介

本檔案介紹由於SGSN/MME和GGSN/服務閘道或PDN閘道(SPGW)之間的重新啟動計數器值不匹配而觀察到的進化GPRS通道通訊協定(EGTP)路徑故障的疑難排解。

疑難排解指令

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 about this commands refer this mentioned link

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/gateway-gprs-support-node-ggsn/119246-technote-ggsn-00.html

分析

從日誌和統計資訊可識別出移動性管理實體(MME)端的重新啟動計數器值為11,EPG端的重新啟動計數器值為12。

您可以觀察此處提到的陷阱：

Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 4,  peer new restart counter 4,  peer session count  240, failure reason no-response-from-peer,  path failure detection Enabled.
Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 54,  peer new restart counter 12,  peer session count  1107240, failure reason restart-counter-change
Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 12,  peer new restart counter 54,  peer session count  1107207, failure reason create-sess-restart-counter-change

如果重新啟動計數器已更改，則供應商網關(GW)無法接受服務GPRS支援節點(SGSN)中的較小值。如果供應商GW儲存了更高的值（舊值），並且如果Cisco SGSN傳送較小的值，則在節點重新載入之後，供應商GW不會接受該值。

註：根據TS 29.060:

1.如果SGSN首次與網關GPRS支援節點(GGSN)聯絡，或者最近在沒有向GGSN指示新的重新啟動計數器值的情況下重新啟動，則它將恢復資訊元素併入建立策略決策點(PDP)上下文請求中。SGSN會在必要時包括此元素。在建立PDP上下文請求消息元素中接收恢復資訊元素的GGSN在接收回應響應消息時處理恢復資訊元素。建立PDP上下文請求消息被視為包含在該消息中的PDP上下文的有效啟用請求。

2.如果GGSN首次與SGSN聯絡，或者GGSN最近重新啟動且尚未向SGSN指示新的重新啟動計數器值，則GGSN會將恢復資訊元素包含到「建立PDP上下文響應」中。接收Recovery資訊元素的SGSN會像接收到Echo Response消息時一樣處理它。但是，如果響應指示在GGSN上成功啟用上下文，則它認為正在建立的PDP上下文是活動的。

3. GTP介面使用重新啟動計數器來跟蹤重新啟動次數。根據TS 23.060,GTP節點必須使用持久儲存以跟蹤其本地GTP重新啟動計數器，因此希望這些重新啟動計數器始終向上運行。然而，當對等節點檢測到重啟計數器的減少時，GTP節點的行為在TS 23.007的會話「18 GTP-C的重啟過程」中詳述。假設先前為對等體儲存的重新啟動計數器的值大於在Echo Response消息或GTP-C消息中接收的重新啟動計數器的值，同時考慮整數滾動更新。在這種情況下，這表示可能存在競爭條件（較新的消息在較舊的消息之前到達）。接收的新Restart計數器值將被丟棄，並且可能會記錄錯誤。換句話說，當GTP節點檢測到來自對等體的較低重啟計數器時，它永遠不會記錄該新的重啟計數器。

StarOS視角

從StarOS端，您可以顯式更改StarOS中的RC值（從路徑） /flash/restart_file_cntr.txt 升級時完成。

根據這個理論，當與當前的配置進行比較時，MME RC值低於供應商GW RC值。為了解決此問題，修改了供應商GW節點的RC值。

現在更改RC值後，可以看到EGTPC路徑故障已停止，但會話並未增加，而且EGTPC連結仍顯示為非活動狀態。

以下是進行疑難排解期間使用的指令：

show sgtp-service all | grep "restart"  ----------------- to check RC value

[local]Nodename# show egtp-service all | more
  Service name                          : egtpc_sv_service
  Service-Id                            : 5
  Context                               : SGs
  Interface Type                        : mme
  Status                                : STARTED
  Restart Counter                       : 11   ----------------- RC value to verify
  Max Remote Restart Counter Change     : 255
  Message Validation Mode               : Standard
  GTPU-Context                          :
  GTPC Retransmission Timeout           : 5000 (milliseconds)
  GTPC Maximum Request Retransmissions  : 4
  GTPC IP QOS DSCP value                : 10
  GTPC Echo                             : Enabled
  GTPC Echo Mode                        : Default


[local]Nodename# show egtpc peers           ------------ To check link status
Sunday February 05 15:31:00 IST 2023
+----Status:                 (I) - Inactive  (A) - Active                        
|                                                                                
|+---GTPC Echo:              (D) - Disabled  (E) - Enabled                       
||                                                                               
||+--Restart Counter Sent:   (S) - Sent      (N) - Not Sent                      
|||                                                                              
|||+-Peer Restart Counter:   (K) - Known     (U) - Unknown                       
||||                                                                             
||||+-Type of Node:          (S) - SGW       (P) - PGW                           
|||||                        (M) - MME       (G) - SGSN                          
|||||                        (L) - LGW       (E) - ePDG                          
|||||                        (C) - CGW       (B) - MBMS                          
|||||                        (U) - Unknown                                       
|||||                                                                            
|||||  Service                       Restart--------+  No. of                    
|||||  ID                            Counter        |  restarts                  
|||||   |                                           |   |   Current       Max    
vvvvv   v              Peer Address                 v   v   sessions    sessions  LCI OCI
-----  --- --------------------------------------- --- --- ----------- ------------------
IDSKS  10                           X.X.X.X         91   0           0           0   X   X
IDNKS  11                           Y.Y.Y.Y          4  95           0       34005   X   X
IDNKS  11                           Z.Z.Z.Z         10 103           0       16805   X   X
IDNKS  11                           A.A.A.A        104  95           0        7250   X   X
AESKS  11                           B.B.B.B          0   0        4004       47649   X   X
AESKS  11                           C.C.C.C          0   0        4053       46571   X   X
AESKS  11                           D.D.D.D          0   0        4026       46734   X   X

ABove output peers if you see no sessions on this peer and also link are inactive

此外，檢查回應請求/響應（要在隱藏模式下檢查）：

egtpc test echo gtp-version 2 src-address <MME end IP> peer-address <EPG end IP> 

這是如下輸出結果：Restart Counter（重新啟動計數器）的值被更正，並且配置與受影響的EGTP對等體的S11介面的MME的值相同，因此Echo請求/響應正常，但鏈路仍然處於非活動狀態。

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>

Sunday February 05 16:22:42 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                          Tx/Rx:  1/1  RTT(ms): 1    (COMPLETE) Recovery: 10 (0x0A)

但是，對於其他有問題的受影響的GW而言，這並不能像預期的那樣發揮作用。您仍然會收到此處所述的回應要求或回應的失敗。

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>




Sunday February 05 16:46:11 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                         Tx/Rx:  1/0  RTT(ms): 0    (FAILURE)

因應措施

1.要解決此問題，請注意中的 /flash/restart_file_cntr.txt 在VNF停用之前。稍後，當使用新軟體啟用該檔案時，請登入到CF並更新該檔案 /flash/restart_file_cntr.txt 使用舊重啟計數器。然後，作為正常的升級過程，使用第N天配置重新載入VNF。

2.修改貓 /flash/restart_file_cntr.txt 恢復為所需值，並使用當前配置重新載入節點。

注意：您可以嘗試將SGTPC重新啟動一次作為初始步驟。