In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden einige der Best Practices zur Erfassung von Sprachdebuggern auf einem Cisco IOS®/IOS XE®-Sprach-Router beschrieben.
Für die Zwecke dieses Dokuments werden folgende Komponenten verwendet:
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Der Prozess der Debugsammlung in diesen Plattformen ist mit Herausforderungen verbunden und kann sich potenziell auf die Leistung des Geräts auswirken. Die Herausforderungen und Risiken nehmen zu, wenn in einem Sprach-Router mehrere aktive Anrufe eingerichtet werden. In einigen Szenarien kann es bei einer falschen Erfassung zu einer hohen CPU kommen, die die Kapazität des Routers beeinträchtigen und sogar einen Softwareabsturz verursachen kann. In diesem Dokument wird der Unterschied zwischen einem Cisco Unified Border Element (CUBE) und einem Time-Division Multiplexing (TDM)/Analog Gateway erläutert.
TDM-Sprach-Gateways werden hauptsächlich verwendet, um ein internes Telefonsystem mit einer anderen Telefonanlage (PBX) oder dem öffentlichen Telefonnetz (PSTN) zu verbinden. Die Verbindungen, die in TDM-Gateways verwendet werden, sind T1/E1-Controller (ISDN oder CAS) und analoge Schaltkreise wie FXS- und FXO-Ports. Ein Digital Signal Processor (DSP) wandelt die Audiodaten aus der Rohform in RTP-Pakete um. Auf ähnliche Weise werden RTP-Pakete in Raw-Audio umgewandelt, nachdem der DSP die RTP-Pakete verarbeitet hat und das Audio über den jeweiligen Schaltkreis sendet. Diese Gateways können mit H323, MGCP oder dem Skinny Call Control Protocol (SCCP) auf der VoIP-Seite und auf der TDM-Seite entweder mit ISDN PRI-Schaltkreisen oder analogen Verbindungen als die gebräuchlichsten Verbindungen zum PSTN oder zu Endpunkten zusammenarbeiten.
Wie im Bild gezeigt, stellen die TDM-Gateways eine Brücke zwischen Ihrer internen VoIP-Infrastruktur und den analogen oder ISDN-Service Providern dar:
Mit der Einführung von VoIP haben Kunden schnell damit begonnen, ihre alten Systeme in eine moderne VoIP-Infrastruktur umzuwandeln. Das Gleiche passierte auf der Seite der Service Provider, wo sie nun Verbindungen nutzen, um standortbasierte Telefoniedienste mit der VoIP-Infrastruktur des Service Providers zu verbinden und ihre Funktionen zu erweitern, um bessere Dienste bereitzustellen. Das heute am häufigsten verwendete VoIP-Protokoll ist das Session Initiation Protocol (SIP), das derzeit von Kunden und Internet-Telefonie-Service Providern (ITSP) weltweit verwendet wird.
CUBE wurde eingeführt, um diese internen VoIP-Systeme über die ITSPs mit SIP als primärem VoIP-Protokoll mit der Außenwelt zu verbinden. CUBE ist ein einfaches IP-IP-Gateway, für das keine TDM-Verbindungen wie T1/E1-Controller oder analoge Ports mehr erforderlich sind. CUBE wird auf denselben Plattformen wie TDM-Gateways ausgeführt.
Das am häufigsten verwendete VoIP-Protokoll ist SIP für die Verbindungsherstellung und -trennung und RTP für die Medienübertragung. In CUBE ist kein DSP erforderlich, es sei denn, ein Transcoder ist erforderlich. Der RTP-Datenverkehr verläuft durchgängig vom ITSP zum Endpunkt. CUBE fungiert dabei als Vermittler, wobei Adressen als eine der vielen Funktionen ausgeblendet werden.
Wie im Bild gezeigt, ermöglicht CUBE eine Trennung zwischen Ihrer internen VoIP-Infrastruktur und dem SIP ITSP:
Sprachfunktionen werden auf einer anderen Plattformliste ausgeführt, z. B. ISR, ASRs, CAT8Ks. Sie verwenden jedoch eine gemeinsame Software, die entweder Cisco IOS oder Cisco IOS XE ist (die Unterschiede zwischen Cisco IOS und Cisco IOS XE werden in diesem Artikel nicht behandelt). Dies sind die Grundlagen für den Zugriff auf den Cisco IOS Router.
Wie alle anderen CLI-basierten Geräte benötigen Router einen Terminalmonitor, um über Secure Shell (SSH) oder Telnet auf die Befehle zugreifen zu können. SSH ist das gängigste Protokoll, das heutzutage für den Zugriff auf die angegebenen Geräte verwendet wird. Es stellt eine sichere und verschlüsselte Verbindung zum Gerät her. Einige der gängigen Terminal-Monitore für den Zugriff auf die CLI der Router sind:
Es gibt verschiedene Möglichkeiten, die Ausgabe aus der CLI zu erfassen. Es wird empfohlen, die Informationen aus der CLI des Routers in eine separate Datei zu exportieren. Dies erleichtert die Weitergabe der Informationen an externe Parteien.
Es gibt folgende Möglichkeiten, die Ausgabe des Geräts zu erfassen:
Später können Sie die Informationen vom Terminalmonitor mit der Option Alle in Zwischenablage kopieren erfassen und die Ausgabe in eine Textdatei einfügen:
Anmerkung: Der Standardname der Protokolldatei wird verwendet, wenn kein anderer Name angegeben wird. Klicken Sie auf die Schaltfläche Durchsuchen, um genau zu wissen, wo die Datei gespeichert wird, um sie später zu finden. Stellen Sie außerdem sicher, dass Sie keine andere Datei putty.log im gleichen Dateipfad überschreiben.
Show-Befehle sind erforderlich, um grundlegende Informationen vom Router zu sammeln, bevor eine Debugsammlung stattfindet. Show-Befehle sind schnell zu erfassen und haben größtenteils keine Auswirkungen auf die Leistung des Routers. Die Isolierung des Problems kann sofort mit der Ausgabe des Befehls show beginnen.
Sobald die Verbindung mit dem Router hergestellt ist, kann die Anschlusslänge auf 0 gesetzt werden. Dies kann die Erfassung beschleunigen, um alle Ausgaben auf einmal anzuzeigen und die Verwendung der Leertaste zu vermeiden. Der einzige Befehl, der detaillierte Informationen über den Router sammelt, ist show tech. Alternativ dazu können Sie show tech voice erfassen, das Daten anzeigt, die spezifisch für die im Router aktivierten Sprachfunktionen sind:
Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default
Die Erfassung der Debugausgabe in Cisco IOS/IOS XE kann sich als problematisch erweisen, da die Gefahr eines Router-Absturzes besteht. Einige der Best Practices werden jedoch in den nächsten Abschnitten erläutert, um Probleme zu vermeiden.
Bevor Sie Debug-Vorgänge aktivieren, müssen Sie sicherstellen, dass genügend Speicher vorhanden ist, um die Ausgabe im Puffer zu speichern.
Führen Sie den Befehl show process memory aus, um herauszufinden, wie viel Speicher Sie zuweisen können, um alle Ausgaben im Puffer zu protokollieren:
Tipp: Verwenden Sie den Befehl terminal length default oder terminal length <num_lines>, um zu einer begrenzten Anzahl von im Terminal angezeigten Zeilen zurückzukehren.
Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832
Im Beispiel sind 7666268552 Byte (7,6 GB) frei, die vom Router verwendet werden können. Dieser Speicher wird vom Router von allen Systemprozessen gemeinsam genutzt. Dies bedeutet, dass Sie nicht den gesamten freien Speicher verwenden können, um die Ausgabe im Puffer zu protokollieren, aber Sie können eine gute Menge an Systemspeicher nach Bedarf verwenden.
Die meisten Szenarien erfordern mindestens 10 MB, um genügend Debug-Ausgabe zu sammeln, bevor die Ausgabe verloren geht oder überschrieben wird. In seltenen Fällen ist eine größere Datenmenge erforderlich. In diesen speziellen Szenarien können Sie 50 MB bis 100 MB an Ausgabe im Puffer erhalten, oder Sie können höher gehen, solange Speicher verfügbar ist.
Wenn der freie Speicher niedrig ist, liegt möglicherweise ein Speicherleckproblem vor. In diesem Fall sollte das Architecture TAC-Team beauftragt werden, die Ursachen für den geringen Arbeitsspeicher zu überprüfen.
Die CPU wird durch die Anzahl der im System aktiven Prozesse, Funktionen und Anrufe beeinflusst. Je mehr Funktionen oder Anrufe im System aktiv sind, desto höher ist der Arbeitsaufwand für die CPU.
Ein guter Maßstab ist, sicherzustellen, dass der Router die CPU mit 30 % oder weniger hat, was bedeutet, dass Sie Debug-Vorgänge sicher von "Basic" bis "Advanced" aktivieren können (achten Sie immer auf die CPU, wenn "Advanced"-Debug verwendet wird). Liegt die CPU des Routers bei ca. 50 %, können grundlegende Fehlerbehebungen durchgeführt und die CPU sorgfältig überwacht werden. Wenn die CPU mehr als 80 % erreicht, stoppen Sie sofort die Fehlerbeseitigung (siehe weiter unten in diesem Artikel) und wenden Sie sich an das TAC.
Den Prozess cpu sortiert verwenden | exclude 0.00 Befehl, um die letzten 5s, 60s und 5mins CPU Werte zusammen mit den Top Prozessen zu überprüfen.
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
In der Ausgabe hat der Router nicht viel Aktivität, die CPU ist niedrig, und Debug-Vorgänge können sicher aktiviert werden.
Vorsicht: Achten Sie besonders auf die wichtigsten aktiven CPU-Prozesse. Wenn die CPU bei 50 % oder höher liegt und der oberste Prozess nur ein Sprachprozess ist, können grundlegende Fehlerbehebungsfunktionen aktiviert werden. Überwachen Sie die CPU fortlaufend mit dem Befehl, um sicherzustellen, dass die Gesamtleistung des Routers nicht beeinträchtigt wird.
Jeder Router hat andere Kapazitätsschwellenwerte. Um sicherzustellen, dass die maximale Kapazität nicht überschritten wird, müssen Sie überprüfen, wie viele Anrufe auf dem Router aktiv sind. Das Datenblatt zu Cisco Unified Border Element Version 12 enthält Informationen zu den einzelnen Plattformkapazitäten.
Verwenden Sie den Befehl show call active total-calls, um eine Vorstellung davon zu erhalten, wie viele Anrufe im System aktiv sind:
Router# show call active total-calls
Total Number of Active Calls : 0
Verwenden Sie den Befehl show call active voice summary, um detailliertere Informationen zu den einzelnen Anruftypen abzurufen, die aktiv sind:
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
Einige der gemeinsamen Werte sind:
Um den Router so zu konfigurieren, dass die Debug-Ausgabe im Puffer gespeichert wird, wird der konfigurierte Terminalmodus eingegeben, um die Einstellungen in der CLI manuell anzupassen. Diese Konfiguration hat keine Auswirkungen auf den Router. Wie in den vorherigen Abschnitten gezeigt, ist jedoch der Befehl show tech oder show running-config vom Router erforderlich, falls ein Rollback der Konfiguration erforderlich ist.
Als Nächstes sehen Sie ein Konfigurationsbeispiel, das eine gemeinsame, von TAC-Technikern verwendete Ausgangsbasis darstellt. In diesem Beispiel werden 10 MB Pufferspeicher zugewiesen. Dieser kann jedoch nach Bedarf erhöht werden:
# 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
Diese Befehle führen folgende Aufgaben aus:
Manchmal kann es sich um zufällige Probleme handeln, die eine Möglichkeit erfordern, Debug-Meldungen kontinuierlich zu sammeln, bis das Ereignis eintritt. Wenn Sie die Debugs im Puffer speichern, werden sie kontinuierlich gesammelt. Beachten Sie, dass diese Option auf den Arbeitsspeicher beschränkt ist, den Sie zuweisen können. Sobald dieser Arbeitsspeicher erreicht ist, kreist der Puffer um den Arbeitsspeicher und verwirft die ältesten Nachrichten, was zu unvollständigen, wertvollen Informationen führt, die zur Isolierung des Problems erforderlich sind.
Mit Syslog kann der Router alle Debug-Meldungen an einen externen Server senden, wo die Syslog Server-Software sie in Textdateien speichert. Dies ist zwar eine gute Möglichkeit, die Debug-Ausgabe zu sammeln, stellt jedoch nicht die bevorzugte Methode für die Protokollsammlung dar. Syslog-Server neigen dazu, aufgrund von Überlastung im Server Zeilen aus der empfangenen Ausgabe zu überspringen oder zu löschen. Da die Debug-Ausgabe den Server überlasten kann, können Pakete aufgrund von Netzwerkbedingungen verworfen werden. In einigen Szenarien ist Syslog jedoch die einzige Möglichkeit, Fortschritte bei einem Problem zu erzielen.
Verwenden Sie nach Möglichkeit eine zuverlässige Transportmethode wie TCP, um einen Informationsverlust zu vermeiden, und schließen Sie den Syslog-Server als Vorschlag an denselben Switch an, an dem der Router angeschlossen ist, oder so nahe wie möglich am Router. Es garantiert immer noch nicht, dass alle Daten in den Dateien gespeichert werden, aber verringert die Gefahr von Datenverlusten.
Standardmäßig verwenden Syslog-Server UDP als Transportprotokoll auf 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
Sobald die Befehle konfiguriert sind, leitet der Router die Nachrichten sofort an die IP-Adresse des Syslog-Servers weiter.
Nachdem die Debugs aktiviert wurden, muss der Puffer gelöscht werden, bevor das Problem reproduziert wird. Auf diese Weise wird sichergestellt, dass die Ausgabe so sauber wie möglich ist, und zusätzliche Daten, die nicht für die Analyse benötigt werden, vermieden. Führen Sie den Befehl clear log aus. Dadurch wird sichergestellt, dass der Puffer gelöscht wird. Wenn im Router andere Anrufe aktiv sind und die Debug-Funktionen aktiviert sind, wird die Ausgabe sofort im Puffer ausgegeben.
Router# clear log
Clear logging buffer [confirm]
Router#
Wenn das Problem reproduziert wurde, deaktivieren Sie das Debugging sofort, um weitere Ausgaben im Puffer zu stoppen. Sammeln Sie dann die Protokolle. Sie können alle Ausgaben im Terminal mit den folgenden Befehlen auslesen:
Router# undebug all
Router# terminal length 0
Router# show log
Manchmal wird PuTTY geschlossen, da es nicht alle Ausgaben auf einmal verarbeiten muss. Das ist normal, und es bedeutet nicht, dass ein Fehlschlag eingetreten ist. Wenn dies der Fall ist, öffnen Sie die Sitzung erneut, und fahren Sie normal fort. In Szenarien, in denen der Protokollierungspuffer zu groß ist oder der Terminalmonitor aufgrund der zu druckenden Datenmenge abstürzt, kopieren Sie die Pufferausgabe direkt mit dem Protokoll show auf ein externes Gerät | Redirect-Befehl:
Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt
Der Befehl kopiert die gesamte Pufferausgabe in ein FTP mit der IP-Adresse 192.168.1.2 und dem Dateinamen debug.txt. Der Dateiname muss immer angegeben werden. Weitere für den Export dieser Daten verfügbare Ziele sind:
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
Jeder Anruffluss und jede Funktionsart (TDM, CUBE oder SCCP-Medienressourcen) ist unterschiedlich, und es gibt spezifische Debugging-Optionen, die Sie aktivieren können. Alle erforderlichen Debug-Meldungen müssen gleichzeitig aktiviert sein. Wenn jeweils nur ein Debugging erfasst wird, ist es ineffektiv und sorgt bei der Analyse der Daten für mehr Verwirrung.
Die Debugging-Funktionen sind in Router#, der CLI-exec-Eingabeaufforderung, aktiviert. Hierfür müssen Sie über Berechtigungen im privilegierten Ausführungsmodus verfügen.
Es gibt grundlegende und erweiterte Debugging-Optionen. Grundlegende Debugging-Funktionen werden zum Erfassen von Signalisierungsinformationen in SIP, H323 oder MGCP verwendet, um die Kommunikation zwischen Router und Peer-Geräten darzustellen.
Erweiterte Debugs sind sehr detailliert und werden normalerweise verwendet, um im Fall von internen Stapelfehlern, die die grundlegenden Debugs nicht anzeigen können, mehr Informationen zu sammeln. Diese Fehlerbehebungen sind normalerweise CPU-intensiv.
Tipp: Denken Sie daran, nach dem Aktivieren der Debug-Funktionen den Befehl clear logging auszuführen. Mit diesem Befehl wird sichergestellt, dass der Puffer für eine sauberere Erfassung der Debugs gelöscht wird.
Innerhalb jedes Cisco IOS/IOS XE Routers gibt es eine Anrufsteuerungs-API, die für die Kommunikation zwischen verschiedenen VoIP-Anwendungen oder -Protokollen und den Datenebenenkomponenten wie RTP, DSP, Voice Cards etc. zuständig ist. Um Daten aus dieser Ebene zu erfassen, kann ein spezielles Debugging verwendet werden:
debug voip ccapi inout
Es gibt andere Optionen für dieses Debuggen. debug voip ccapi inout deckt jedoch alle grundlegenden Wählplan- und Anrufeinrichtungsinformationen ab, die normalerweise mehr als genug sind, um die Zustände dieser Ebene zu verstehen.
Tipp: debug voip ccapi inout hat in der Regel nur minimale Auswirkungen auf die CPU des Routers, und es wird empfohlen, zusammen mit allen Signalisierungs-Debugs zu aktivieren, um einen vollständigen Satz von Protokollen mit Informationen über die Anrufe und ihre unterschiedlichen Zustände bereitzustellen.
Diese Debug-Meldungen werden am häufigsten für SIP-Anrufverläufe verwendet und können innerhalb von CUBE- und TDM-Gateways mit einem SIP-Leg zwischen dem Router und dem CUCM oder einem anderen SIP-Server oder -Proxy aktiviert werden.
debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.
debug ccsip all
debug ccsip verbose
debug voice ccapi inout
Diese Fehlerbehebungen gelten für Primary Rate Interfaces (PRI) T1/E1 oder Basic Rate Interfaces (BRI):
debug isdn q931
debug isdn q921
Diese Debugging-Protokolle werden verwendet, wenn es sich um analoge Leitungen wie Foreign eXchange Subscriber (FXS)- oder Foreign eXchange Office (FXO)-Ports handelt:
debug vpm signal
debug voip vtsp all
Diese Debug-Protokolle werden verwendet, wenn MGCP als Sprachprotokoll zwischen einem Voice Gateway und CUCM verwendet wird.
debug mgcp packets
debug mgcp errors
Die ccm-manager-Debugging-Protokolle dienen zum Nachverfolgen des Download der Konfiguration sowie von Warteschleifenmusik- und PRI/BRI-Backhaul-Nachrichten zwischen dem CUCM und dem Voice Gateway. Diese Debugs werden nach Bedarf verwendet und sind vom Fehlerszenario abhängig.
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 mgcp all
Obwohl H323 nicht häufig verwendet wird, gibt es dennoch einige Bereitstellungen mit konfiguriertem H323:
debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events
debug cch323 h225
debug cch323 h245
debug cch323 all
Diese Fehlerbehebungen dienen der Behebung von Problemen mit SCCP-Medienressourcen, die MTP (Media Termination Point) oder bei einem CUCM-Server registrierte Transcoder betreffen:
debug sccp messages
debug sccp events
debug sccp errors
debug sccp all
Mit der Einführung von Cisco IOS XE 17.4.1 und 17.3.2 gibt es eine neue Option zum Erfassen von Sprachprotokollen im Cisco Unified Border Element (CUBE). Diese neue Funktion heißt VoIP Trace. Hierbei handelt es sich um ein neues Framework für die Benutzerfreundlichkeit, mit dem SIP-Signalisierungen und -Ereignisse protokolliert werden, ohne dass Debugging-Vorgänge aktiviert werden müssen.
VoIP Trace ist standardmäßig aktiviert und kann bei Bedarf jederzeit deaktiviert werden. VoIP Trace erfasst nur bestimmte Informationen für SIP-Anrufe:
VoIP Trace protokolliert keine Informationen zu Out-of-Dialog-SIP-Nachrichten:
VoIP-Nachverfolgung in HA wird unterstützt. Es gelten jedoch folgende Einschränkungen:
Wie bereits erwähnt, ist diese Funktion standardmäßig aktiviert. Der Befehl zum Aktivieren dieser Funktion lautet:
Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#
Um diese Funktion zu deaktivieren, sind die folgenden Befehle verfügbar:
Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown
Vorsicht: Nachdem die VoIP-Ablaufverfolgung deaktiviert wurde, wird der gesamte Speicher gelöscht, und es gehen Informationen verloren.
Im Konfigurationsmodus für die Ablaufverfolgung stehen folgende Befehle zur Verfügung:
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
Die Speichergrenze bestimmt, wie viel Speicher von VoIP Trace zum Speichern der Daten verwendet wird. Standardmäßig beträgt sie 10 % des verfügbaren Speichers auf der Plattform, kann jedoch auf maximal 1 GB und mindestens 10 MB geändert werden. Der Speicher wird dynamisch zugewiesen, d. h., die Funktion nutzt nur bei Bedarf den Speicher und ist abhängig vom Anrufvolumen. Sobald der maximal verfügbare Speicher erreicht ist, kreist er um und löscht ältere Einträge.
Wenn der Speichergrenzwert so geändert wird, dass er größer als der verfügbare Speicher von 10 % ist, wird in der Befehlszeilenschnittstelle eine Meldung angezeigt:
Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.
Um den Standardwert auf 10 % Speicherauslastung festzulegen, kann der Befehl memory-limit platform verwendet werden:
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]:
Vorsicht: Wenn die Speichergrenze reduziert wird, gehen alle VoIP-Trace-Daten verloren. Bevor der Speicher verkleinert wird, muss eine Sicherung der Daten erfolgen.
Um die Daten von VoIP Trace anzuzeigen, müssen Sie bestimmte Befehle zum Anzeigen verwenden. Die Daten können in derselben Terminalsitzung angezeigt oder auch über Syslog an einen externen Syslog-Server gesendet werden.
Anmerkung: Ablaufverfolgungen werden nach 32 Sekunden nach dem Empfang eines BYE für einen Anruf gelöscht.
Anmerkung: Die SIP-Signalisierung wird pro Leg angezeigt und nicht wie bei regulären Debugging-Vorgängen kombiniert. Bei regulären Debug-Vorgängen wie dem Debuggen von CCSIP-Nachrichten wird die SIP-Signalisierung eines Anrufs in der genauen Reihenfolge der Ereignisse angezeigt. In VoIP Trace ist jeder Abschnitt separat. Zur Bestimmung der richtigen Reihenfolge werden die Zeitstempel verwendet.
Folgende Befehle stehen zur Anzeige der Daten zur Verfügung:
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
Mit diesem Befehl werden alle im Puffer verfügbaren VoIP-Trace-Daten angezeigt. Die Verwendung dieses Befehls beeinträchtigt die Leistung des Routers. Nach der Eingabe des Befehls wird eine Warnmeldung angezeigt, die Sie über das Risiko informiert und den Fortgang bestätigt:
Router# show voip trace all
Displaying 11858 cover buffers
This may severely impact system performance.
Continue? [yes/no] no
Dieser Befehl zeigt eine Übersicht der Anrufdetails für alle unter VoIP-Trace gemeldeten Anrufe an. Für jeden Anrufabschnitt wird ein Cover-Puffer erstellt, der eine Zusammenfassung des protokollierten Anrufs enthält.
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
-----------------------------------------------
Weitere Informationen zu den einzelnen Feldern finden Sie in der folgenden Tabelle:
Feld |
Beschreibung |
Suchschlüssel |
Enthält eine Kombination aus Anrufer, angerufener Nummer und Anruf-ID. |
Zeitstempel |
Erstellungszeit des Abdeckungspuffers |
Puffer-ID |
Pufferkennung des Deckungspuffers |
Anruf-ID |
Call-ID des jeweiligen Call-Abschnitts von zum Cover-Puffer |
Peer-Anruf-ID |
Anruf-ID des Peer-Abschnitts |
Korrelator |
FPI-Korrelator des Anrufs |
Angerufene Nummer |
Angerufene Nummer des jeweiligen Anrufabschnitts des Abdeckungspuffers |
Anrufernummer |
Rufnummer der jeweiligen Rufstrecke des Deckungspuffers |
SIP-Anruf-ID |
SIP-Anruf-ID des jeweiligen Anrufabschnitts des Abdeckungspuffers |
SIP-Sitzungs-ID |
SIP-Sitzungs-ID des jeweiligen Anrufabschnitts des Abdeckungspuffers |
GUID |
GUID des jeweiligen Rufs des Deckungspuffers |
Ankerbein |
Der Ankerzweig wird auf "yes" (Ja) gesetzt, wenn der jeweilige Anrufzweig ein Ankerzweig im Anrufweiterleitungsprozess oder in der Media Proxy-Bereitstellung ist. |
Gabelbein |
Forked Leg wird auf yes gesetzt, wenn die jeweilige Anrufstrecke eine Ankerstrecke im Anrufweiterleitungsprozess oder in der Media Proxy-Bereitstellung ist. |
Zugehörige Anruf-IDs |
Anruf-ID der zugehörigen Gabelbeine |
Um die Cover-Puffer zu filtern, können Sie die Befehle include und section verwenden:
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
In Kombination mit dem vorherigen Befehl kann show voip trace call-id verwendet werden, um die Aufrufe zu finden. Nachdem die Anruf-ID identifiziert wurde, kann dieser Befehl verwendet werden, um alle Informationen zum jeweiligen Anrufabschnitt anzuzeigen:
Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661
Dieser Befehl show zeigt detaillierte Informationen zu Status, Speicherbelegung, Fehlern oder Fehlern, erfolgreichen Anrufen, Zeitstempeln der neuesten und ältesten Einträge und mehr an.
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
Weitere Informationen zu den einzelnen Feldern finden Sie in der folgenden Tabelle:
Feld |
Beschreibung |
Ablaufverfolgungsstatus |
Zeigt den Ablaufverfolgungsstatus an, einschließlich der Zeit und des Datums, an dem die VoIP-Ablaufverfolgung aktiviert wurde. |
Speicherlimit konfiguriert |
Zeigt das konfigurierte Speicherlimit an. Dies entspricht 10 % der Speichergröße des Prozessorpools. |
Arbeitsspeicher belegt |
Zeigt den dynamisch für VoIP-Trace belegten Arbeitsspeicher an |
Gesamtzahl abgebrochener Anrufverbindungen |
Zeigt die Anzahl der fehlerhaften Anrufabschnitte an, die in den Protokollierungspuffer geschrieben wurden. Gedumpte Anrufe beziehen sich auf Anrufabschnitte, die mit IEC-Fehlern verbunden sind |
Älteste Spurensicherung |
Zeigt Zeitstempel und Suchschlüssel für den ältesten fehlgeschlagenen Anruf seit Aktivierung der VoIP-Ablaufverfolgung an. |
Neueste Spur verworfen |
Zeigt Zeitstempel und Suchschlüssel für den letzten fehlgeschlagenen Anruf seit Aktivierung der VoIP-Ablaufverfolgung an. |
Gesamtzahl erfasster Anrufabschnitte |
Zeigt die Gesamtzahl der nach Aktivierung von VoIP Trace erfassten Levels an |
Verfügbare Anrufabschnitte gesamt |
Zeigt die Gesamtzahl der verfügbaren Anrufabschnitte im Verlauf an. Dies kann im Vergleich zur Gesamtanzahl der erfassten Anrufabschnitte gleich oder unterschiedlich sein und hängt vom Speicherlimit ab. |
Älteste verfügbare Spur |
Zeigt den Zeitstempel und den Suchschlüssel des ältesten verfügbaren Deckungspuffers im Speicher an. |
Neueste Spur verfügbar |
Zeigt den Zeitstempel und den Suchschlüssel des neuesten im Speicher verfügbaren Cover-Puffers an. |
Verpasste Ablaufverfolgungen gesamt |
Zeigt die Anzahl der Anrufabschnitte an, die aufgrund eines Speicherlimits verpasst wurden. |
Feld |
Nutzung |
Beschreibung |
show voip trace correlator <Korrelator> |
show voip trace correlator 4 |
Filtert und zeigt VoIP-Ablaufverfolgung für eine bestimmte Anruf-ID an, beginnend mit dem Cover-Puffer |
show voip trace session-id <Sitzungs-ID> |
show voip trace session-id 87003120822b5dbd8fd80f62d8e57c48 |
Filtert und zeigt VoIP-Ablaufverfolgung für einen Anruf basierend auf der SIP-Sitzungs-ID an. Die lokale oder die Remote-UUID aus dem Session-ID-Header der SIP-Nachricht kann verwendet werden, um beide Abschnitte des Anrufs anzuzeigen. |
show voip trace sip-call-id <call-id> |
show voip trace sip-call-id 01e60dfa9d8442848336d79e3155a8a1 |
Filtert und zeigt VoIP-Ablaufverfolgung basierend auf SIP-Anruf-ID an |
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
3.0 |
13-Feb-2025 |
Aktualisierte Branding-Anforderungen, Stilanforderungen, Formatierung und Grammatik. |
2.0 |
13-Apr-2023 |
Alternativer Text hinzugefügt.
Aktualisierter Titel, Einführung, Branding Anforderungen, Stilvorgaben, Gerunds, Formatierung und Grammatik. |
1.0 |
13-Aug-2021 |
Erstveröffentlichung |