소개
이 문서에서는 EGTP 경로 오류 문제를 해결하는 방법에 대해 설명합니다.
개요
EGTP(Evolved GPRS Tunneling Protocol) 경로 장애는 모바일 네트워크의 GTP 노드 간 통신 경로 문제를 나타냅니다. GTP는 서로 다른 네트워크 요소 간의 사용자 데이터 및 신호 메시지 전송에 사용되는 프로토콜입니다.
EGTP 경로 실패의 가능한 원인
1. 연결성 문제 - 네트워크 연결 문제
2. 카운터 값 변경 사항 다시 시작
3. 대규모 수신 트래픽 요청 - 네트워크 혼잡
4. DSCP/QOS 등의 구성 문제
5. EGTPC 링크에 가입자/세션이 없습니다.
필요한 로그
1. 문제가 발생하기 최소 2시간 전에 문제가 발생한 시간대를 포함하여 현재 시간까지 SSD/syslog를 실행합니다.
2. 로그로 연결성 확인, 즉 경로 장애가 발생한 경로에 대한 ping 및 traceroute
3. 문제가 있는 노드와 문제가 없는 노드 간의 구성 확인
4. 동일 선로에서 트래픽이 급증하거나 거부가 증가하는지 확인할 필요가 있을 것
5. 문제 발생 최소 2-3일 전 기간을 포함하여 문제가 발생한 시간 동안의 Bulkstats
참고: 문제의 유형에 따라 앞에서 언급한 로그가 필요할 수 있습니다. 모든 로그가 매번 필요한 것은 아닙니다.
트러블슈팅 명령
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 서비스가 실행 중인 콘텐츠에서 확인해야 합니다.
카운터 값 변경 다시 시작
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
참고: 이 해결 방법은 일부 영향을 미칠 수 있으므로 MW에서만 구현해야 합니다.
구성 변경
DSCP/QOS/EGTP IP 경로/서비스 매핑 관련 컨피그레이션을 확인할 수 있습니다.
참고: 이는 EGTP 경로 실패의 주요 원인이지만, 어떤 시나리오도 발견되지 않는 경우 일부 추적 및 디버깅 로그를 추가로 수집할 수 있습니다.
디버깅 로그
(필요한 경우)
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>