Fehlerbehebung bei der Beeinträchtigung der Erfolgsrate beim erstmaligen Anhängen in ePDG

Einleitung

In diesem Dokument werden die Probleme im Zusammenhang mit der ASR-Verschlechterung (Initial Attach Success Rate) im ePDG (Evolved Packet Data Gateway) beschrieben.

Überblick

Die anfängliche ASR ist eine wichtige Kennzahl, die die Erfolgsrate der Gesamtzahl der Sitzungseinrichtungsversuche angibt.

Die Formel für die Key Performance Indication (KPI) enthält die Gesamtzahl der ePDG-Sitzungseinrichtungsversuche und die Gesamtzahl der erfolgreichen ePDG-Sitzungseinrichtungsversuche. Wenn die Anzahl der erfolgreichen Versuche abnimmt, wird der gesamte KPI herabgesetzt.

Grundvoraussetzungen

Für die ePDG-Funktionalität ist Internet Protocol Security (IPsec) der Prozess, der IPsec-Transaktionen übernimmt. Bei ePDG-Fällen müssen einige der Vorprüfungen befolgt werden, bevor Sie mit der Fehlerbehebung fortfahren.

1. Überprüfen Sie den Status der DPC-Karte, wie ipsecmgr auf diesen Karten ausgeführt wird. DPC-Karten müssen in einem aktiven Zustand sein (mit Ausnahme von Standby-Karten).

show card table

2. Überprüfen Sie den Status der Ressourcen für jedes ähnliche Gerät, sessmgr/ipsecmgr  um festzustellen, ob bezüglich der Anzahl der Sitzungen pro Karte ein abnormales Muster sessmgr/ipsecmgr  des Datenverkehrsflusses festgestellt wurde oder ob sich diese Prozesse im Warn-/Überlastungszustand befinden. In dieser Ausgabe ipsecmgr ist z. B. der hier gezeigte Zustand "over ist" zu sehen.

[local]abc# show task resources | grep -v good Thursday January 19 19:41:15 UTC 2023 task cputime memory files sessions cpu facility inst used allc used alloc used allc used allc S status ----------------------- ----------- ------------- --------- ------------- ------ 3/0 ipsecmgr 261 0.28% 75% 383.4M 300.0M 196 1500 30 6000 - over 3/0 ipsecmgr 262 0.23% 75% 378.0M 300.0M 185 1500 28 6000 - over 3/0 ipsecmgr 263 0.46% 75% 382.7M 300.0M 197 1500 30 6000 - over 3/0 ipsecmgr 264 0.22% 75% 383.7M 300.0M 212 1500 27 6000 - over ....

Hier ist ein Beispiel für sessmgrs eine ungleichmäßige Sitzungsverteilung beim Laufen auf den Karten 4 und 5:

[local]xyx# show task resources max | grep -i sess Monday February 17 21:52:38 UTC 2023 task cputime memory files sessions 4/0 sessmgr 45 12% 100% 429.9M 2.00G 129 500 4260 26000 I good 4/0 sessmgr 48 12% 100% 428.8M 2.00G 129 500 4267 26000 I good 4/0 sessmgr 49 12% 100% 428.5M 2.00G 129 500 4274 26000 I good 4/0 sessmgr 52 12% 100% 428.3M 2.00G 129 500 4258 26000 I good 5/0 sessmgr 5002 2.34% 50% 87.46M 190.0M 89 500 -- -- S good 5/0 sessmgr 2 12% 100% 458.5M 2.00G 107 500 9279 26000 I good 5/0 sessmgr 3 13% 100% 459.9M 2.00G 106 500 9281 26000 I good

3. Überprüfen Sie die Kryptografiestatistik, wenn auf der IPsec-Ebene ein Absturz auftritt:

show crypto managers detail     ----------------- this command shows statistics per ipsec so we can check if any drops
show crypto statistics ikev2    ----------------- this command shows overall ikev2 statistics for EPDGs for different msg flows

Hinweis: Vorprüfungen sind wichtig, da manchmal Probleme auf Kartenebene auftreten, wenn der IPsec/sessmgr einer bestimmten Karte Benutzersitzungen/Datenverkehr nicht aufnehmen kann und Sie in den oben genannten Statistiken eindeutig Tropfen auf der IPsec-Ebene sehen können.

Erforderliche Protokolle


