Sem fio : Cisco ASR 5000 Series

Configurar a Falha-manipulação e mecanismos Server-inacessíveis para a definição da falha OC no ASR5K

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (21 Abril 2016) | Feedback

Introdução

Este documento descreve como configurar a Falha-manipulação (FH) e os mecanismos (SU) Server-inacessíveis na GY conecta a fim resolver as edições que são encontradas no sistema de carregamento em linha (OC) ou com respeito à Conectividade entre a política e a função de carregamento da aplicação (PCEF) e os OC. A informação que é descrita neste documento é aplicável ao Home Agent (HA), ao nó de suporte do General Packet Radio Service do gateway (GPRS) (GGSN), e ao gateway da rede dos dados do pacote as funcionalidades (PGW) que são executado no roteador agregado Cisco 5000 Series dos serviços (ASR5K).

Contribuído por Shashank Varshney, engenheiro de TAC da Cisco.

Pré-requisitos

Requisitos

Cisco recomenda que sua reunião do sistema estas exigências a fim usar os mecanismos FH e SU:

  • O serviço de carregamento aumentado (ECS) está disponível

  • O PCEF existe dentro do HA, do GGSN, ou do PGW

  • Há uma Conectividade apropriada do diâmetro através da diabase

  • O aplicativo de controle do crédito do diâmetro (DCCA) está disponível

Componentes Utilizados

A informação neste documento é baseada em todas as versões do ASR5K.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Informações de Apoio

O PCEF é conectado aos OC sobre a relação GY, que usa o diâmetro como o protocolo e o DCCA baixos. Este é o fluxo de mensagem entre o PCEF e os OC:

  • Pedido do controle de crédito (CCR) – Esta mensagem é enviada do PCEF aos OC. Há três tipos de mensagens CCR: A inicial, atualização, e termina.

  • Resposta do controle de crédito (CCA) – Esta mensagem é enviada dos OC ao PCEF em resposta ao CCR. Há igualmente três tipos de mensagens CCA: A inicial, atualização, e termina.

  • Pedido da Re-autorização (RAR) – Esta mensagem está enviada dos OC ao PCEF quando uma re-autorização da sessão é exigida.

  • Resposta da Re-autorização (RAA) – Esta é a resposta a RAR do PCEF aos OC.

A Conectividade do diâmetro é estabelecida entre o PCEF e os OC a fim permitir o fluxo de mensagem. Há uma possibilidade que os OC puderam enviar mensagens negativas, a conexão de transporte pôde falhar entre o PCEF e os OC, ou a mensagem pôde o intervalo, que pode causar uma falha no estabelecimento de sessão do subscritor. Isto pode impedir o subscritor do uso dos serviços.

Estes dois mecanismos podem ser usados a fim resolver esta edição:

  • O mecanismo FH

  • O mecanismo SU

Configurar

Esta seção descreve as configurações que são exigidas a fim apoiar os mecanismos FH e SU.

Diagrama de Rede

A informação neste documento usa esta topologia:

TX-expiração

Este é um temporizador do nível de aplicativo para o DCCA que é configurável nos ajustes do crédito-controle do diâmetro. O valor pode variar entre 1 e 300 segundos.

Aqui está um exemplo:

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

Timeout de resposta

Este é um intervalo da diabase e é configurável nos ajustes do valor-limite do diâmetro. O valor pode variar entre 1 e 300 segundos.

Nota: O valor que é configurado para este temporizador deve ser maior do que aquele usado para o temporizador da TX-expiração.

Aqui está um exemplo:

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

Failover de sessão do diâmetro

Esta característica é usada a fim permitir ou desabilitar o failover de sessão do controle de crédito do diâmetro, que permite que o sistema use um servidor secundário quando o servidor primário se torna inacessível. Isto é configurável nos ajustes do crédito-controle do diâmetro.

Aqui está um exemplo:

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

Mecanismo FH

O mecanismo FH opera-se somente se o failover de sessão do diâmetro esta presente. O FH permite que o sistema escolha se continuar a sessão e o converso a off line, ou terminar a sessão quando um erro da conexão ou do nível de mensagem ocorre.

