Configurazione della gestione dei guasti e dei meccanismi irraggiungibili dal server per la risoluzione dei guasti OCS sull'ASR5K

Opzioni per il download

PDF (176.7 KB)
Visualizza con Adobe Reader su diversi dispositivi
ePub (110.9 KB)
Visualizza in diverse app su iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (111.6 KB)
Visualizza su dispositivo Kindle o tramite app Kindle su più dispositivi

Aggiornato:2 giugno 2015

ID documento:118993

Linguaggio senza pregiudizi

La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.

Informazioni su questa traduzione

Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).

Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Premesse

Configurazione

Esempio di rete

Tx-Scadenza

Timeout risposta

Failover di sessione con diametro

Meccanismo FH

Configurazione meccanismo FH

Comportamento predefinito del meccanismo FH

Flusso chiamate dettagliate meccanismo FH

Meccanismo SU

Configurazione meccanismo SU

Flussi chiamate meccanismo SU

Configurazioni di esempio per FH e SU

Verifica

Risoluzione dei problemi

Informazioni correlate

Introduzione

In questo documento viene descritto come configurare i meccanismi FH (Failure-Handling) e SU (Server-Unreachable) sull'interfaccia Gy per risolvere i problemi rilevati nel sistema di caricamento online (OCS) o per quanto riguarda la connettività tra la funzione PCEF (Policy and Charging Enforcement Function) e OCS. Le informazioni descritte in questo documento si applicano alle funzionalità Home Agent (HA), GPRS (Gateway General Packet Radio Service) Support Node (GSN) e PGW (Packet Data Network Gateway) che vengono eseguite su Cisco serie 5000 Aggregated Services Router (ASR5K).

Prerequisiti

Requisiti

Cisco consiglia al sistema di soddisfare questi requisiti per utilizzare i meccanismi FH e SU:

È disponibile il servizio di ricarica avanzata (ECS, Enhanced Charging Service)
La funzione PCEF esiste all'interno di HA, GSN o PGW
La connettività del diametro è adeguata tramite il diabase
È disponibile l'applicazione DCCA (Diameter Credit Control Application)

Componenti usati

Le informazioni fornite in questo documento si basano su tutte le versioni di ASR5K.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

Il PCEF è collegato a OCS tramite l'interfaccia Gy, che utilizza Diameter come protocollo di base e DCCA. Questo è il flusso di messaggi tra PCEF e OCS:

Credit Control Request (CCR) âÂ Questo messaggio viene inviato dal PCEF a OCS. Esistono tre tipi di messaggi CCR: Iniziale, Aggiorna e Termina.
Credit Control Answer (CCA) âÂÂ Questo messaggio viene inviato da OCS al PCEF in risposta al CCR. Esistono inoltre tre tipi di messaggi CCA: Iniziale, Aggiorna e Termina.
Richiesta di riautorizzazione (RAR) âÂ Questo messaggio viene inviato da OCS al PCEF quando è necessaria una riautorizzazione della sessione.
Risposta di riautorizzazione (RAA) âÂQuesta è la risposta al RAR dal PCEF all'OCS.

Viene stabilita una connettività del diametro tra il PCEF e l'OCS per abilitare il flusso dei messaggi. È possibile che OCS invii messaggi negativi, che la connessione di trasporto tra PCEF e OCS abbia esito negativo oppure che il messaggio sia in timeout e ciò possa causare un errore nell'impostazione della sessione del sottoscrittore. In questo modo l'abbonato potrebbe non poter utilizzare i servizi.

Per risolvere il problema è possibile utilizzare i due meccanismi seguenti:

Il meccanismo FH
Il meccanismo degli Stati Uniti

Configurazione

In questa sezione vengono descritte le configurazioni necessarie per supportare i meccanismi FH e SU.

Esempio di rete

Per le informazioni di questo documento viene utilizzata la topologia seguente:

Tx-Scadenza

Timer a livello di applicazione per DCCA configurabile nelle impostazioni di controllo del credito del diametro. Il valore può essere compreso tra 1 e 300 secondi.

Di seguito è riportato un esempio:

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

Timeout risposta

Si tratta di un timeout del diabase ed è possibile configurarlo nelle impostazioni dell'endpoint del diametro. Il valore può essere compreso tra 1 e 300 secondi.

Nota: Il valore configurato per questo timer deve essere maggiore di quello utilizzato per il timer Tx-Expiry.

Di seguito è riportato un esempio:

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

Failover di sessione con diametro

Questa funzione viene utilizzata per abilitare o disabilitare il failover della sessione di controllo del credito del diametro, che consente al sistema di utilizzare un server secondario quando il server primario diventa irraggiungibile. Questa opzione può essere configurata nelle impostazioni di controllo del credito del diametro.