Es gibt nur wenige Punkte, die Sie zur besseren Behebung des Problems beachten sollten:

• Seit dem Zeitpunkt, an dem das Problem erkannt wurde (unter Angabe des genauen Datums und der genauen Uhrzeit des Beginns der Ausgabe)
• Wurden Änderungen am Netzwerk oder an der Konfiguration vorgenommen?
• Für ASR in ePDG verwendete Formeln
• Wie viele ePDGs gibt es in dem betroffenen Kreis, und darunter ist das Problem, das in allen ePDGs oder einer spezifischen EPD beobachtet wurde

Hier sind die zu sammelnden Protokolle:

• Zeigt Support-Details (SSD) des Knotens vor Beginn, während und nach dem Problem an (wenn das Problem nicht mehr auftritt).
• Syslogs für 1 Woche vor dem Problem (für vergleichende Studie), die den Zeitpunkt des Problems und nach dem Problem (wenn das Problem nicht mehr auftritt).
• SNMP-Traps (Simple Network Management Protocol) für eine Woche vor dem Problem (für Vergleichsstudien), um die Zeit des Problems und danach abzudecken (wenn das Problem nicht mehr auftritt).
• Bulkstats 1 Woche vor der Ausgabe (für vergleichende Studie), über den Zeitpunkt der Ausgabe und nach der Ausgabe (wenn das Problem nicht mehr auftritt).
• Monsub ist nach folgenden Optionen zu erheben:

monitor subscriber with options S, X, A, Y, 19, 33, 34, 35, 26, 37, 40, 50, 88, 89. Collect traces at verbosity 5 for problematic and non-problematic number.

• 3 SSD in einem Intervall von 30-45 Minuten, um den Grund für die Ablehnung zu finden.

Hinweis: Disconnect-reason 519 bis 533 sind für ePDG Session reject.

• Sie müssen Konfigurationen der problematischen und nicht problematischen Knoten vergleichen.

show configuration

show configuration verbose

• Zum Debuggen von Protokollen erforderlich:

logging filter active facility sessmgr level <critical/error> logging filter active facility ipsec level <critical/error> logging filter active facility ikev2 level <critical/error> logging filter active facility epdg level <critical/error> logging filter active facility diameter level<critical/error> logging filter active facility egtpc level<critical/error> logging active ------------------- to enable debug logs no logging active --------------- to disable debug logs Note :: Above mentioned debug logs are taken considering debug logs at the level of critical/error but we can capture at debug level also as per need basis e.g logging filter active facility egtpc level debug

• Die Ausgabe von Befehlen, die für die Fehlerbehebung nützlich sein können:

show epdg-service all counters   
-> View ePDG service information and statistics

show epdg-service statistics     
-> View ePDG service statistics

show epdg-service session all    
-> View ePDG service session information

show egtpc statistics interface edpg-egress debug-info    
-> View egtpc statistics for  ePD-egress

show session [ disconnect-reasons | duration | progress | setuptime | subsystem ] 
-> iew additional session statistics.

show crypto statistics ikev2     
-> View IKEv2 statistics

show diameter aaa-statistics all 
->View Diameter AAA server statistics.

show subscribers epdg-only [ [ all ] | [ callid call_id ]]   
-> View a list of ePDG subscribers currently accessing the system.

show subscribers epdg-service service_name [ [ all ] | [ callid call_id ]] 
 ->View a list of ePDG subscribers currently accessing the system per ePDG service.

show crypto managers summary ipsec-sa-stats 
---Need to collect with some iterations to check ipsec associations stats

Warnung: Wenn Sie aufgefordert werden, Protokolle wie Debug-Protokolle, Protokollierungsmonitor, mon-sub und mon pro zu sammeln, sammeln Sie diese immer im Wartungsfenster und überwachen Sie immer die CPU-Last.

Analyse 

Dies ist das Beispiel einer Formel für die Erfolgsrate bei anfänglichen ePDG-Attach-Sitzungen:

Initial Attach Sessions Success Rate ==((totsetupsuccess / totsetupattempt )*100)

Unter Statistik und Zählerreferenz - Bulkstatistik-Beschreibungen finden Sie die Zähler, die in der Formel verwendet werden, um ihre Bedeutung zu kennen.

epdg totsetup-attempt- Total number of epdg session setup attempts. Increments upon receiving IKE_AUTH (CFG_REQ) for ePDG session creation.

