Sans fil : Gamme Cisco ASR 5000

Configurez la Panne-manipulation et les mécanismes Serveur-inaccessibles pour la résolution de panne OCS concernant l'ASR5K

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (21 avril 2016) | Commentaires

Introduction

Ce document décrit comment configurer la Panne-manipulation (FH) et les mécanismes (SU) Serveur-inaccessibles sur la GY relient afin de résoudre les problèmes qui sont produits sur le système de remplissage en ligne (OCS) ou en vue de la Connectivité entre la stratégie et la fonction de remplissage d'application (PCEF) et l'OCS. Les informations qui sont décrites dans ce document s'appliquent les fonctionnalités à l'agent à la maison (ha), au noeud de support de Service général de radiocommunication par paquets (GPRS) de passerelle (GGSN), et de données de paquets à passerelle de réseau (PGW) qui fonctionnent sur le routeur de services agrégé par gamme Cisco 5000 (ASR5K).

Contribué par Shashank Varshney, ingénieur TAC Cisco.

Conditions préalables

Conditions requises

Cisco recommande que votre rassemblement de système ces conditions requises afin d'utiliser les mécanismes FH et du SU :

  • Le service de remplissage amélioré (ECS) est disponible

  • Le PCEF existe dans l'ha, le GGSN, ou le PGW

  • Il y a de Connectivité appropriée de diamètre par l'intermédiaire du diabase

  • L'application d'encadrement du crédit de diamètre (DCCA) est disponible

Composants utilisés

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

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Informations générales

Le PCEF est connecté à l'OCS au-dessus de l'interface de la GY, qui utilise le diamètre comme protocole et DCCA de base. C'est le flux des messages entre le PCEF et l'OCS :

  • Demande d'encadrement du crédit (CCR) ? Ce message est envoyé du PCEF à l'OCS. Il y a trois types de messages CCR : L'initiale, mise à jour, et se terminent.

  • Réponse d'encadrement du crédit (CCA) ? Ce message est envoyé de l'OCS au PCEF en réponse au CCR. Il y a également trois types de messages de CCA : L'initiale, mise à jour, et se terminent.

  • Demande de Re-autorisation (RAR) ? Ce message est envoyé de l'OCS au PCEF quand une re-autorisation de session est exigée.

  • Réponse de Re-autorisation (RAA) ? C'est la réponse au RAR du PCEF à l'OCS.

La Connectivité de diamètre est établie entre le PCEF et l'OCS afin d'activer le flux des messages. Il y a une possibilité que l'OCS pourrait envoyer les messages négatifs, la connexion de transport pourrait échouer entre le PCEF et l'OCS, ou le message pourrait le délai d'attente, qui peut entraîner une panne dans l'établissement de session d'abonné. Ceci peut empêcher l'abonné de l'utilisation des services.

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

  • Le mécanisme FH

  • Le mécanisme du SU

Configurez

Cette section décrit les configurations qui sont exigées afin de prendre en charge les mécanismes FH et du SU.

Diagramme du réseau

Les informations dans ce document utilisent cette topologie :

Tx-échéance

C'est un temporisateur de niveau application pour le DCCA qui est configurable dans les configurations d'encadrement du crédit de diamètre. La valeur peut s'étendre entre 1 et 300 secondes.

Voici un exemple :

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

Temporisation de réponse

C'est un délai d'attente de diabase et est configurable dans les configurations de point final de diamètre. La valeur peut s'étendre entre 1 et 300 secondes.

Remarque: La valeur qui est configurée pour ce temporisateur devrait être plus grande que cela utilisée pour la Tx-échéance temporisateur.

Voici un exemple :

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

Basculement de session de diamètre

Cette caractéristique est utilisée afin d'activer ou désactiver le Basculement de session d'encadrement du crédit de diamètre, qui permet au système pour utiliser un serveur secondaire quand le serveur primaire devient inaccessible. C'est configurable dans les configurations d'encadrement du crédit de diamètre.

Voici un exemple :

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

Mécanisme FH

