解决由于重新启动计数器值不匹配而导致的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存储了较高的值（旧值），并且在节点重新加载后，如果思科SGSN发送较小的值，则供应商GW不接受它。

注意：根据TS 29.060：

1. 如果SGSN首次与网关GPRS支持节点(GGSN)联系或最近重新启动，但未向GGSN指示新的重新启动计数器值，则会在创建策略决策点(PDP)情景请求中纳入恢复信息元素。SGSN会在必要时包括此元素。接收创建PDP环境请求消息元素中的恢复信息元素的GGSN会像接收回声响应消息时一样处理该元素。创建PDP环境请求消息被视为对消息中包含的PDP环境的有效激活请求。

2. 如果GGSN首次与SGSN联系，或者GGSN最近重新启动并且新的重新启动计数器值尚未指定给SGSN，则GGSN会在创建PDP环境响应中包含恢复信息元素。接收恢复信息元素的SGSN会像接收回声响应消息时一样处理该信息。但是，如果响应指示在GGSN成功激活环境，则它将创建的PDP环境视为活动状态。

3. GTP接口使用重新启动计数器来跟踪重新启动次数。根据TS 23.060，GTP节点必须使用永久存储以跟踪其本地GTP重启计数器，因此希望这些重启计数器始终向上执行。然而，当对等节点检测到重新启动计数器的减少时，GTP节点的行为在TS 23.007的会话“18 GTP-C based restart procedures”中详述。假设先前为对等体存储的重新启动计数器的值大于在Echo Response消息或GTP-C消息中收到的重新启动计数器的值，并将整数滚动更新考虑在内。在这种情况下，这表示可能存在争用条件（较新的消息在较旧的消息之前到达）。收到的新Restart计数器值将被丢弃并记录错误。换句话说，当GTP节点检测到来自对等体的较低重启计数器时，它绝不会记录该新重启计数器。

StarOS视角

从StarOS端，您可以从升级时完成的路径/flash/restart_file_cntr.txt显式更改StarOS中的RC值。

根据这一理论，当将其与当前配置进行比较时，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)

但是，这在其他有问题的受影响网关上无法按预期运行。您仍然会遇到此处所述的回应请求/响应故障。

[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. 要解决此问题，请在VNF停用之前注意/flash/restart_file_cntr.txt中的当前重新启动计数器。稍后，使用新软件激活时，登录CF并使用旧重启计数器更新文件/flash/restart_file_cntr.txt。然后，作为正常的升级过程，使用day-N配置重新加载VNF。

2. 将cat/flash/restart_file_cntr.txt修改为所需值，并使用当前配置重新加载节点。

注意：您可以尝试将SGTPC重新启动一次作为初始步骤。