Configurazione della raccolta di debug per i gateway CUBE (Unified Border Element) e TDM (Time-Division Multiplexing)

Introduzione

In questo documento vengono descritte alcune delle best practice da adottare per raccogliere i bug vocali in un router voce Cisco IOS/IOS-XE.

Prerequisiti

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.

Requisiti

• Conoscenze base di Cisco IOS/IOS-XE all'interno di ISR (Integrated Services Router).
• Accesso privilegiato per eseguire i comandi nei router ISR.
• Si desidera avere già esperienza con i protocolli VoIP (Voice-over-IP).
• Per la traccia VoIP è richiesto almeno Cisco IOS-XE 17.4.1 o 17.3.2.

Componenti usati

Ai fini del presente documento, i componenti utilizzati sono:

• Cisco ISR 3925
• Cisco ISR 4451
• PuTTY

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.

Sfondo

Il processo di raccolta di debug in queste piattaforme presenta problemi e potrebbe influire sulle prestazioni del dispositivo. Le sfide e i rischi aumentano quando vengono stabilite più chiamate attive in un router voce. In alcuni scenari, se i debug non vengono raccolti correttamente, la CPU può essere elevata, il che potrebbe compromettere la capacità del router e causare un arresto anomalo del software. In questo documento viene descritta la differenza tra un CUBE (Cisco Unified Border Element) e un TDM/Analog Gateway.

TDM Voice Gateway e CUBE

I gateway voce TDM vengono utilizzati principalmente per interconnettere un sistema telefonico interno con un altro PBX (Private Branch Exchange) o PSTN (Public Switched Telephony Network). I tipi di connessione utilizzati nei gateway TDM sono i controller T1/E1 (ISDN o CAS) e i circuiti analogici come le porte FXS e FXO. Un DSP (Digital Signal Processor) converte l'audio dalla sua forma raw in pacchetti RTP. Analogamente, i pacchetti RTP vengono convertiti in audio raw dopo che il DSP ha elaborato i pacchetti RTP e invia l'audio sul circuito specifico. Questi gateway possono interagire con H323, MGCP o SCCP sul lato VoIP e, sul lato TDM, con i circuiti PRI ISDN o Analogici come le connessioni più comuni ai PSTN o agli endpoint.

Come mostrato nell'immagine, i gateway TDM fungono da ponte tra l'infrastruttura VoIP interna e i provider di servizi analogici o ISDN.

Con l'introduzione del VoIP, i clienti hanno iniziato a trasformare rapidamente i sistemi legacy in una moderna infrastruttura VoIP. Lo stesso si è verificato dal lato del provider di servizi, dove ora utilizzano le connessioni per interconnettere i servizi di telefonia locale con l'infrastruttura VoIP del provider di servizi ed espandere le loro funzionalità per fornire servizi migliori. Il protocollo VoIP più comune utilizzato attualmente è il SIP (Session Initiation Protocol), attualmente ampiamente utilizzato dai clienti e dai provider di servizi di telefonia Internet (ITSP) in tutto il mondo.

CUBE è stato introdotto per fornire un modo per interconnettere questi sistemi VoIP interni con il mondo esterno attraverso gli ITSP con SIP come protocollo VoIP primario. CUBE è semplicemente un gateway IP in cui non ha più bisogno di alcun tipo di connessione TDM come i controller T1/E1 o le porte analogiche. CUBE viene eseguito sulle stesse piattaforme dei gateway TDM.

Il protocollo VoIP più comune utilizzato è il SIP, per la definizione e la disinstallazione delle chiamate, e la RTP per il trasporto dei media. In CUBE non è necessario un DSP a meno che non sia richiesto un transcodificatore. I flussi di traffico RTP terminano dall'ITSP all'endpoint e CUBE funge da intermediario, nascondendo l'indirizzo come una delle numerose funzionalità offerte.

Come mostrato nell'immagine, CUBE fornisce una divisione tra l'infrastruttura VoIP interna e SIP ITSP:

Raccolta dei debug vocali Cisco IOS/IOS-XE

Le funzionalità vocali vengono eseguite su un elenco diverso di piattaforme, ad esempio ISR, ASR, CAT8K e altre ancora, tuttavia utilizzano un software comune che può essere Cisco IOS o Cisco IOS-XE (le differenze tra Cisco IOS e Cisco IOS-XE non sono illustrate in questo articolo). Iniziamo con le informazioni di base su come accedere al router Cisco IOS.