Di seguito è riportato un esempio:

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

Meccanismo FH

Il meccanismo FH funziona solo se è presente il failover di sessione del diametro. FH consente al sistema di scegliere se continuare la sessione e convertirla in modalità non in linea oppure terminare la sessione quando si verifica un errore a livello di connessione o di messaggio.

Nota: FH è abilitato e configurato per impostazione predefinita.

Configurazione meccanismo FH

Il meccanismo FH può essere configurato nelle impostazioni di controllo del credito del diametro. Di seguito viene riportata la sintassi utilizzata nella configurazione 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 prima sezione specifica il tipo di richiesta: Iniziale (CCR-I), Aggiornamento (CCR-U) e Termina (CCR-T).

La seconda sezione specifica l'azione da eseguire quando viene attivato il meccanismo FH. Il meccanismo FH permette di realizzare le tre seguenti azioni:

Continue âÂ In questo modo la sessione continua e la converte in offline. Questa funzione utilizza due opzioni correlate alla scadenza imposta:
- Go-offline-after-tx-expÂ ÂÂ Questa opzione avvia la ricarica offline dopo la scadenza di Tx.
- Retry-after-tx-expÂ ÂÂ In questo modo si ritenta il server secondario dopo la scadenza di Tx.
Retry-and-terminate âÂ In questo modo la sessione viene terminata dopo che il sistema ha eseguito un nuovo tentativo di accesso al server secondario, se questo non è disponibile. In questo modo viene inoltre utilizzata l'opzione Retry-after-tx-expend, che consente di riprovare il server secondario dopo la scadenza di Tx.
Terminate âÂÂ In questo modo la sessione viene terminata senza alcun tentativo di contattare il server secondario.

Comportamento predefinito del meccanismo FH

In questa sezione viene descritto il comportamento predefinito di FH quando non è presente alcuna configurazione. Per impostazione predefinita, il meccanismo FH viene attivato durante un timeout di risposta (RT, Response Timeout), tranne quando è configurata l'azione Termina.

Se viene ricevuta una coppia di valori dell'attributo Credit-Control-Failure-Handling (AVP) dal server, vengono applicate le impostazioni ricevute.

Seguono alcuni esempi:

Initial-Request > Termina
Update-Request > Retry-and-Terminate
Termina-Richiesta > Riprova-e-Termina

Flusso chiamate dettagliate meccanismo FH

In questa sezione viene descritto in dettaglio il flusso di chiamata del meccanismo FH con tutte le opzioni possibili.

Richiesta iniziale

Impostazione CCFH	Comando CLI	Comportamento a Tx	Comportamento in RT	Il database secondario è attivo	Secondario non attivo
Continua	richiesta iniziale continua	N/D	Continua	Secondaria rileva dopo RT	Offline dopo un altro RT. Non vengono eseguite altre richieste di quota per qualsiasi gruppo di valutazione all'interno della sessione dopo un errore DCCA (anche se la connettività a DCCA viene ripristinata)
	richiesta iniziale continua offline dopo tx-scadenza	Non in linea	N/D	Offline in modalità Tx	Offline in modalità Tx
	richiesta iniziale continua dopo tx-scadenza	Continua	N/D	Secondaria rileva dopo Tx	Offline dopo un'altra transazione
Riprova e termina	richiesta iniziale retry-and-terminate	N/D	Riprova	Secondaria rileva dopo RT	Termina dopo un altro RT
Riprova e termina	richiesta iniziale retry-and-terminate riprova-dopo-scadenza-tx	Riprova	N/D	Secondaria rileva dopo Tx	Termina dopo un'altra trasmissione
Termina	richiesta iniziale terminare	Termina	N/D	Termina dopo Tx	Termina dopo Tx

Update-Request

Impostazione CCFH	Comando CLI	Comportamento a Tx	Comportamento in RT	Il database secondario è attivo	Secondario non attivo
Continua	richiesta-aggiornamento continua	N/D	Continua	Secondaria rileva dopo RT	Offline dopo un altro RT
	richiesta-aggiornamento continua offline dopo tx-scadenza	Non in linea	N/D	Offline in modalità Tx	Offline in modalità Tx
	richiesta-aggiornamento continua dopo tx-scadenza	Continua	N/D	Secondaria rileva dopo Tx	Offline dopo un'altra transazione
