Configurar mecanismos de tratamento de falhas e de servidor inalcançável para resolução de falhas de OCS no ASR5K

Opções de download

PDF (209.9 KB)
Ver no Adobe Reader em vários dispositivos
ePub (109.8 KB)
Ver em vários aplicativos no iPhone, iPad, Android, Sony Reader ou Windows Phone
Mobi (Kindle) (111.9 KB)
Ver no dispositivo Kindle ou no aplicativo Kindle em vários dispositivos

Atualizado:2 de junho de 2015

ID do documento:118993

Linguagem imparcial

O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.

Sobre esta tradução

A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.

Introduction

Prerequisites

Requirements

Componentes Utilizados

Informações de Apoio

Configurar

Diagrama de Rede

Tx-Expiry

Tempo limite da resposta

Failover de Sessão de Diâmetro

Mecanismo FH

Configuração do mecanismo FH

Comportamento Padrão do Mecanismo FH

Fluxo de chamada detalhado do mecanismo FH

Mecanismo de SU

Configuração do mecanismo de SU

Fluxos de chamada do mecanismo de SU

Configurações de exemplo de FH e SU

Verificar

Troubleshoot

Informações Relacionadas

Introduction

Este documento descreve como configurar os mecanismos de Tratamento de Falha (FH - Failure-Handling) e de Servidor Inalcançável (SU - Server-Unreachable) na interface Gy para resolver problemas encontrados no Sistema de Cobrança On-line (OCS - Online Charging System) ou em relação à conectividade entre a Função de Aplicação de Política e Cobrança (PCEF - Policy and Charging Implementation Function) e o OCS. As informações descritas neste documento aplicam-se às funcionalidades Home Agent (HA), Gateway General Packet Radio Service (GPRS) Support Node (GGSN) e Packet Data Network Gateway (PGW) executadas no Cisco 5000 Series Aggregated Services Router (ASR5K).

Prerequisites

Requirements

A Cisco recomenda que seu sistema atenda a esses requisitos para usar os mecanismos FH e SU:

O ECS (Enhanced Charging Service) está disponível
O PCEF existe dentro do HA, GGSN ou PGW
Há conectividade de diâmetro adequada através do banco de dados
O Pedido de Controlo de Crédito de Diâmetro (DCCA) está disponível

Componentes Utilizados

As informações neste documento são baseadas em todas as versões do 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.

Informações de Apoio

O PCEF é conectado ao OCS pela interface Gy, que usa Diameter como o protocolo base e DCCA. Este é o fluxo de mensagem entre o PCEF e o OCS:

Credit Control Request (CCR) â Â Esta mensagem é enviada do PCEF para o OCS. Há três tipos de mensagens CCR: Inicial, Atualizar e Terminar.
Resposta de Controle de Crédito (CCA) â Â Esta mensagem é enviada do OCS para o PCEF em resposta ao CCR. Há também três tipos de mensagens CCA: Inicial, Atualizar e Terminar.
Solicitação de Reautorização (RAR) â Â Esta mensagem é enviada do OCS para o PCEF quando uma nova autorização de sessão é necessária.
Resposta de autorização (RAA) â Â Esta é a resposta ao RAR do PCEF para o OCS.

A conectividade de diâmetro é estabelecida entre o PCEF e o OCS para ativar o fluxo de mensagem. Há a possibilidade de que o OCS envie mensagens negativas, a conexão de transporte pode falhar entre o PCEF e o OCS ou a mensagem pode expirar, o que pode causar uma falha no estabelecimento da sessão do assinante. Isso pode impedir que o assinante use serviços.

Esses dois mecanismos podem ser usados para resolver esse problema:

O mecanismo FH
O mecanismo SU

Configurar

Esta seção descreve as configurações necessárias para suportar os mecanismos FH e SU.

Diagrama de Rede

As informações neste documento usam esta topologia:

Tx-Expiry

Este é um temporizador de nível de aplicação para o DCCA que pode ser configurado nas configurações de controle de crédito de diâmetro. O valor pode variar entre 1 e 300 segundos.

Aqui está um exemplo:

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

Tempo limite da resposta

Este é um tempo limite de banco de dados e pode ser configurado nas configurações de ponto de extremidade de diâmetro. O valor pode variar entre 1 e 300 segundos.

