Konfiguration von Mechanismen für die Fehlerbehandlung und Serverunerreichbarkeit für die OCS-Fehlerbehebung auf dem ASR5K

Download-Optionen

PDF (179.8 KB)
Mit Adobe Reader auf verschiedenen Geräten anzeigen
ePub (111.8 KB)
In verschiedenen Apps auf iPhone, iPad, Android, Sony Reader oder Windows Phone anzeigen
Mobi (Kindle) (114.1 KB)
Auf einem Kindle-Gerät oder einer Kindle-App auf mehreren Geräten anzeigen

Aktualisiert:2. Juni 2015

Dokument-ID:118993

Inklusive Sprache

In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.

Informationen zu dieser Übersetzung

Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.

Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Konfigurieren

Netzwerkdiagramm

X-Ablaufdatum

Antwort-Timeout

Durchmesser: Sitzungs-Failover

FH-Mechanismus

Konfiguration des FH-Mechanismus

Standardverhalten des FH-Mechanismus

FH-Mechanismus - Detaillierter Anruffluss

SU-Mechanismus

Konfiguration des SU-Mechanismus

SU-Mechanismus - Anrufverläufe

FH- und SU-Beispielkonfigurationen

Überprüfen

Fehlerbehebung

Zugehörige Informationen

Einführung

In diesem Dokument wird beschrieben, wie die Mechanismen FH (Failure-Handling) und SU (Server-Unreachable) auf der Gy-Schnittstelle konfiguriert werden, um Probleme im Online Charging System (OCS) zu beheben oder die Verbindung zwischen der Policy and Charging Enforcement Function (PCEF) und dem OCS herzustellen. Die in diesem Dokument beschriebenen Informationen gelten für die Funktionen Home Agent (HA), Gateway General Packet Radio Service (GPRS) Support Node (GGSN) und Packet Data Network Gateway (PGW), die auf dem Cisco Aggregated Services Router der Serie 500 (ASR5K) ausgeführt werden.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Ihr System diese Anforderungen erfüllt, um die FH- und SU-Mechanismen zu verwenden:

Der Enhanced Charging Service (ECS) ist verfügbar
Das PCEF ist innerhalb von HA, GGSN oder PGW vorhanden.
Es gibt einen passenden Durchmesser für die Anbindung über die Datenbank.
Die Diameter Credit Control Application (DCCA) ist verfügbar.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf allen Versionen des ASR5K.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Hintergrundinformationen

Das PCEF ist über die Gy-Schnittstelle mit dem OCS verbunden, die Diameter als Basisprotokoll und DCCA verwendet. Dies ist der Nachrichtenfluss zwischen PCEF und OCS:

Credit Control Request (CCR) âÂ Â Diese Nachricht wird vom PCEF an das OCS gesendet. Es gibt drei Arten von CCR-Meldungen: Anfänglich, aktualisieren und beenden
Credit Control Answer (CCA) âÂ Â Diese Nachricht wird vom OCS als Antwort auf den CCR an das PCEF gesendet. Es gibt auch drei Arten von CCA-Meldungen: Anfänglich, aktualisieren und beenden
Re-Authorization Request (RAR) âÂ Â Diese Nachricht wird vom OCS an das PCEF gesendet, wenn eine erneute Autorisierung der Sitzung erforderlich ist.
Re-Authorization Answer (RAA) âÂ Â Dies ist die Antwort auf die RAR vom PCEF zum OCS.

Um den Nachrichtenfluss zu ermöglichen, wird zwischen dem PCEF und dem OCS eine Durchmesserverbindung hergestellt. Es besteht die Möglichkeit, dass das OCS negative Nachrichten sendet, die Transportverbindung zwischen dem PCEF und dem OCS fehlschlägt oder die Nachricht ausfällt, was zu einem Ausfall in der Teilnehmersitzungseinrichtung führen kann. Dies kann den Teilnehmer an der Nutzung von Diensten hindern.