Le mécanisme FH fonctionne seulement si le Basculement de session de diamètre est présent. Le FH permet au système pour choisir si continuer la session et la conversion à off-line, ou terminer la session quand une erreur de connexion ou de niveau de message se produit.

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

Configuration de mécanisme FH

Le mécanisme FH peut être configuré dans les configurations d'encadrement du crédit de diamètre. Voici la syntaxe qui est 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 requête : L'initiale (CCR-I), la mise à jour (CCR-U), et se terminent (CCR-T).

La deuxième section spécifie l'action qui devrait être exécutée quand le mécanisme FH est lancé. Ces trois actions sont possibles avec le mécanisme FH :

  • Continuez ? Ceci permet à la session pour continuer et la convertit en off-line. Cette fonction utilise deux options qui sont liées à la Tx-échéance :

    • Aller-hors ligne-après-tx-échéance ? Ceci commence off-line le remplissage après que la Tx-échéance se produise.

    • Relance-après-tx-échéance ? Ceci relance le serveur secondaire après que la Tx-échéance se produise.

  • Relance-et-terminez ? Ceci termine la session après que le système relance le serveur secondaire, si le serveur secondaire n'est pas disponible non plus. Ceci utilise également la Relance-après-tx-échéance option, qui relance le serveur secondaire après que la Tx-échéance se produise.

  • Terminez ? Ceci ne termine la session sans aucune tentative de contacter le serveur secondaire.

Comportement par défaut de mécanisme FH

Cette section décrit le comportement par défaut FH quand aucune configuration n'est présente. Par défaut, le mécanisme FH est lancé pendant une temporisation de réponse (droite), excepté quand l'action de terminaison est configurée.

Si une paire de valeurs d'attribut de Crédit-Contrôle-Panne-manipulation (AVP) est reçue du serveur, alors les configurations reçues sont appliquées.

Voici quelques exemples :

  • La requête initiale > se terminent

  • La Mise à jour-demande > Relance-et-se terminent

  • La Terminer-demande > Relance-et-se terminent

Écoulement d'appel détaillé de mécanisme FH

Cette section décrit l'écoulement d'appel détaillé du mécanisme FH avec tous les choix possibles.

Requête initiale

Configuration CCFHCommande CLIComportement chez TxComportement à la droiteSecondaire est Secondaire est vers le bas

Continuez

requête initiale
continuez

S/O

Continuez

Secondaire
succède ensuite
Droite

Off-line après une autre droite.
Plus de demandes de quota ne sont exécutées
pour tout groupe de évaluation dans la session
après panne DCCA (même si
la Connectivité à DCCA est restaurée)

requête initiale
continuez aller-hors ligne-après
tx-échéance

Off-line

S/O

Off-line chez Tx

Off-line chez Tx

requête initiale
continuez relance-après
tx-échéance

Continuez

S/O

Secondaire
succède ensuite
Tx

Off-line après un autre Tx

Relance-et-terminez

requête initiale
relance-et-terminez

S/O

Relance

Secondaire
succède ensuite
Droite

Terminez après une autre droite

requête initiale
relance-et-terminez
relance-après-tx-échéance

Relance

S/O

Secondaire
succède ensuite
Tx

Terminez après un autre Tx

Terminez

requête initiale
terminez

Terminez

S/O

Terminez après Tx

Terminez après Tx

Mise à jour-demande

Configuration CCFHCommande CLIComportement chez TxComportement à la droiteSecondaire est Secondaire est vers le bas

Continuez

mise à jour-demande
continuez

S/O

Continuez

Secondaire
succède ensuite
Droite

Off-line après une autre droite

mise à jour-demande
continuez aller-hors ligne-après
tx-échéance

Off-line

S/O

Off-line chez Tx

Off-line chez Tx

mise à jour-demande
continuez relance-après
tx-échéance

Continuez

S/O

Secondaire
succède ensuite
Tx

Off-line après un autre Tx

Relance-et-terminez

mise à jour-demande
relance-et-terminez

S/O

Relance

Secondaire
succède ensuite
Droite

Envoie CCR-T après une autre droite

mise à jour-demande
relance-et-terminez
relance-après-tx-échéance