Nota: O FH é permitido e configurado à revelia.

Configuração de mecanismo FH

O mecanismo FH pode ser configurado nos ajustes do crédito-controle do diâmetro. Está aqui a sintaxe que é 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 do pedido: A inicial (CCR-I), a atualização (CCR-U), e terminam (CCR-T).

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

  • Continue – Isto permite que a sessão continue e converte-à off line. Esta função usa duas opções que são relacionadas à TX-expiração:

    • Ir-autônomo-após-TX-expiração – Isto começa off line carregar depois que a TX-expiração ocorre.

    • Novo-após-TX-expiração – Isto experimenta de novo o servidor secundário depois que a TX-expiração ocorre.

  • Novo-e-termine – Isto termina a sessão depois que o sistema experimenta de novo o servidor secundário, se o servidor secundário não está disponível tampouco. Isto igualmente usa a opção da Novo-após-TX-expiração, que experimenta de novo o servidor secundário depois que a TX-expiração ocorre.

  • Termine – Isto termina a sessão sem nenhumas tentativas de contactar o servidor secundário.

Comportamento padrão do mecanismo FH

Esta seção descreve o comportamento padrão FH quando nenhuma configuração esta presente. À revelia, o mecanismo FH é ativado durante um timeout de resposta (RT), exceto quando a ação da terminação é configurada.

Se um par de valor de atributo demanipulação (AVP) é recebido do server, a seguir os ajustes recebidos são aplicados.

Aqui estão alguns exemplos:

  • A solicitação inicial > termina

  • O Atualização-pedido > Novo-e-termina

  • Terminate-Request > Novo-e-termina

Fluxo de chamadas detalhado do mecanismo FH

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

Solicitação inicial

Ajuste CCFHComando CLIComportamento em TxComportamento no RTSecundário está acimaSecundário está para baixo

Continuar

solicitação inicial
continuar

N/A

Continuar

Secundário
toma sobre em seguida
RT

Off line após um outro RT.
Não mais pedido da quota é executado
para qualquer grupo de avaliação dentro da sessão
após a falha DCCA (mesmo se
a Conectividade a DCCA é restaurada)

solicitação inicial
continue ir-autônomo-após
TX-expiração

Off-line

N/A

Off line em Tx

Off line em Tx

solicitação inicial
continue novo-após
TX-expiração

Continuar

N/A

Secundário
toma sobre em seguida
Tx

Off line após um outro Tx

Novo-e-termine

solicitação inicial
novo-e-termine

N/A

Nova tentativa

Secundário
toma sobre em seguida
RT

Termine após um outro RT

solicitação inicial
novo-e-termine
novo-após-TX-expiração

Nova tentativa

N/A

Secundário
toma sobre em seguida
Tx

Termine após um outro Tx

Termine

solicitação inicial
termine

Termine

N/A

Termine após Tx

Termine após Tx

Atualização-pedido

Ajuste CCFHComando CLIComportamento em TxComportamento no RTSecundário está acimaSecundário está para baixo

Continuar

atualização-pedido
continuar

N/A

Continuar

Secundário
toma sobre em seguida
RT

Off line após um outro RT

atualização-pedido
continue ir-autônomo-após
TX-expiração

Off-line

N/A

Off line em Tx

Off line em Tx

atualização-pedido
continue novo-após
TX-expiração

Continuar

N/A

Secundário
toma sobre em seguida
Tx

Off line após um outro Tx

Novo-e-termine

atualização-pedido
novo-e-termine

N/A

Nova tentativa

Secundário
toma sobre em seguida
RT

Envia CCR-T após um outro RT

atualização-pedido
novo-e-termine
novo-após-TX-expiração

Nova tentativa

N/A

Secundário
toma sobre em seguida
Tx

Envia CCR-T após um outro Tx

Termine

atualização-pedido
termine

Termine

N/A

Envia CCR-T após Tx

Envia CCR-T após Tx

Terminate-Request

Ajuste CCFHComando CLIComportamento em TxComportamento no RTSecundário está acimaSecundário está para baixo

Continuar

terminar-pedido
continuar

N/A

Nova tentativa