Come accedere a un router Cisco IOS/IOS-XE dall'interfaccia della riga di comando (CLI)

I router, come tutti gli altri dispositivi basati sulla CLI, richiedono un terminal monitor per accedere e eseguire i comandi tramite Secure Shell (SSH) o Telnet. SSH è il protocollo più comune utilizzato oggigiorno per accedere ai dispositivi, in quanto fornisce una connessione protetta e crittografata al dispositivo. Alcuni dei terminal monitor più comuni utilizzati per accedere alla CLI dei router sono:

Come impostare Terminal Monitor per la raccolta dei comandi show o dei debug

Ci sono diversi modi per raccogliere l'output dalla CLI. Si consiglia di esportare le informazioni dalla CLI del router in un file separato. Ciò semplifica la condivisione delle informazioni con terze parti.

Di seguito sono riportati due modi per raccogliere gli output dal dispositivo:

• Scaricare tutto l'output nel terminale, per questo è necessario assicurarsi che ci siano abbastanza linee di scrollback, altrimenti lo scrollback non prende le prime sezioni dell'output e i dati possono essere incompleti. Per aumentare le linee di scorrimento in Putty, selezionate Configurazione Putty > Finestra > Linee di scorrimento. Normalmente questo valore è impostato su un valore molto alto per avere un output di scorrimento sufficiente:

Successivamente, è possibile raccogliere le informazioni dal monitor del terminale con l'opzione Copy All to Clipboard (Copia tutto negli Appunti) e incollare l'output in un file di testo:

• Un'altra opzione consiste nel registrare l'output dell'intera sessione in un file .txt. Con questa opzione tutti i comandi immessi e gli output raccolti vengono immediatamente registrati nel file di testo. Questa è una procedura comune per registrare tutto l'output in una sessione. Per registrare l'output di tutte le sessioni in un file in Putty, selezionate Configurazione Putty > Sessione > Log, quindi selezionate Output di tutte le sessioni come segue:

Nota: Se non viene specificato alcun altro nome, viene utilizzato il nome del file di registro predefinito. Fare clic sul pulsante Sfoglia per sapere esattamente dove è stato salvato il file e individuarlo in seguito. Assicurarsi inoltre di non sovrascrivere un altro file putty.log nello stesso percorso.

Raccogli output di base del comando show dalla CLI

I comandi show sono necessari per raccogliere informazioni di base dal router prima di qualsiasi raccolta di debug. I comandi show sono veloci da raccogliere e, nella maggior parte dei casi, non influiscono sulle prestazioni del router. L'isolamento del problema potrebbe iniziare immediatamente con un semplice output del comando show.

Una volta connesso al router, la lunghezza del terminale può essere impostata su 0. In questo modo, la raccolta può essere più veloce in modo da visualizzare tutto l'output contemporaneamente ed evitare l'uso della barra spaziatrice. L'unico comando che raccoglie informazioni dettagliate sul router è "show tech". In alternativa, è possibile raccogliere show tech voice che mostra dati più specifici delle funzionalità vocali abilitate sul router:

Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default

Raccogli output di debug dalla CLI

La raccolta degli output di debug in Cisco IOS/IOS-XE a volte può essere un problema, in quanto esiste il rischio di un arresto anomalo del router. Nelle sezioni seguenti vengono illustrate alcune delle procedure ottimali per evitare problemi.

Controllo della memoria

Prima di abilitare i debug, accertarsi che la memoria sia sufficiente per memorizzare l'output nel buffer.

Eseguire il comando show process memory per verificare la quantità di memoria che è possibile allocare per registrare tutto l'output nel buffer:

Suggerimento: Usare il comando terminal length default o terminal length <num_lines> per tornare a una quantità limitata di linee visualizzate nel terminale.

Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832

Nell'esempio, il router può usare fino a 766268552 byte (7,6 GB). Questa memoria è condivisa dal router tra tutti i processi di sistema; ciò significa che non è possibile utilizzare l'intera memoria libera per registrare l'output nel buffer, ma è possibile utilizzare una buona quantità di memoria di sistema in base alle esigenze.