Riprova e termina	richiesta-aggiornamento retry-and-terminate	N/D	Riprova	Secondaria rileva dopo RT	Invia CCR-T dopo un altro RT
Riprova e termina	richiesta-aggiornamento retry-and-terminate riprova-dopo-scadenza-tx	Riprova	N/D	Secondaria rileva dopo Tx	Invia CCR-T dopo un'altra trasmissione
Termina	richiesta-aggiornamento terminare	Termina	N/D	Invia CCR-T dopo Tx	Invia CCR-T dopo Tx

Terminate-Request

Impostazione CCFH	Comando CLI	Comportamento a Tx	Comportamento in RT	Il database secondario è attivo	Secondario non attivo
Continua	terminate-request continua	N/D	Riprova	CCR-T inviato secondario dopo RT	Termina dopo un altro RT
	terminate-request continua offline dopo tx-scadenza	Riprova	N/D	CCR-T inviato secondario dopo Tx	Termina dopo un'altra trasmissione
	terminate-request continua dopo tx-scadenza	Riprova	N/D	CCR-T inviato secondario dopo Tx	Termina dopo un'altra trasmissione
Riprova e termina	terminate-request retry-and-terminate	N/D	Riprova	CCR-T inviato secondario dopo RT	Termina dopo un altro RT
Riprova e termina	terminate-request retry-and-terminate riprova-dopo-scadenza-tx	Riprova	N/D	CCR-T inviato secondario dopo Tx	Termina dopo un'altra trasmissione
Termina	terminate-request terminare	Termina	N/D	Termina dopo Tx	Termina dopo Tx

Meccanismo SU

Il meccanismo SU è simile al meccanismo FH, ma fornisce un controllo più granulare sulle procedure di errore. Oltre alla continuazione della sessione dopo gli errori a livello di messaggio e connessione (trasporto), questo meccanismo può essere utilizzato quando le risposte sono lente da OCS. Fornisce inoltre le opzioni per continuare la sessione per una certa durata/esaurimento della quota prima della terminazione, oppure utilizzare la quota temporanea configurabile (volume e tempo) e i tentativi del server configurabili prima che una sessione venga convertita in non in linea o terminata.

Configurazione meccanismo SU

Il meccanismo SU può essere configurato nelle impostazioni di controllo del credito del diametro. La sintassi utilizzata nella configurazione su varia in base alla versione utilizzata.

Nelle versioni 12.1 e precedenti, questa è la sintassi utilizzata per la configurazione del meccanismo SU:

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

Per la versione 12.2 e successive, questa è la sintassi utilizzata per la configurazione del meccanismo 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: Nelle versioni precedenti alla versione 12.2, era possibile configurare i meccanismi FH e SU in modo indipendente; tuttavia, nelle versioni 12.2 e successive, il meccanismo SU ha la precedenza sul meccanismo FH quando viene configurato.

Se il server restituisce l'AVP CC-FH e il meccanismo SU è configurato per una serie di trigger di comportamento, viene applicata la configurazione SU; in caso contrario, viene applicato il valore CC-FH AVP. Per impostazione predefinita, i codici di risultato come 3002, 3004 e 3005 rientrano in un errore di recapito e vengono trattati come RT.

Queste azioni sono possibili grazie al meccanismo USA:

Behavior-Trigger ÂÂ Specifica il tipo di messaggi che possono essere Richieste iniziali (CCR-I) o Richieste di aggiornamento (CCR-U). Per questi trigger sono disponibili tre opzioni:
- Codice risultato âÂÂÂ Consente la configurazione di codici risultato specifici, di intervalli di codici risultato (3000-5999) o di qualsiasi errore insieme al tipo di messaggio.
- Transport-Failure âÂÂ Questa specifica attiva il comportamento in caso di errore di trasporto, compatibile con la versione 12.0 precedente. Sono disponibili due opzioni per questa impostazione:
  - Response-Timeout âÂ Questa opzione attiva il comportamento su RT e deve essere sempre utilizzata in caso di errori di trasporto.
  - Tx-Expiry âÂ Questa opzione attiva il comportamento alla scadenza di Tx e deve essere sempre utilizzata in caso di errore di trasporto.
- Azioni âÂÂ Specifica l'azione che viene eseguita quando si verifica un trigger SU per CCR-I o CCR-U. Questa azione varia in base al tipo di messaggio e alla versione del software.
Continue ÂÂ In questo modo è possibile convertire la sessione in offline e continuare. Non sono disponibili altre opzioni per l'utilizzo di questa azione nelle versioni precedenti alla 12.2. Nelle versioni 12.2 e successive, le opzioni relative alla quota provvisoria, ai tentativi del server e alla scadenza del timer sono disponibili per la configurazione con questa azione.
TerminateÂÂ In questo modo la sessione viene terminata quando il server diventa irraggiungibile. Questa azione consente di impostare le opzioni relative alla quota provvisoria, ai tentativi del server e alla scadenza del timer.