CCR-T é enviado
a secundário
após o RT

Termine após um outro RT

terminar-pedido
continue ir-autônomo-após
TX-expiração

Nova tentativa

N/A

CCR-T é enviado
a secundário
após Tx

Termine após um outro Tx

terminar-pedido
continue novo-após
TX-expiração

Nova tentativa

N/A

CCR-T é enviado
a secundário
após Tx

Termine após um outro Tx

Novo-e-termine

terminar-pedido
novo-e-termine

N/A

Nova tentativa

CCR-T é enviado
a secundário
após o RT

Termine após um outro RT

terminar-pedido
novo-e-termine
novo-após-TX-expiração

Nova tentativa

N/A

CCR-T é enviado
a secundário
após Tx

Termine após um outro Tx

Termine

terminar-pedido
termine

Termine

N/A

Termine em seguida
Tx

Termine após Tx

Mecanismo SU

O mecanismo SU é similar o mecanismo FH, mas fornece um controle mais granulado sobre procedimentos da falha. Além do que a continuação da sessão depois que as falhas da mensagem e do conexão-nível (transporte), este mecanismo podem ser usadas quando as respostas forem lentas dos OC. Igualmente fornece as opções a continua a exaustão da duração/quota da sessão por algum tempo antes da terminação, ou usa (o volume e o tempo provisórios configuráveis) da quota e o server configurável experimenta de novo antes que uma sessão esteja convertida a off line ou terminada. 

Configuração de mecanismo SU

O mecanismo SU pode ser configurado nos ajustes do crédito-controle do diâmetro. A sintaxe que é usada na configuração SU varia de acordo com a versão que é usada.

Para versões 12.1 e anterior, esta é a sintaxe que é usada para a configuração de 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 versões 12.2 e mais recente, esta é a sintaxe que é usada para a configuração de 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: Nas versões antes da versão 12.2, havia uma flexibilidade configurar independentemente os mecanismos FH e SU; contudo, nas versões 12.2 e mais recente, o mecanismo SU toma a precedência sobre o mecanismo FH quando configurado.

Se o server retorna o CC-FH AVP, e o mecanismo SU está configurado para um grupo de disparadores do comportamento, a seguir a configuração SU é aplicada; se não, o valor CC-FH AVP é aplicado. À revelia, os códigos do resultado tais como a queda 3002, 3004, e 3005 sob a falha da entrega e são tratados como RT.

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

  • Comportamento-disparador – Isto especifica o tipo de mensagem que pode ser as solicitações inicial (CCR-I) ou os Atualização-pedidos (CCR-U). Há três opções disponíveis para estes disparadores:

    • Código do resultado – Isto permite a configuração de códigos do resultado específicos, de escala dos códigos do resultado (3000-5999), ou de todo o erro junto com o tipo de mensagem.

    • Transporte-falha – Esta especificação provoca o comportamento em cima da falha do transporte, que é para trás compatível com versão 12.0. Há duas opções disponíveis para este ajuste:

      • Resposta-intervalo – Esta opção provoca o comportamento em cima do RT e deve sempre ser usada com falhas do transporte.

      • TX-expiração – Esta opção provoca o comportamento em cima da TX-expiração e deve sempre ser usada com falha do transporte.

    • Ações – Isto especifica a ação que é executada quando um disparador SU para CCR-I ou CCR-U ocorre. Esta ação varia de acordo com o tipo de mensagem e a versão de software.

  • Continue – Isto permite que a sessão seja convertida a off line e continua. Não há nenhuma opção mais adicional disponível para o uso desta ação nas versões antes da versão 12.2. Nas versões 12.2 e mais recente, a quota provisória, o server-Retries, e as opções da após-temporizador-expiração estão disponíveis para a configuração com esta ação.

  • Termine – Isto conduz à terminação da sessão quando o server se torna inacessível. Esta ação permite a quota provisória, o server-Retries, e as opções da após-temporizador-expiração.