La maggior parte degli scenari richiede almeno 10 MB per raccogliere un output di debug sufficiente prima che l'output venga perso o sovrascritto. In rari casi è necessario raccogliere una quantità maggiore di dati, in questi scenari specifici è possibile ottenere un output di 50 MB-100 MB nel buffer o si può andare più in alto se c'è memoria disponibile.

Se la memoria disponibile è insufficiente, è possibile che si verifichi una perdita di memoria. In questo caso, rivolgersi al team TAC per rivedere la causa di tale perdita di memoria.

Controllo CPU

La CPU è influenzata dalla quantità di processi, funzionalità e chiamate attivi nel sistema. Maggiore è il numero di funzioni o chiamate attive nel sistema, maggiore è il traffico della CPU.

Un buon punto di riferimento è quello di garantire che la CPU del router sia al 30% o inferiore, il che significa che è possibile abilitare i debug da quelli di base a quelli avanzati (è necessario tenere sempre sotto controllo la CPU quando si utilizzano i debug avanzati). Se la CPU del router è al 50% circa, è possibile eseguire i debug di base e monitorare attentamente la CPU. Se la CPU raggiunge un valore superiore all'80%, interrompere immediatamente i debug (come mostrato più avanti in questo articolo) e chiedere assistenza al centro TAC.

Utilizzare il comando show process cpu | exclude 0.00 per controllare i valori degli ultimi 5, 60 e 5 min della CPU insieme ai primi processi.

Router# show processes cpu sorted | exclude 0.00
CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
211 4852758 228862580 21 0.15% 0.06% 0.07% 0 IPAM Manager
84 3410372 32046994 106 0.07% 0.04% 0.05% 0 IOSD ipc task
202 3856334 114790390 33 0.07% 0.05% 0.05% 0 VRRS Main thread

Nell'output, il router non ha molta attività, la CPU è bassa e i debug possono essere abilitati senza problemi.

Attenzione: Prestare particolare attenzione ai primi processi CPU attivi, se la CPU è al 50% o superiore e il processo superiore è un processo vocale, è possibile abilitare solo i debug di base. Monitorare continuamente la CPU con il comando per garantire che le prestazioni complessive del router non siano influenzate.

Controllo chiamate attive correnti

Ogni router ha soglie di capacità diverse. È importante controllare quante chiamate sono attive nel router per assicurarsi che non si avvicini alla capacità massima. Il Data Sheet degli elementi del bordo unificato Cisco versione 12 fornisce informazioni su ciascuna capacità della piattaforma come riferimento.

Utilizzare il comando show call active total-call per avere un'idea del numero di chiamate attive nel sistema:

Router# show call active total-calls
Total Number of Active Calls : 0

Utilizzare il comando show call active voice summary per ottenere informazioni più dettagliate sui tipi di chiamata specifici attivi:

Router# show call active voice summary
Telephony call-legs: 0
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
STCAPP call-legs: 0
Multicast call-legs: 0
Total call-legs: 0

Alcuni dei valori comuni sono:

• Call-leg di telefonia: Chiamate TDM Gateway, incluse le chiamate Analog e PRI/ISDN.
• Call-leg SIP: Totale chiamate SIP. Se si tratta di un router CUBE, verranno visualizzati 2 segmenti di chiamata per chiamata. Dividere per 2 il totale delle chiamate visualizzate per ottenere un numero preciso.
• Call-leg H323: Totale chiamate H323.
• Call-leg SCCP: Risorse multimediali controllate da CUCM utilizzate nel router, ad esempio trascodificatori e MTP.

Impostazioni buffer di registrazione

Per configurare il router in modo che memorizzi l'output di debug nel buffer, viene immessa la modalità di configurazione del terminale per regolare manualmente le impostazioni nella CLI. Questa configurazione non ha alcun impatto sul router, tuttavia, come mostrato nelle sezioni precedenti, il comando show tech o show running-config inviato dal router è necessario nel caso sia necessario eseguire il rollback della configurazione.

Di seguito è riportato un esempio di configurazione, ovvero una linea di base comune utilizzata dai tecnici TAC. Nell'esempio vengono allocati 10 MB di memoria buffer, ma è possibile aumentarli in base alle esigenze: 

# configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers
logging buffered 10000000
no logging console
no logging monitor
logging queue-limit 10000
logging rate-limit 10000
voice iec syslog

I comandi eseguono le seguenti attività:

