Tecnología inalámbrica : Cisco ASR de la serie 5000

Error-dirección de la configuración y mecanismos Servidor-inalcanzables para la resolución del error OCS en el ASR5K

18 Junio 2016 - Traducción Automática
Otras Versiones: PDFpdf | Comentarios

Introducción

Este documento describe cómo configurar la Error-dirección (FH) y los mecanismos Servidor-inalcanzables (SU) en la GY interconecta para resolver los problemas que se encuentran en el sistema de carga en línea (OCS) o con respecto a la Conectividad entre la directiva y la función de carga de la aplicación (PCEF) y el OCS. La información que se describe en este documento es aplicable al Home Agent (HA), al nodo de soporte del General Packet Radio Service del gateway (GPRS) (GGSN), y las funciones al gateway de la red de los datos del paquete (PGW) que se ejecutan en el router agregado las Cisco 5000 Series de los servicios (ASR5K).

Contribuido por Shashank Varshney, ingeniero de Cisco TAC.

Prerrequisitos

Requisitos

Cisco recomienda que su reunión del sistema estos requisitos para utilizar los mecanismos FH y SU:

  • El servicio de carga aumentado (ECS) está disponible

  • El PCEF existe dentro del HA, del GGSN, o del PGW

  • Hay Conectividad apropiada del diámetro vía la diabasa

  • La aplicación de control del crédito del diámetro (DCCA) está disponible

Componentes Utilizados

La información en este documento se basa en todas las versiones del ASR5K.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener cualquier comando.

Antecedentes

El PCEF está conectado con el OCS sobre la interfaz GY, que utiliza el diámetro como el protocolo y el DCCA bajos. Éste es el flujo de mensajes entre el PCEF y el OCS:

  • Petición del control de crédito (CCR) – Este mensaje se envía del PCEF al OCS. Hay tres tipos de mensajes CCR: La inicial, actualización, y termina.

  • Respuesta del control de crédito (CCA) – Este mensaje se envía del OCS al PCEF en respuesta al CCR. Hay también tres tipos CCA de mensajes: La inicial, actualización, y termina.

  • Petición de la Re-autorización (RAR) – Este mensaje se envía del OCS al PCEF cuando se requiere una re-autorización de la sesión.

  • Respuesta de la Re-autorización (RAA) – Ésta es la respuesta a RAR del PCEF al OCS.

La Conectividad del diámetro se establece entre el PCEF y el OCS para habilitar el flujo de mensajes. Hay una posibilidad que el OCS pudo enviar los mensajes negativos, la conexión del transporte pudo fallar entre el PCEF y el OCS, o el mensaje pudo el descanso, que puede causar un error en el establecimiento de sesión del suscriptor. Esto puede prevenir al suscriptor del uso de los servicios.

Estos dos mecanismos se pueden utilizar para resolver este problema:

  • El mecanismo FH

  • El mecanismo SU

Configurar

Esta sección describe las configuraciones que se requieren para soportar los mecanismos FH y SU.

Diagrama de la red

La información en este documento utiliza esta topología:

Tx-vencimiento

Esto es un temporizador del nivel de la aplicación para el DCCA que es configurable en las configuraciones del crédito-control del diámetro. El valor puede extenderse entre 1 y 300 segundos.

Aquí tiene un ejemplo:

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

Tiempo de espera de respuesta agotado

Esto es un descanso de la diabasa y es configurable en las configuraciones del punto final del diámetro. El valor puede extenderse entre 1 y 300 segundos.

Nota: El valor que se configura para este temporizador debe ser mayor que lo usado para el temporizador del Tx-vencimiento.

Aquí tiene un ejemplo:

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

Transmisión de la sesión por un error del diámetro

Esta característica se utiliza para habilitar o inhabilitar la transmisión de la sesión por un error del control de crédito del diámetro, que permite que el sistema utilice a un servidor secundario cuando el servidor primario hace inalcanzable. Esto es configurable en las configuraciones del crédito-control del diámetro.

Aquí tiene un ejemplo:

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

Mecanismo FH

El mecanismo FH actúa solamente si la transmisión de la sesión por un error del diámetro está presente. El FH permite que el sistema elija si continuar la sesión y al convertido a off-liné, o terminar la sesión cuando ocurre un error de la conexión o del nivel de mensaje.

