목차

소개

개요

EGTP 경로 실패의 가능한 원인

필요한 로그

트러블슈팅 명령

시나리오/이유 요약

연결 문제 - 네트워크 연결 문제

카운터 값 변경 다시 시작

거대한 수신 트래픽 요청 - 네트워크 혼잡

솔루션

해결 방법

구성 변경

디버깅 로그

소개

이 문서에서는 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>