Configurer la collecte de débogage pour les passerelles CUBE et TDM
Table des matières
Introduction
Ce document décrit certaines des meilleures pratiques pour collecter des débogages vocaux dans le routeur vocal Cisco IOS®/IOS XE®.
Conditions préalables
Exigences
- Accès privilégié pour exécuter des commandes dans les routeurs ISR.
- Une expérience préalable des protocoles VoIP (Voice-over-IP) est souhaitée.
- Pour VoIP Trace, un minimum de Cisco IOS XE 17.4.1 ou 17.3.2 est requis.
- Connaissances de base de Cisco IOS/IOS XE au sein des routeurs à services intégrés (ISR).
Composants utilisés
Pour les besoins de ce document, les composants utilisés sont :
- PuTTY
- Cisco ISR 3925
- Cisco ISR 4451
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
Le processus de collecte de débogage dans ces plates-formes présente des défis et peut potentiellement affecter les performances du périphérique. Les défis et les risques augmentent lorsque plusieurs appels actifs sont établis dans un routeur vocal. Dans certains scénarios, si les débogages ne sont pas collectés correctement, cela peut conduire à une CPU élevée qui peut endommager la capacité du routeur et même déclencher une panne logicielle. Ce document traite des différences entre un CUBE (Cisco Unified Border Element) et une passerelle analogique/multiplexage temporel (TDM).
Passerelles vocales TDM et CUBE
Les passerelles vocales TDM sont principalement utilisées pour interconnecter un système téléphonique interne avec un autre autocommutateur privé (PBX) ou le réseau téléphonique public commuté (RTPC). Les types de connexions utilisés dans les passerelles TDM sont les contrôleurs T1/E1 (RNIS ou CAS) et les circuits analogiques tels que les ports FXS et FXO. Un processeur de signal numérique (DSP) convertit l'audio de sa forme brute en paquets RTP. De la même manière, les paquets RTP sont convertis en audio brut après que DSP a traité les paquets RTP et envoyé l'audio au circuit spécifique. Ces passerelles interagissent avec H323, MGCP ou Skinny Call Control Protocol (SCCP) du côté VoIP et du côté TDM. Ses circuits RNIS PRI ou analogiques sont les connexions les plus courantes au RTPC ou aux points d'extrémité.
Comme l'illustre l'image, les passerelles TDM fournissent un pont entre votre infrastructure VoIP interne et les fournisseurs de services analogiques ou RNIS :
Avec l'introduction de la VoIP, les clients ont rapidement changé leurs systèmes hérités pour adopter une infrastructure VoIP moderne. La même chose s'est produite du côté des fournisseurs de services, où ils utilisent désormais des connexions pour interconnecter les services de téléphonie sur site avec l'infrastructure VoIP des fournisseurs de services et étendre leurs capacités pour fournir de meilleurs services. Le protocole VoIP le plus couramment utilisé aujourd'hui est le protocole SIP (Session Initiation Protocol), et est actuellement largement utilisé par les clients et les fournisseurs de services de téléphonie Internet (ITSP) dans le monde entier.
CUBE a été introduit pour fournir un moyen d'interconnecter ces systèmes VoIP internes avec le monde extérieur par le biais des ITSP avec SIP comme protocole VoIP principal. CUBE est simplement une passerelle IP-IP qui ne nécessite plus de type de connexion TDM, comme les contrôleurs T1/E1 ou les ports analogiques. CUBE fonctionne sur les mêmes plates-formes que les passerelles TDM.
Le protocole VoIP le plus couramment utilisé est le protocole SIP, pour l'établissement et le démontage des appels, et le protocole RTP pour le transport multimédia. Dans CUBE, un DSP n'est pas nécessaire, sauf si un transcodeur est requis. Le trafic RTP circule de bout en bout du fournisseur de services Internet au point d'extrémité, et CUBE agit comme intermédiaire avec une adresse cachée comme l'une des nombreuses fonctionnalités qu'il offre.
Comme l'illustre l'image, CUBE permet de distinguer votre infrastructure VoIP interne de l'ITSP SIP :
Collection de débogages vocaux Cisco IOS/IOS XE
Les fonctions vocales sont exécutées sur une liste différente de plates-formes, telles que ISR, ASR, CAT8K, entre autres ; cependant, ils utilisent un logiciel commun qui est soit Cisco IOS ou Cisco IOS XE (les différences entre Cisco IOS et Cisco IOS XE ne sont pas couvertes dans cet article). Voici les bases de l’accès au routeur Cisco IOS.
Comment accéder à un routeur Cisco IOS/IOS XE via l'interface de ligne de commande (CLI)
Les routeurs, comme tous les autres périphériques basés sur l’interface de ligne de commande, nécessitent un moniteur de terminal pour accéder à l’exécution des commandes via Secure Shell (SSH) ou Telnet. SSH est le protocole le plus couramment utilisé de nos jours pour accéder aux périphériques donnés. Il fournit une connexion sécurisée et chiffrée au périphérique. Voici quelques-uns des moniteurs de terminal couramment utilisés pour accéder à l’interface de ligne de commande des routeurs :
Comment configurer le moniteur de terminal pour collecter des commandes show ou des débogages
Il existe différentes manières de collecter les résultats de l'interface de ligne de commande. Il est recommandé d'exporter les informations de l'interface de ligne de commande du routeur vers un fichier distinct. Cela facilite le partage de l'information avec des parties externes.
Voici quelques façons de collecter les sorties du périphérique :
- Videz tous les résultats dans le terminal. Vous devez vous assurer qu'il y a suffisamment de lignes de défilement, sinon, le défilement manque les premières sections de la sortie et les données peuvent être incomplètes. Afin d'augmenter les lignes de défilement dans Putty, naviguez à Putty Configuration > Window > Lines of Scrollback. Normalement, cette valeur est très élevée afin d'avoir assez de résultats de défilement :
Vous pouvez ensuite collecter les informations du moniteur de terminal à l'aide de l'option Copier tout dans le Presse-papiers et coller le résultat dans un fichier texte :
- Une autre option consiste à consigner la sortie de session entière dans un fichier .txt. Avec cette option, toutes les commandes entrées et toutes les sorties collectées sont immédiatement consignées dans le fichier texte. Il s'agit d'une pratique courante afin de consigner tous les résultats dans une session. Afin de consigner toutes les sorties de session dans un fichier dans Putty, naviguez à Putty Configuration > Session > Logging puis sélectionnez All Session Output comme suit :
Collecter les résultats de la commande show de base à partir de la CLI
Les commandes show sont nécessaires pour collecter des informations de base à partir du routeur avant toute collecte de débogage. Les commandes show sont rapides à collecter et, pour la plupart, n’ont aucun impact sur les performances du routeur. L'isolation du problème peut commencer immédiatement en exécutant une commande show.
Une fois connecté au routeur, la longueur du terminal peut être définie sur 0. Cela permet une collecte plus rapide pour afficher toutes les sorties à la fois et éviter l’utilisation de la barre d’espace. La commande show tech permet de collecter des informations détaillées sur le routeur. Vous pouvez également collecter la commande show tech voice, qui affiche des données plus spécifiques aux fonctionnalités vocales activées sur le routeur :
Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default
Collecter les résultats du débogage à partir de la CLI
La collecte des résultats de débogage dans Cisco IOS/IOS XE peut parfois être un défi, car il y a un risque de panne du routeur. Certaines des meilleures pratiques sont expliquées dans les sections suivantes pour éviter certains de ces problèmes.
Vérification de la mémoire
Avant d'activer des débogages, vous devez vous assurer qu'il y a suffisamment de mémoire pour stocker le résultat dans la mémoire tampon.
Exécutez la commande show process memory pour déterminer la quantité de mémoire que vous pouvez allouer pour consigner toutes les sorties dans la mémoire tampon :
Conseil : Utilisez la commande terminal length default ou terminal length pour revenir à un nombre limité de lignes affichées dans le terminal.
Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832
Dans cet exemple, 7666268552 octets (7,6 Go) peuvent être utilisés par le routeur. Cette mémoire est partagée par le routeur entre tous les processus système. Cela signifie que vous ne pouvez pas utiliser toute la mémoire disponible pour enregistrer les résultats dans la mémoire tampon, mais vous pouvez utiliser une bonne quantité de mémoire système si nécessaire.
La plupart des scénarios nécessitent au moins 10 Mo pour collecter suffisamment de sortie de débogage avant que la sortie ne soit perdue ou écrasée. Dans de rares cas, une plus grande quantité de données est requise pour la collecte. Dans ces scénarios, vous pouvez recevoir de 50 Mo à 100 Mo de sortie dans la mémoire tampon, ou vous pouvez aller plus haut si la mémoire est disponible.
Si la mémoire disponible est insuffisante, il peut y avoir un problème de fuite de mémoire. Si tel est le cas, demandez à l'équipe du TAC de l'architecture de réviser la cause de la mémoire insuffisante.
Vérification de l'unité centrale (UC)
Le processeur est affecté par le nombre de processus, de fonctionnalités et d'appels actifs dans le système. Plus le nombre de fonctions ou d'appels actifs dans le système est élevé, plus le processeur est occupé.
Un bon test consiste à s'assurer que le routeur dispose d'un processeur à 30 % ou moins, ce qui signifie que vous pouvez activer en toute sécurité les débogages de basique à avancé (gardez toujours un oeil sur le processeur lorsque des débogages avancés sont utilisés). Si le processeur du routeur est d'environ 50 %, des débogages de base peuvent être exécutés, mais surveillez toujours le processeur. Si le processeur atteint plus de 80 %, arrêtez immédiatement les débogages (voir plus loin dans cet article) et demandez l'aide du centre d'assistance technique.
Exécutez la commande show process cpu sorted | exclude 0.00 pour passer en revue les 5 dernières secondes, 60 secondes et 5 minutes des valeurs de CPU avec les processus supérieurs.
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
Dans le résultat, le routeur n'a pas beaucoup d'activité, le processeur est faible et les débogages peuvent être activés en toute sécurité.
Mise en garde : Soyez particulièrement attentif aux principaux processus CPU actifs. Si le processeur est à 50 % ou plus et que le processus supérieur est un processus vocal uniquement, les débogages de base peuvent être activés. Surveillez en permanence le processeur à l'aide de la commande pour vous assurer que les performances globales du routeur ne sont pas affectées.
Vérification des appels actifs actuels
Chaque routeur a des seuils de capacité différents. Il est important de vérifier combien d'appels sont actifs dans le routeur pour s'assurer qu'il n'est pas proche de la capacité maximale. La fiche technique Cisco Unified Border Element Version 12 fournit des informations sur la capacité de chaque plate-forme à titre de référence.
Exécutez la commande show call active total-calls pour avoir une idée du nombre d'appels actifs dans le système :
Router# show call active total-calls
Total Number of Active Calls : 0
Exécutez la commande show call active voice summary pour recevoir des informations plus détaillées sur les types d'appels qui sont actifs :
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
Voici quelques valeurs courantes :
- Tronçons d'appel de téléphonie : Appels TDM Gateway, y compris les appels analogiques et PRI/RNIS.
- Pieds d'appel SIP : Total des appels SIP ; s'il s'agit d'un routeur CUBE, cela indique deux tronçons d'appel par appel. Divisez le nombre total d'appels par deux pour obtenir un numéro précis.
- Tronçons d'appel H323 : Total des appels H323.
- Tronçons d'appel SCCP : Ressources multimédias contrôlées par Cisco Unified Communications Manager (CUCM) utilisées dans le routeur, telles que les transcodeurs et les MTP.
Paramètres du tampon de journalisation
Pour configurer le routeur de manière à stocker la sortie de débogage dans la mémoire tampon, le mode configure terminal est activé pour modifier manuellement les paramètres de l'interface de ligne de commande. Cette configuration n'a pas d'impact sur le routeur, cependant, comme indiqué dans les sections précédentes, les commandes show tech ou show running-config du routeur sont requises si l'événement de la configuration doit être restauré.
Il s'agit d'un exemple de configuration, qui est une ligne de base commune utilisée par les ingénieurs du TAC. Cela alloue 10 Mo de mémoire tampon, mais peut être augmenté si nécessaire :
# 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
Ces commandes permettent d'effectuer les tâches suivantes :
- service timestamps debug ou log : Garantit que les heures locales du routeur sont écrites sur chaque message enregistré avec une précision de millisecondes. Cette fonction est utile pour rechercher des appels en fonction de l'heure. horodatage en millisecondes, qui vous permet de regrouper des lignes de débogage en événements logiques connexes lorsque deux lignes se produisent au cours de la même milliseconde.
- numéro d'ordre du service : Écrit le numéro de séquence du débogage dans la ligne. Ceci est utile (obligatoire) lorsque les journaux sont transférés à un serveur Syslog. Ceci est très utile pour identifier si un message de débogage au serveur Syslog a été abandonné dans le réseau. Le numéro d'ordre est le premier élément du débogage avant l'horodatage et le message du journal. Ceci est différent de l'horodatage/numéro de séquence que les serveurs Syslog peuvent écrire localement dans leurs fichiers.
- tampon de journalisation : Indique au routeur d’envoyer des débogages à la mémoire tampon locale. La taille du tampon est définie en octets. Dans la configuration, la taille de la mémoire tampon a été définie sur 10 Mo.
- no logging console et no logging monitor : Aucun message de journal n'est imprimé dans la console ou le moniteur de terminal. Si ces commandes ne sont pas configurées, elles peuvent nuire aux performances du routeur et à la précision de la sortie de débogage.
- voice iec syslog : Active les messages de code d'erreur interne vocal pour déterminer les raisons de déconnexion.
Configuration des paramètres Syslog
Parfois, les problèmes peuvent être aléatoires et nécessitent un moyen de collecter continuellement des débogages jusqu'à ce que l'événement se produise. Lorsque vous stockez des débogages dans la mémoire tampon, elle les collecte en continu. Elle est limitée à la quantité de mémoire que vous pouvez allouer et une fois qu'elle atteint cette quantité de mémoire, la mémoire tampon entoure et abandonne les messages les plus anciens, ce qui conduit à des informations précieuses incomplètes requises pour isoler le problème.
Avec Syslog, le routeur peut envoyer tous les messages de débogage à un serveur externe où le logiciel serveur Syslog les stocke dans des fichiers texte. Bien qu'il s'agisse d'un bon moyen de collecter les résultats du débogage, il ne s'agit pas de la méthode préférée pour la collecte des journaux. Les serveurs Syslog ont tendance à ignorer ou à supprimer des lignes dans le résultat reçu en raison d'un encombrement du serveur. Comme les sorties de débogage peuvent submerger le serveur ou que les paquets peuvent tomber en raison des conditions du réseau. Cependant, dans certains scénarios, les syslogs sont le seul moyen de progresser sur un problème.
Si possible, utilisez une méthode de transport fiable telle que TCP pour éviter toute perte d'informations et, comme suggestion, connectez le serveur Syslog au même commutateur où le routeur est connecté, ou aussi près que possible du routeur. Cela ne garantit pas que toutes les données sont stockées dans les fichiers, mais réduit le risque de perte de données.
Par défaut, les serveurs syslog utilisent le protocole UDP comme protocole de transport sur le port 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>
Une fois les commandes configurées, le routeur transfère immédiatement les messages à l'adresse IP du serveur Syslog.
Debug Collection
Une fois les débogages activés, la mémoire tampon doit être effacée avant que le problème ne soit reproduit. Cela permet de s'assurer que le résultat est aussi propre que possible et d'éviter des données supplémentaires qui ne sont pas nécessaires à l'analyse. Exécutez la commande clear log , car cela garantit que la mémoire tampon est effacée. Si d'autres appels sont actifs dans le routeur et que les débogages sont activés, le résultat s'imprime immédiatement dans la mémoire tampon :
Router# clear log
Clear logging buffer [confirm]
Router#
Une fois le problème reproduit, désactivez les débogages immédiatement pour arrêter les sorties supplémentaires dans la mémoire tampon, puis collectez les journaux. Vous pouvez vider tous les résultats dans le terminal avec ces commandes :
Router# undebug all
Router# terminal length 0
Router# show log
Parfois, PuTTY se ferme car il ne gère pas toutes les sorties à la fois. Cela est normal et ne signifie pas qu'une défaillance s'est produite. Dans ce cas, rouvrez la session et continuez normalement. Dans les scénarios où la mémoire tampon de journalisation est trop grande ou le moniteur de terminal tombe en panne en raison de la quantité de données qui doivent être imprimées, copiez la sortie de la mémoire tampon sur un périphérique externe directement avec show log | commande redirect :
Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt
Cette commande copie l'intégralité de la sortie du tampon vers une adresse IP FTP de : 192.168.1.2 avec le nom de fichier debug.txt. Le nom de fichier doit toujours être spécifié. Les autres destinations disponibles pour l'exportation des données sont :
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
Quels débogages peuvent être activés dans les routeurs vocaux
Chaque flux d'appels et type de fonctionnalités (TDM, CUBE ou ressources multimédias SCCP) est différent et des débogages spécifiques doivent être activés. Tous les débogages requis doivent être activés simultanément. Lorsqu'un seul débogage est capturé à la fois, il est inefficace et accroît la confusion lors de l'analyse des données.
Les débogages sont activés au niveau de l’invite d’exécution de l’interface de ligne de commande Router#, ce qui nécessite que vous disposiez d’autorisations en mode d’exécution privilégié.
Il existe des débogages de base et avancés et des débogages de base sont utilisés pour collecter des informations de signalisation dans SIP, H323 ou MGCP. Ceci montre les conversations que le routeur a avec ses périphériques homologues.
Les débogages avancés sont très détaillés et sont utilisés pour collecter des informations supplémentaires si les erreurs de pile internes ne peuvent pas afficher les débogages de base. Ces débogages sollicitent généralement beaucoup le processeur.
Débogage de l'API de contrôle d'appel interne (CCAPI)
À l'intérieur de chaque routeur Cisco IOS/IOS XE, il y a une API de contrôle d'appel qui est responsable de la communication entre les différentes applications ou protocoles VoIP. Les composants du plan de données tels que RTP, DSP, cartes vocales, entre autres, capturent les données de cette couche. Il y a un débogage spécifique qui peut être utilisé :
debug voip ccapi inout
Il y a d'autres options pour ce débogage ; cependant, l'exécution de la commande debug voip ccapi inout couvre toutes les informations de base de plan de numérotation et d'établissement d'appel qui sont normalement plus que suffisantes pour comprendre quels sont les états de cette couche.
Conseil : debug voip ccapi inout a généralement un impact minimal sur le CPU du routeur et il est recommandé d'activer avec tout débogage de signalisation afin de fournir un ensemble complet de journaux avec des informations sur le ou les appels et ses différents états.
Flux d'appels SIP
Ces débogages sont couramment utilisés pour les flux d'appels SIP et peuvent être activés à l'intérieur des passerelles CUBE et TDM avec un segment SIP entre le routeur et CUCM ou tout autre serveur ou proxy SIP.
Débogages SIP de base
debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.
Débogages SIP avancés
debug ccsip all
debug ccsip verbose
debug voice ccapi inout
Flux d'appels numériques (PRI, BRI)
Ces débogages s'appliquent aux interfaces PRI T1/E1 ou BRI (Basic Rate Interfaces) :
Débogage numérique de base
debug isdn q931
Débogage numérique avancé
debug isdn q921
Flux d'appels analogiques
Ces débogages sont utilisés lorsque des circuits analogiques impliquent des ports Foreign eXchange Subscriber (FXS) ou Foreign eXchange Office (FXO) :
debug vpm signal
debug voip vtsp all
Flux d'appels MGCP
Ces débogages sont utilisés lorsque MGCP est utilisé comme protocole vocal entre une passerelle vocale et CUCM.
Débogages de base
debug mgcp packets
debug mgcp errors
Débogages de CCM-Manager
Les débogages ccm-manager sont utilisés pour suivre le téléchargement de la configuration, et les messages de liaison MoH et PRI/BRI entre CUCM et la passerelle vocale. Ces débogages sont utilisés en fonction des besoins et dépendent du scénario de défaillance :
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
Débogages MGCP avancés
debug mgcp all
Flux d'appels H323
Bien que H323 ne soit pas très répandu, il existe encore des déploiements avec H323 configuré :
Débogages H323 de base
debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events
Débogages H323 avancés
debug cch323 h225
debug cch323 h245
debug cch323 all
Ressources multimédias SCCP
Ces débogages sont utilisés pour dépanner les problèmes de ressources multimédias SCCP qui impliquent un point de terminaison multimédias (MTP) ou des transcodeurs enregistrés sur un serveur CUCM :
Débogages SCCP de base
debug sccp messages
debug sccp events
debug sccp errors
Débogage SCCP avancé
debug sccp all
Suivi VoIP
Avec l'introduction de Cisco IOS XE 17.4.1 et 17.3.2, il existe une nouvelle option pour capturer les journaux vocaux à l'intérieur de Cisco Unified Border Element (CUBE). Cette nouvelle fonctionnalité est appelée VoIP Trace. Il s'agit d'un nouveau cadre de facilité de maintenance créé pour consigner la signalisation et les événements SIP sans avoir à activer de débogages.
VoIP Trace est activé par défaut et peut être désactivé à tout moment si nécessaire. VoIP Trace capture des informations spécifiques pour les appels SIP uniquement :
- Erreurs SIP
- Homologue de numérotation correspondant
- Ports RTP alloués
- Corrélation des erreurs IEC avec la signalisation SIP
- Messages SIP pour les appels de liaison SIP à liaison
- États et événements FSM (Finite State Machines)
- Événements et appels API de la couche SIP vers d'autres couches dans CUBE
- Contrôle d'appel (flux d'appels de communications unifiées traités par CUBE)
Restrictions
VoIP Trace n'enregistre pas les informations relatives aux messages SIP hors dialogue :
- ENREGISTRER
- OPTIONS
- ABONNEMENT/NOTIFICATION
- INFOS
VoIP Trace in HA est pris en charge, mais les mises en garde suivantes s'appliquent :
- Par défaut, VoIP Trace est activé sur le routeur de secours. Seules les traces applicables au processus de veille sont présentées jusqu'à ce qu'il devienne actif.
- Une fois la veille active, elle ne contient PAS les traces complètes des appels avec points de contrôle, mais uniquement les nouveaux appels.
- show voip trace <key> fonctionne toujours sur le routeur de secours et affiche les données du tampon de couverture et du flux multimédia pour les appels.
Activation de la trace VoIP
Comme indiqué, cette fonctionnalité est activée par défaut. Pour activer cette fonction, exécutez les commandes suivantes :
Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#
Désactivation de la trace VoIP
Pour désactiver cette fonction, exécutez les commandes suivantes :
Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown
Mise en garde : Une fois la fonction VoIP Trace désactivée, toute la mémoire est effacée et les informations sont perdues.
Les commandes disponibles dans le mode de configuration trace sont les suivantes :
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
Configurer la limite de mémoire
La limite de mémoire détermine la quantité de mémoire utilisée par VoIP Trace pour stocker des données. Par défaut, elle représente 10 % de la mémoire disponible sur la plate-forme. Toutefois, elle peut être ajustée à un maximum de 1 Go et à un minimum de 10 Mo. La mémoire est allouée de manière dynamique, car la fonction utilise uniquement la mémoire nécessaire et dépend du volume d'appels. Une fois qu'il a atteint la mémoire maximale disponible, il tourne autour et supprime les entrées plus anciennes.
Lorsque la limite de mémoire est modifiée pour être supérieure à 10 % de mémoire disponible, un message s'affiche sur l'interface de ligne de commande :
Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.
Pour définir la valeur par défaut sur 10 % d'utilisation de la mémoire, exécutez la commande 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]:
Affichage des données de suivi VoIP
Pour afficher les données de VoIP Trace, vous devez utiliser des commandes show spécifiques. Les données peuvent être affichées dans la même session de terminal ou peuvent être envoyées via syslog à un serveur syslog hors-box.
Remarque : Les traces sont vidées 32 secondes après la réception d'un BYE pour un appel.
La signalisation SIP est affichée par segment et n'est pas combinée comme des débogages standard. Les débogages réguliers, tels que les messages de débogage CCSIP, affichent la signalisation SIP d'un appel dans l'ordre exact des événements. Dans VoIP Trace, chaque segment est séparé, pour déterminer le bon ordre, les horodatages sont utilisés.
Pour afficher les données disponibles, exécutez ces commandes :
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
Cette commande affiche toutes les données de trace VoIP disponibles dans la mémoire tampon. L’utilisation de cette commande a un impact sur les performances du routeur. Une fois la commande entrée, un message d'avertissement s'affiche pour vous avertir des risques si vous continuez :
Router# show voip trace all
Displaying 11858 cover buffers
This may severely impact system performance.
Continue? [yes/no] no
Show VoIP Trace Cover-Buffers
Cette commande affiche une vue d'ensemble des détails de tous les appels signalés sous VoIP Trace. Chaque tronçon d'appel comporte une mémoire tampon de couverture créée qui contient un résumé des appels consignés :
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
-----------------------------------------------
Pour plus d'informations sur chaque champ, reportez-vous au tableau suivant :
| Champ |
Description |
| Clé De Recherche |
Contient une combinaison d'appel, de numéro appelé et d'ID d'appel |
| Horodatage |
Heure de création du tampon de couverture |
| Buffer-ID |
ID tampon du tampon de couverture |
| ID d'appel |
ID d'appel de la branche d'appel respective vers la mémoire tampon de couverture |
| Peer-Call-ID |
ID d'appel de la branche homologue |
| Corrélateur |
corrélateur FPI de l'appel |
| Numéro appelé |
Numéro appelé de la branche d'appel respective de la mémoire tampon de couverture |
| Numéro-Appelant |
Numéro d'appel de la branche d'appel respective du tampon de couverture |
| ID d'appel SIP |
ID d'appel SIP de la branche d'appel respective de la mémoire tampon de couverture |
| ID de session Sip |
ID de session SIP de la branche d'appel respective du tampon de couverture |
| GUIDE |
GUID de l'appel respectif de la mémoire tampon de couverture |
| Jambe D'Ancrage |
La branche d'ancrage est définie sur « Oui » si la branche d'appel correspondante est une branche d'ancrage dans le flux de transfert d'appel ou le déploiement de proxy multimédia |
| Jambe Fourchue |
Le segment bifurqué est défini sur « Oui » si le segment d'appel correspondant est un segment d'ancrage dans le flux de bifurcation d'appel ou le déploiement de proxy multimédia |
| ID d'appels associés |
ID d'appel des branches fourchues associées |
Pour filtrer les tampons de couverture, exécutez les commandes include et 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 combinaison avec la commande précédente, show voip trace call-id peut être utilisé pour rechercher des appels. Une fois l'ID d'appel identifié, la commande suivante peut être exécutée pour afficher toutes les informations sur le tronçon d'appel spécifique :
Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661
Afficher les statistiques de suivi VoIP
Cette commande show affiche des informations détaillées sur l'état, la consommation de mémoire, les erreurs/échecs d'appel, les appels réussis, les horodatages des entrées les plus récentes et les plus anciennes, etc. :
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
Pour plus d'informations sur chaque champ, reportez-vous au tableau suivant :
| Champ |
Description |
| État de suivi |
Affiche l'état du suivi, qui inclut l'heure et la date d'activation du suivi VoIP. |
| Limite de mémoire configurée |
Affiche la limite de mémoire configurée. Il s'agit de 10 % de la taille de la mémoire du pool de processeurs. |
| Mémoire consommée |
Affiche la quantité de mémoire consommée dynamiquement pour la trace VoIP. |
| Nombre total de segments d'appel vidés |
Affiche le nombre de tronçons d'appel ayant échoué dans la mémoire tampon de journalisation. Les appels ignorés font référence aux tronçons d'appel associés aux erreurs IEC. |
| Trace la plus ancienne abandonnée |
Affiche les horodatages et la clé de recherche de l'appel ayant échoué le plus ancien depuis l'activation de VoIP Trace. |
| Dernière trace vidée |
Affiche les horodatages et la clé de recherche du dernier appel ayant échoué depuis l'activation de la trace VoIP. |
| Nombre total de segments d'appel capturés |
Affiche le nombre total de tronçons capturés après l'activation de VoIP Trace. |
| Nombre total de segments d'appel disponibles |
Affiche le nombre total de tronçons d'appel disponibles dans l'historique. Cela peut être identique ou différent par rapport au nombre total de tronçons d'appel capturés, cela dépend de la limite de mémoire. |
| Plus ancienne trace disponible |
Affiche l'horodatage et la clé de recherche du tampon de couverture le plus ancien disponible dans la mémoire. |
| Dernière trace disponible |
Affiche l'horodatage et la clé de recherche de la dernière mémoire tampon disponible dans la mémoire. |
| Total des traces manquantes |
Affiche le nombre de tronçons d'appel manqués en raison d'une limite de mémoire. |
Commandes show supplémentaires
| Champ |
Utilisation |
Description |
| show voip trace correlator <correlator> |
show voip trace correlator 4 |
Filtre et affiche le suivi VOIP pour un ID d'appel spécifique à partir de la mémoire tampon de couverture. |
| show voip trace session-id <session-id> |
show voip trace session-id 87003120822b5dbd8fd80f62d8e57c48 |
Filtre et affiche le suivi VOIP d'un appel en fonction de l'ID de session SIP. L'UUID local ou distant de l'en-tête session-ID du message SIP peut être utilisé pour afficher les deux tronçons de l'appel. |
| show voip trace sip-call-id <call-id> |
show voip trace sip-call-id 01e60dfa9d8442848336d79e3155a8a1 |
Filtre et affiche le suivi VOIP en fonction de l'ID d'appel SIP. |
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
4.0 |
17-Aug-2026
|
Mise à jour de l'introduction, de l'orthographe, de la grammaire, des lignes horizontales insérées dans des sections distinctes pour une meilleure lisibilité, correction des erreurs CCW. |
3.0 |
13-Feb-2025
|
Mise à jour des exigences de personnalisation, de style, de formatage et de grammaire. |
2.0 |
13-Apr-2023
|
Texte de remplacement ajouté.
Mise à jour du titre, de l'introduction, des exigences de marque, du style, des fonds, du formatage et de la grammaire. |
1.0 |
13-Aug-2021
|
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)