Configurer les mécanismes de gestion des défaillances et d'inaccessibilité du serveur pour la résolution des défaillances OCS sur ASR5K

Options de téléchargement

PDF (210.5 KB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (112.4 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (114.6 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:2 juin 2015

ID du document:118993

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Informations générales

Configuration

Diagramme du réseau

Expiration Tx

Délai de réponse

Basculement de session de diamètre

Mécanisme FH

Configuration du mécanisme FH

Comportement par défaut du mécanisme FH

Flux d'appels détaillé du mécanisme FH

Mécanisme SU

Configuration du mécanisme SU

Flux d'appels du mécanisme SU

Exemples de configuration FH et SU

Vérification

Dépannage

Informations connexes

Introduction

Ce document décrit comment configurer les mécanismes de gestion des pannes (FH) et de serveur inaccessible (SU) sur l'interface Gy afin de résoudre les problèmes rencontrés sur le système de facturation en ligne (OCS) ou en ce qui concerne la connectivité entre la fonction PCEF (Policy and Charging Enforcement Function) et OCS. Les informations décrites dans ce document s'appliquent aux fonctionnalités Home Agent (HA), Gateway General Packet Radio Service (GPRS) Support Node (GGSN) et Packet Data Network Gateway (PGW) qui s'exécutent sur le routeur à services agrégés de la gamme Cisco 5000 (ASR5K).

Conditions préalables

Conditions requises

Cisco recommande que votre système réponde à ces exigences afin d'utiliser les mécanismes FH et SU :

Le service de tarification améliorée (ECS) est disponible
Le PCEF existe au sein de la HA, GGSN ou PGW
Il existe une connectivité de diamètre correct via la base de données
L'application Diamètre Credit Control Application (DCCA) est disponible

Components Used

Les informations de ce document sont basées sur toutes les versions de l'ASR5K.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Informations générales

Le PCEF est connecté à OCS via l'interface Gy, qui utilise Diameter comme protocole de base et DCCA. Il s'agit du flux de messages entre le PCEF et le OCS :

Demande de contrôle de crédit (CCR) âÂ â Ce message est envoyé du PCEF au BSC. Il existe trois types de messages CCR : Initial, Update et Terminate.
Réponse au contrôle du crédit (DPA) - - Ce message est envoyé du BCP au PCEF en réponse au CCR. Il existe également trois types de messages CCA : Initial, Update et Terminate.
Demande de réautorisation (RAR) - - Ce message est envoyé par le Bureau des services de communication au PCEF lorsqu'une nouvelle autorisation de session est requise.
Réponse de réautorisation (RAA) - - Ceci est la réponse au RAR du PCEF au OCS.

La connectivité de diamètre est établie entre le PCEF et le OCS afin d'activer le flux de messages. Il est possible que l'OCS envoie des messages négatifs, que la connexion de transport échoue entre le PCEF et l'OCS ou que le message expire, ce qui peut provoquer une défaillance dans l'établissement de la session de l'abonné. Cela peut empêcher l'abonné d'utiliser les services.

Ces deux mécanismes peuvent être utilisés pour résoudre ce problème :

Le mécanisme FH
Le mécanisme des États-Unis

Configuration

Cette section décrit les configurations requises pour prendre en charge les mécanismes FH et SU.

Diagramme du réseau

Les informations de ce document utilisent cette topologie :

Expiration Tx

Il s'agit d'un compteur de niveau application pour le DCCA qui est configurable dans les paramètres de contrôle de crédit de diamètre. La valeur peut être comprise entre 1 et 300 secondes.

Voici un exemple :

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

Délai de réponse

Il s'agit d'un délai d'expiration de la base de données et il est configurable dans les paramètres Diamètre du point de terminaison. La valeur peut être comprise entre 1 et 300 secondes.

Note: La valeur configurée pour ce compteur doit être supérieure à celle utilisée pour le compteur Tx-Expiry.

Voici un exemple :

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

Basculement de session de diamètre

Cette fonctionnalité est utilisée afin d'activer ou de désactiver le basculement de session de contrôle de crédit de diamètre, qui permet au système d'utiliser un serveur secondaire lorsque le serveur principal devient inaccessible. Ceci est configurable dans les paramètres de contrôle de crédit de diamètre.

Voici un exemple :

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

Mécanisme FH

Le mécanisme FH ne fonctionne que si le basculement de session de diamètre est présent. Le FH permet au système de choisir de poursuivre la session et de la convertir en mode hors connexion, ou de mettre fin à la session en cas d'erreur de connexion ou de niveau message.

Note: Le FH est activé et configuré par défaut.

Configuration du mécanisme FH

Le mécanisme FH peut être configuré dans les paramètres de contrôle de crédit de diamètre. Voici la syntaxe utilisée dans la configuration FH :

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 }

La première section spécifie le type de demande : Initial (CCR-I), Update (CCR-U) et Terminate (CCR-T).

La deuxième section spécifie l'action qui doit être effectuée lorsque le mécanisme FH est activé. Ces trois actions sont possibles avec le mécanisme FH :

Continue ââ â Ceci permet à la session de continuer et de la convertir en mode hors connexion. Cette fonction utilise deux options liées à l'expiration du délai d'attente :
- Go-offline-after-tx-expiration âÂ â Ceci commence la charge hors connexion après l'expiration de Tx se produit.
- Retry-after-tx-expiration âÂ â Ceci renouvelle le serveur secondaire après l'expiration de Tx.
Réessayer et terminer âÂ â Cette opération met fin à la session après que le système a recommencé le serveur secondaire, si le serveur secondaire n'est pas disponible non plus. Cela utilise également l'option Retry-after-tx-expiration, qui tente à nouveau le serveur secondaire après l'expiration de Tx.
Terminate âÂ â Ceci met fin à la session sans aucune tentative de contact avec le serveur secondaire.

Comportement par défaut du mécanisme FH

Cette section décrit le comportement par défaut de FH lorsqu'aucune configuration n'est présente. Par défaut, le mécanisme FH est activé lors d'un délai de réponse (RT), sauf lorsque l'action Terminate est configurée.

Si une paire de valeurs d'attribut Credit-Control-Failure-Handling (AVP) est reçue du serveur, les paramètres reçus sont appliqués.

Voici quelques exemples :

Demande initiale > Terminer
Update-Request > Retry-and-Terminate
Terminate-Request > Retry-and-Terminate

Flux d'appels détaillé du mécanisme FH

Cette section décrit le flux d'appels détaillé du mécanisme FH avec toutes les options possibles.

Demande initiale

Paramètre CCFH	Commande CLI	Comportement à Tx	Comportement à RT	Le secondaire est actif	Secondaire désactivé
Continuer	requête initiale continuer	S/O	Continuer	Secondaire prend le relais après RT	Hors ligne après une autre RT. Aucune autre demande de quota n'est effectuée pour tout groupe de notation de la session après une défaillance DCCA (même si la connectivité à DCCA est restaurée)
	requête initiale continuer la mise hors connexion après- tx-expiration	Hors ligne	S/O	Hors ligne à Tx	Hors ligne à Tx
	requête initiale continuer la tentative après- tx-expiration	Continuer	S/O	Secondaire prend le relais après Tx	Hors connexion après une autre transaction
Réessayer et terminer	requête initiale réessayer et terminer	S/O	Réessayer	Secondaire prend le relais après RT	Terminer après une autre RT
Réessayer et terminer	requête initiale réessayer et terminer retry-after-tx-expiration	Réessayer	S/O	Secondaire prend le relais après Tx	Terminer après une autre transaction
Terminer	requête initiale terminer	Terminer	S/O	Terminer après Tx	Terminer après Tx

Update-Request

Paramètre CCFH	Commande CLI	Comportement à Tx	Comportement à RT	Le secondaire est actif	Secondaire désactivé
Continuer	update-request continuer	S/O	Continuer	Secondaire prend le relais après RT	Hors connexion après une autre RT
	update-request continuer la mise hors connexion après- tx-expiration	Hors ligne	S/O	Hors ligne à Tx	Hors ligne à Tx
	update-request continuer la tentative après- tx-expiration	Continuer	S/O	Secondaire prend le relais après Tx	Hors connexion après une autre transaction
Réessayer et terminer	update-request réessayer et terminer	S/O	Réessayer	Secondaire prend le relais après RT	Envoie CCR-T après une autre RT
Réessayer et terminer	update-request réessayer et terminer retry-after-tx-expiration	Réessayer	S/O	Secondaire prend le relais après Tx	Envoie CCR-T après une autre transmission
Terminer	update-request terminer	Terminer	S/O	Envoie CCR-T après Tx	Envoie CCR-T après Tx

Terminate-Request

Paramètre CCFH	Commande CLI	Comportement à Tx	Comportement à RT	Le secondaire est actif	Secondaire désactivé
Continuer	Terminer-request continuer	S/O	Réessayer	CCR-T est envoyé au secondaire après RT	Terminer après une autre RT
	Terminer-request continuer la mise hors connexion après- tx-expiration	Réessayer	S/O	CCR-T est envoyé au secondaire après Tx	Terminer après une autre transaction
	Terminer-request continuer la tentative après- tx-expiration	Réessayer	S/O	CCR-T est envoyé au secondaire après Tx	Terminer après une autre transaction
Réessayer et terminer	Terminer-request réessayer et terminer	S/O	Réessayer	CCR-T est envoyé au secondaire après RT	Terminer après une autre RT
Réessayer et terminer	Terminer-request réessayer et terminer retry-after-tx-expiration	Réessayer	S/O	CCR-T est envoyé au secondaire après Tx	Terminer après une autre transaction
Terminer	Terminer-request terminer	Terminer	S/O	Terminer après Tx	Terminer après Tx

Mécanisme SU

Le mécanisme SU est similaire au mécanisme FH, mais il fournit un contrôle plus granulaire des procédures de défaillance. En plus de la poursuite de la session après les échecs de niveau de message et de connexion (transport), ce mécanisme peut être utilisé lorsque les réponses sont lentes à partir du OCS. Il fournit également les options permettant de poursuivre la session pendant une certaine durée/épuisement du quota avant la fin, ou d'utiliser un quota provisoire configurable (volume et temps) et des tentatives de serveur configurables avant qu'une session ne soit convertie en mode hors connexion ou terminée.

Configuration du mécanisme SU

Le mécanisme SU peut être configuré dans les paramètres de contrôle de crédit de diamètre. La syntaxe utilisée dans la configuration SU varie en fonction de la version utilisée.

Pour les versions 12.1 et antérieures, il s'agit de la syntaxe utilisée pour la configuration du mécanisme SU :

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

Pour les versions 12.2 et ultérieures, il s'agit de la syntaxe utilisée pour la configuration du mécanisme SU :

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> ] } }