• debug o registro timestamp servizio: Assicura che l'ora del router locale venga scritta su ogni messaggio registrato, con una precisione di millisecondi. Ciò è utile per trovare le chiamate in base alla durata. Gli indicatori di ora in millisecondi consentono di raggruppare le linee di debug in eventi correlati logici quando due linee si verificano nello stesso millisecondo.
• numeri di sequenza del servizio: Scrive il numero di sequenza del debug nella riga. Ciò è utile (essenzialmente obbligatorio) quando i registri vengono inoltrati a un server syslog. Questa opzione permette di verificare se alcuni messaggi di debug inviati al server syslog sono stati scartati dalla rete. Il numero di sequenza è il primo elemento del debug, prima dell'indicatore orario e del messaggio del log effettivo. Si noti che questo valore è diverso dal numero di timestamp/sequenza che i server syslog possono scrivere localmente nei propri file.
• buffer di registrazione: Comunica al router di inviare i debug alla memoria buffer locale. La dimensione del buffer è impostata in byte. Nella configurazione la dimensione del buffer è stata impostata su 10 MB.
• nessuna console di registrazione e nessun monitor di registrazione: Sul monitor della console o del terminale non viene stampato alcun messaggio log. Se questi comandi non sono configurati, potrebbero influire negativamente sulle prestazioni del router e sull'accuratezza dell'output del debug.
• voice iec syslog: Abilita i messaggi dei codici di errore interni voce per determinare i motivi della disconnessione.

Configura impostazioni syslog

A volte i problemi possono essere casuali e richiedere un modo continuo di raccogliere i debug fino al verificarsi dell'evento. Quando i debug vengono memorizzati nel buffer, vengono raccolti continuamente. Notare che è limitato alla quantità di memoria che è possibile allocare e una volta raggiunta tale quantità di memoria, il buffer cerchia e rilascia i messaggi più vecchi, il che porta a informazioni incomplete e preziose necessarie per isolare il problema.

Con Syslog, il router può inviare tutti i messaggi di debug a un server esterno, dove il software Syslog Server li memorizza in file di testo. Sebbene sia un metodo valido per raccogliere l'output di debug, non è il metodo preferito per la raccolta dei log. I server Syslog tendono a ignorare o a eliminare le linee dall'output ricevuto a causa della congestione del server, poiché l'output di debug può sovraccaricare il server o i pacchetti possono essere scartati a causa delle condizioni della rete. Tuttavia, in alcuni scenari Syslog è l'unico modo per fare progressi su un problema.

Se possibile, utilizzare un metodo di trasporto affidabile, come il protocollo TCP, per evitare la perdita di informazioni. Si consiglia di collegare il server Syslog allo stesso switch a cui è connesso il router o il più vicino possibile al router. Ciò non garantisce che tutti i dati siano memorizzati nei file, ma riduce le possibilità di perdita dei dati.

Per impostazione predefinita, i server syslog utilizzano UDP come protocollo di trasporto sulla porta 514.

#configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers

!Optional in case you still want to store debug output in the buffer.
logging buffered 10000000

no logging console
no logging monitor

logging trap debugging

!Replace the 192.168.1.2 with the actual Syslog Server IP Address
logging host 192.168.1.2 transport [tcp|udp] port 
     
     

Non appena i comandi sono configurati, il router inoltra immediatamente i messaggi all'indirizzo IP del server Syslog.

Raccolta di debug

Dopo aver abilitato i debug, è necessario cancellare il buffer prima di riprodurre il problema. Ciò viene fatto per garantire che l'output sia il più pulito possibile ed evitare dati aggiuntivi non necessari per l'analisi. Eseguire il comando clear log per assicurarsi che il buffer venga cancellato. Se sul router sono attive altre chiamate e i debug sono abilitati, l'output viene immediatamente stampato nel buffer.

Router# clear log
Clear logging buffer [confirm]
Router#

Una volta riprodotto il problema, disabilitare immediatamente i debug per arrestare l'output nel buffer. Raccogliere quindi i registri. È possibile eseguire il dump di tutto l'output nel terminale con i seguenti comandi:

Router# undebug all
Router# terminal length 0
Router# show log

A volte PuTTY si chiude in quanto non è in grado di gestire tutto l'output in una volta sola. Questa condizione è normale e non significa che si sia verificato un errore, se ciò si verifica, riaprire di nuovo la sessione e continuare normalmente. Se il buffer di registrazione è troppo grande o il monitor del terminale si blocca a causa della quantità di dati da stampare, copiare l'output del buffer su una periferica esterna direttamente con il comando show log | reindirizzamento:

Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt

