소개
이 문서에서는 SGSN/MME와 GGSN/Serving Gateway 또는 SPGW(PDN Gateway) 간의 재시작 카운터 값이 일치하지 않아 관찰되는 EGTP(Evolved-GPRS Tunneling Protocol) 경로 장애의 트러블슈팅에 대해 설명합니다.
트러블슈팅 명령
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(Mobility Management Entity) 측의 재시작 카운터 값은 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(Vendor Gateway)에서 재시작 카운터가 변경된 경우 SGSN(Serving GPRS Support Node)에서 더 작은 값을 허용하는 데 문제가 있습니다. 벤더 GW가 더 높은 값(이전 값)을 저장했고 노드 다시 로드 후 Cisco SGSN이 더 낮은 값을 전송하면 벤더 GW는 이를 수락하지 않습니다.
참고: TS 29.060에 따라
1. SGSN이 GGSN(Gateway GPRS Support Node)에 처음으로 연결되거나 GGSN에 새 재시작 카운터 값을 표시하지 않고 최근에 재시작된 경우 PDP(Create Policy Decision Point) 상황 요청에 복구 정보 요소를 통합합니다. 이 요소는 필요한 경우 SGSN에 포함됩니다. PDP 상황 요청 생성 메시지 요소의 복구 정보 요소를 수신하는 GGSN은 에코 응답 메시지를 수신할 때와 마찬가지로 이를 처리합니다. PDP 컨텍스트 생성 요청 메시지는 메시지에 포함된 PDP 컨텍스트에 대한 유효한 활성화 요청으로 간주된다.
2. GGSN이 SGSN과 처음으로 접촉하고 있거나 GGSN이 최근에 다시 시작되었고 새 재시작 카운터 값이 아직 SGSN에 표시되지 않은 경우 GGSN은 복구 정보 요소를 PDP 상황 생성 응답에 포함합니다. 복구 정보 요소를 수신하는 SGSN은 에코 응답 메시지를 수신할 때 이를 처리합니다. 그러나 응답이 GGSN에서 성공적인 컨텍스트 활성화를 나타내는 경우 PDP 컨텍스트가 생성되는 것으로 간주합니다.
3. GTP 인터페이스는 재시작 횟수를 추적하기 위해 재시작 카운터를 사용합니다. TS 23.060에 따르면 GTP 노드는 로컬 GTP 재시작 카운터를 추적하기 위해 영구 스토리지를 사용해야 하므로 이러한 재시작 카운터가 항상 위로 진행되어야 합니다. 그러나 피어 노드가 재시작 카운터의 감소를 감지하는 경우 TS 23.007의 '18 GTP-C 기반 재시작 절차' 세션에서 GTP 노드 동작이 정교해집니다. 피어에 대해 이전에 저장된 재시작 카운터의 값이 정수 롤오버를 고려하여 에코 응답 메시지 또는 GTP-C 메시지에서 받은 재시작 카운터 값보다 크다고 가정합니다. 이 경우 가능한 경쟁 조건(이전 메시지보다 먼저 도착하는 최신 메시지)을 나타냅니다. 수신한 새 다시 시작 카운터 값이 무시되고 오류가 기록될 수 있습니다. 다시 말해, GTP 노드는 피어로부터 더 낮은 재시작 카운터를 탐지하면 해당 새 재시작 카운터를 기록하지 않습니다.
StarOS 관점
StarOS 끝에서는 업그레이드 시에 수행된 경로에서 StarOS/flash/restart_file_cntr.txt의 RC 값을 명시적으로 변경할 수 있습니다.
이 이론에 따르면 현재 구성과 비교하였을 때 MME RC 값은 Vendor GW RC 값보다 낮았다. 이 문제를 해결하기 위해 Vendor 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. 이 문제를 해결하려면 VNF가 비활성화되기 전에 현재/flash/restart_file_cntr.txt 재시작 카운터를 메모하십시오. 나중에 새 소프트웨어로 활성화되면 CF에 로그인하고 기존 재시작 카운터로 파일/flash/restart_file_cntr.txt을 업데이트합니다. 그런 다음 일반적인 업그레이드 절차로서 day-N 컨피그레이션으로 VNF를 다시 로드합니다.
2. cat/flash/restart_file_cntr.txt를 필요한 값으로 수정하고 노드를 현재 구성으로 다시 로드합니다.
참고: SGTPC를 다시 시작할 수도 있고, 초기 단계도 한 번 시도할 수도 있습니다.