Nota: El FH se habilita y se configura por abandono.

Configuración del mecanismo FH

El mecanismo FH se puede configurar en las configuraciones del crédito-control del diámetro. Aquí está el sintaxis que se utiliza en la configuración 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 primera sección especifica el tipo de la petición: La inicial (CCR-I), la actualización (CCR-U), y terminan (CCR-T).

La segunda sección especifica la acción que debe ser realizada cuando se activa el mecanismo FH. Estas tres acciones son posibles con el mecanismo FH:

  • Continúe – Esto permite que la sesión continúe y la convierte a off-liné. Esta función utiliza dos opciones que se relacionen con el Tx-vencimiento:

    • Ir-offline-después-tx-vencimiento – Esto comienza off-liné a cargar después de que ocurra el Tx-vencimiento.

    • Recomprobación-después-tx-vencimiento – Esto revisa al servidor secundario después de que ocurra el Tx-vencimiento.

  • Recomprobación-y-termine – Esto termina la sesión después de que el sistema revise al servidor secundario, si el servidor secundario no está disponible tampoco. Esto también utiliza la opción del Recomprobación-después-tx-vencimiento, que revisa al servidor secundario después de que ocurra el Tx-vencimiento.

  • Termine – Esto termina la sesión sin ningunas tentativas de entrar en contacto al servidor secundario.

Comportamiento predeterminado del mecanismo FH

Esta sección describe el comportamiento predeterminado FH cuando no hay configuración presente. Por abandono, el mecanismo FH se activa durante un tiempo de espera de respuesta agotado (RT), excepto cuando se configura la acción del terminal.

Si un par de valores de atributos de Crédito-Control-Error-dirección (AVP) se recibe del servidor, después las configuraciones recibidas son aplicadas.

A continuación, se incluyen algunos ejemplos:

  • La Solicitud inicial > termina

  • La Actualización-petición > Recomprobación-y-termina

  • Termine Request > Recomprobación-y-termina

Flujo de llamada detallado del mecanismo FH

Esta sección describe el flujo de llamada detallado del mecanismo FH con todas las opciones posibles.

Solicitud inicial

Configuración CCFHComando CLIComportamiento en el txComportamiento en el RTSecundario está para arribaSecundario está abajo

Continúe

Solicitud inicial
continúe

N/A

Continúe

Secundario
asume el control después
RT

Off-liné después de otro RT.
Se realizan no más de peticiones de la cuota
para cualquier grupo de clasificación dentro de la sesión
después del error DCCA (incluso si
la Conectividad a DCCA se restablece)

Solicitud inicial
continúe ir-offline-después de
tx-vencimiento

Fuera de línea

N/A

Off-liné en el tx

Off-liné en el tx

Solicitud inicial
continúe recomprobación-después de
tx-vencimiento

Continúe

N/A

Secundario
asume el control después
Tr

Off-liné después de otro tx

Recomprobación-y-termine

Solicitud inicial
recomprobación-y-termine

N/A

Recomprobación

Secundario
asume el control después
RT

Termine después de otro RT

Solicitud inicial
recomprobación-y-termine
recomprobación-después-tx-vencimiento

Recomprobación

N/A

Secundario
asume el control después
Tr

Termine después de otro tx

Termine

Solicitud inicial
termine

Termine

N/A

Termine después del tx

Termine después del tx

Actualización-petición

Configuración CCFHComando CLIComportamiento en el txComportamiento en el RTSecundario está para arribaSecundario está abajo

Continúe

actualización-petición
continúe

N/A

Continúe

Secundario
asume el control después
RT

Off-liné después de otro RT

actualización-petición
continúe ir-offline-después de
tx-vencimiento

Fuera de línea

N/A

Off-liné en el tx

Off-liné en el tx

actualización-petición
continúe recomprobación-después de
tx-vencimiento

Continúe

N/A

Secundario
asume el control después
Tr

Off-liné después de otro tx

Recomprobación-y-termine

actualización-petición
recomprobación-y-termine

N/A

Recomprobación

Secundario
asume el control después
RT

Envía CCR-T después de otro RT

actualización-petición
recomprobación-y-termine
recomprobación-después-tx-vencimiento