Relance

S/O

Secondaire
succède ensuite
Tx

Envoie CCR-T après un autre Tx

Terminez

mise à jour-demande
terminez

Terminez

S/O

Envoie CCR-T après Tx

Envoie CCR-T après Tx

Terminer-demande

Configuration CCFHCommande CLIComportement chez TxComportement à la droiteSecondaire est Secondaire est vers le bas

Continuez

terminer-demande
continuez

S/O

Relance

CCR-T est envoyé
à secondaire
après droite

Terminez après une autre droite

terminer-demande
continuez aller-hors ligne-après
tx-échéance

Relance

S/O

CCR-T est envoyé
à secondaire
après Tx

Terminez après un autre Tx

terminer-demande
continuez relance-après
tx-échéance

Relance

S/O

CCR-T est envoyé
à secondaire
après Tx

Terminez après un autre Tx

Relance-et-terminez

terminer-demande
relance-et-terminez

S/O

Relance

CCR-T est envoyé
à secondaire
après droite

Terminez après une autre droite

terminer-demande
relance-et-terminez
relance-après-tx-échéance

Relance

S/O

CCR-T est envoyé
à secondaire
après Tx

Terminez après un autre Tx

Terminez

terminer-demande
terminez

Terminez

S/O

Terminez ensuite
Tx

Terminez après Tx

Mécanisme du SU

Le mécanisme du SU est semblable le mécanisme FH, mais il fournit un contrôle plus granulaire des procédures de panne. En plus de la suite de la session après que le message et les pannes niveau de la connexion (de transport), ce mécanisme puissent être utilisés quand les réponses sont lentes de l'OCS. Il fournit également les options à continuent l'épuisement de durée/quota de session pendant quelque temps avant arrêt, ou utilisent (le volume et le temps) intérimaires configurables de quota et le serveur configurable relance avant qu'une session soit convertie en off-line ou terminée. 

Configuration de mécanisme du SU

Le mécanisme du SU peut être configuré dans les configurations d'encadrement du crédit de diamètre. La syntaxe qui est utilisée dans la configuration du SU varie selon la version qui est utilisée.

Pour des versions 12.1 et antérieures, c'est la syntaxe qui est utilisée pour la configuration de mécanisme du SU :

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

Pour des versions 12.2 et ultérieures, c'est la syntaxe qui est utilisée pour la configuration de mécanisme du 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> ] } }

Remarque: Dans les versions avant la version 12.2, il y avait de flexibilité de configurer les mécanismes FH et du SU indépendamment ; cependant, dans les versions 12.2 et ultérieures, le mécanisme du SU a la priorité au-dessus du mécanisme FH une fois configuré.

Si le serveur renvoie le CC-FH AVP, et le mécanisme du SU est configuré pour un ensemble de déclencheurs de comportement, alors la configuration du SU est appliquée ; autrement, la valeur CC-FH AVP est appliquée. Par défaut, des codes de résultat tels que la chute 3002, 3004, et 3005 sous la panne de la livraison et sont traités comme rts.

Ces actions sont possibles avec le mécanisme du SU :

  • Comportement-déclencheur ? Ceci spécifie le type de messages qui peuvent être les requêtes initiales (CCR-I) ou les Mise à jour-demandes (CCR-U). Il y a trois options disponibles pour ces déclencheurs :

    • Résultat-code ? Ceci permet la configuration des codes spécifiques de résultat, de la plage des codes de résultat (3000-5999), ou de n'importe quelle erreur avec le type de message.

    • Transport-panne ? Cette spécification déclenche le comportement sur la panne de transport, qui est vers l'arrière compatible avec la version 12.0. Il y a deux options disponibles pour cette configuration :

      • Response-timeout ? Cette option déclenche le comportement sur la droite et devrait toujours être utilisée avec des pannes de transport.

      • Tx-échéance ? Cette option déclenche le comportement sur la Tx-échéance et devrait toujours être utilisée avec la panne de transport.

    • Actions ? Ceci spécifie l'action qui est exécutée quand le SU déclenchent pour CCR-I ou CCR-U se produit. Cette action varie selon le type de message et la version de logiciel.

  • Continuez ? Ceci permet la session à convertir en off-line et continue. Il n'y a aucune autre option disponible pour l'usage de cette action dans les versions avant la version 12.2. Dans les versions 12.2 et ultérieures, le quota, les serveur-relances, et l'après-temporisateur-échéance intérimaires options sont disponibles pour la configuration avec cette action.

  • Terminez ? Ceci a comme conséquence l'arrêt de la session quand le serveur devient inaccessible. Cette action accorde le quota, les serveur-relances, et l'après-temporisateur-échéance intérimaires options.