Note: O valor configurado para esse temporizador deve ser maior do que o usado para o temporizador Tx-Expiry.

Aqui está um exemplo:

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

Failover de Sessão de Diâmetro

Esse recurso é usado para habilitar ou desabilitar o failover da sessão de controle de crédito de diâmetro, que permite que o sistema use um servidor secundário quando o servidor primário se tornar inalcançável. Isso é configurável nas configurações de controle de crédito de diâmetro.

Aqui está um exemplo:

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

Mecanismo FH

O mecanismo FH só opera se houver failover de sessão de diâmetro. O FH permite que o sistema escolha se deseja continuar a sessão e convertê-la em off-line ou encerrar a sessão quando ocorrer um erro de conexão ou de nível de mensagem.

Note: O FH está ativado e configurado por padrão.

Configuração do mecanismo FH

O mecanismo FH pode ser configurado nas configurações de controle de crédito de diâmetro. Esta é a sintaxe usada na configuração 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 }

A primeira seção especifica o tipo de solicitação: Inicial (CCR-I), Atualizar (CCR-U) e Terminar (CCR-T).

A segunda seção especifica a ação que deve ser executada quando o mecanismo FH é ativado. Essas três ações são possíveis com o mecanismo FH:

Continue â Â Isso permite que a sessão continue e a converta para off-line. Esta função usa duas opções relacionadas à expiração de transmissão:
- Go-offline-after-tx-expire â Â Isto começa a carregar offline após a expiração de Tx.
- Repetir após tx-expiração â Â Isso repete o servidor secundário após a expiração de Tx.
Tente novamente e termine â Â Isso encerra a sessão após o sistema tentar novamente o servidor secundário, se o servidor secundário também não estiver disponível. Isso também usa a opção Repetir após tx-expirar, que repete o servidor secundário após a expiração de Tx.
Encerre â Â Isso encerra a sessão sem nenhuma tentativa de entrar em contato com o servidor secundário.

Comportamento Padrão do Mecanismo FH

Esta seção descreve o comportamento padrão do FH quando não há configuração presente. Por padrão, o mecanismo FH é ativado durante um Tempo Limite de Resposta (RT), exceto quando a ação Terminar é configurada.

Se um Credit-Control-Failure-Handling Attribute Value Pair (AVP) for recebido do servidor, as configurações recebidas serão aplicadas.

Aqui estão alguns exemplos:

Solicitação inicial > Terminar
Update-Request > Retry-and-Terminate
Terminate-Request > Retry-and-Terminate

Fluxo de chamada detalhado do mecanismo FH

Esta seção descreve o fluxo de chamada detalhado do mecanismo FH com todas as opções possíveis.

Solicitação inicial

Configuração do CCFH	Comando CLI	Comportamento no Tx	Comportamento na RT	O secundário está ativo	Secundário está inativo
Continuar	requisição inicial continuar	N/A	Continuar	Secundário assume depois RT	Offline após outro RT. Não são executadas mais solicitações de cota para qualquer grupo de classificação na sessão após falha de DCCA (mesmo que a conectividade com DCCA é restaurada)
	requisição inicial continue a ficar offline após tx-expire	Off-line	N/A	Offline no Tx	Offline no Tx
	requisição inicial continue repetindo após tx-expire	Continuar	N/A	Secundário assume depois Tx	Offline após outro Tx
Repetir e terminar	requisição inicial repetir e terminar	N/A	Repetir	Secundário assume depois RT	Terminar após outro RT
Repetir e terminar	requisição inicial repetir e terminar retry-after-tx-expire	Repetir	N/A	Secundário assume depois Tx	Terminar após outro Tx
Terminar	requisição inicial terminar	Terminar	N/A	Terminar após Tx	Terminar após Tx

Atualizar-Solicitar

Configuração do CCFH	Comando CLI	Comportamento no Tx	Comportamento na RT	O secundário está ativo	Secundário está inativo
Continuar	update-request continuar	N/A	Continuar	Secundário assume depois RT	Offline após outro RT
	update-request continue a ficar offline após tx-expire	Off-line	N/A	Offline no Tx	Offline no Tx
	update-request continue repetindo após tx-expire	Continuar	N/A	Secundário assume depois Tx	Offline após outro Tx