Note: Dans les versions antérieures à la version 12.2, il était possible de configurer indépendamment les mécanismes FH et SU ; cependant, dans les versions 12.2 et ultérieures, le mécanisme SU a priorité sur le mécanisme FH lorsqu'il est configuré.

Si le serveur renvoie l'AVP CC-FH et que le mécanisme SU est configuré pour un ensemble de déclencheurs de comportement, la configuration SU est appliquée ; sinon, la valeur AVP CC-FH est appliquée. Par défaut, les codes de résultats tels que 3002, 3004 et 3005 sont défaillants de livraison et sont traités comme des RTs.

Ces actions sont possibles avec le mécanisme des États-Unis :

Comportement-Déclencheur - - Indique le type de messages pouvant être des Demandes initiales (CCR-I) ou Demandes de mise à jour (CCR-U). Trois options sont disponibles pour ces déclencheurs :
- Code de résultat âÂ â Ceci permet de configurer des codes de résultat spécifiques, une plage de codes de résultat (3000-5999), ou toute erreur avec le type de message.
- Transport-Failure - â Cette spécification déclenche le comportement en cas de défaillance du transport, qui est rétrocompatible avec la version 12.0. Deux options sont disponibles pour ce paramètre :
  - Response-Timeout âÂ Â Cette option déclenche le comportement sur RT et doit toujours être utilisée avec les échecs de transport.
  - Tx-Expiry âÂ â Cette option déclenche le comportement à l'expiration de Tx et doit toujours être utilisée avec une défaillance de transport.