Recomprobación

N/A

Secundario
asume el control después
Tr

Envía CCR-T después de otro tx

Termine

actualización-petición
termine

Termine

N/A

Envía CCR-T después del tx

Envía CCR-T después del tx

Terminate-Request (Pedido de finalización)

Configuración CCFHComando CLIComportamiento en el txComportamiento en el RTSecundario está para arribaSecundario está abajo

Continúe

terminar-petición
continúe

N/A

Recomprobación

Se envía CCR-T
a secundario
después del RT

Termine después de otro RT

terminar-petición
continúe ir-offline-después de
tx-vencimiento

Recomprobación

N/A

Se envía CCR-T
a secundario
después del tx

Termine después de otro tx

terminar-petición
continúe recomprobación-después de
tx-vencimiento

Recomprobación

N/A

Se envía CCR-T
a secundario
después del tx

Termine después de otro tx

Recomprobación-y-termine

terminar-petición
recomprobación-y-termine

N/A

Recomprobación

Se envía CCR-T
a secundario
después del RT

Termine después de otro RT

terminar-petición
recomprobación-y-termine
recomprobación-después-tx-vencimiento

Recomprobación

N/A

Se envía CCR-T
a secundario
después del tx

Termine después de otro tx

Termine

terminar-petición
termine

Termine

N/A

Termine después
Tr

Termine después del tx

Mecanismo SU

El mecanismo SU es similar el mecanismo FH, pero proporciona un control más granular sobre los procedimientos del error. Además de la continuación de la sesión después de que los errores del mensaje y del conexión-nivel (transporte), este mecanismo puedan ser utilizados cuando las respuestas son lentas del OCS. También proporciona las opciones a continúa el agotamiento de la duración/de la cuota de la sesión por algún tiempo antes de la terminación, o utiliza (el volumen y el tiempo interinos configurables) de la cuota y el servidor configurable revisa antes de que una sesión se convierta a off-liné o se termine. 

Configuración del mecanismo SU

El mecanismo SU se puede configurar en las configuraciones del crédito-control del diámetro. El sintaxis que se utiliza en la configuración SU varía de acuerdo con la versión se utiliza que.

Para las versiones 12.1 y anterior, éste es el sintaxis que se utiliza para la configuración del mecanismo SU:

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

Para las versiones 12.2 y posterior, éste es el sintaxis que se utiliza para la configuración del mecanismo 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> ] } }

Nota: En las versiones antes de la versión 12.2, había flexibilidad para configurar los mecanismos FH y SU independientemente; sin embargo, en las versiones 12.2 y posterior, el mecanismo SU toma la precedencia sobre el mecanismo FH cuando está configurado.

Si el servidor vuelve el CC-FH AVP, y el mecanismo SU se configura para un conjunto de los activadores del comportamiento, después la configuración SU es aplicada; si no, el valor CC-FH AVP es aplicado. Por abandono, los códigos de resultado tales como caída 3002, 3004, y 3005 bajo error de la salida y se tratan como RT.

Estas acciones son posibles con el mecanismo SU:

  • Comportamiento-activador – Esto especifica el tipo de mensaje que puede ser las Solicitudes iniciales (CCR-I) o las Actualización-peticiones (CCR-U). Hay tres opciones disponibles para estos activadores:

    • Código de resultado – Esto permite la configuración de los códigos de resultado específicos, del rango de los códigos de resultado (3000-5999), o de cualquier error junto con el Tipo de mensaje.

    • Transporte-error – Esta especificación acciona el comportamiento sobre el error del transporte, que es al revés compatible con la versión 12.0. Hay dos opciones disponibles para esta configuración:

      • Respuesta-descanso – Esta opción acciona el comportamiento sobre el RT y se debe utilizar siempre con los errores del transporte.

      • Tx-vencimiento – Esta opción acciona el comportamiento sobre el Tx-vencimiento y se debe utilizar siempre con el error del transporte.

    • Acciones – Esto especifica la acción se realiza que cuando ocurre un activador SU para CCR-I o CCR-U. Esta acción varía de acuerdo con el Tipo de mensaje y la versión de software.

  • Continúe – Esto permite que la sesión sea convertida a off-liné y continúa. No hay otras opciones disponibles para el uso de esta acción en las versiones antes de la versión 12.2. En las versiones 12.2 y posterior, la cuota interina, el servidor-Retries, y las opciones del después-temporizador-vencimiento están disponibles para la configuración con esta acción.

  • Termine – Esto da lugar a la terminación de la sesión cuando el servidor llega a ser inalcanzable. Esta acción permite la cuota interina, el servidor-Retries, y las opciones del después-temporizador-vencimiento.