Il comando copia l'intero output del buffer in un ftp con indirizzo IP 192.168.1.2 e nome file debug.txt. Specificare sempre il nome del file. Altre destinazioni disponibili per l'esportazione dei dati sono:

Router# sh log | redirect ?
bootflash: Uniform Resource Locator
flash: Uniform Resource Locator
ftp: Uniform Resource Locator
harddisk: Uniform Resource Locator
http: Uniform Resource Locator
https: Uniform Resource Locator
nvram: Uniform Resource Locator
tftp: Uniform Resource Locator

Quali debug possono essere abilitati nei router voce?

Ogni flusso di chiamata e tipo di funzionalità (TDM, CUBE o SCCP (Media Resources)) sono diversi ed è possibile abilitare debug specifici. Tutti i debug richiesti devono essere abilitati contemporaneamente. L'acquisizione simultanea di un solo debug non è efficace e genera maggiore confusione durante l'analisi dei dati.

i debug sono abilitati all'interno del router n. del prompt di CLI exec che richiede le autorizzazioni della modalità di esecuzione privilegiata.

Sono disponibili debug di base e avanzati. I debug di base vengono usati per raccogliere le informazioni di segnalazione in SIP, H323 o MGCP, per mostrare le conversazioni tra il router e i dispositivi peer.

I debug avanzati sono molto dettagliati e vengono in genere utilizzati per raccogliere più informazioni in caso di errori interni dello stack che i debug di base non sono in grado di visualizzare. In genere, questi debug richiedono un utilizzo intensivo della CPU.

Suggerimento: Dopo aver abilitato i debug, eseguire il comando clear logging. Questo comando assicura che il buffer venga cancellato per un'acquisizione più pulita dei debug.

Debug dell'API CCAPI (Internal Call Control API)

All'interno di ciascun router Cisco IOS/IOS-XE è presente un'API di controllo delle chiamate responsabile della comunicazione tra diverse applicazioni o protocolli VoIP e i componenti Data Plane, ad esempio RTP, DSP, schede voce e altri. Per acquisire i dati da questo livello, è possibile usare un debug specifico:

debug voip ccapi inout

Per questo debug sono disponibili altre opzioni, tuttavia il comando debug voip ccapi inout copre tutte le informazioni di base relative alla connessione a dial-plan e alla chiamata, informazioni in genere più che sufficienti per comprendere quali sono gli stati di questo livello.

Suggerimento: il comando debug voip capi inout ha in genere un impatto minimo sulla CPU del router e si consiglia di abilitarlo insieme ai debug delle segnalazioni in modo da fornire un set completo di registri con le informazioni sulle chiamate e i relativi stati.

Flussi di chiamate SIP

Questi debug sono i più comunemente utilizzati per i flussi di chiamate SIP e possono essere abilitati all'interno dei gateway CUBE e TDM con una linea SIP tra il router e CUCM o qualsiasi altro server/proxy SIP.

Debug SIP base

debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.

Debug SIP avanzati

debug ccsip all
debug ccsip verbose
debug voice ccapi inout

Flussi di chiamate digitali (PRI, BRI)

Questi debug si applicano alle interfacce di frequenza primaria (PRI) T1/E1 o alle interfacce di velocità base (BRI):

Debug digitale di base

debug isdn q931

Debug digitale avanzato

debug isdn q921

Flussi di chiamate analogiche

Questi debug vengono usati quando sono coinvolti circuiti analogici come le porte Foreigh eXchange Subscriber (FXS) o Foreign eXchange Office (FXO):

debug vpm signal
debug voip vtsp all

Flussi di chiamate MGCP

Questi debug vengono usati quando il protocollo MGCP viene usato come protocollo vocale tra un Voice Gateway e CUCM.

Debug di base

debug mgcp packets
debug mgcp errors

Debug di CCM-Manager

Il comando debug cm-manager viene usato per tenere traccia dei messaggi di backhaul MoH e PRI/BRI tra CUCM e Voice Gateway. Questi debug vengono utilizzati in base alle necessità e dipendono dallo scenario di errore.