Ces options peuvent être utilisées avec la continuation ou terminer l'action :

    • Après-intérim-temps ? Cette option permet la continuité ou l'arrêt de l'appel après le délai d'inactivité intérimaire. C'est semblable à un quota de temps avant que l'action soit exécutée. La valeur est formatée en quelques secondes et peut s'étendre entre 1 et 4,294,967,295.

    • Après-intérim-volume ? Cette option assigne le quota intérimaire et permet la continuité ou l'arrêt de la session avant l'épuisement du volume configuré. La valeur est formatée dans les octets et peut s'étendre entre 1 et 4,294,967,295.

    • Serveur-relances ? Cette option permet au PCEF pour relancer l'OCS avant continuité ou arrêt de la session. Le nombre de tentatives peut être configuré, et les plages de valeur entre 0 et 65,535. Si la valeur est zéro, alors la relance ne se produit pas et l'action est immédiatement appliquée.

Remarque: Les options d'après-intérim-temps et d'après-intérim-volume sont toujours utilisées avec l'option de serveur-relances, ou chacun des trois peut être utilisé simultanément et appliqué à continuez et terminez les actions. Les options d'après-intérim-temps et d'après-intérim-volume assignent également le quota de temps aussi bien que de volume, et le quota qui est épuisé d'abord déclenche la relance de serveur.

  • Après-temporisateur-échéance ? Cette option spécifie la durée de temps (en quelques secondes) lesoù les sessions demeurent dans l'état hors ligne avant que l'arrêt se produise. Les valeurs peuvent s'étendre entre 1 et 4,294,967,295. Cette option s'applique seulement pour terminent des actions.

  • Après-quota-échéance ? Cette option termine la session sur l'épuisement du quota déjà assigné.

Voici quelques informations importantes à se souvenir :

  • L'après-intérim-temps, après-intérim-volume, et des options de serveur-relances peuvent être utilisées individuellement ou en association, et elles s'appliquent à continuent et se terminent actions.

  • L'après-quota-échéance option s'applique seulement pour le déclencheur de comportement de Mise à jour-demandes.

  • L'après-temporisateur-échéance option s'applique seulement pour l'action de terminaison.

  • L'après-intérim-temps, l'après-intérim-volume, et les options de serveur-relances s'appliquent seulement pour des versions 12.2 et ultérieures.

  • Si le Basculement de session de diamètre est pris en charge (et configuré), alors le serveur secondaire est toujours contacté avant que le mécanisme du SU soit déclenché.

  • Le serveur qui a été contacté pour la dernière fois avant que le mécanisme du SU soit déclenché est toujours contacté quand le volume intérimaire de temps ou d'intérim est épuisé et les relances de serveur que l'option est configurée avec une valeur qui est plus grande que zéro. Par exemple, si OCS1 est essayé d'abord, et OCS2 est essayé après une erreur à OCS1, alors transmission avec OCS2 déclenche le mécanisme du SU. Pendant la tentative de relance de serveur, OCS2 d'abord et puis est entré en contact OCS1 si une réponse négative est reçue d'OCS2.

Écoulements d'appel de mécanisme du SU