- Actions — â Indique l'action qui est exécutée lorsqu'un déclencheur SU pour CCR-I ou CCR-U se produit. Cette action varie en fonction du type de message et de la version du logiciel.
Continuer âÂ â Cela permet de convertir la session en mode hors connexion et de continuer. Aucune autre option n'est disponible pour l'utilisation de cette action dans les versions antérieures à la version 12.2. Dans les versions 12.2 et ultérieures, les options de quota intermédiaire, de tentatives de serveur et d'expiration après délai de temporisation sont disponibles pour la configuration avec cette action.
Terminate âÂ â Ceci entraîne la fin de la session lorsque le serveur devient inaccessible. Cette action autorise les options de quota intermédiaire, de tentatives de serveur et d'expiration après minuteur.

Ces options peuvent être utilisées avec l'action Continuer ou Terminer :

Post-intermédiaire-time âÂ â Cette option permet la continuation ou la fin de l'appel après la période de temporisation intermédiaire. Ceci est similaire à un quota de temps avant l'exécution de l'action. La valeur est formatée en secondes et peut être comprise entre 1 et 4 294 967 295.
After-intermédiaire-volume âÂ â Cette option attribue le quota intermédiaire et permet la poursuite ou la fin de la session avant l'épuisement du volume configuré. La valeur est formatée en octets et peut être comprise entre 1 et 4 294 967 295.
Server-retries - ââ' Cette option permet au PCEF de réessayer le OCS avant la poursuite ou la fin de la session. Le nombre de tentatives peut être configuré et la valeur est comprise entre 0 et 65 535. Si la valeur est égale à zéro, la nouvelle tentative ne se produit pas et l'action est immédiatement appliquée.