Repetir e terminar	update-request repetir e terminar	N/A	Repetir	Secundário assume depois RT	Envia CCR-T após outro RT
Repetir e terminar	update-request repetir e terminar retry-after-tx-expire	Repetir	N/A	Secundário assume depois Tx	Envia CCR-T após outro Tx
Terminar	update-request terminar	Terminar	N/A	Envia CCR-T após Tx	Envia CCR-T após Tx

Terminate-Request

Configuração do CCFH	Comando CLI	Comportamento no Tx	Comportamento na RT	O secundário está ativo	Secundário está inativo
Continuar	terminate-request continuar	N/A	Repetir	CCR-T é enviado para secundário após RT	Terminar após outro RT
	terminate-request continue a ficar offline após tx-expire	Repetir	N/A	CCR-T é enviado para secundário após Tx	Terminar após outro Tx
	terminate-request continue repetindo após tx-expire	Repetir	N/A	CCR-T é enviado para secundário após Tx	Terminar após outro Tx
Repetir e terminar	terminate-request repetir e terminar	N/A	Repetir	CCR-T é enviado para secundário após RT	Terminar após outro RT
Repetir e terminar	terminate-request repetir e terminar retry-after-tx-expire	Repetir	N/A	CCR-T é enviado para secundário após Tx	Terminar após outro Tx
Terminar	terminate-request terminar	Terminar	N/A	Terminar após Tx	Terminar após Tx

Mecanismo de SU

O mecanismo SU é semelhante ao mecanismo FH, mas fornece um controle mais granular sobre procedimentos de falha. Além da continuação da sessão após as falhas de nível de mensagem e conexão (transporte), esse mecanismo pode ser usado quando as respostas são lentas do OCS. Ele também fornece as opções para continuar a sessão por um período de tempo/esgotamento de cota antes do término, ou usar cota temporária configurável (volume e tempo) e novas tentativas de servidor configuráveis antes de uma sessão ser convertida para off-line ou encerrada.

Configuração do mecanismo de SU

O mecanismo SU pode ser configurado nas configurações de controle de crédito de diâmetro. A sintaxe usada na configuração da SU varia de acordo com a versão usada.

Para as versões 12.1 e anteriores, esta é a sintaxe usada para a configuração do 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 as versões 12.2 e posteriores, esta é a sintaxe usada para a configuração do 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> ] } }

Note: Em versões anteriores à versão 12.2, havia flexibilidade para configurar os mecanismos FH e SU de forma independente; no entanto, nas versões 12.2 e posteriores, o mecanismo SU tem precedência sobre o mecanismo FH quando configurado.

Se o servidor retornar o AVP CC-FH e o mecanismo SU for configurado para um conjunto de acionadores de comportamento, a configuração do SU será aplicada; caso contrário, o valor de AVP CC-FH é aplicado. Por padrão, os códigos de resultado como 3002, 3004 e 3005 estão sob falha de entrega e são tratados como RTs.

Essas ações são possíveis com o mecanismo SU:

Comportamento-Disparo â Â Especifica o tipo de mensagem que pode ser Solicitações iniciais (CCR-I) ou Solicitações de atualização (CCR-U). Há três opções disponíveis para esses acionadores:
- Result-Code â Â Isso permite a configuração de códigos de resultado específicos, intervalo de códigos de resultado (3000-5999) ou qualquer erro junto com o tipo de mensagem.
- Transport-Failure â Â Esta especificação ativa o comportamento em caso de falha de transporte, que é retrocompatível com a versão 12.0. Há duas opções disponíveis para esta configuração:
  - Response-Timeout â Â Esta opção aciona o comportamento em relação à RT e deve sempre ser usada com falhas de transporte.
  - Tx-Expiry âÂ Â Esta opção aciona o comportamento após Tx-expiração e deve sempre ser usada com falha de transporte.
- Ações â Â Especifica a ação que é executada quando ocorre um disparo de SU para CCR-I ou CCR-U. Essa ação varia de acordo com o tipo de mensagem e a versão do software.
Continue â Â Isso permite que a sessão seja convertida para off-line e continue. Não há mais opções disponíveis para o uso desta ação em versões anteriores à versão 12.2. Nas versões 12.2 e posteriores, as opções de cota temporária, novas tentativas de servidor e expiração de temporizador estão disponíveis para configuração com esta ação.
Terminar â Â Isso resulta no encerramento da sessão quando o servidor se torna inalcançável. Essa ação permite as opções de cota temporária, novas tentativas de servidor e expiração após o temporizador.