Estas opciones pueden ser utilizadas con la continuación o terminar la acción:

    • Después-interino-tiempo – Esta opción permite la continuación o la terminación de la llamada después del período de agotamiento del tiempo de espera interino. Esto es similar a una cuota del tiempo antes de que se realice la acción. El valor se formata en los segundos y puede extenderse entre 1 y 4,294,967,295.

    • Después-interino-volumen – Esta opción asigna la cuota interina y permite la continuación o la terminación de la sesión antes del agotamiento del volumen configurado. El valor se formata en los bytes y puede extenderse entre 1 y 4,294,967,295.

    • Servidor-Retries – Esta opción permite que el PCEF revise el OCS antes de la continuación o de la terminación de la sesión. La cuenta de reintentos se puede configurar, y los rangos del valor entre 0 y 65,535. Si el valor es cero, después la recomprobación no ocurre y la acción es inmediatamente aplicada.

Nota: Las opciones del después-interino-tiempo y del después-interino-volumen se utilizan siempre con la opción del servidor-Retries, o los tres pueden ser utilizados simultáneamente y aplicado a continúe y termine las acciones. Las opciones del después-interino-tiempo y del después-interino-volumen también asignan la cuota del tiempo así como del volumen, y la cuota que se agota primero acciona la recomprobación del servidor.

  • Después-temporizador-vencimiento – Esta opción especifica la duración del tiempo (en los segundos) para los cuales sigue habiendo las sesiones en el estado de desconexión antes de que ocurra la terminación. Los valores pueden extenderse entre 1 y 4,294,967,295. Esta opción es solamente aplicable para termina las acciones.

  • Después-cuota-vencimiento – Esta opción termina la sesión sobre el agotamiento de la cuota ya asignada.

Aquí está una cierta información importante a recordar:

  • El después-interino-tiempo, el después-interino-volumen, y las opciones del servidor-Retries se pueden utilizar individualmente o en la combinación, y son aplicables a continúan y terminan las acciones.

  • La opción del después-cuota-vencimiento es solamente aplicable para el activador del comportamiento de las Actualización-peticiones.

  • La opción del después-temporizador-vencimiento es solamente aplicable para la acción del terminal.

  • El después-interino-tiempo, el después-interino-volumen, y las opciones del servidor-Retries son solamente aplicables para las versiones 12.2 y posterior.

  • Si se soporta (y se configura) la transmisión de la sesión por un error del diámetro, después entran en contacto al servidor secundario siempre antes de que se accione el mecanismo SU.

  • El servidor que era último entrado en contacto antes de que se accione el mecanismo SU se entra en contacto siempre cuando se agota el volumen interino del tiempo o del interino y las recomprobaciones del servidor que la opción se configura con un valor que sea mayor de cero. Por ejemplo, si OCS1 se intenta primero, y OCS2 se intenta después de un error en OCS1, entonces comunicación con OCS2 acciona el mecanismo SU. Durante la tentativa de la recomprobación del servidor, OCS2 primero y después se entra en contacto OCS1 si una respuesta negativa se recibe de OCS2.

Flujos de llamada del mecanismo SU

El mecanismo SU se puede accionar por un error del CCR-I o del CCR-U, y la causa puede ser un código de error, un error del transporte, un Tx-vencimiento, o un RT. La acción puede ser una asignación de la cuota interina (tiempo y/o volumen), de la cuenta de recomprobaciones del servidor, del valor del temporizador (hace la sesión ir off-liné por el tiempo especificado y solamente para la terminación), o del vencimiento de la cuota (solamente para el CCR-U y la terminación) antes de que la sesión vaya off-liné o termine.

La cuota interina se proporciona en una base del por session, no una base del grupo del por-grado (RG) en los escenarios del control de crédito de los servicios múltiples (MSCC).

