Configuración de la recopilación de depuración para puertas de enlace TDM y CUBE
Contenido
Introducción
Este documento describe algunas de las prácticas recomendadas para recopilar las depuraciones de voz en el router de voz IOS®/IOS XE® de Cisco.
Prerequisites
Requirements
- Acceso privilegiado para ejecutar comandos en los routers ISR.
- Se requiere experiencia previa con protocolos de voz sobre IP (VoIP).
- Para VoIP Trace, se requiere un mínimo de Cisco IOS XE 17.4.1 o 17.3.2.
- Conocimientos básicos de Cisco IOS/IOS XE en routers de servicios integrados (ISR).
Componentes Utilizados
A los efectos de este documento, los componentes utilizados son:
- PuTTY
- Cisco ISR 3925
- Cisco ISR 4451
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Antecedentes
El proceso de recolección de depuración en estas plataformas tiene desafíos y puede afectar potencialmente el rendimiento del dispositivo. Los retos y riesgos aumentan cuando hay varias llamadas activas establecidas en un router de voz. En algunos escenarios, si los debugs no se recolectan correctamente, puede conducir a una CPU alta que puede causar daños a la capacidad del router e incluso provocar una caída del software. Este documento explica las diferencias entre un Cisco Unified Border Element (CUBE) y una Time-Division Multiplexing (TDM)/Analog Gateway.
Gateways de voz TDM frente a CUBE
Los gateways de voz TDM se utilizan principalmente para interconectar un sistema telefónico interno con otra centralita privada (PBX) o la red pública de telefonía conmutada (PSTN). El tipo de conexiones que se utilizan en las gateways TDM son los controladores T1/E1 (ISDN o CAS) y los circuitos analógicos como los puertos FXS y FXO. Un procesador de señales digitales (DSP) convierte el audio de su forma original en paquetes RTP. De manera similar, los paquetes RTP se convierten en audio sin procesar después de que DSP haya procesado los paquetes RTP y envíe el audio al circuito específico. Estas puertas de enlace interoperan con H323, MGCP o el protocolo de control de llamadas skinny (SCCP) en el lado de VoIP y en el lado de TDM. Se trata de circuitos ISDN PRI o analógicos como las conexiones más comunes a la PSTN o los terminales.
Como se muestra en la imagen, los gateways TDM proporcionan un puente entre su infraestructura VoIP interna y los proveedores de servicios analógicos o ISDN:
Con la introducción de VoIP, los clientes cambiaron rápidamente sus sistemas anteriores por una infraestructura VoIP moderna. Lo mismo ocurrió en el lado del proveedor de servicios, donde ahora utilizan conexiones para interconectar los servicios de telefonía en las instalaciones con la infraestructura VoIP del proveedor de servicios y ampliar sus capacidades para proporcionar mejores servicios. El protocolo VoIP más habitual que se utiliza actualmente es el protocolo de inicio de sesión (SIP), que en la actualidad utilizan habitualmente los clientes y los proveedores de servicios de telefonía por Internet (ITSP) de todo el mundo.
CUBE se introdujo para proporcionar una manera de interconectar esos sistemas VoIP internos con el mundo externo a través de los ITSP con SIP como el protocolo VoIP principal. CUBE es simplemente una puerta de enlace IP-IP en la que ya no se necesita ningún tipo de conexión TDM, como controladores T1/E1 o puertos analógicos. CUBE se ejecuta en las mismas plataformas que los gateways TDM.
El protocolo VoIP más utilizado es SIP, para el establecimiento y el cierre de llamadas, y RTP para el transporte de medios. En CUBE no se necesita un DSP a menos que se requiera un transcodificador. El tráfico RTP fluye de extremo a extremo desde el ITSP al terminal, y CUBE actúa como intermediario con la ocultación de direcciones como una de las muchas funciones que ofrece.
Como se muestra en la imagen, CUBE proporciona una división entre su infraestructura VoIP interna y SIP ITSP:
Colección de Cisco IOS/IOS XE Voice Debugs
Las funciones de voz se ejecutan en una lista diferente de plataformas, como ISR, ASR, CAT8Ks, entre otras; sin embargo, utilizan un software común que es Cisco IOS o Cisco IOS XE (las diferencias entre Cisco IOS y Cisco IOS XE no se tratan en este artículo). Estos son los conceptos básicos sobre cómo acceder al router Cisco IOS.
Cómo acceder a un router Cisco IOS/IOS XE a través de la interfaz de línea de comandos (CLI)
Los routers, como cualquier otro dispositivo basado en CLI, requieren un monitor de terminal para obtener acceso y ejecutar los comandos a través de Secure Shell (SSH) o Telnet. SSH es el protocolo más utilizado hoy en día para acceder a los dispositivos dados. Proporciona una conexión segura y cifrada al dispositivo. Algunos de los monitores de terminal comunes utilizados para acceder a la CLI de los routers son:
Cómo configurar el Monitor de Terminal para que recopile comandos Show o depuraciones
Hay diferentes maneras de recopilar el resultado de la CLI. Se recomienda exportar la información de la CLI del router a un archivo independiente. Esto facilita el intercambio de la información con terceros.
Algunas formas de recopilar las salidas del dispositivo son:
- Volcar toda la salida en el terminal. Debe asegurarse de que haya suficientes líneas de desplazamiento; de lo contrario, el desplazamiento no se realizará en las primeras secciones de la salida y los datos pueden estar incompletos. Para aumentar las líneas de desplazamiento en masilla, navegue hasta Configuración de masilla > Ventana > Líneas de desplazamiento. Normalmente, se establece en un valor muy alto para tener suficiente salida de retrodesplazamiento:
Posteriormente, puede recopilar la información desde el monitor de terminal con la opción Copiar todo en el Portapapeles y pegar el resultado en un archivo de texto:
- Otra opción es registrar el resultado de toda la sesión en un archivo .txt. Con esta opción, todos los comandos introducidos y las salidas recopiladas se registran inmediatamente en el archivo de texto. Esta es una práctica común para registrar todos los resultados en una sesión. Para registrar toda la salida de sesión en un archivo en Putty, navegue hasta Configuración de masilla > Sesión > Registro y luego seleccione Toda la salida de sesión de la siguiente manera:
Recopile el resultado básico del comando Show desde la CLI
Los comandos Show son necesarios para recopilar información básica del router antes de que se produzca cualquier recopilación de depuración. Los comandos Show se recopilan rápidamente y, en su mayor parte, no tienen ningún impacto en el rendimiento del router. El aislamiento del problema puede iniciarse inmediatamente ejecutando un comando show.
Una vez conectado al router, la longitud del terminal se puede establecer en 0. Esto permite una recolección más rápida para mostrar toda la salida a la vez, y evitar el uso de la barra espaciadora. Un comando que recopila información detallada en el router es show tech y, alternativamente, puede recopilar show tech voice, que muestra datos más específicos de las funciones de voz habilitadas en el 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
Recopile la salida de depuración de la CLI
La recopilación de salida de depuración en Cisco IOS/IOS XE puede ser a veces un desafío ya que existe el riesgo de una caída del router. En las siguientes secciones se explican algunas prácticas recomendadas para evitar algunos de estos problemas.
Comprobación de memoria
Antes de habilitar cualquier depuración, debe asegurarse de que haya suficiente memoria para almacenar el resultado en el búfer.
Ejecute el comando show process memory para determinar cuánta memoria puede asignar para registrar todos los resultados en el buffer:
Consejo: Utilice el comando terminal length default o terminal length para volver a una cantidad limitada de líneas que se muestran en el terminal.
Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832
En este ejemplo, hay 7666268552 bytes (7,6 GB) disponibles para ser utilizados por el router. El router comparte esta memoria entre todos los procesos del sistema. Esto significa que no puede utilizar toda la memoria libre disponible para registrar la salida en el buffer, sin embargo, puede utilizar una buena cantidad de memoria del sistema según sea necesario.
La mayoría de los escenarios requieren al menos 10 MB para recopilar suficiente salida de depuración antes de que se pierda o se sobrescriba la salida. En raras ocasiones, se requiere una mayor cantidad de datos para la recolección. En estos casos, puede recibir entre 50 y 100 MB de rendimiento en el búfer, o puede aumentar si hay memoria disponible.
Si la memoria libre es baja, es posible que exista un problema de pérdida de memoria. Si este es el caso, póngase en contacto con el equipo del TAC de arquitectura para revisar cuál puede ser la causa de la memoria baja.
Comprobación de la unidad central de procesamiento (CPU)
La CPU se ve afectada por la cantidad de procesos, funciones y llamadas activas en el sistema. Cuantas más funciones o llamadas estén activas en el sistema, más ocupada estará la CPU.
Un buen punto de referencia es asegurarse de que el router tiene la CPU en un 30% o menos, lo que significa que puede habilitar con seguridad depuraciones de básicas a avanzadas (esté siempre atento a la CPU cuando se utilicen depuraciones avanzadas). Si la CPU del router está alrededor del 50%, se pueden ejecutar depuraciones básicas; sin embargo, siempre monitoree la CPU. Si la CPU supera el 80%, detenga inmediatamente las depuraciones (que se muestran más adelante en este artículo) y solicite ayuda al TAC.
Ejecute el comando show process cpu sorted | exclude 0.00 para revisar los últimos 5 s, 60 s y 5 min de valores de CPU junto con los procesos principales.
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
En el resultado, el router no tiene mucha actividad, la CPU es baja y las depuraciones se pueden habilitar de forma segura.
Precaución: Preste mucha atención a los principales procesos de la CPU que están activos. Si la CPU está al 50% o más, y el proceso superior es un proceso de voz solamente, se pueden habilitar las depuraciones básicas. Supervise continuamente la CPU con el comando para asegurarse de que el rendimiento general del router no se vea afectado.
Comprobación de llamadas activas actuales
Cada router tiene diferentes umbrales de capacidad. Es importante comprobar cuántas llamadas hay activas en el router para asegurarse de que no se aproxima a la capacidad máxima. La hoja de datos de Cisco Unified Border Element versión 12 proporciona información sobre la capacidad de cada plataforma para referencia.
Ejecute el comando show call active total-calls para tener una idea de cuántas llamadas están activas en el sistema:
Router# show call active total-calls
Total Number of Active Calls : 0
Ejecute el comando show call active voice summary para recibir información más detallada de los tipos de llamada que están activos:
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
Algunos valores comunes son:
- Tramos de llamada de telefonía: Llamadas de gateway TDM, incluidas las llamadas analógicas y PRI/ISDN.
- Tramos de llamadas SIP: Llamadas SIP totales; si se trata de un router CUBE, muestra dos tramos de llamada por llamada. Divida el total de llamadas entre dos para recibir un número exacto.
- Bloques de llamada H323: Total de llamadas H323.
- Tramos de llamada SCCP: Recursos multimedia controlados de Cisco Unified Communications Manager (CUCM) utilizados en el router, como transcodificador y MTP.
Configuración del búfer de registro
Para configurar el router para almacenar la salida de depuración en el búfer, se ingresa el modo de terminal de configuración para ajustar manualmente los ajustes en la CLI. Esta configuración no tiene impacto en el router; sin embargo, como se muestra en las secciones anteriores, se requieren los comandos show tech o show running-config del router si se debe revertir el evento en la configuración.
Este es un ejemplo de configuración, que es una línea de base común utilizada por los ingenieros del TAC. Esto asigna 10 MB de memoria intermedia, pero se puede aumentar según sea necesario:
# 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
Estos comandos realizan estas tareas:
- service timestamps debug o log: Garantiza que las horas del router local se escriben en cada mensaje registrado con precisión de milisegundos. Resulta útil para buscar llamadas en función del tiempo. marcas de tiempo en milisegundos, que permiten agrupar líneas de depuración en eventos lógicos relacionados cuando se producen dos líneas en el mismo milisegundo.
- service sequence-numbers: Escribe el número de secuencia de la depuración en la línea. Esto es útil (obligatorio) cuando los registros se reenvían a un servidor syslog. Esto es muy útil para identificar si cualquier mensaje de depuración al servidor syslog ha sido descartado en la red. El número de secuencia es el primer elemento de la depuración antes de la marca de tiempo y el mensaje de registro. Esto es diferente de la marca de tiempo/número de secuencia que los servidores syslog pueden escribir localmente en sus archivos.
- búfer de registro: Indica al router que envíe depuraciones a la memoria intermedia local. El tamaño del búfer se establece en bytes. En la configuración, el tamaño del búfer se estableció en 10 MB.
- no logging console y no logging monitor: No se imprimen mensajes de registro en la consola o en el monitor de terminal. Si estos comandos no se configuran, pueden ser perjudiciales para el rendimiento del router y la precisión del resultado de la depuración.
- voice iec syslog: Habilita los mensajes de código de error interno de voz para determinar las razones de desconexión.
Configuración de Syslog
A veces, los problemas pueden ser aleatorios y requieren una manera de recopilar continuamente las depuraciones hasta que ocurre el evento. Cuando almacena las depuraciones en el búfer, las recopila continuamente. Se limita a la cantidad de memoria que puede asignar y, una vez que alcanza esa cantidad de memoria, el búfer rodea y descarta los mensajes más antiguos, lo que da lugar a información valiosa e incompleta necesaria para aislar el problema.
Con syslog, el router puede enviar todos los mensajes de depuración a un servidor externo donde el software del servidor syslog los almacena en archivos de texto. Aunque esta es una buena manera de recopilar el resultado de la depuración, no es el método preferido para la recopilación de registros. Los servidores de Syslog tienden a saltar o descartar líneas de la salida recibida debido a la congestión en el servidor. Dado que los resultados de depuración pueden saturar al servidor o los paquetes pueden descartarse debido a las condiciones de la red. Sin embargo, en algunos escenarios, los syslogs son la única manera de avanzar en un problema.
Si es posible, utilice un método de transporte confiable como TCP para evitar cualquier pérdida de información y, como sugerencia, conecte el servidor syslog al mismo switch donde está conectado el router o lo más cerca posible del router. Esto no garantiza que todos los datos se almacenen en los archivos, pero reduce la posibilidad de pérdida de datos.
De forma predeterminada, los servidores syslog utilizan UDP como protocolo de transporte en el puerto 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 <port>
Una vez configurados los comandos, el router reenvía inmediatamente los mensajes a la dirección IP del servidor syslog.
Colección Debug
Una vez que se habilitan las depuraciones, el búfer debe borrarse antes de que se reproduzca el problema. Esto se hace para garantizar que el resultado sea lo más limpio posible y para evitar datos adicionales que no son necesarios para el análisis. Ejecute el comando clear log, ya que esto garantiza que se borre el búfer. Si hay otras llamadas activas en el router y los debugs están habilitados, el resultado se imprime inmediatamente en el buffer:
Router# clear log
Clear logging buffer [confirm]
Router#
Una vez reproducido el problema, desactive las depuraciones inmediatamente para detener la salida adicional en el búfer y, a continuación, recopile los registros. Puede volcar todos los resultados en el terminal con estos comandos:
Router# undebug all
Router# terminal length 0
Router# show log
A veces PuTTY se cierra porque no maneja todas las salidas a la vez. Esto es normal y no significa que se haya producido un fallo. Si esto ocurre, vuelva a abrir la sesión y continúe con normalidad. En escenarios donde el buffer de registro es demasiado grande o el monitor de terminal falla debido a la cantidad de datos que se deben imprimir, copie la salida del buffer a un dispositivo externo directamente con el comando show log | comando redirect:
Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt
Este comando copia el resultado completo del búfer en una dirección IP de FTP de: 192.168.1.2 con el nombre de archivo debug.txt. Siempre se debe especificar el nombre del archivo. Otros destinos disponibles para exportar datos son:
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
Qué depuraciones se pueden habilitar en los routers de voz
Cada flujo de llamadas y tipo de funciones (recursos de medios TDM, CUBE o SCCP) son diferentes y hay depuraciones específicas que se deben habilitar. Todas las depuraciones necesarias deben estar habilitadas simultáneamente. Cuando solo se captura una depuración a la vez, es ineficaz y proporciona más confusión cuando se analizan los datos.
Las depuraciones se habilitan dentro del Router# de nivel de mensaje ejecutivo de CLI, que requiere que tenga permisos de modo de ejecución privilegiados.
Existen depuraciones básicas y avanzadas, y las depuraciones básicas se utilizan para recopilar información de señalización en SIP, H323 o MGCP. Esto muestra las conversaciones que el router tiene con sus dispositivos pares.
Las depuraciones avanzadas son bastante detalladas y se utilizan para recopilar información adicional si los errores internos de la pila no pueden mostrar depuraciones básicas. Estos debugs son normalmente intensivos en la CPU.
Depuración de API de control de llamadas interno (CCAPI)
Dentro de cada router Cisco IOS/IOS XE, hay una API de control de llamadas que se encarga de la comunicación entre diferentes aplicaciones o protocolos VoIP. Los componentes del plano de datos como RTP, DSP, tarjetas de voz, entre otros, capturan datos de esta capa. Hay una depuración específica que se puede utilizar:
debug voip ccapi inout
Hay otras opciones para esta depuración; sin embargo, la ejecución del comando debug voip ccapi inout cubre toda la información básica de plan de marcado y establecimiento de llamadas que normalmente es más que suficiente para comprender cuáles son los estados de esta capa.
Consejo: debug voip ccapi inout usualmente tiene un impacto mínimo en la CPU del router y se recomienda habilitarlo junto con cualquier depuración de señalización para proporcionar un conjunto completo de registros con información de las llamadas y sus diferentes estados.
Flujos de llamadas SIP
Estas depuraciones se utilizan normalmente para flujos de llamadas SIP y se pueden habilitar dentro de gateways de CUBE y TDM con un tramo SIP entre el router y CUCM o cualquier otro servidor SIP o proxy.
Depuraciones SIP básicas
debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.
Depuraciones SIP avanzadas
debug ccsip all
debug ccsip verbose
debug voice ccapi inout
Flujos de llamadas digitales (PRI, BRI)
Estas depuraciones se aplican a las interfaces de velocidad primaria (PRI) T1/E1 o a las interfaces de velocidad básica (BRI):
Depuración digital básica
debug isdn q931
Depuración digital avanzada
debug isdn q921
Flujos de llamadas analógicas
Estas depuraciones se utilizan cuando los circuitos analógicos implican puertos de Foreign eXchange Subscriber (FXS) o Foreign eXchange Office (FXO):
debug vpm signal
debug voip vtsp all
Flujos de llamadas MGCP
Estas depuraciones se utilizan cuando se utiliza MGCP como protocolo de voz entre una puerta de enlace de voz y CUCM.
Depuraciones básicas
debug mgcp packets
debug mgcp errors
Depuraciones de CCM-Manager
Las depuraciones de ccm-manager se utilizan para realizar un seguimiento de la descarga de la configuración y de los mensajes de red de retorno MoH y PRI/BRI entre CUCM y la puerta de enlace de voz. Estos debugs se utilizan según sea necesario y dependen del escenario de falla:
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
Depuraciones MGCP avanzadas
debug mgcp all
Flujos de llamadas H323
Aunque H323 no se utiliza ampliamente, todavía hay algunas implementaciones con H323 configurado:
Depuraciones básicas de H323
debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events
Depuraciones avanzadas de H323
debug cch323 h225
debug cch323 h245
debug cch323 all
Recursos de medios SCCP
Estas depuraciones se utilizan para solucionar problemas de recursos de medios SCCP que implican punto de terminación de medios (MTP) o transcodificadores registrados en un servidor CUCM:
Depuraciones SCCP básicas
debug sccp messages
debug sccp events
debug sccp errors
Depuración SCCP avanzada
debug sccp all
Seguimiento de VoIP
Con la introducción de Cisco IOS XE 17.4.1 y 17.3.2, existe una nueva opción para capturar registros de voz dentro de Cisco Unified Border Element (CUBE). Esta nueva función se llama VoIP Trace. Se trata de un nuevo marco de facilidad de mantenimiento creado para registrar la señalización SIP y los eventos sin necesidad de habilitar ninguna depuración.
VoIP Trace está activado de forma predeterminada y se puede desactivar en cualquier momento según sea necesario. VoIP Trace captura información específica solo para llamadas SIP:
- Errores SIP
- Coincidencia de par de marcado
- Puertos RTP asignados
- Correlación de errores IEC con señalización SIP
- Mensajes SIP para llamadas de troncal SIP a troncal SIP
- Estados y eventos de máquinas de estado finito (FSM)
- Llamadas de eventos y API desde la capa SIP a otras capas de CUBE
- Control de llamadas (flujos de llamadas de Unified Communication procesados por CUBE)
Restricciones
VoIP Trace no registra información relacionada con mensajes SIP fuera de diálogo:
- REGISTRO
- OPCIONES
- SUSCRIBIRSE/NOTIFICAR
- INFO
Se admite VoIP Trace en HA; sin embargo, se aplican estas advertencias:
- El router en espera tiene activado VoIP Trace de forma predeterminada. Solo se muestran los seguimientos aplicables para el proceso en espera hasta que se activa.
- Una vez que el modo en espera está activo, NO contiene seguimientos completos de llamadas verificadas, y solo llamadas nuevas.
- show voip trace <key> aún funciona en el router en espera y muestra el búfer de cobertura y los datos del flujo de medios para las llamadas.
Cómo Habilitar el Seguimiento VoIP
Como se ha mencionado, esta función está activada de forma predeterminada. Para habilitar esta función, ejecute estos comandos:
Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#
Cómo Inhabilitar VoIP Trace
Para desactivar esta función, ejecute estos comandos:
Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown
Precaución: Una vez que se inhabilita el seguimiento VoIP, se borra toda la memoria y se pierde la información.
Los comandos disponibles dentro del modo de configuración trace son:
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
Configurar límite de memoria
El límite de memoria determina la cantidad de memoria que utiliza el Seguimiento VoIP para almacenar datos. De forma predeterminada, es el 10% de la memoria disponible en la plataforma; sin embargo, esto se puede ajustar a un máximo de 1 GB y un mínimo de 10 MB. La memoria se asigna dinámicamente, ya que la función solo utiliza la memoria según sea necesario y depende del volumen de la llamada. Una vez que alcanza la memoria máxima disponible, da vueltas y elimina las entradas más antiguas.
Cuando se modifica el límite de memoria para que sea mayor que el 10% de memoria disponible, se muestra un mensaje en la CLI:
Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.
Para establecer el valor predeterminado en 10% de uso de memoria, ejecute el 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]:
Cómo Mostrar Datos de Rastreo VoIP
Para mostrar los datos de VoIP Trace, debe utilizar comandos show específicos. Los datos se pueden mostrar en la misma sesión de terminal o se pueden enviar a través de syslog a un servidor syslog externo.
Nota: Los seguimientos se descartan transcurridos 32 segundos desde el momento en que se recibe un BYE para una llamada.
La señalización SIP se muestra por tramo y no se combina como depuraciones regulares. Las depuraciones regulares, como los mensajes de depuración CCSIP, muestran la señalización SIP de una llamada en el orden exacto en que ocurrieron los eventos. En VoIP Trace, cada tramo es independiente, para determinar el orden correcto, se utilizan las marcas de tiempo.
Para ver los datos disponibles, ejecute estos comandos:
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
Este comando muestra todos los datos de rastreo VoIP disponibles en el buffer. Al utilizar este comando, afecta el rendimiento del router. Una vez introducido el comando, se muestra un mensaje de advertencia para alertar sobre los riesgos si continúa:
Router# show voip trace all
Displaying 11858 cover buffers
This may severely impact system performance.
Continue? [yes/no] no
Show VoIP Trace Cover-Buffers
Este comando muestra una descripción general de los detalles de llamada para todas las llamadas notificadas bajo Seguimiento VoIP. Cada segmento de llamada tiene un búfer de cobertura creado que contiene un resumen de las llamadas registradas:
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
-----------------------------------------------
Para obtener más información sobre cada campo, consulte la siguiente tabla:
| Campo |
Descripción |
| Search-Key |
Contiene una combinación de call, called number y call-id |
| Grupo fecha/hora |
Tiempo de creación del búfer de cobertura |
| Buffer-ID |
ID de búfer del búfer de cobertura |
| ID de llamada |
ID de llamada del tramo de llamada respectivo al búfer de cobertura |
| Peer-Call-ID |
ID de llamada del tramo de peer |
| Correlador |
Correlator FPI de la llamada |
| Called-Number |
Número llamado del tramo de llamada respectivo del búfer de cobertura |
| Calling-Number |
Número de llamada del tramo de llamada respectivo del búfer de cobertura |
| ID de llamada SIP |
ID de llamada SIP del tramo de llamada respectivo del búfer de cobertura |
| ID de sesión Sip |
ID de sesión SIP del tramo de llamada respectivo del búfer de cobertura |
| GUID |
GUID de la llamada respectiva del búfer de cubierta |
| Pierna de anclaje |
El tramo de anclaje se establece en 'Sí' si el tramo de llamada respectivo es un tramo de anclaje en el flujo de bifurcación de llamada o en la implementación de proxy de medios |
| Tronco bifurcado |
El segmento bifurcado se establece en 'Sí' si el segmento de llamada respectivo es un segmento de anclaje en el flujo de bifurcación de llamada o en la implementación de proxy de medios |
| ID de llamadas asociadas |
ID de llamada de los tramos bifurcados asociados |
Para filtrar los buffers de cubierta, ejecute los comandos include y 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
En combinación con el comando anterior, show voip trace call-id se puede utilizar para buscar llamadas. Una vez que se identifica el call-id, se puede ejecutar el siguiente comando para mostrar toda la información sobre el tramo de llamada específico:
Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661
Show VoIP Trace Statistics
Este comando show muestra información detallada sobre el estado, el consumo de memoria, los errores/llamadas con fallas, las llamadas exitosas, las marcas de tiempo de las entradas más recientes y más antiguas y más:
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
Para obtener más información sobre cada campo, consulte la siguiente tabla:
| Campo |
Descripción |
| Estado de seguimiento |
Muestra el estado de seguimiento, que incluye la fecha y la hora en que se habilitó el seguimiento VoIP. |
| Límite de memoria configurado |
Muestra el límite de memoria configurado. Esto representa el 10% del tamaño de la memoria del conjunto de procesadores. |
| Memoria consumida |
Muestra la cantidad de memoria consumida dinámicamente para el rastreo VoIP. |
| Tramos de llamadas totales volcados |
Muestra el número de tramos de llamadas fallidas volcados en el buffer de registro. Las llamadas volcadas se refieren a tramos de llamadas asociados con errores IEC. |
| Rastreo más antiguo volcado |
Muestra las marcas de tiempo y la clave de búsqueda de la llamada fallida más antigua desde que se habilitó el seguimiento VoIP. |
| Último seguimiento volcado |
Muestra las marcas de tiempo y la clave de búsqueda de la última llamada fallida desde que se habilitó el seguimiento VoIP. |
| Tramos de llamadas totales capturados |
Muestra los tramos totales capturados después de habilitar el seguimiento VoIP. |
| Tramos de llamadas totales disponibles |
Muestra los tramos de llamadas totales disponibles en el historial. Puede ser igual o diferente en comparación con los tramos de llamadas totales capturados, esto depende del límite de memoria. |
| Seguimiento más antiguo disponible |
Muestra la marca de tiempo y la clave de búsqueda del búfer de cubierta más antiguo disponible en la memoria. |
| Último seguimiento disponible |
Muestra la marca de tiempo y la clave de búsqueda del último búfer de cubierta disponible en la memoria. |
| Rastreos totales perdidos |
Muestra el número de tramos de llamada perdidos debido al límite de memoria. |
Comandos Show adicionales
| Campo |
Uso |
Descripción |
| show voip trace correlator <correlator> |
show voip trace correlator 4 |
Filtra y muestra el seguimiento de VOIP para una identificación de llamada específica a partir del búfer de cobertura. |
| show voip trace session-id <session-id> |
show voip trace session-id 87003120822b5dbd8fd80f62d8e57c48 |
Filtra y muestra el seguimiento de VOIP para una llamada basada en el ID de sesión SIP. El UUID local o remoto del encabezado session-ID del mensaje SIP se puede utilizar para mostrar ambos tramos de la llamada. |
| show voip trace sip-call-id <call-id> |
show voip trace sip-call-id 01e60dfa9d8442848336d79e3155a8a1 |
Filtra y muestra el seguimiento de VOIP basado en el ID de llamada SIP. |
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
4.0 |
17-Aug-2026
|
Actualización Introducción, ortografía, gramática, líneas horizontales insertadas para separar secciones para facilitar la lectura, corrección de errores de CCW. |
3.0 |
13-Feb-2025
|
Actualización de requisitos de marca, requisitos de estilo, formato y gramática. |
2.0 |
13-Apr-2023
|
Texto alternativo agregado.
Título actualizado, introducción, requisitos de marca, requisitos de estilo, motivos, formato y gramática. |
1.0 |
13-Aug-2021
|
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)