Estas opções podem ser usadas com a continuação ou terminar a ação:

    • Após-ínterim-tempo – Esta opção permite a continuação ou a terminação do atendimento após o período de timeout provisório. Isto é similar a uma quota do tempo antes que a ação esteja executada. O valor é formatado nos segundos e pode variar entre 1 e 4,294,967,295.

    • Após-ínterim-volume – Esta opção atribui a quota provisória e permite a continuação ou a terminação da sessão antes da exaustão do volume configurado. O valor é formatado nos bytes e pode variar entre 1 e 4,294,967,295.

    • Server-Retries – Esta opção permite que o PCEF experimente de novo os OC antes da continuação ou da terminação da sessão. O contagem de novas tentativas pode ser configurado, e as escalas do valor entre 0 e 65,535. Se o valor é zero, a seguir a nova tentativa não ocorre e a ação é imediatamente aplicada.

Nota: As opções do após-ínterim-tempo e do após-ínterim-volume são usadas sempre com a opção do server-Retries, ou todos os três podem ser usados simultaneamente e aplicado a continue e termine ações. As opções do após-ínterim-tempo e do após-ínterim-volume igualmente atribuem a quota do tempo assim como do volume, e a quota que é esgotada primeiramente provoca a nova tentativa do server.

  • Após-temporizador-expiração – Esta opção especifica a duração do tempo (nos segundos) para que as sessões permanecem no status off-line antes que a terminação ocorra. Os valores podem variar entre 1 e 4,294,967,295. Esta opção é somente aplicável para termina ações.

  • Após-quota-expiração – Esta opção termina a sessão em cima da exaustão da quota já atribuída.

Está aqui alguma informação importante a recordar:

  • O após-ínterim-tempo, o após-ínterim-volume, e as opções do server-Retries podem ser usados individualmente ou na combinação, e é aplicável a continua e termina ações.

  • A opção da após-quota-expiração é somente aplicável para o disparador do comportamento dos Atualização-pedidos.

  • A opção da após-temporizador-expiração é somente aplicável para a ação da terminação.

  • O após-ínterim-tempo, o após-ínterim-volume, e as opções do server-Retries são somente aplicáveis para versões 12.2 e mais recente.

  • Se o failover de sessão do diâmetro está apoiado (e configurado), a seguir o servidor secundário está contactado sempre antes que o mecanismo SU esteja provocado.

  • O server que esteve contactado por último antes que o mecanismo SU esteja provocado é contactado sempre quando o volume provisório do tempo ou do ínterim é esgotado e as novas tentativas que do server a opção é configurada com um valor que seja maior de zero. Por exemplo, se OCS1 é tentado primeiramente, e OCS2 é tentado após um erro em OCS1, então uma comunicação com o OCS2 provoca o mecanismo SU. Durante a tentativa da nova tentativa do server, OCS2 está contactado primeiramente e então OCS1 se uma resposta negativa é recebida de OCS2.

Fluxos de chamadas do mecanismo SU

O mecanismo SU pode ser provocado por uma falha do CCR-I ou do CCR-U, e a causa pode ser um código de erro, uma falha do transporte, uma TX-expiração, ou um RT. A ação pode ser uma atribuição da quota provisória (tempo e/ou volume), da contagem de novas tentativas do server, do valor de temporizador (faz com que a sessão vá off line pelo tempo especificado e somente para a terminação), ou da expiração da quota (somente para o CCR-U e a terminação) antes que a sessão vá off line ou termine.

A quota provisória é fornecida por sessão em uma base, não uma base do grupo da por-avaliação (RG) em encenações do controle de crédito dos serviços múltiplos (MSCC).

Há uma possibilidade que os disparadores do servidor primário transportam a falha e o servidor secundário provoca a TX-expiração ou o resposta-intervalo. Nesta encenação, o erro o mais atrasado é considerado ser o disparador da falha.

Se o mecanismo SU não é configurado para nenhum disparador da falha, a seguir o mecanismo FH está provocado.

Nota: As seções que seguem fornecem alguns exemplos do fluxo de chamadas que são relacionados ao mecanismo SU. Estes fluxos de chamadas são fornecidos sob a suposição que o diâmetro-sessão-Failover está apoiado e o servidor secundário está configurado com um valor da TX-expiração que seja menos do que o valor RT. Também, supõe-se que o mecanismo SU está configurado para a transporte-falha, a TX-expiração, e o RT.