Note: Les options post-provisoire et post-intermédiaire-volume sont toujours utilisées avec l'option server-retries, ou les trois peuvent être utilisées simultanément et appliquées à la fois pour poursuivre et terminer les actions. Les options post-provisoire et post-intermédiaire-volume attribuent également du temps ainsi que des quotas de volume, et le quota épuisé déclenche d'abord une nouvelle tentative du serveur.

After-timer-expiration âÂ Â Cette option spécifie la durée (en secondes) pendant laquelle les sessions restent dans l'état hors connexion avant la fin. Les valeurs peuvent être comprises entre 1 et 4 294 967 295. Cette option ne s'applique qu'aux actions terminées.
Après l'expiration du quota âÂ â Cette option met fin à la session à l'épuisement du quota déjà assigné.

Voici quelques informations importantes à retenir :

Les options post-provisoire, post-intermédiaire-volume et server-retries peuvent être utilisées individuellement ou en combinaison, et elles sont applicables aux actions de poursuite et de fin.
L'option post-quota-expiration ne s'applique qu'au déclencheur de comportement Update-Requests.
L'option post-expiration du compteur ne s'applique qu'à l'action de fin.
Les options post-provisoire, post-provisoire-volume et server-retries ne s'appliquent qu'aux versions 12.2 et ultérieures.
Si le basculement de session de diamètre est pris en charge (et configuré), le serveur secondaire est toujours contacté avant le déclenchement du mécanisme SU.
Le serveur qui a été contacté avant le déclenchement du mécanisme de l'unité de mesure est toujours contacté lorsque l'heure ou le volume intermédiaire est épuisé et que l'option de nouvelles tentatives du serveur est configurée avec une valeur supérieure à zéro. Par exemple, si OCS1 est essayé en premier et OCS2 est essayé après une erreur sur OCS1, alors la communication avec OCS2 déclenche le mécanisme SU. Pendant la tentative de nouvelle tentative du serveur, OCS2 est contacté en premier, puis OCS1 si une réponse négative est reçue d'OCS2.

Flux d'appels du mécanisme SU

Le mécanisme SU peut être déclenché par une défaillance du CCR-I ou du CCR-U, et la cause peut être un code d'erreur, une défaillance de transport, une expiration de Tx ou une RT. L'action peut être une allocation de quota intermédiaire (temps et/ou volume), le nombre de tentatives du serveur, la valeur du compteur (cause la déconnexion de la session pendant une durée spécifiée et uniquement pour la fin), ou l'expiration du quota (uniquement pour le CCR-U et la fin) avant que la session ne soit hors connexion ou se termine.

Le quota provisoire est fourni par session et non par groupe de cotation (RG) dans les scénarios MSCC (Multiple Services Credit Control).

Il est possible que le serveur principal déclenche une défaillance de transport et que le serveur secondaire déclenche l'expiration de délai de réponse ou l'expiration de délai de réponse. Dans ce scénario, la dernière erreur est considérée comme le déclencheur de l'échec.

Si le mécanisme SU n'est configuré pour aucun déclencheur de défaillance, le mécanisme FH est déclenché.

Note: Les sections suivantes fournissent des exemples de flux d'appels liés au mécanisme SU. Ces flux d'appels sont fournis sous l'hypothèse que le basculement de session de diamètre est pris en charge et que le serveur secondaire est configuré avec une valeur d'expiration Tx inférieure à la valeur RT. En outre, on suppose que le mécanisme SU est configuré pour les défaillances de transport, Tx-expiration et RT.

Demande initiale sans déconnexion de session