Diese beiden Mechanismen können zur Lösung dieses Problems verwendet werden:

Der FH-Mechanismus
Der SU-Mechanismus

Konfigurieren

In diesem Abschnitt werden die Konfigurationen beschrieben, die zur Unterstützung der FH- und SU-Mechanismen erforderlich sind.

Netzwerkdiagramm

Die Informationen in diesem Dokument verwenden die folgende Topologie:

X-Ablaufdatum

Dies ist ein Timer auf Anwendungsebene für das DCCA, der in den Einstellungen für die Kreditsteuerung des Durchmessers konfiguriert werden kann. Der Wert kann zwischen 1 und 300 Sekunden liegen.

Hier ein Beispiel:

[local]host_name(config-dcca)# diameter pending-timeout

Antwort-Timeout

Dies ist ein Datenbank-Timeout und kann in den Diameter-Endpunkteeinstellungen konfiguriert werden. Der Wert kann zwischen 1 und 300 Sekunden liegen.

Hinweis: Der für diesen Timer konfigurierte Wert sollte größer sein als der für den Tx-Expiry-Timer verwendete Wert.

Hier ein Beispiel:

[context_name]host_name(config-ctx-diameter)# response-timeout

Durchmesser: Sitzungs-Failover

Diese Funktion wird verwendet, um die Ausfallsicherung für Kreditsteuerungssitzungen mit einem Durchmesser zu aktivieren oder zu deaktivieren. Dadurch kann das System einen Sekundärserver verwenden, wenn der Primärserver nicht erreichbar ist. Dies ist in den Einstellungen für die Kreditsteuerung des Durchmessers konfigurierbar.

Hier ein Beispiel:

local]host_name(config-dcca)# diameter session failover

FH-Mechanismus

Der FH-Mechanismus funktioniert nur, wenn Sitzungsausfallsicherung mit Durchmesser vorhanden ist. Das FH ermöglicht dem System zu entscheiden, ob die Sitzung fortgesetzt und in Offline konvertiert oder die Sitzung beendet werden soll, wenn ein Verbindungs- oder Nachrichtenfehler auftritt.

Hinweis: Der FH ist standardmäßig aktiviert und konfiguriert.

Konfiguration des FH-Mechanismus

Der FH-Mechanismus kann in den Einstellungen für die Kreditsteuerung des Durchmessers konfiguriert werden. Die folgende Syntax wird in der FH-Konfiguration verwendet:

failure-handling { initial-request | terminate-request | update-request } { continue
 [ go-offline-after-tx-expiry | retry-after-tx-expiry ] | retry-and-terminate,
 [ retry-after-tx-expiry ] | terminate }

Der erste Abschnitt gibt den Anforderungstyp an: Initial (CCR-I), Update (CCR-U) und Terminate (CCR-T).

Im zweiten Abschnitt wird die Aktion angegeben, die bei Aktivierung des FH-Mechanismus durchgeführt werden soll. Diese drei Aktionen sind mit dem FH-Mechanismus möglich:

Continue â Â Dies ermöglicht die Sitzung fortzufahren und konvertiert sie in offline. Diese Funktion verwendet zwei Optionen, die sich auf Tx-Ablauf beziehen:
- Go-offline-after-tx-exponent âÂ Â Diese startet das Offline-Aufladen nach dem Tx-Ablauf tritt.
- Nach-tx-Verfallsdatum âÂ Â Diese erneuert den sekundären Server nach dem Tx-Verfallsdatum.
Retry-and-terminate âÂ Â Diese beendet die Sitzung, nachdem das System den sekundären Server erneut versucht, wenn der sekundäre Server ebenfalls nicht verfügbar ist. Dabei wird auch die Option Retry-after-tx-Expending verwendet, die den sekundären Server nach dem Tx-Ablaufdatum erneut versucht.
Terminate â Â Diese beendet die Sitzung ohne Versuche, den sekundären Server zu kontaktieren.