Solicitação inicial sem disconexão da sessão

Está aqui o fluxo de mensagem para esta encenação:

  1. O PCEF envia um CCR-I aos OC.

  2. Uma falha do intervalo ou do transporte é detectada. Se a falha do transporte é detectada, a seguir o PCEF experimenta de novo imediatamente com o servidor secundário; se não, a TX-expiração é provocada.

  3. Se o servidor secundário igualmente tem uma falha ou um intervalo do transporte, a seguir o mecanismo SU está provocado. Isto ocorre imediatamente para falhas do transporte, ou após a TX-expiração para um intervalo.

  4. Se o volume e/ou o tempo provisórios são configurados, a seguir a quota provisória está atribuída à sessão.

  5. Após a exaustão da quota provisória (tempo ou volume) e se o valor de novas tentativas do server é maior de zero, a seguir o CCR-I é enviado outra vez ao server que provocou o mecanismo SU. Se há uma outra falha, o CCR-I está enviado a um outro server.

  6. Se a falha ou o TX-intervalo do transporte são detectados outra vez, a seguir etapas 2 com 5 estão repetidas até que o valor de novas tentativas do server esteja esgotado ou uma resposta bem sucedida não vier dos OC.

  7. Se a edição ainda existe, a seguir a sessão está continuada (convertido a off line) ou terminada conforme a configuração.

Nota: A quota provisória que é consumida quando a sessão entrar no modo SU devido a CCR-I não é relatada no CCR-I seguinte. Toda a quota provisória usada é relatada no CCR-U, que segue o CCA-I bem sucedido.

Solicitação inicial com disconexão da sessão

Está aqui o fluxo de mensagem para esta encenação:

  1. O PCEF envia um CCR-I aos OC.

  2. Uma falha do intervalo ou do transporte é detectada. Se a falha do transporte é detectada, a seguir o PCEF experimenta de novo imediatamente com o servidor secundário; se não, a TX-expiração é provocada.

  3. Se o servidor secundário igualmente tem uma falha ou um intervalo do transporte, a seguir o mecanismo SU está provocado. Isto ocorre imediatamente para falhas do transporte, ou após a TX-expiração para um intervalo.

  4. Se o volume e/ou o tempo provisórios são configurados, a seguir a quota provisória está atribuída à sessão.

  5. Após a exaustão da quota provisória (tempo ou volume) e se o valor de novas tentativas do server é maior de zero, a seguir o CCR-I é enviado outra vez ao server que provocou o mecanismo SU. Se há uma outra falha, o CCR-I está enviado a um outro server.

  6. Se a falha ou o TX-intervalo do transporte são detectados outra vez, a seguir etapas 2 com 5 estão repetidas até que o valor de novas tentativas do server esteja esgotado ou uma resposta bem sucedida não vier dos OC. Neste momento, a sessão é desligada sem consumo da quota provisória inteira.

  7. Após a terminação de sessão, o PCEF envia outra vez o CCR-I a fim começar uma sessão nova. Se isto é bem sucedido, a seguir o PCEF envia o CCR-T, que relata a quota provisória do todo que foi usada.

Atualização-pedido sem disconexão da sessão

Está aqui o fluxo de mensagem para esta encenação:

  1. O PCEF envia um CCR-U aos OC.

  2. Uma falha do intervalo ou do transporte é detectada. Se a falha do transporte é detectada, a seguir o PCEF experimenta de novo imediatamente com o servidor secundário; se não, a TX-expiração é provocada.

  3. Se o servidor secundário igualmente tem uma falha ou um intervalo do transporte, a seguir o mecanismo SU está provocado. Isto ocorre imediatamente para falhas do transporte, ou após a TX-expiração para um intervalo.

  4. Se o volume e/ou o tempo provisórios são configurados, a seguir a quota provisória está atribuída à sessão.

  5. Após a exaustão da quota provisória (tempo ou volume) e se o valor de novas tentativas do server é maior de zero, a seguir o CCR-U é enviado outra vez ao server que provocou o mecanismo SU. Se há uma outra falha, um CCR-U está enviado a um outro server que contenha a quota não-relatado consumida inteira.

  6. Se a falha ou o TX-intervalo do transporte são detectados outra vez, a seguir etapas 2 com 5 estão repetidas até que o valor de novas tentativas do server esteja esgotado ou uma resposta bem sucedida não vier dos OC.

  7. A quota consumida inteira é relatada aos OC com o CCR-U bem sucedido.

  8. Se a edição ainda existe, a seguir a sessão está continuada (convertido a off line) ou terminada conforme a configuração após a exaustão do valor de nova tentativa máxima.