Hay una posibilidad que los activadores del servidor primario transportan el error y el servidor secundario acciona el Tx-vencimiento o el respuesta-descanso. En este escenario, el último error se considera ser el activador del error.

Si el mecanismo SU no se configura para ningún activador del error, después se acciona el mecanismo FH.

Nota: Las secciones que siguen proporcionan algunos ejemplos del flujo de llamada que se relacionen con el mecanismo SU. Estos flujos de llamada se proporcionan bajo suposición que la diámetro-sesión-Conmutación por falla está soportada y configuran al servidor secundario con un valor del Tx-vencimiento que sea menos que el valor RT. También, se asume que el mecanismo SU está configurado para el transporte-error, el Tx-vencimiento, y el RT.

Solicitud inicial sin la desconexión de la sesión

Aquí está el flujo de mensajes para este escenario:

  1. El PCEF envía un CCR-I al OCS.

  2. Detectan a un error del descanso o del transporte. Si detectan al error del transporte, después el PCEF revisa inmediatamente con el servidor secundario; si no, se acciona el Tx-vencimiento.

  3. Si el servidor secundario también tiene un error o un descanso del transporte, después se acciona el mecanismo SU. Esto ocurre inmediatamente para los errores del transporte, o después del Tx-vencimiento para un descanso.

  4. Si se configuran el volumen y/o el tiempo interinos, después la cuota interina se asigna a la sesión.

  5. Después del agotamiento de la cuota interina (tiempo o volumen) y si el valor de recomprobaciones del servidor es mayor de cero, después el CCR-I se envía otra vez al servidor que accionó el mecanismo SU. Si hay otro error, el CCR-I se envía a otro servidor.

  6. Si detectan al error o el Tx-descanso del transporte otra vez, después se relanzan los pasos 2 a 5 hasta que se agote el valor de recomprobaciones del servidor o una respuesta acertada no viene del OCS.

  7. Si todavía existe el problema, después se continúa (convertido a off-liné) o se termina la sesión según la configuración.

Nota: La cuota interina se consume que mientras que la sesión entra el modo SU debido a CCR-I no está señalada en el CCR-I siguiente. Toda la cuota interina usada está señalada en el CCR-U, que sigue el CCA-I acertado.

Solicitud inicial con la desconexión de la sesión

Aquí está el flujo de mensajes para este escenario:

  1. El PCEF envía un CCR-I al OCS.

  2. Detectan a un error del descanso o del transporte. Si detectan al error del transporte, después el PCEF revisa inmediatamente con el servidor secundario; si no, se acciona el Tx-vencimiento.

  3. Si el servidor secundario también tiene un error o un descanso del transporte, después se acciona el mecanismo SU. Esto ocurre inmediatamente para los errores del transporte, o después del Tx-vencimiento para un descanso.

  4. Si se configuran el volumen y/o el tiempo interinos, después la cuota interina se asigna a la sesión.

  5. Después del agotamiento de la cuota interina (tiempo o volumen) y si el valor de recomprobaciones del servidor es mayor de cero, después el CCR-I se envía otra vez al servidor que accionó el mecanismo SU. Si hay otro error, el CCR-I se envía a otro servidor.

  6. Si detectan al error o el Tx-descanso del transporte otra vez, después se relanzan los pasos 2 a 5 hasta que se agote el valor de recomprobaciones del servidor o una respuesta acertada no viene del OCS. En este momento, la sesión es disconnected sin el consumo de la cuota interina entera.

  7. Después de la terminación de la sesión, el PCEF envía otra vez el CCR-I para comenzar una nueva sesión. Si esto es acertado, después el PCEF envía el CCR-T, que señala la cuota temporal del conjunto que fue utilizada.

Actualización-petición sin la desconexión de la sesión