debug ccm-manager backhaul !For PRI and BRI Deployments
debug ccm-manager errors
debug ccm-manager events
debug ccm-manager config-download !Troubleshoot Configuration download issues from CUCM TFTP
debug ccm-mananger music-on-hold !Troubleshoot internal MoH Process

Debug avanzati MGCP

debug mgcp all

Flussi di chiamata H323

Sebbene H323 non sia ampiamente utilizzato, vi sono ancora alcune implementazioni con H323 configurato:

Debug base H323

debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events

Debug avanzati H323

debug cch323 h225
debug cch323 h245
debug cch323 all

Risorse multimediali SCCP

Questi debug vengono utilizzati per risolvere i problemi relativi alle risorse multimediali SCCP (Skinny Call Control Protocol) che coinvolgono MTP (Media Termination Point) o Transcoder registrati su un server Cisco Unified Communications Manager (CUCM):

Debug SCCP di base

debug sccp messages
debug sccp events
debug sccp errors

Debug SCCP avanzato

debug sccp all

Traccia VoIP

Con l'introduzione di Cisco IOS-XE 17.4.1 e 17.3.2, è disponibile una nuova opzione per acquisire i log vocali all'interno del CUBE (Cisco Unified Border Element). Questa nuova funzionalità è denominata Traccia VoIP. Si tratta di una nuova struttura di servizi creata per registrare i segnali SIP e gli eventi senza la necessità di abilitare debug. 

La traccia VoIP è abilitata per impostazione predefinita e può essere disabilitata in qualsiasi momento. VoIP Trace acquisisce informazioni specifiche solo per le chiamate SIP:

• Messaggi SIP per chiamate da trunk SIP a trunk
• Eventi e chiamate API dal livello SIP ad altri livelli nel CUBE
• Errori SIP
• Controllo delle chiamate (flussi di chiamate Unified Communications elaborati da CUBE)
• Stati ed eventi di macchine a stato finito (FSM)
• Dial Peer corrispondente
• Porte RTP allocate
• Correlazione degli errori IEC con la segnalazione SIP

Restrizioni

• La traccia VoIP non registra le informazioni correlate ai messaggi SIP fuori dialogo:
  • REGISTRATI
  • OPZIONI
  • ISCRIVITI/NOTIFICA
  • INFORMAZIONI
• La traccia VoIP in HA è supportata, tuttavia si applicano le seguenti avvertenze:
  • Per impostazione predefinita, per il router in standby la traccia VoIP è abilitata. Vengono presentate solo le tracce applicabili per il processo di standby fino a quando non diventa attivo
  • Quando lo standby è attivo, NON contiene le tracce complete delle chiamate a checkpoint e solo le nuove chiamate
  • show voip trace <key> funziona ancora sul router di standby e visualizza il buffer di copertura e i dati del flusso multimediale per le chiamate

Come abilitare la traccia VoIP

Come accennato in precedenza, questa funzione è abilitata per impostazione predefinita. Il comando per abilitare questa funzione è:

Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#

Come disabilitare la traccia VoIP

Per disabilitare questa funzione, i comandi sono:

Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown

Attenzione: Dopo aver disattivato la traccia VoIP, tutta la memoria viene cancellata e le informazioni vengono perse.

I comandi disponibili nella modalità di configurazione traccia sono:

Router(conf-serv-trace)# ?
default       Set a command to its defaults
  exit          Exit from voice service voip trace mode
  memory-limit  Set limit based on memory used
  no            Negate a command or set its defaults
  shutdown      Shut Voip Trace debugging

Configura limite di memoria

Il limite di memoria determina la quantità di memoria utilizzata dalla traccia VoIP per archiviare i dati. Per impostazione predefinita, è il 10% della memoria disponibile nella piattaforma, ma può essere modificato in un massimo di 1 GB e un minimo di 10 MB. La memoria allocata in modo dinamico, ovvero la funzionalità utilizza la memoria solo in base alle esigenze e dipende dal volume di chiamata. Una volta raggiunta la quantità massima di memoria disponibile, la macro esegue un cerchio ed elimina le voci meno recenti.

Quando il limite di memoria viene modificato in modo che sia maggiore del 10% della memoria disponibile, viene visualizzato un messaggio nell'interfaccia della riga di comando:

Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.

Per impostare l'utilizzo predefinito della memoria al 10%, è possibile utilizzare il comando memory-limit platform:

Router(conf-serv-trace)# memory-limit platform
 Reducing the memory-limit clears all VoIP Trace statistics and data.
 If you wish to copy this data first, enter 'no' to cancel,
 otherwise enter 'yes' to proceed. Continue? [no]: 

Attenzione: Quando si riduce il limite di memoria, tutti i dati di traccia VoIP vengono persi. Prima di ridurre la memoria è necessario raccogliere un backup dei dati.

Come visualizzare i dati di traccia VoIP

Per visualizzare i dati da VoIP Trace, è necessario utilizzare comandi show specifici. I dati possono essere visualizzati nella stessa sessione del terminale o inviati tramite Syslog a un server syslog esterno.

Nota: Le tracce vengono scaricate dopo 32 secondi dalla ricezione di un BYE per una chiamata.

Nota: Il segnale SIP viene visualizzato per tappa e non è combinato come un normale debug. I debug regolari, come i messaggi debug ccsip visualizzano la segnalazione SIP di una chiamata nell'ordine esatto in cui si sono verificati gli eventi. Nella traccia VoIP ogni segmento è separato. Per determinare l'ordine corretto, vengono utilizzati i timestamp.

Per visualizzare i dati, sono disponibili i seguenti comandi:

Router# show voip trace ?
  all            Display all VoIP Traces
  call-id        Filter traces based on Internal Call Id
  correlator     Filter traces based on FPI Correlator
  cover-buffers  Display the summary of all cover buffers
  session-id     Filter traces based on SIP Session ID
  sip-call-id    Filter traces based on SIP Call Id
  statistics     Display statistics for VoIP Trace

 show voip trace all

Con questo comando vengono visualizzati tutti i dati di traccia VoIP disponibili nel buffer. L'uso di questo comando influisce sulle prestazioni del router. Una volta immesso il comando, viene visualizzato un messaggio di avvertenza per avvisare del rischio e confermare per continuare:

Router# show voip trace all
 Displaying 11858 cover buffers
 This may severely impact system performance.
 Continue? [yes/no] no 

show voip trace cover-buffer

Questo comando visualizza una panoramica dei dettagli delle chiamate per tutte le chiamate segnalate in Traccia VoIP. Ogni tappa della chiamata dispone di un buffer di copertura che contiene un riepilogo della chiamata registrata.

Router# show voip trace cover-buffers
------------------ Cover Buffer ---------------
Search-key = 8845:3002:659
Timestamp = *Sep 30 01:17:33.615
Buffer-Id = 1
CallID = 659
Peer-CallID = 661
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 20857880-1ec12085-13b930-411b300a@10.48.27.65
SIP Session ID = 2b1289c400105000a0002c3ecf872659
GUID = 208578800000
-----------------------------------------------

------------------ Cover Buffer ---------------
Search-key = 8845:3002:661
Timestamp = *Sep 30 01:17:33.634
Buffer-Id = 2
CallID = 661
Peer-CallID = 659
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 8D6DEC28-1F111EB-829FD797-1B22F6DB@10.48.55.11
SIP Session ID = 0927767800105000a0005006ab805584
GUID = 208578800000
-----------------------------------------------

Per ulteriori informazioni su ciascun campo, consultare la tabella seguente:

Campo	Descrizione
Chiave di ricerca	Contiene una combinazione di chiamata, chiamata numero e call-id
Timestamp	Ora di creazione del buffer di copertura
Buffer-ID	ID buffer del buffer di copertura
Call-id	Call-id del segmento di chiamata corrispondente del buffer di copertura
Peer-CallID	ID chiamata della gamba peer
Correlatore	Correlatore FPI della chiamata
Numero chiamato	Numero richiamato della gamba di richiamo del buffer di copertura
Calling-number	Numero chiamante del segmento di chiamata corrispondente del buffer di copertura
Sip Call-ID	Call-id SIP del segmento di chiamata corrispondente del buffer di copertura
ID sessione SIP	ID sessione SIP della rispettiva parte di chiamata del buffer di copertura
GUID	GUID della chiamata corrispondente del buffer di copertura
Gamba di ancoraggio	La gamba di ancoraggio è impostata su yes se la gamba di richiamo corrispondente è una gamba di ancoraggio nel flusso di richiamo o nella distribuzione del proxy di supporto
Gamba biforcata	Gamba biforcata è impostata su yes se la gamba di richiamo corrispondente è una gamba di ancoraggio nel flusso di richiamo o nella distribuzione del proxy multimediale
ID CalI associati	Call-id delle gambe biforcate associate

