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 als ipsecmgr läuft auf diesen Karten. 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 jede wie  sessmgr/ipsecmgr  um festzustellen, ob ein ungewöhnliches Muster des Datenverkehrsflusses gemessen an der Anzahl der Sitzungen pro  sessmgr/ipsecmgr  oder wenn sich diese Prozesse im Warn/Over-Status befinden. In dieser Ausgabe sehen Sie beispielsweise  ipsecmgr ist in  over  Zustand wie hier dargestellt.

[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  Ausführung auf den Karten 4 und 5 mit ungleichmäßiger Sitzungsverteilung:

[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

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.

• 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 
    
    
      logging filter active facility ipsec level 
     
       logging filter active facility ikev2 level 
      
        logging filter active facility epdg level 
       
         logging filter active facility diameter level 
        
          logging filter active facility egtpc level 
         
           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

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 können Sie die Ausgabe sehen show crash list um festzustellen, ob es eine fortlaufende/hohe Anzahl von Abstürzen gibt, die zum KPI-Dip führen.

Von der SSD können Sie überprüfen, show license info und show resource um festzustellen, ob die Lizenz nicht abgelaufen ist oder ob 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, der erhöht wird, überprüft werden.

******** 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 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 gilt als normal für Benutzer ohne Abonnement, da sie vom AAA-Server (Authentication, Authorization, Accounting) zum Zeitpunkt des Prozesses abgelehnt werden.

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 ergaben, dass die ePDG eine  EGTP_CREATE_SESSION_REQUEST  an den SPGW gesendet, erhält aber keine Antwort. 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.