Aquí está el flujo de mensajes para este escenario:

  1. El PCEF envía un CCR-U al OCS.

  2. Detectan a un error del descanso o del transporte. Si detectan al error del transporte, después el PCEF revisa inmediatamente con el servidor secundario; si no, se acciona el Tx-vencimiento.

  3. Si el servidor secundario también tiene un error o un descanso del transporte, después se acciona el mecanismo SU. Esto ocurre inmediatamente para los errores del transporte, o después del Tx-vencimiento para un descanso.

  4. Si se configuran el volumen y/o el tiempo interinos, después la cuota interina se asigna a la sesión.

  5. Después del agotamiento de la cuota interina (tiempo o volumen) y si el valor de recomprobaciones del servidor es mayor de cero, después el CCR-U se envía otra vez al servidor que accionó el mecanismo SU. Si hay otro error, un CCR-U se envía a otro servidor que contenga la cuota no denunciada consumida entera.

  6. Si detectan al error o el Tx-descanso del transporte otra vez, después se relanzan los pasos 2 a 5 hasta que se agote el valor de recomprobaciones del servidor o una respuesta acertada no viene del OCS.

  7. La cuota consumida entera está señalada al OCS con el CCR-U acertado.

  8. Si todavía existe el problema, después se continúa (convertido a off-liné) o se termina la sesión según la configuración después del agotamiento del valor de cantidad de intentos máxima.

Actualización-petición con la desconexión de la sesión

Aquí está el flujo de mensajes para este escenario:

  1. El PCEF envía un CCR-U al OCS.

  2. Detectan a un error del descanso o del transporte. Si detectan al error del transporte, después el PCEF revisa inmediatamente con el servidor secundario; si no, se acciona el Tx-vencimiento.

  3. Si el servidor secundario también tiene un error o un descanso del transporte, después se acciona el mecanismo SU. Esto ocurre inmediatamente para los errores del transporte, o después del Tx-vencimiento para un descanso.

  4. Si se configuran el volumen y/o el tiempo interinos, después la cuota interina se asigna a la sesión.

  5. Después del agotamiento de la cuota interina (tiempo o volumen) y si el valor de recomprobaciones del servidor es mayor de cero, después el CCR-U se envía otra vez al servidor que accionó el mecanismo SU. Si hay otro error, un CCR-U se envía a otro servidor que contenga la cuota no denunciada consumida entera.

  6. Si detectan al error o el Tx-descanso del transporte otra vez, después se relanzan los pasos 2 a 5 hasta que se agote el valor de recomprobaciones del servidor o una respuesta acertada no viene del OCS. En este momento, la sesión es disconnected antes de que consuma la cuota temporal entera.

  7. El PCEF envía un CCR-T al OCS para señalar la cuota consumida entera.

  8. Si el OCS responde con un código de resultado 2002, después los informes adicionales no son necesarios.

Actualización-petición con la sesión desconocida

Aquí está el flujo de mensajes para este escenario:

  1. El PCEF envía un CCR-U al OCS.

  2. Detectan a un error del descanso o del transporte. Si detectan al error del transporte, después el PCEF revisa inmediatamente con el servidor secundario; si no, se acciona el Tx-vencimiento.

  3. Si el servidor secundario también tiene un error o un descanso del transporte, después se acciona el mecanismo SU. Esto ocurre inmediatamente para los errores del transporte, o después del Tx-vencimiento para un descanso.

  4. Si se configuran el volumen y/o el tiempo interinos, después la cuota interina se asigna a la sesión.

  5. Después del agotamiento de la cuota interina (tiempo o volumen) y si el valor de recomprobaciones del servidor es mayor de cero, después el CCR-U se envía otra vez al servidor que accionó el mecanismo SU. Si hay otro error, un CCR-U se envía a otro servidor que contenga la cuota no denunciada consumida entera.

  6. El OCS contesta con un código de resultado 5002 (del ID de sesión desconocido) para el CCR-U, que es posible en el escenario donde el OCS recomenzó y perdió la información del ID de sesión.

  7. El PCEF inicia una nueva sesión con el CCR-I y recibe el CCA-I.

  8. El PCEF señala la cuota interina consumida entera vía CCR-U en los mensajes subsiguientes.

Actualización-petición con RGs múltiple (escenario MSCC)