Standardverhalten des FH-Mechanismus

In diesem Abschnitt wird das FH-Standardverhalten beschrieben, wenn keine Konfiguration vorhanden ist. Standardmäßig wird der FH-Mechanismus während eines Response Timeout (RT) aktiviert, außer wenn die Aktion Terminate konfiguriert ist.

Wenn ein AVP (Credit-Control-Failure-Handling Attribute Value Pair) vom Server empfangen wird, werden die empfangenen Einstellungen angewendet.

Hier einige Beispiele:

Anfängliche Anfrage > Kündigen
Update-Request > Retry-and-Terminate
Abschlussanforderung > Wiederholen und Beenden

FH-Mechanismus - Detaillierter Anruffluss

In diesem Abschnitt wird der detaillierte Anrufablauf des FH-Mechanismus mit allen möglichen Optionen beschrieben.

Anfängliche Anforderung

CCFH-Einstellung	CLI-Befehl	Verhalten bei Tx	Verhalten bei RT	Sekundär ist aktiv	Sekundäres Gerät ist ausgefallen.
Weiter	Erstantrag fortfahren	K/A	Weiter	Sekundär übernimmt RT	Offline nach einem anderen RT. Es werden keine Quotenanfragen mehr durchgeführt. für beliebige Ratinggruppen in der Sitzung nach DCCA-Ausfall (auch wenn Verbindung zum DCCA wird wiederhergestellt)
	Erstantrag weiter offline gehen TX-Ablaufdatum	Offline	K/A	Offline bei Tx	Offline bei Tx
	Erstantrag Wiederholung des Wiederholungsversuchs TX-Ablaufdatum	Weiter	K/A	Sekundär übernimmt Tx	Offline nach einem anderen Tx
Wiederholen und beenden	Erstantrag wiederholen und beenden	K/A	Wiederholen	Sekundär übernimmt RT	Nach einem anderen RT kündigen
Wiederholen und beenden	Erstantrag wiederholen und beenden Nach-tx-Ablauf erneut versuchen	Wiederholen	K/A	Sekundär übernimmt Tx	Nach einer anderen Tx beenden
Beenden	Erstantrag beenden	Beenden	K/A	Nach Tx beenden	Nach Tx beenden

Aktualisierungsanforderung

CCFH-Einstellung	CLI-Befehl	Verhalten bei Tx	Verhalten bei RT	Sekundär ist aktiv	Sekundäres Gerät ist ausgefallen.
Weiter	Aktualisierungsanfrage fortfahren	K/A	Weiter	Sekundär übernimmt RT	Offline nach einem anderen RT
	Aktualisierungsanfrage weiter offline gehen TX-Ablaufdatum	Offline	K/A	Offline bei Tx	Offline bei Tx
	Aktualisierungsanfrage Wiederholung des Wiederholungsversuchs TX-Ablaufdatum	Weiter	K/A	Sekundär übernimmt Tx	Offline nach einem anderen Tx
Wiederholen und beenden	Aktualisierungsanfrage wiederholen und beenden	K/A	Wiederholen	Sekundär übernimmt RT	Sendet CCR-T nach einem anderen RT
Wiederholen und beenden	Aktualisierungsanfrage wiederholen und beenden Nach-tx-Ablauf erneut versuchen	Wiederholen	K/A	Sekundär übernimmt Tx	Sendet CCR-T nach einer anderen Tx
Beenden	Aktualisierungsanfrage beenden	Beenden	K/A	Sendet CCR-T nach Tx	Sendet CCR-T nach Tx

Anfrage beenden