epdg totsetup-success Total number of epdg session setup success. Increments upon successful IPv4/IPv6/Dual Stack ePDG session call setup.                

Von der SSD aus können Sie die Ausgabe show crash list sehen, um festzustellen, ob es eine kontinuierliche/hohe Anzahl von Abstürzen gibt, die zum KPI-Dip führen.

Auf der SSD können Sie überprüfen show license info und show resource ausgeben, ob die Lizenz nicht abgelaufen ist oder die Anzahl der Sitzungen innerhalb des Limits liegt.

******** show resources ******* Wednesday December 07 16:58:25 IST 2022 EPDG Service: In Use : 1118147 Max Used : 1450339 ( Tuesday November 29 00:06:00 IST 2022 ) Limit : 1600000 License Status : Within Acceptable Limits >>>>>

Aus der Ausgabe des Befehls show epdg-service statistics kann der Fehlergrund überprüft werden, der inkrementiert wird.

******** show epdg-service statistics ******* Session Disconnect reason: Remote disconnect: 580994781 Admin disconnect: 168301 Idle timeout: 0 Absolute timeout: 0 Long duration timeout: 0 Session setup timeout: 169445470 No resource: 185148 Auth failure: 7634409 Flow add failure: 0 Invalid dest-context: 0 Source address violation: 42803 LMA Revocations(non-HO): 0 Duplicate Request: 19973167 Addr assign failure: 0 LTE/Other handoff: 1310701444 Miscellaneous reasons: 456928065 MIP-reg-timeout : 0 Invalid-APN : 0 ICSR Procedure : 0 Local PGW Res. Failed : 10424 Invalid QCI : 0 UE Redirected : 0 Roaming Mandatory : 0 Invalid IMEI : 3 

Aus den problematischen Spuren kann der Grund für Ablehnungen gefunden werden und mit der unproblematischen Spur für eventuelle Diskrepanzen verglichen werden.

Einige der Szenarien, die Sie aus Traces erhalten können:

In Fall 1 (Durchmesser - kein Abonnement) wird nach der Analyse der Traces beobachtet, dass eine Diameter-EAP-Anforderung an den AAA-Server gesendet wird. Die empfangene Antwort weist jedoch auf einen Fehler im Ursachencode hin. DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION. Daher registriert das Serving Packet Data Gateway (SPGW) denselben Fehler mit dem Grund für die Verbindungstrennung. diameter-no-subscription. Dieses Verhalten wird für einen Benutzer ohne Abonnement als normal angesehen, da es vom AAA-Server (Authentication, Authorization, Accounting) zum Zeitpunkt des Prozesses abgelehnt wird.

Hinweis: Lassen Sie das APN-Abonnement bei AAA/HSS auf die Testnummer prüfen und vereinbaren Sie nach Möglichkeit Online-Tests für dasselbe.

In Fall 2 (Session-setup-timeout) wird bei der Analyse der Traces festgestellt, dass die Session-Einrichtung mit dem Grund für die Verbindungstrennung abgelehnt wird. Session-setup-timeout. Weitere Untersuchungen haben ergeben, dass die ePDG eine Nachricht an den SPGW sendet, aber keine Antwort für diese EGTP_CREATE_SESSION_REQUEST erhält. Es ist zu beobachten, dass drei aufeinander folgende Anfragen ohne Antwort gesendet werden.

Solution : In such cases mostly need to check why SPGW is not sending any response towards EPDG because EPDG maintains this setup timer within which it needs to have the response

In Fall 3 wird eine Anforderung mit einem bestimmten Access Point-Namen (APN) an das PGW gesendet, sie wird jedoch mit dem Ursachencode abgelehnt.  EGTP_CAUSE_USER_AUTHENTICATION_FAILED.

Solution : Here the issue can be either at HSS or EPDG itself need to check the authentication parameters being exchanged between EPDG/HSS/AAA          

Um alle genannten Fälle zu untersuchen, müssen Debug-Protokolle für eine detailliertere Analyse erfasst werden. Diese Protokolle werden nach dem 3GPP-Standard geprüft und anhand der Ergebnisse kann ein geeigneter Aktionsplan oder Workaround ermittelt werden. Dabei ist zu beachten, dass die Vorgehensweise je nach Szenario variieren kann.