Aquí está el flujo de mensajes para este escenario:

  1. El PCEF envía el CCR-U para RG1 al OCS.

  2. Detectan a un error del descanso o del transporte. Si detectan al error del transporte, después el PCEF revisa inmediatamente con el servidor secundario; si no, se acciona el Tx-vencimiento.

  3. Si el servidor secundario también tiene un error o un descanso del transporte, después se acciona el mecanismo SU. Esto ocurre inmediatamente para los errores del transporte, o después del Tx-vencimiento para un descanso.

  4. Si se configuran el volumen y/o el tiempo interinos, después la cuota interina se asigna a la sesión

  5. En este momento RG2 también agota la cuota asignada entera pero no inicia el CCR-U porque la sesión está ya en el modo SU y comienza a consumir la cuota interina.

  6. Después del agotamiento de la cuota interina (tiempo o volumen) y si el valor de recomprobaciones del servidor es mayor de cero, después el CCR-U se envía otra vez al servidor que accionó el mecanismo SU. Si hay otro error, un CCR-U se envía a otro servidor que contenga la cuota no denunciada consumida entera para ambos el RGs.

  7. Si detectan al error o el Tx-descanso del transporte otra vez, después se relanzan los pasos 2 a 6 hasta que se agote el valor de recomprobaciones del servidor o una respuesta acertada no viene del OCS.

  8. La cuota consumida entera está señalada al OCS con el CCR-U acertado.

  9. Si todavía existe el problema, después se continúa (convertido a off-liné) o se termina la sesión según la configuración después del agotamiento del valor de cantidad de intentos máxima.

Terminate-Request (Pedido de finalización)

Aquí está el flujo de mensajes para este escenario:

  1. El PCEF envía un CCR-T al OCS.

  2. Detectan a un error del descanso o del transporte. Si detectan al error del transporte, después el PCEF revisa inmediatamente con el servidor secundario; si no, se acciona el Tx-vencimiento.

  3. Si el servidor secundario también tiene un error o un descanso del transporte, después se quita la sesión.

Dirección del código de error CCR

Aquí está el flujo de mensajes para este escenario:

  1. Los PCEF envían un CCR al OCS, y el OCS contesta con un código de error.

  2. El código de error se configura estáticamente en el mecanismo SU.

  3. El PCEF proporciona la cuota interina sin una recomprobación al servidor secundario.

Ejemplos de configuración FH y SU

Esta sección proporciona un ejemplo de configuración para los mecanismos FH y SU. Cuando se configuran los mecanismos FH y SU, el SU toma la precedencia sobre el FH para el mismo activador del comportamiento.

Aquí tiene un ejemplo:

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

Verificación

Para verificar que su configuración trabaje correctamente, ingrese el comando de activo-carga del name> del <service del servicio de la demostración:

# 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

Troubleshooting

Ingrese el comando statistics de activo-carga del crédito-control de la demostración para ver las estadísticas que se relacionan con los mecanismos SU y FH. Éste es un ejemplo de salida:

#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

Aquí están algunas NOTAS IMPORTANTES sobre esta salida de ejemplo:

  • Tx-vencimiento – Esto indica una condición SU debido a un Tx-vencimiento.

  • Respuesta-descanso – Esto indica una condición SU debido a un RT.

  • Falla de conexión – Esto indica una condición SU debido a un error del transporte.

  • Acción-continúe – Este campo indica el número de sesiones que fueron off-liné.

  • Acción-termine – Este campo indica el número de sesiones que fueron terminadas.

  • Retries del servidor – Este campo indica la cantidad de veces que el OCS fue revisado.

  • Sesiones Asumir-positivas:

    • Actual – Este campo indica el número de sesiones que estén actualmente en la condición SU.

    • Acumulativo – Este campo indica el número total de sesiones que se han trasladado al estatus SU.

Ingrese el comando all completo de activo-carga de las sesiones de la demostración para ver la información que se relaciona con el estado SU de la sesión. Éste es un ejemplo de salida:

#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

Aquí están algunas NOTAS IMPORTANTES sobre esta salida de ejemplo:

  • Estado inalcanzable del servidor actual – Esto especifica si el estado actual SU es debido al CCR-I o al CCR-U.

  • El volumen interino en los bytes (usados/asignados) – esto muestra el volumen interino en los bytes usados contra los bytes afectados un aparato.

  • Tiempo interino en los segundos (usados/asignados) – esto muestra el volumen interino en los segundos usados contra los segundos afectados un aparato.

  • El servidor revisa (intentado/configurado) – esto es el número de recomprobaciones del servidor frustradas contra ésa configurada.

Información Relacionada


Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.