Atualização-pedido com disconexão da sessão

Está aqui o fluxo de mensagem para esta encenação:

  1. O PCEF envia um CCR-U aos OC.

  2. Uma falha do intervalo ou do transporte é detectada. Se a falha do transporte é detectada, a seguir o PCEF experimenta de novo imediatamente com o servidor secundário; se não, a TX-expiração é provocada.

  3. Se o servidor secundário igualmente tem uma falha ou um intervalo do transporte, a seguir o mecanismo SU está provocado. Isto ocorre imediatamente para falhas do transporte, ou após a TX-expiração para um intervalo.

  4. Se o volume e/ou o tempo provisórios são configurados, a seguir a quota provisória está atribuída à sessão.

  5. Após a exaustão da quota provisória (tempo ou volume) e se o valor de novas tentativas do server é maior de zero, a seguir o CCR-U é enviado outra vez ao server que provocou o mecanismo SU. Se há uma outra falha, um CCR-U está enviado a um outro server que contenha a quota não-relatado consumida inteira.

  6. Se a falha ou o TX-intervalo do transporte são detectados outra vez, a seguir etapas 2 com 5 estão repetidas até que o valor de novas tentativas do server esteja esgotado ou uma resposta bem sucedida não vier dos OC. Neste momento, a sessão é desligada antes que consuma a quota provisória inteira.

  7. O PCEF envia um CCR-T aos OC a fim relatar a quota consumida inteira.

  8. Se os OC respondem com um código do resultado 2002, a seguir os relatórios adicionais não estão precisados.

Atualização-pedido com sessão desconhecida

Está aqui o fluxo de mensagem para esta encenação:

  1. O PCEF envia um CCR-U aos OC.

  2. Uma falha do intervalo ou do transporte é detectada. Se a falha do transporte é detectada, a seguir o PCEF experimenta de novo imediatamente com o servidor secundário; se não, a TX-expiração é provocada.

  3. Se o servidor secundário igualmente tem uma falha ou um intervalo do transporte, a seguir o mecanismo SU está provocado. Isto ocorre imediatamente para falhas do transporte, ou após a TX-expiração para um intervalo.

  4. Se o volume e/ou o tempo provisórios são configurados, a seguir a quota provisória está atribuída à sessão.

  5. Após a exaustão da quota provisória (tempo ou volume) e se o valor de novas tentativas do server é maior de zero, a seguir o CCR-U é enviado outra vez ao server que provocou o mecanismo SU. Se há uma outra falha, um CCR-U está enviado a um outro server que contenha a quota não-relatado consumida inteira.

  6. Os OC respondem com (um código do resultado 5002 do ID de sessão desconhecido) para o CCR-U, que é possível na encenação onde os OC reiniciaram e perderam a informação do ID de sessão.

  7. O PCEF inicia uma sessão nova com o CCR-I e recebe o CCA-I.

  8. O PCEF relata a quota provisória consumida inteira através de CCR-U nos mensagens subsequente.

Atualização-pedido com RGs múltiplo (encenação MSCC)