Essas opções podem ser usadas com a ação Continuar ou Terminar:

Após o tempo interino â Â Esta opção permite a continuação ou encerramento da chamada após o período de tempo limite interino. Isso é semelhante a uma cota de tempo antes da ação ser executada. O valor é formatado em segundos e pode variar entre 1 e 4.294.967.295.
Após o volume interino â Â Esta opção atribui a cota temporária e permite a continuação ou o término da sessão antes do esgotamento do volume configurado. O valor é formatado em bytes e pode variar entre 1 e 4.294.967.295.
Repetir o servidor â Â Esta opção permite que o PCEF repita o OCS antes da continuação ou do término da sessão. A contagem de novas tentativas pode ser configurada e o valor varia entre 0 e 65.535. Se o valor for zero, a nova tentativa não ocorrerá e a ação será aplicada imediatamente.

Note: As opções de tempo interino e de volume interino são sempre usadas com a opção server-retries, ou todas as três podem ser usadas simultaneamente e aplicadas às ações de continuação e de término. As opções de tempo intermédio e de volume intermediário também atribuem tempo, bem como cota de volume, e a cota que está esgotada primeiro aciona a nova tentativa do servidor.

Â pós-expiração do temporizador Esta opção especifica a duração (em segundos) para a qual as sessões permanecem no status offline antes que ocorra a terminação. Os valores podem variar entre 1 e 4.294.967.295. Esta opção só se aplica a ações de término.
Após a expiração da cota â Â Esta opção encerra a sessão após o esgotamento da cota já atribuída.

Aqui estão algumas informações importantes para lembrar:

As opções pós-interino, pós-intercalação-volume e servidor-repetições podem ser usadas individualmente ou em combinação, e são aplicáveis às ações de continuação e término.
A opção de expiração de cota só é aplicável para o disparador de comportamento Update-Requests.
A opção pós-expiração só é aplicável para a ação de fim.
As opções pós-interino, pós-intercalação-volume e servidor-repetições só se aplicam às versões 12.2 e posteriores.
Se houver suporte para failover de sessão de diâmetro (e configurado), o servidor secundário será sempre contatado antes que o mecanismo SU seja acionado.
O servidor que foi contatado pela última vez antes do mecanismo SU ser disparado é sempre contatado quando o tempo temporário ou o volume temporário é esgotado e a opção de novas tentativas do servidor é configurada com um valor maior que zero. Por exemplo, se o OCS1 for tentado primeiro e o OCS2 for tentado após um erro no OCS1, a comunicação com o OCS2 acionará o mecanismo SU. Durante a tentativa de nova tentativa do servidor, o OCS2 é contatado primeiro e depois o OCS1 se uma resposta negativa for recebida do OCS2.

Fluxos de chamada do mecanismo de SU

O mecanismo SU pode ser acionado por uma falha do CCR-I ou do CCR-U, e a causa pode ser um código de erro, falha de transporte, Tx-expiração ou RT. A ação pode ser uma alocação de cota temporária (tempo e/ou volume), contagem de novas tentativas do servidor, valor do temporizador (faz com que a sessão fique off-line durante um tempo especificado e somente para término) ou expiração da cota (somente para o CCR-U e término) antes que a sessão fique off-line ou termine.

A cota temporária é fornecida por sessão, não por grupo de classificação (RG) em cenários de controle de crédito de vários serviços (MSCC).

Há uma possibilidade de que o servidor primário dispare a falha de transporte e o servidor secundário acionem o Tx-expire ou o response-timeout. Nesse cenário, o erro mais recente é considerado o disparador da falha.

Se o mecanismo SU não estiver configurado para nenhum disparador de falha, o mecanismo FH será acionado.

Note: As seções a seguir fornecem alguns exemplos de fluxo de chamada relacionados ao mecanismo SU. Esses fluxos de chamada são fornecidos sob o pressuposto de que o failover de sessão de diâmetro é suportado e o servidor secundário é configurado com um valor de expiração de Tx inferior ao valor de RT. Além disso, supõe-se que o mecanismo SU esteja configurado para falha de transporte, Tx-expiração e RT.

Solicitação inicial sem desconexão de sessão