Inhalt

Einführung

Hintergrundinformationen

Problem

Lösung

Einführung

In diesem Dokument werden die Schritte zur Fehlerbehebung bei der Archivierung von Charging Data Records (CDRs)/General Packet Radio Service (GPRS) Tunneling Protocol Prime (GTPP) in Aggregation Services Router (ASR) 5000/ASR 5500/Virtual Packet Core beschrieben.

Hintergrundinformationen

ASR 5000/ASR 5500/Virtual Packet Core kann CDRs aus verschiedenen Gründen archivieren (Dateien können aufgrund von IP-Verbindungsproblemen nicht übertragen werden, der Remote-Server kann keine CDRs empfangen, verschiedene Fehlkonfigurationen usw.). Ein aaproxy-Neustart löst das Problem in vielen Fällen, selbst wenn es sich um ein Problem mit Charging Gateway Function (CGF) handelt. Wenn beispielsweise ein CGF eine bestimmte Art von Nachricht nicht akzeptieren kann (z. B. Anfrage zum Abbrechen), wird die Nachricht nach dem Neustart des aaaproxy nicht mehr gesendet. Da das Problem durch den Neustart von aaproxy behoben wird, wird ein falsch positiver Wert angezeigt, da ASR 5000/ASR 5500/Virtual Packet Core die Ursache ist. Die Verwendung einer externen PCAP zur Erfassung des Datenverkehrs würde dabei helfen, die Ursache zu ermitteln, die in diesem Fall der CGF wäre.

Problem

Die show gtpp-Zähler zeigen den Typ und die Zähler für CDRs an. Die Zähler zeigen archivierte CDRs an. Im Beispiel hier beträgt die Anzahl der archivierten Gateway GPRS Support Node (GGSN) CDRs (GCDRs) 144015. Mehrere Ausgaben der show gtpp-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 SCDR-Archivierung (Serving GPRS Support Node (SGSN), während das GCDR-Archiv stabil ist.

[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 der CDRs archiviert werden. Diese Ausgabe zeigt, dass die Archivierung für den Kontext-GTPP- und gtpp-Gruppenstandard 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 Akkumulation 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 eine Archivierung durchgeführt. Überprüfen Sie, ob die Konfiguration für die folgenden allgemeinen Probleme vorhanden oder gültig ist:

- "gtpp group default" in der APN-Konfiguration

- "Accounting-Kontext" in GGSN, Serving Gateway (SGW), SAEGW, SGSN Services

- IP-Adresse des Charging Agent und CGF-Server.

- Überprüfen Sie, ob CGF aktiv ist.

2. Überprüfen Sie, ob die Socket-Schnittstelle im entsprechenden Kontext aktiviert ist. Fehler bei der Socket-Erstellung können zur CDR-Archivierung führen. Um solche Probleme zu erkennen, testen Sie die CGF-Verbindung mit diesem Befehl. Dieser Befehl sollte im Kontext ausgeführt werden, in dem die gtpp-Gruppe konfiguriert ist.

[context]StarOS# gtpp test accounting group name <name>

3. Prüfen Sie, ob das Charging Gateway die CDRs erkennt. Der Abschnitt "show gtpp statistics verbose" zeigt den RTD für CGF an.

4. Prüfen Sie das Transportnetzwerk, um festzustellen, ob es über die Kapazität verfügt, den Datenverkehr vom Gateway zu verarbeiten. Verzögerungen oder Paketverluste im Netzwerk führen dazu, dass CDRs im Gateway archiviert werden. Wenn 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 durch Erhöhung der Transportverbindungskapazität oder Hinzufügen von QoS im Netzwerk behoben werden.

5. Überprüfen Sie aktive Datensätze in einer AMAG-Instanz mit "debug aamgr show archive-record instance <aamgr_instance_id>" (erfordert CLI-Testbefehlskennwort, 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 AMAGR. Diese Informationen helfen bei der Identifizierung möglicher Fehlkonfigurationen. Aus der folgenden Beispielausgabe geht hervor, dass CDRs in gtpp group default in context ggsn fixiert/archiviert werden. Der APN, der diese CDRs generiert hat, ist am besten geeignet. Möglicherweise hat diese Standard-gtpp-Gruppe im ggsn-Kontext eine ungültige Konfiguration.

--------------------------------------------------------------------------------------

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