Está aqui o fluxo de mensagem para esta encenação:

  1. O PCEF envia o CCR-U para RG1 aos OC.

  2. Uma falha do intervalo ou do transporte é detectada. Se a falha do transporte é detectada, a seguir o PCEF experimenta de novo imediatamente com o servidor secundário; se não, a TX-expiração é provocada.

  3. Se o servidor secundário igualmente tem uma falha ou um intervalo do transporte, a seguir o mecanismo SU está provocado. Isto ocorre imediatamente para falhas do transporte, ou após a TX-expiração para um intervalo.

  4. Se o volume e/ou o tempo provisórios são configurados, a seguir a quota provisória está atribuída à sessão

  5. Neste momento RG2 igualmente esgota a quota atribuída inteira mas não inicia o CCR-U porque a sessão reage já do modo SU e começa a consumir a quota provisória.

  6. Após a exaustão da quota provisória (tempo ou volume) e se o valor de novas tentativas do server é maior de zero, a seguir o CCR-U é enviado outra vez ao server que provocou o mecanismo SU. Se há uma outra falha, um CCR-U está enviado a um outro server que contenha a quota não-relatado consumida inteira para ambos o RGs.

  7. Se a falha ou o TX-intervalo do transporte são detectados outra vez, a seguir etapas 2 com 6 estão repetidas até que o valor de novas tentativas do server esteja esgotado ou uma resposta bem sucedida não vier dos OC.

  8. A quota consumida inteira é relatada aos OC com o CCR-U bem sucedido.

  9. Se a edição ainda existe, a seguir a sessão está continuada (convertido a off line) ou terminada conforme a configuração após a exaustão do valor de nova tentativa máxima.

Terminate-Request

Está aqui o fluxo de mensagem para esta encenação:

  1. O PCEF envia um CCR-T aos OC.

  2. Uma falha do intervalo ou do transporte é detectada. Se a falha do transporte é detectada, a seguir o PCEF experimenta de novo imediatamente com o servidor secundário; se não, a TX-expiração é provocada.

  3. Se o servidor secundário igualmente tem uma falha ou um intervalo do transporte, a seguir a sessão está removida.

Manipulação do código de erro CCR

Está aqui o fluxo de mensagem para esta encenação:

  1. Os PCEF enviam um CCR aos OC, e os OC respondem com um código de erro.

  2. O código de erro é configurado estaticamente no mecanismo SU.

  3. O PCEF fornece a quota provisória sem uma nova tentativa ao servidor secundário.

Exemplos de configuração FH e SU

Esta seção fornece um exemplo de configuração para os mecanismos FH e SU. Quando os mecanismos FH e SU são configurados, o SU toma a precedência sobre o FH para o mesmo disparador do comportamento.

Aqui está um exemplo:

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

Verificar

A fim verificar que sua configuração trabalha corretamente, incorpore o comando decarregamento do name> do <service do serviço da mostra:

# 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

Inscreva o comando statistics decarregamento do crédito-controle da mostra a fim ver as estatísticas que são relacionadas aos mecanismos SU e FH. Está aqui um exemplo de saída:

#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

Estão aqui algumas observações importantes sobre estas saídas de exemplo:

  • TX-expiração – Isto indica uma condição SU devido a uma TX-expiração.

  • Resposta-intervalo – Isto indica uma condição SU devido a um RT.

  • Falha de conexão – Isto indica uma condição SU devido a uma falha do transporte.

  • Ação-continue – Este campo indica o número de sessões que foram off line.

  • Ação-termine – Este campo indica o número de sessões que foram terminadas.

  • Retries do server – Este campo indica o número de vezes que os OC estiveram experimentados de novo.

  • Sessões Supor-positivas:

    • Atual – Este campo indica o número de sessões que estão atualmente na condição SU.

    • Cumulativo – Este campo indica o número total de sessões que se moveram no estado SU.

Inscreva o comando all completo decarregamento das sessões da mostra a fim ver a informação que é relacionada ao estado SU da sessão. Está aqui um exemplo de saída:

#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

Estão aqui algumas observações importantes sobre estas saídas de exemplo:

  • Estado inacessível do servidor atual – Isto especifica se o estado atual SU é devido ao CCR-I ou ao CCR-U.

  • O volume provisório nos bytes (usados/distribuídos) – isto mostra o volume provisório nos bytes usados contra os bytes atribuídos.

  • Tempo provisório nos segundos (usados/distribuídos) – isto mostra o volume provisório nos segundos usados contra os segundos atribuídos.

  • O server experimenta de novo (tentado/configurado) – este é o número de novas tentativas do server tentadas contra aquela configurada.

Informações Relacionadas



Document ID: 118993