CCFH-Einstellung	CLI-Befehl	Verhalten bei Tx	Verhalten bei RT	Sekundär ist aktiv	Sekundäres Gerät ist ausgefallen.
Weiter	Abschlussanforderung fortfahren	K/A	Wiederholen	CCR-T wird gesendet sekundär nach RT	Nach einem anderen RT kündigen
	Abschlussanforderung weiter offline gehen TX-Ablaufdatum	Wiederholen	K/A	CCR-T wird gesendet sekundär nach Tx	Nach einer anderen Tx beenden
	Abschlussanforderung Wiederholung des Wiederholungsversuchs TX-Ablaufdatum	Wiederholen	K/A	CCR-T wird gesendet sekundär nach Tx	Nach einer anderen Tx beenden
Wiederholen und beenden	Abschlussanforderung wiederholen und beenden	K/A	Wiederholen	CCR-T wird gesendet sekundär nach RT	Nach einem anderen RT kündigen
Wiederholen und beenden	Abschlussanforderung wiederholen und beenden Nach-tx-Ablauf erneut versuchen	Wiederholen	K/A	CCR-T wird gesendet sekundär nach Tx	Nach einer anderen Tx beenden
Beenden	Abschlussanforderung beenden	Beenden	K/A	Kündigen nach Tx	Nach Tx beenden

SU-Mechanismus

Der SU-Mechanismus ähnelt dem FH-Mechanismus, bietet jedoch eine präzisere Kontrolle über Fehlerverfahren. Zusätzlich zur Fortsetzung der Sitzung nach Ausfällen auf Nachrichten- und Verbindungsebene (Transport) kann dieser Mechanismus verwendet werden, wenn die Antworten aus dem OCS langsam sind. Sie bietet außerdem die Möglichkeit, die Sitzung entweder für eine bestimmte Zeit/Ausschöpfung des Kontingents vor Beendigung fortzusetzen oder ein konfigurierbares vorläufiges Kontingent (Volumen und Zeit) sowie konfigurierbare Server-Wiederholungen zu verwenden, bevor eine Sitzung in offline umgewandelt oder beendet wird.

Konfiguration des SU-Mechanismus

Der SU-Mechanismus kann in den Einstellungen für die Kreditsteuerung des Durchmessers konfiguriert werden. Die in der SU-Konfiguration verwendete Syntax variiert je nach verwendeter Version.

Für die Versionen 12.1 und früher ist dies die Syntax, die für die Konfiguration des SU-Mechanismus verwendet wird:

servers-unreachable { initial-request { continue | terminate [ after-timer-expiry
 <timeout_period> ] } | update-request { continue | terminate [ after-quota-expiry
 | aftertimer-expiry <timeout_period> ] } }

Für die Versionen 12.2 und höher ist dies die Syntax, die für die Konfiguration des SU-Mechanismus verwendet wird:

servers-unreachable { behavior-triggers { initial-request | update-request }
 result-code { any-error | <result-code> [ to <end-result-code> ] }
 | transport-failure [ response-timeout | tx-expiry ] | initial-request
 { continue [ { [ after-interim-time <timeout_period> ] [ after-interim-volume
 <quota_value> ] } server-retries <retry_count> ] | terminate [ {
 [ after-interim-time <timeout_period> ] [ after-interim-volume <quota_value> ]
 } server-retries <retry_count> | after-timer-expiry <timeout_period> ] }
 | update-request { continue [ { [ after-interim-time <timeout_period> ]
 [ after-interim-volume <quota_value> ] } server-retries <retry_count> ]
 | terminate [ { [ after-interim-time <timeout_period> ] [ after-interim-volume
 <quota_value> ] } server-retries <retry_count> ] | after-quota-expiry |
 after-timer-expiry <timeout_period> ] } }

Hinweis: In Versionen vor Version 12.2 gab es Flexibilität, die FH- und SU-Mechanismen unabhängig zu konfigurieren. In Version 12.2 und höher hat der SU-Mechanismus jedoch bei der Konfiguration Vorrang vor dem FH-Mechanismus.