Per filtrare i buffer di copertura, è possibile utilizzare i comandi include e section:

Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
!or
Router# show voip trace cover-buffers | section Search-key | 8845 | 3002
Search-key = 8845:3002:661

show voip trace call-id

In combinazione con il comando precedente, è possibile utilizzare show voip trace call-id per trovare le chiamate. Dopo aver identificato l'id della chiamata, è possibile utilizzare questo comando per visualizzare tutte le informazioni relative alla coda di chiamata specifica:

Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661

mostra statistiche traccia voip

Questo comando show visualizza un output dettagliato su stato, consumo di memoria, chiamate errate o non riuscite, chiamate riuscite, timestamp delle voci più recenti e meno recenti e altro ancora.

Router# show voip trace statistics
VoIP Trace Statistics
Tracing status             : ENABLED at *Sep 12 06:44:02.349
Memory limit configured    : 803209216 bytes
Memory consumed            : 254550928 bytes (31%)
Total call legs dumped     : 2
Oldest trace dumped        : *Sep 12 07:29:21.077 Search-key: 9898:30000:64
Latest trace dumped        : *Sep 12 07:29:21.010 Search-key: 9898:30000:63
Total call legs captured   : 11858
Total call legs available  : 11858
Oldest trace available     : *Sep 12 06:57:23.923, Search-key: 5250001:4720001:11
Latest trace available     : *Sep 13 05:08:25.353, Search-key: 19074502232:30000:13177
Total traces missed        : 0

Per ulteriori informazioni su ciascun campo, fare riferimento alla tabella seguente:

Campo	Descrizione
Stato traccia	Visualizza lo stato di traccia, inclusa la data e l'ora in cui è stata abilitata la traccia VoIP.
Limite di memoria configurato	Visualizza il limite di memoria configurato. 10% delle dimensioni della memoria del pool di processori
Memoria utilizzata	Visualizza la quantità di memoria utilizzata in modo dinamico per la traccia VoIP
Totale gambe chiamate scaricate	Visualizza il numero di segmenti di chiamata non riusciti scaricati nel buffer di registrazione. Le chiamate di tipo dump si riferiscono a componenti di chiamata associati a errori IEC
Traccia meno recente di cui è stato eseguito il dump	Visualizza i timestamp e la chiave di ricerca della chiamata non riuscita meno recente dall'abilitazione della traccia VoIP
Ultima traccia di cui è stato eseguito il dump	Visualizza i timestamp e la chiave di ricerca dell'ultima chiamata non riuscita dall'abilitazione della traccia VoIP
Totale gambe chiamate acquisite	Visualizza il totale dei segmenti acquisiti dopo l'abilitazione della traccia VoIP
Totale gambe chiamate disponibili	Visualizza il totale delle parti di chiamata disponibili nella cronologia. Può essere uguale o diverso rispetto al totale delle code di chiamata acquisite, a seconda del limite di memoria.
Traccia meno recente disponibile	Visualizza l'indicatore orario e la chiave di ricerca del buffer di copertura più vecchio disponibile in memoria
Traccia più recente disponibile	Visualizza l'indicatore orario e la chiave di ricerca dell'ultimo buffer di copertura disponibile nella memoria
Tracce mancanti totali	Visualizza il numero di segmenti di chiamata non riusciti a causa del limite di memoria.

Comandi show aggiuntivi

Campo	Utilizzo	Descrizione
show voip trace correlator <correlatore>	show voip trace correator 4	Filtra e visualizza la traccia VOIP per un ID chiamata specifico a partire dal buffer di copertura
show voip trace session-id <id-sessione>	show voip trace session-id 87003120822b5dbd8fd80f62d8e57c48	Filtra e visualizza la traccia VOIP per una chiamata in base all'ID sessione SIP. È possibile utilizzare l'UUID locale o remoto presente nell'intestazione dell'ID della sessione del messaggio sip per visualizzare entrambi i componenti della chiamata.
show voip trace sip-call-id <id-chiamata>	show voip trace sip-call-id 01e60dfa9d8442848336d79e3155a8a1	Filtra e visualizza la traccia VOIP in base all'ID chiamata SIP