Einleitung
Dieses Dokument beschreibt die Schritte zur Fehlerbehebung bei der Archivierung von Charging Data Records (CDRs)/General Packet Radio Service (GPRS) Tunneling Protocol Prime (GTPP) in Aggregation Services Routers (ASR) 5000/ASR 5500/Virtual Packet Core.
Hintergrundinformationen
ASR 5000/ASR 5500/Virtual Packet Core kann CDRs aus vielen Gründen archivieren (aufgrund von IP-Verbindungsproblemen können keine Dateien übertragen werden, der Remote-Server kann keine CDRs empfangen, es können verschiedene Fehlkonfigurationen auftreten usw.). Ein Proxy-Neustart löst das Problem in vielen Fällen, auch wenn es sich um ein Problem mit der Charging Gateway Function (CGF) handelt. Wenn beispielsweise ein CGF einen bestimmten Nachrichtentyp nicht akzeptieren kann (z. B. eine Anforderung abbrechen), wird die Nachricht nach dem Neustart des aaproxy nicht mehr gesendet. Da das Problem durch den Neustart des Proxys behoben wird, ergibt sich ein falsch positives Ergebnis, da ASR 5000/ASR 5500/Virtual Packet Core die Ursache ist. Die Verwendung eines externen PCAP zur Erfassung des Datenverkehrs würde dabei helfen, die Ursache zu identifizieren, in diesem Fall den CGF.
Problem
Der Befehl show gtpp counters zeigt den Typ und die Zähler für CDRs an. Die Zähler zeigen archivierte CDRs an. Im vorliegenden Beispiel beträgt die Anzahl der archivierten Gateway GPRS Support Node (GGSN) CDRs (GCDRs) 144015. Mehrere Ausgaben der Anzeige-GTP-Zähler zeigen an, ob die Anzahl der archivierten CDRs zunimmt.
[local]StarOS# show gtpp counters all
Archived GCDRs: 144015
GCDRs buffered with AAAPROXY: 0
GCDRs buffered with AAAMGR: 22354
Diese Ausgabe zeigt eine laufende SGSN-CDRs-Archivierung (Serving GPRS Support Node) bei stabilem GCDR-Archiv.
[local]StarOS# show gtpp counters all | grep Archive
Archived GCDRs: 176703
Archived MCDRs: 0
Archived SCDRs: 2244673
Archived S-SMO-CDRs: 0
Archived S-SMT-CDRs: 0
Archived G-MB-CDRs: 0
Archived SGW CDRs: 0
Archived WLAN CDRs: 0
Archived LCS-MT CDRs: 0
[local]StarOS# show gtpp counters all | grep Archive
Archived GCDRs: 176703
Archived MCDRs: 0
Archived SCDRs: 2244864
Archived S-SMO-CDRs: 0
Archived S-SMT-CDRs: 0
Archived G-MB-CDRs: 0
Archived SGW CDRs: 0
Archived WLAN CDRs: 0
Archived LCS-MT CDRs: 0
[local]StarOS# show gtpp counters all | grep Archive
Archived GCDRs: 176703
Archived MCDRs: 0
Archived SCDRs: 2245281
Archived S-SMO-CDRs: 0
Archived S-SMT-CDRs: 0
Archived G-MB-CDRs: 0
Archived SGW CDRs: 0
Archived WLAN CDRs: 0
Archived LCS-MT CDRs: 0
Die Überprüfung von Syslogs auf die Warnung "gtpp 52056" kann verwendet werden, um den Kontext und die GTPP-Gruppe zu identifizieren, in denen CDRs archiviert werden. Diese Ausgabe zeigt, dass die Archivierung für den GTPP- und GTPP-Gruppenstandard des Kontexts gemeldet wird.
[gtpp 52056 warning] [5/0/2399 <aaamgr:50> gr_gtpp_proxy.c:667] [context: GTPP, contextID: 6]
[software internal security system critical-info syslog] [gtpp-group default]
GTPP request with req-count 61747 retried by AAAmgr. Retry-count 3342670
Lösung
1. Die falsche Konfiguration kann zu einer Ansammlung von CDRs im Archiv führen. Wenn CDRs/GTPP-Datensätze von einer unbeabsichtigten GTPP-Gruppe generiert werden und diese Gruppe eine ungültige Konfiguration aufweist, wird die Archivierung durchgeführt. Überprüfen Sie, ob die Konfiguration vorhanden oder für die folgenden allgemeinen Probleme gültig ist:
- "gtpp group default" in der APN-Konfiguration
- "Abrechnungskontext" in GGSN-, Serving Gateway (SGW)-, SAEGW-, SGSN-Services
- IP-Adresse des Charging-Agent und IP-Adresse des CGF-Servers
- Prüfen Sie, ob CGF läuft.
2. Überprüfen Sie, ob die Socket-Schnittstelle im entsprechenden Kontext aktiv ist. Ein Fehler bei der Socketerstellung kann zu einer CDR-Archivierung führen. Um solche Probleme zu identifizieren, testen Sie die CGF-Konnektivität mit diesem Befehl. Dieser Befehl sollte in dem Kontext ausgeführt werden, in dem die gtpp-Gruppe konfiguriert ist.
[context]StarOS# gtpp test accounting group name <name>
3. Überprüfen Sie den RTD (Round Trip Delay, Round-Trip-Verzögerung), ob das Charging-Gateway die CDRs bestätigt. Der Befehl "show gtpp statistics verbose" zeigt die RTD für CGF.
4. Überprüfen Sie das Transportnetzwerk, um festzustellen, ob es über die Kapazität verfügt, um den Verkehr am Gateway zu verarbeiten. Eine Verzögerung oder Paketverluste im Netzwerk führen dazu, dass CDRs im Gateway archiviert werden. Wenn die Pakete verworfen werden (was zur erneuten Übertragung von Paketen vom ASR 5000/ASR 5500/Virtual Packet Core führt, wodurch die CDR-Übertragungsrate verlangsamt wird), führt dies zu archivierten CDRs. Dies kann behoben werden, indem die Transportverbindungskapazität erhöht oder QoS zum Netzwerk hinzugefügt wird.
5. Überprüfen Sie aktive Datensätze in einer aaamgr-Instanz mit "debug aaamgr show archive-records instance <aaaamgr_instance_id>" (erfordert CLI-Testbefehle-Kennwort, das im Chassis konfiguriert ist.) auf den neueren Softwareversionen liefert Informationen über CDR-Typ, Kontext und GTPP-Gruppennamen für archivierte Datensätze auf einem bestimmten aaamgr. Diese Informationen helfen bei der Identifizierung möglicher Fehlkonfigurationen. Aus der unten stehenden Beispielausgabe wird deutlich, dass CDRs in gtpp group default im Kontext ggsn festgehalten/archiviert werden. Die APN, die diese CDRs generiert hat, ist am schnellsten. Möglicherweise weist diese Standard-GTP-Gruppe im GSN-Kontext eine ungültige Konfiguration auf.
--------------------------------------------------------------------------------------
Record Type | Apn Name | Accounting Context | Group Name | Timestamp
--------------------------------------------------------------------------------------
EGCDR |wifitest |ggsn |default |Tuesday August 26 10:18:21
EGCDR |wifitest |ggsn |default |Tuesday August 26 10:23:21
EGCDR |wifitest |ggsn |default |Tuesday August 26 10:28:21
EGCDR |wifitest |ggsn |default |Tuesday August 26 10:33:22
Feedback