Wenn der Server den CC-FH AVP zurückgibt und der SU-Mechanismus für eine Reihe von Verhaltens-Triggern konfiguriert ist, wird die SU-Konfiguration angewendet. Andernfalls wird der AVP-Wert für CC-FH angewendet. Ergebniscodes wie 3002, 3004 und 3005 fallen standardmäßig unter Lieferfehler und werden als RTs behandelt.

Diese Aktionen sind mit dem SU-Mechanismus möglich:

Behavior-Trigger âÂ Â Dieser Wert gibt die Art der Nachrichten an, die Initial-Requests (CCR-I) oder Update-Requests (CCR-U) sein können. Für diese Trigger stehen drei Optionen zur Verfügung:
- Result-Code âÂ Â Dies ermöglicht die Konfiguration von bestimmten Ergebniscodes, Bereich der Ergebniscodes (3000-5999) oder jeder Fehler zusammen mit dem Meldungstyp.
- Transport-Failure âÂ Â Diese Spezifikation löst das Verhalten bei Transportausfall aus, das abwärtskompatibel mit Version 12.0 ist. Für diese Einstellung stehen zwei Optionen zur Verfügung:
  - Response-Timeout âÂ Â Diese Option löst das Verhalten bei RT aus und sollte immer bei Transportausfällen verwendet werden.
  - Tx-Expiry âÂ Â Diese Option löst das Verhalten bei Tx-Ablauf aus und sollte immer bei Transportausfällen angewendet werden.
- Aktionen â Â Dieser Wert legt die Aktion fest, die ausgeführt wird, wenn ein SU-Trigger für CCR-I oder CCR-U auftritt. Diese Aktion hängt vom Nachrichtentyp und der Softwareversion ab.
Continue â Â Dies ermöglicht, die Sitzung zu offline konvertieren und fortzufahren. Für die Verwendung dieser Aktion in Versionen vor Version 12.2 stehen keine weiteren Optionen zur Verfügung. In Version 12.2 und höher stehen die Optionen für das Zwischenkontingent, Server-Retries und das Ablaufdatum nach dem Timeout für den Timer für diese Aktion zur Verfügung.
Terminate â Â Dies führt zum Ende der Sitzung, wenn der Server nicht erreichbar wird. Diese Aktion ermöglicht die Optionen für Zwischenkontingent, Server-Wiederholungen und Timeout nach Ablauf des Timers.

Diese Optionen können mit der Aktion Weiter oder Beenden verwendet werden:

Nach der Zwischenzeit âÂ Â Diese Option ermöglicht die Fortsetzung oder Beendigung des Anrufs nach der Zwischenzeitüberschreitung. Dies entspricht einem Zeitkontingent, bevor die Aktion ausgeführt wird. Der Wert wird in Sekunden formatiert und kann zwischen 1 und 4.294.967.295 liegen.
After-Interim-Volume âÂ Â Diese Option weist das Zwischenkontingent zu und ermöglicht die Fortsetzung oder Beendigung der Sitzung vor Erschöpfung der konfigurierten Menge. Der Wert wird in Byte formatiert und kann zwischen 1 und 4.294.967.295 liegen.
Server-Retries âÂ Â Diese Option ermöglicht es dem PCEF, das OCS vor dem Fortfahren oder Beenden der Sitzung erneut zu testen. Die Wiederholungszahl kann konfiguriert werden, und der Wert liegt zwischen 0 und 65.535. Wenn der Wert 0 (null) lautet, wird der Wiederholungsversuch nicht ausgeführt, und die Aktion wird sofort angewendet.

Hinweis: Die Optionen für Zwischenvolumen und NachZwischenvolumen werden immer mit der Option Serverneuerversuche verwendet, oder alle drei Optionen können gleichzeitig verwendet und sowohl für Fortsetzung als auch für Terminierung angewendet werden. Die Optionen für Zwischen- und Nachbereitungsvolumen weisen ebenfalls Zeit sowie Mengenkontingent zu, und das ausgeschöpfte Kontingent löst den Serverneustart aus.