Le opzioni seguenti possono essere utilizzate con l'azione Continua o Termina:

After-interim-time ÂÂ Questa opzione consente di continuare o terminare la chiamata dopo il periodo di timeout provvisorio. È simile a una quota di tempo prima dell'esecuzione dell'azione. Il valore viene formattato in secondi e può essere compreso tra 1 e 4.294.967.295.
After-interim-volume ÂÂ Questa opzione assegna la quota provvisoria e consente la continuazione o la chiusura della sessione prima dell'esaurimento del volume configurato. Il valore è formattato in byte e può essere compreso tra 1 e 4.294.967.295.
Server-retries ÂÂ Questa opzione consente al PCEF di riprovare a eseguire OCS prima della continuazione o della chiusura della sessione. È possibile configurare il numero di tentativi e il valore è compreso tra 0 e 65.535. Se il valore è zero, il tentativo non verrà eseguito e l'azione verrà applicata immediatamente.

Nota: Le opzioni after-interim-time e after-interim-volume vengono sempre utilizzate con l'opzione server-retries oppure possono essere utilizzate contemporaneamente e applicate a entrambe le azioni continue e terminate. Le opzioni after-interim-time e after-interim-volume assegnano anche il tempo e la quota del volume e la quota esaurita innesca un nuovo tentativo del server.

Dopo la scadenza del timerÂÂ Questa opzione specifica la durata (in secondi) per la quale le sessioni rimangono nello stato offline prima che si verifichi la terminazione. I valori possono essere compresi tra 1 e 4.294.967.295. Questa opzione è applicabile solo per le azioni di terminazione.
Dopo la scadenza della quota âÂÂ Questa opzione termina la sessione al momento dell'esaurimento della quota già assegnata.

Ecco alcune importanti informazioni da ricordare:

Le opzioni after-interim-time, after-interim-volume e server-retries possono essere utilizzate singolarmente o in combinazione e sono applicabili sia alle azioni continue che alle azioni terminate.
L'opzione after-quota-expndr è applicabile solo al trigger di comportamento Update-Requests.
L'opzione after-timer-exceeded (dopo la scadenza del timer) è applicabile solo all'azione di terminazione.
Le opzioni after-interim-time, after-interim-volume e server-retries sono applicabili solo alla versione 12.2 e successive.
Se il failover di sessione del diametro è supportato (e configurato), il server secondario viene sempre contattato prima dell'attivazione del meccanismo SU.
Il server contattato per ultimo prima dell'attivazione del meccanismo su viene sempre contattato quando il tempo o il volume intermedio è esaurito e l'opzione tentativi del server è configurata con un valore maggiore di zero. Ad esempio, se si prova prima OCS1 e si prova OCS2 dopo un errore in OCS1, la comunicazione con OCS2 attiva il meccanismo SU. Durante il nuovo tentativo del server, viene contattato prima OCS2 e quindi OCS1 se viene ricevuta una risposta negativa da OCS2.

Flussi chiamate meccanismo SU

Il meccanismo SU può essere attivato da un guasto del CCR-I o del CCR-U, e la causa può essere un codice di errore, un guasto di trasporto, una scadenza Tx o RT. L'azione può consistere nell'allocazione di una quota provvisoria (tempo e/o volume), nel numero di tentativi del server, nel valore del timer (determina l'attivazione della modalità non in linea per l'ora specificata e solo per l'interruzione) o nella scadenza della quota (solo per CCR-U e l'interruzione) prima che la sessione venga disconnessa o termini.

La quota provvisoria viene fornita per sessione e non per gruppo di valutazione (RG) negli scenari MSCC (Multiple Services Credit Control).

Esiste la possibilità che il server primario generi un errore di trasporto e che il server secondario generi un timeout di scadenza Tx o di risposta. In questo scenario, l'errore più recente viene considerato come la causa del fallimento.

Se il meccanismo SU non è configurato per l'attivazione di un guasto, viene attivato il meccanismo FH.

Nota: Nelle sezioni seguenti vengono forniti alcuni esempi di flusso di chiamata correlati al meccanismo SU. Questi flussi di chiamate vengono forniti in base al presupposto che sia supportato il failover della sessione di diametro e che il server secondario sia configurato con un valore di scadenza Tx inferiore al valore RT. Inoltre, si presume che il meccanismo SU sia configurato per errori di trasporto, scadenza Tx e RT.

Richiesta iniziale senza disconnessione della sessione