Le mécanisme du SU peut être déclenché par une panne du CCR-I ou du CCR-U, et la cause peut être code d'erreur, une panne de transport, une Tx-échéance, ou une droite. L'action peut être une allocation de quota intérimaire (temps et/ou volume), de compte de relances de serveur, de valeur de temporisateur (fait aller la session off-line pendant le temps spécifié et seulement pour l'arrêt), ou d'échéance de quota (seulement pour le CCR-U et l'arrêt) avant que la session aille off-line ou se termine.

Le quota intérimaire n'est fourni sur une base de par-session, pas une base du groupe de par-évaluation (RG) dans des scénarios de l'encadrement du crédit de plusieurs services (MSCC).

Il y a une possibilité que les déclencheurs primaires de serveur transportent la panne et le serveur secondaire déclenche la Tx-échéance ou la response-timeout. Dans ce scénario, la dernière erreur est considérée le déclencheur de la panne.

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

Remarque: Les sections qui suivent fournissent quelques exemples d'écoulement d'appel qui sont liés au mécanisme du SU. Ces écoulements d'appel sont fournis dans la supposition que le diamètre-session-Basculement est pris en charge et le serveur secondaire est configuré avec une Tx-échéance valeur qui est moins que la valeur droite. En outre, on le suppose que le mécanisme du SU est configuré pour la transport-panne, la Tx-échéance, et la droite.

Requête initiale sans débranchement de session

Voici le flux des messages pour ce scénario :

  1. Le PCEF envoie un CCR-I à l'OCS.

  2. Une panne de délai d'attente ou de transport est détectée. Si la panne de transport est détectée, alors le PCEF relance immédiatement avec le serveur secondaire ; autrement, la Tx-échéance est déclenchée.

  3. Si le serveur secondaire a également une panne ou un délai d'attente de transport, alors le mécanisme du SU est déclenché. Ceci se produit immédiatement pour des pannes de transport, ou après la Tx-échéance pour un délai d'attente.

  4. Si le volume et/ou le temps intérimaires sont configurés, alors le quota intérimaire est assigné à la session.

  5. Après l'épuisement du quota intérimaire (temps ou volume) et si la valeur de relances de serveur est plus grande que zéro, puis le CCR-I est de nouveau envoyé au serveur qui a déclenché le mécanisme du SU. S'il y a une autre panne, le CCR-I est envoyé à un autre serveur.

  6. Si la panne ou le tx-timeout de transport est de nouveau détectée, alors étapes 2 à 5 sont répétées jusqu'à ce que la valeur de relances de serveur soit épuisée ou une réponse réussie ne provient pas l'OCS.

  7. Si la question existe toujours, alors la session est continuée (converti en off-line) ou terminée selon la configuration.

Remarque: Le quota intérimaire qui est consommé tandis que la session entre dans le mode du SU dû à CCR-I n'est pas signalé dans le prochain CCR-I. Tout les quota intérimaire utilisé est signalé dans le CCR-U, qui suit le CCA-I réussi.

Requête initiale avec le débranchement de session

Voici le flux des messages pour ce scénario :

  1. Le PCEF envoie un CCR-I à l'OCS.

  2. Une panne de délai d'attente ou de transport est détectée. Si la panne de transport est détectée, alors le PCEF relance immédiatement avec le serveur secondaire ; autrement, la Tx-échéance est déclenchée.

  3. Si le serveur secondaire a également une panne ou un délai d'attente de transport, alors le mécanisme du SU est déclenché. Ceci se produit immédiatement pour des pannes de transport, ou après la Tx-échéance pour un délai d'attente.

  4. Si le volume et/ou le temps intérimaires sont configurés, alors le quota intérimaire est assigné à la session.

  5. Après l'épuisement du quota intérimaire (temps ou volume) et si la valeur de relances de serveur est plus grande que zéro, puis le CCR-I est de nouveau envoyé au serveur qui a déclenché le mécanisme du SU. S'il y a une autre panne, le CCR-I est envoyé à un autre serveur.

  6. Si la panne ou le tx-timeout de transport est de nouveau détectée, alors étapes 2 à 5 sont répétées jusqu'à ce que la valeur de relances de serveur soit épuisée ou une réponse réussie ne provient pas l'OCS. En ce moment, la session est déconnectée sans consommation du quota intérimaire entier.

  7. Après fermeture de session, le PCEF envoie de nouveau le CCR-I afin de commencer une nouvelle session. Si c'est réussi, alors le PCEF envoie le CCR-T, qui signale le quota provisoire de totalité qui a été utilisé.

Mise à jour-demande sans débranchement de session

Voici le flux des messages pour ce scénario :

  1. Le PCEF envoie un CCR-U à l'OCS.

  2. Une panne de délai d'attente ou de transport est détectée. Si la panne de transport est détectée, alors le PCEF relance immédiatement avec le serveur secondaire ; autrement, la Tx-échéance est déclenchée.

  3. Si le serveur secondaire a également une panne ou un délai d'attente de transport, alors le mécanisme du SU est déclenché. Ceci se produit immédiatement pour des pannes de transport, ou après la Tx-échéance pour un délai d'attente.

  4. Si le volume et/ou le temps intérimaires sont configurés, alors le quota intérimaire est assigné à la session.

  5. Après l'épuisement du quota intérimaire (temps ou volume) et si la valeur de relances de serveur est plus grande que zéro, puis le CCR-U est de nouveau envoyé au serveur qui a déclenché le mécanisme du SU. S'il y a une autre panne, un CCR-U est envoyé à un autre serveur qui contient le quota non rapporté consommé entier.

  6. Si la panne ou le tx-timeout de transport est de nouveau détectée, alors étapes 2 à 5 sont répétées jusqu'à ce que la valeur de relances de serveur soit épuisée ou une réponse réussie ne provient pas l'OCS.

  7. Le quota consommé entier est signalé à l'OCS avec le CCR-U réussi.

  8. Si la question existe toujours, alors la session est continuée (converti en off-line) ou terminée selon la configuration après l'épuisement de la valeur de réessai maximum.

Mise à jour-demande avec le débranchement de session

Voici le flux des messages pour ce scénario :

  1. Le PCEF envoie un CCR-U à l'OCS.

  2. Une panne de délai d'attente ou de transport est détectée. Si la panne de transport est détectée, alors le PCEF relance immédiatement avec le serveur secondaire ; autrement, la Tx-échéance est déclenchée.

  3. Si le serveur secondaire a également une panne ou un délai d'attente de transport, alors le mécanisme du SU est déclenché. Ceci se produit immédiatement pour des pannes de transport, ou après la Tx-échéance pour un délai d'attente.

  4. Si le volume et/ou le temps intérimaires sont configurés, alors le quota intérimaire est assigné à la session.

  5. Après l'épuisement du quota intérimaire (temps ou volume) et si la valeur de relances de serveur est plus grande que zéro, puis le CCR-U est de nouveau envoyé au serveur qui a déclenché le mécanisme du SU. S'il y a une autre panne, un CCR-U est envoyé à un autre serveur qui contient le quota non rapporté consommé entier.

  6. Si la panne ou le tx-timeout de transport est de nouveau détectée, alors étapes 2 à 5 sont répétées jusqu'à ce que la valeur de relances de serveur soit épuisée ou une réponse réussie ne provient pas l'OCS. En ce moment, la session est déconnectée avant qu'elle consomme le quota provisoire entier.

  7. Le PCEF envoie un CCR-T à l'OCS afin de signaler le quota consommé entier.

  8. Si l'OCS répond avec un code de 2002 résultats, alors les états supplémentaires ne sont pas nécessaires.

Mise à jour-demande avec la session inconnue

Voici le flux des messages pour ce scénario :

  1. Le PCEF envoie un CCR-U à l'OCS.

  2. Une panne de délai d'attente ou de transport est détectée. Si la panne de transport est détectée, alors le PCEF relance immédiatement avec le serveur secondaire ; autrement, la Tx-échéance est déclenchée.

  3. Si le serveur secondaire a également une panne ou un délai d'attente de transport, alors le mécanisme du SU est déclenché. Ceci se produit immédiatement pour des pannes de transport, ou après la Tx-échéance pour un délai d'attente.

  4. Si le volume et/ou le temps intérimaires sont configurés, alors le quota intérimaire est assigné à la session.

  5. Après l'épuisement du quota intérimaire (temps ou volume) et si la valeur de relances de serveur est plus grande que zéro, puis le CCR-U est de nouveau envoyé au serveur qui a déclenché le mécanisme du SU. S'il y a une autre panne, un CCR-U est envoyé à un autre serveur qui contient le quota non rapporté consommé entier.

  6. L'OCS répond avec un code du résultat 5002 (d'ID de session inconnu) pour le CCR-U, qui est possible dans le scénario où l'OCS redémarré et perdu les informations d'ID de session.

  7. Le PCEF initie une nouvelle session avec le CCR-I et reçoit le CCA-I.

  8. Le PCEF signale le quota intérimaire consommé entier par l'intermédiaire de CCR-U dans les messages ultérieurs.

Mise à jour-demande avec plusieurs RGs (scénario MSCC)

Voici le flux des messages pour ce scénario :

  1. Le PCEF envoie le CCR-U pour RG1 à l'OCS.

  2. Une panne de délai d'attente ou de transport est détectée. Si la panne de transport est détectée, alors le PCEF relance immédiatement avec le serveur secondaire ; autrement, la Tx-échéance est déclenchée.

  3. Si le serveur secondaire a également une panne ou un délai d'attente de transport, alors le mécanisme du SU est déclenché. Ceci se produit immédiatement pour des pannes de transport, ou après la Tx-échéance pour un délai d'attente.

  4. Si le volume et/ou le temps intérimaires sont configurés, alors le quota intérimaire est assigné à la session

  5. En ce moment RG2 également épuise le quota assigné entier mais n'initie pas le CCR-U parce que la session est déjà en mode du SU et commence à consommer le quota intérimaire.

  6. Après l'épuisement du quota intérimaire (temps ou volume) et si la valeur de relances de serveur est plus grande que zéro, puis le CCR-U est de nouveau envoyé au serveur qui a déclenché le mécanisme du SU. S'il y a une autre panne, un CCR-U est envoyé à un autre serveur qui contient le quota non rapporté consommé entier pour chacun des deux le RGs.

  7. Si la panne ou le tx-timeout de transport est de nouveau détectée, alors étapes 2 à 6 sont répétées jusqu'à ce que la valeur de relances de serveur soit épuisée ou une réponse réussie ne provient pas l'OCS.

  8. Le quota consommé entier est signalé à l'OCS avec le CCR-U réussi.

  9. Si la question existe toujours, alors la session est continuée (converti en off-line) ou terminée selon la configuration après l'épuisement de la valeur de réessai maximum.

Terminer-demande

Voici le flux des messages pour ce scénario :

  1. Le PCEF envoie un CCR-T à l'OCS.

  2. Une panne de délai d'attente ou de transport est détectée. Si la panne de transport est détectée, alors le PCEF relance immédiatement avec le serveur secondaire ; autrement, la Tx-échéance est déclenchée.

  3. Si le serveur secondaire a également une panne ou un délai d'attente de transport, alors la session est retirée.

Manipulation de code d'erreur CCR

Voici le flux des messages pour ce scénario :

  1. Les PCEF envoient un CCR à l'OCS, et l'OCS répond avec code d'erreur.

  2. Code d'erreur est statiquement configuré dans le mécanisme du SU.

  3. Le PCEF fournit le quota intérimaire sans relance au serveur secondaire.

Exemples de configuration FH et du SU

Cette section fournit un exemple de configuration pour les mécanismes FH et du SU. Quand les mécanismes FH et du SU sont configurés, le SU a la priorité au-dessus du FH pour le même déclencheur de comportement.

Voici un exemple :

credit-control group test

diameter origin endpoint test

diameter peer-select peer test

quota volume-threshold percent 10

diameter pending-timeout 80 deciseconds msg-type any

diameter session failover

trigger type rat lac

apn-name-to-be-included virtual

quota request-trigger exclude-packet-causing-trigger

failure-handling initial-request continue retry-after-tx-expiry

servers-unreachable initial-request terminate after-interim-volume 200
after-interim-time 3600 server-retries 0

servers-unreachable behavior-triggers initial-request transport-failure
tx-expiry

servers-unreachable update-request continue after-interim-volume 200
after-interim-time 3600 server-retries 50

servers-unreachable behavior-triggers update-request transport-failure
tx-expiry

Vérifiez

Afin de vérifier que votre configuration fonctionne correctement, sélectionnez la commande de actif-remplissage de name> de <service de service d'exposition :

# show active-charging service name test



Service name: test



TCP Flow Idle Timeout : 300 (secs)

UDP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ICMP Flow Idle Timeout : 300 (secs)

ALG Media Idle Timeout : 120 (secs)



TCP Flow-Mapping Idle Timeout : 300 (secs)

UDP Flow-Mapping Idle Timeout : Not Configured



Deep Packet Inspection: Enabled

Passive Mode : Disabled

CDR Flow Control : Enabled

CDR Flow Control Unsent Queue Size: 75

Unsent Queue high watermark: 56

Unsent Queue low watermark: 18



Content Filtering: Disabled



Dynamic Content Filtering: Disabled



URL-Blacklisting: Disabled

URL-Blacklisting Match-method: Exact



Content Filtering Match-method: Generic





Interpretation of Charging-rule-base-name: active-charging-group-of-ruledefs





Selection of Charging-rule-base AVP : Last



Credit Control:

Group : test



Mode : diameter

APN-name-to-be-included: gn

Trigger-Type : N/A



Failure-Handling:

Initial-Request : continue retry-after-tx-expiry

Update-Request : retry-and-terminate

Terminate-Request: retry-and-terminate



Server Unreachable Failure-Handling:

Initial-Request : terminate

Update-Request : continue

Dépannez

Sélectionnez la commande de actif-remplissage de statistiques d'encadrement du crédit d'exposition afin de visualiser les statistiques qui sont liés aux mécanismes du SU et FH. Voici un exemple de sortie :

#show active-charging credit-control statistics
...

OCS Unreachable Stats:

Tx-Expiry: 2291985 Response-TimeOut: 615

Connection-Failure: 2 Action-Continue: 0

Action-Terminated: 0 Server Retries: 2023700



Assumed-Positive Sessions:

Current: 2 Cumulative: 2196851

Voici quelques informations importantes au sujet de cet exemple de sortie :

  • Tx-échéance ? Ceci indique un état du SU dû à une Tx-échéance.

  • Response-timeout ? Ceci indique un état du SU dû à une droite.

  • Connexion-panne ? Ceci indique un état du SU dû à une panne de transport.

  • Action continue ? Ce champ indique le nombre de sessions qui sont allées off-line.

  • Action-terminez ? Ce champ indique le nombre de sessions qui ont été terminées.

  • Relances de serveur ? Ce champ indique le nombre de fois que l'OCS a été relancées.

  • Sessions Supposer-positives :

    • Courant ? Ce champ indique le nombre de sessions qui sont actuellement en état du SU.

    • Cumulatif ? Ce champ indique le nombre total de sessions qui sont entrées dans l'état du SU.

Écrivez les sessions de actif-remplissage d'exposition complètement toute la commande afin de visualiser les informations qui sont liées à l'état du SU de la session. Voici un exemple de sortie :

#show active-charging sessions full all
..
..

Current Server Unreachable State: CCR-I

Interim Volume in Bytes (used / allotted): 84/ 200

Interim Time in Seconds (used / allotted): 80/ 3600

Server Retries (attempted / configured): 1/ 50

Voici quelques informations importantes au sujet de cet exemple de sortie :

  • État inaccessible de serveur en cours ? Ceci spécifie si le courant SU énoncent est dû au CCR-I ou au CCR-U.

  • Le volume intérimaire dans les octets (utilisés/répartis) ? ceci affiche le volume intérimaire dans les octets utilisés contre des octets alloués.

  • Temps intérimaire en quelques secondes (utilisées/réparties) ? ceci affiche le volume intérimaire en quelques secondes utilisées contre des secondes allouées.

  • Le serveur relance (tenté/configuré) ? ceci est le nombre de relances de serveur tentées contre cela configurée.

Informations connexes



Document ID: 118993