After-Timer-Expending âÂ Â Diese Option gibt die Zeitdauer (in Sekunden) an, für die Sitzungen im Offline-Status verbleiben, bevor sie beendet werden. Die Werte können zwischen 1 und 4.294.967.295 liegen. Diese Option gilt nur für Terminierungsaktionen.
Nach Ablauf des Kontingents Â Â Diese Option endet mit Erschöpfung der bereits zugewiesenen Quote.

Hier einige wichtige Informationen, die Sie sich merken sollten:

Die Optionen für Nach-Interim- und Server-Retries können einzeln oder in Kombination verwendet werden. Sie gelten sowohl für Fortsetzung als auch für Beendigung von Aktionen.
Die Option nach Ablauf des Kontingents gilt nur für den Auslöser für das Aktualisierungsverhalten.
Die Option nach Ablauf des Zeitgebers gilt nur für die Terminierungsaktion.
Die Optionen nach Zwischen-, Nach-Interim-Volume- und Server-Retries gelten nur für die Versionen 12.2 und höher.
Wenn Sitzungs-Failover mit Durchmesser unterstützt (und konfiguriert) wird, wird immer der sekundäre Server kontaktiert, bevor der SU-Mechanismus ausgelöst wird.
Der Server, der zuletzt kontaktiert wurde, bevor der SU-Mechanismus ausgelöst wird, wird immer kontaktiert, wenn die Zwischen- oder Zwischenzeit erschöpft ist und die Option Server retries mit einem Wert größer als Null konfiguriert ist. Wenn beispielsweise zunächst OCS1 ausprobiert wird und OCS2 nach einem Fehler bei OCS1 ausprobiert wird, löst die Kommunikation mit OCS2 den SU-Mechanismus aus. Während des Serverneuversuchs wird zunächst OCS2 kontaktiert und dann OCS1, wenn eine negative Antwort von OCS2 eingeht.

SU-Mechanismus - Anrufverläufe

Der SU-Mechanismus kann durch einen Ausfall des CCR-I oder des CCR-U ausgelöst werden. Die Ursache kann ein Fehlercode, ein Transportfehler, ein Tx-Limit oder ein RT sein. Dabei kann es sich um eine Zuweisung von Interimskontingenten (Zeit und/oder Volumen), Server-Wiederholungen, Timer-Werten (die dazu führen, dass die Sitzung für eine bestimmte Zeit und nur für eine Beendigung offline geht) oder Quoten-Ablaufdatum (nur für CCR-U und Beendigung) handeln, bevor die Sitzung offline geht oder beendet wird.

Das vorläufige Kontingent wird pro Sitzung und nicht pro Rating-Gruppe (RG) in MSCC-Szenarien (Multiple Services Credit Control) bereitgestellt.

Es besteht die Möglichkeit, dass der primäre Server einen Transportfehler auslöst und der sekundäre Server den Tx-Ablauf oder das Response-Timeout auslöst. In diesem Szenario wird der letzte Fehler als Auslöser des Fehlers angesehen.

Wenn der SU-Mechanismus nicht für einen Auslöser für einen Ausfall konfiguriert ist, wird der FH-Mechanismus ausgelöst.

Hinweis: In den folgenden Abschnitten werden einige Beispiele für den Anrufablauf im Zusammenhang mit dem SU-Mechanismus aufgeführt. Diese Anrufverläufe werden unter der Annahme bereitgestellt, dass ein Cailover-Modus mit Durchmesser und Sitzungen unterstützt wird und der sekundäre Server mit einem Wert mit Ablaufdatum (Tx) konfiguriert ist, der unter dem RT-Wert liegt. Außerdem wird davon ausgegangen, dass der SU-Mechanismus für Transportausfälle, Tx-Limit und RT konfiguriert ist.

Anfängliche Anforderung ohne Sitzungstrennung