Debug-Sammlung für CUBE- und TDM-Gateways konfigurieren
Inhalt
Einleitung
In diesem Dokument werden einige der Best Practices zur Erfassung von Sprachdebuggern auf dem Cisco IOS®/IOS XE® Voice Router beschrieben.
Voraussetzungen
Anforderungen
- Privilegierter Zugriff zur Ausführung von Befehlen in den ISR-Routern
- Die Nutzung von Voice-over-IP (VoIP)-Protokollen ist wünschenswert.
- Für VoIP Trace ist mindestens Cisco IOS XE 17.4.1 oder 17.3.2 erforderlich.
- Grundkenntnisse von Cisco IOS/IOS XE in Integrated Services Routern (ISR)
Verwendete Komponenten
Für die Zwecke dieses Dokuments werden folgende Komponenten verwendet:
- PuTTY
- Cisco ISR 3925
- Cisco ISR 4451
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.
Hintergrundinformationen
Der Prozess der Debugsammlung in diesen Plattformen hat Herausforderungen 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. Wenn die Fehlerbehebungen nicht korrekt erfasst werden, kann dies in einigen Szenarien zu einer hohen CPU-Auslastung führen, die die Kapazität des Routers beschädigen und sogar einen Software-Absturz auslösen kann. In diesem Dokument werden die Unterschiede zwischen einem Cisco Unified Border Element (CUBE) und einem Time-Division Multiplexing (TDM)/Analog Gateway erläutert.
TDM-Sprach-Gateways gegen CUBE
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 an die spezifische Schaltung sendet. Diese Gateways arbeiten auf VoIP- und TDM-Seite mit H323, MGCP oder Skinny Call Control Protocol (SCCP) zusammen. Entweder ISDN PRI-Schaltkreise oder analoge Leitungen als die gebräuchlichsten Verbindungen zum PSTN oder zu Endpunkten.
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 ihre alten Systeme schnell auf eine moderne VoIP-Infrastruktur umgestellt. 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 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:
Sammlung von Cisco IOS/IOS XE-Sprachdebuggern
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.
Zugriff auf einen Cisco IOS/IOS XE Router über eine Kommandozeile (CLI)
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:
Festlegen des Terminalmonitors zum Sammeln von Show-Befehlen oder Debuggen
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:
- Geben Sie die gesamte Ausgabe im Terminal aus. Sie müssen sicherstellen, dass ausreichend Zeilen für den Scrollback vorhanden sind, da andernfalls die ersten Abschnitte der Ausgabe nicht angezeigt werden und die Daten unvollständig sind. Um die Scrollbacklinien in Putty zu erhöhen, navigieren Sie zu Putty Configuration > Window > Lines of Scrollback. Normalerweise wird dies auf einen sehr hohen Wert gesetzt, um genügend Scrollback-Ausgabe zu haben:
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:
- Eine weitere Option besteht darin, die gesamte Sitzungsausgabe in einer TXT-Datei zu protokollieren. Mit dieser Option werden alle eingegebenen Befehle und Ausgaben, die erfasst werden, sofort in der Textdatei protokolliert. Dies ist eine gängige Vorgehensweise, um alle Ausgaben in einer Sitzung zu protokollieren. Um die gesamte Sitzungsausgabe in einer Datei unter Putty (Putty) zu protokollieren, navigieren Sie zu Putty Configuration > Session > Logging (Putty-Konfiguration > Sitzung > Protokollierung), und wählen Sie dann All Session Output (Alle Sitzungsausgabe) wie folgt aus:
Sammeln der grundlegenden Ausgabe von Show-Befehlen über die CLI
Show-Befehle sind erforderlich, um grundlegende Informationen vom Router zu sammeln, bevor eine Debugsammlung stattfindet. Show-Befehle lassen sich schnell erfassen und haben größtenteils keine Auswirkungen auf die Leistung des Routers. Die Isolierung des Problems kann sofort mit dem Befehl show beginnen.
Sobald der Router angeschlossen ist, kann die Terminallänge auf 0 gesetzt werden. Dies ermöglicht eine schnellere Erfassung, um alle Ausgaben auf einmal anzuzeigen und die Verwendung der Leertaste zu vermeiden. Ein Befehl, der detaillierte Informationen über den Router sammelt, ist show tech. Alternativ können Sie show tech voice erfassen, das spezifischere Daten zu den auf dem Router aktivierten Sprachfunktionen anzeigt:
Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default
Sammeln der Debug-Ausgabe von der CLI
Die Erfassung der Debugausgabe in Cisco IOS/IOS XE kann sich als problematisch erweisen, da die Gefahr eines Router-Absturzes besteht. In den nächsten Abschnitten werden einige Best Practices erläutert, um einige dieser Probleme zu vermeiden.
Speicherüberprüfung
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 zu bestimmen, wie viel Speicher Sie zuweisen können, um alle Ausgaben im Puffer zu protokollieren:
Tipp: Verwenden Sie den Befehl terminal length default (Terminallänge) oder terminal length (Terminallänge), 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
In diesem Beispiel stehen 7666268552 Byte (7,6 GB) für die Verwendung durch den Router zur Verfügung. Dieser Speicher wird vom Router von allen Systemprozessen gemeinsam genutzt. Dies bedeutet, dass Sie nicht den gesamten verfügbaren freien Speicher verwenden können, um die Ausgabe im Puffer zu protokollieren, Sie können jedoch eine gute Menge an Systemspeicher nach Bedarf verwenden.
Die meisten Szenarien erfordern mindestens 10 MB, um genügend Debugausgabe zu sammeln, bevor die Ausgabe verloren geht oder überschrieben wird. In seltenen Fällen ist eine größere Datenmenge für die Erfassung erforderlich. In diesen Szenarien können Sie eine Ausgabe von 50 MB bis 100 MB im Puffer erhalten, oder Sie können einen höheren Wert auswählen, wenn verfügbarer Speicher vorhanden ist.
Wenn nicht genügend freier Speicher vorhanden ist, liegt möglicherweise ein Speicherleck vor. In diesem Fall sollte das Architecture TAC-Team beauftragt werden, die Ursachen für den geringen Arbeitsspeicher zu überprüfen.
CPU-Prüfung (Zentraleinheit)
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). Bei einer Router-CPU-Auslastung von ca. 50 % können grundlegende Fehlerbehebungen ausgeführt werden. Die CPU wird jedoch immer überwacht. Wenn die CPU mehr als 80 % erreicht, stoppen Sie sofort das Debugging (siehe weiter unten in diesem Artikel), und wenden Sie sich an das TAC.
Den Anzeigeprozess cpu sortiert ausführen | 0.00 ausschließen, um die CPU-Werte der letzten 5 Sekunden, 60 Sekunden und 5 Minuten zusammen mit den wichtigsten 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 genau 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.
Prüfung der aktuellen aktiven Anrufe
Jeder Router hat andere Kapazitätsschwellenwerte. Es ist wichtig, zu überprüfen, wie viele Anrufe im Router aktiv sind, um sicherzustellen, dass die maximale Kapazität nicht erreicht wird. Das Datenblatt zu Cisco Unified Border Element Version 12 enthält Informationen zur Kapazität der einzelnen Plattformen.
Führen Sie den Befehl show call active total-calls aus, 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
Führen Sie den Befehl show call active voice summary aus, um detailliertere Informationen zu den Anruftypen zu erhalten, 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 gängige Werte sind:
- Telefonanruf-Legs: TDM-Gateway-Anrufe, einschließlich analoger und PRI/ISDN-Anrufe
- SIP-angerufene Geräte: SIP-Anrufe gesamt; Wenn es sich um einen CUBE-Router handelt, werden zwei Anrufabschnitte pro Anruf angezeigt. Teilen Sie die Gesamtzahl der Anrufe durch zwei, um eine genaue Zahl zu erhalten.
- H323-Anrufvereine: Gesamtzahl der H323-Anrufe
- SCCP-Anruflegien: Vom Cisco Unified Communications Manager (CUCM) gesteuerte Medienressourcen, die im Router verwendet werden, z. B. Transcoder und MTPs.
Protokollierungspuffereinstellungen
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, sind jedoch Befehle vom Router show tech oder show running-config erforderlich, wenn ein Rollback für das Ereignis in der Konfiguration erforderlich ist.
Dies ist ein Konfigurationsbeispiel, das eine gemeinsame Basislinie darstellt, die von TAC-Technikern verwendet wird. Dadurch werden 10 MB Pufferspeicher zugewiesen, der jedoch nach Bedarf erhöht werden kann:
# 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 diese Aufgaben aus:
- service timestamps debug oder log: Stellt sicher, dass die Zeiten des lokalen Routers in jede protokollierte Nachricht mit millisekundengenauer Genauigkeit geschrieben werden. Dies ist nützlich, um Anrufe basierend auf der Zeit zu finden. Millisekunden-Zeitstempel, mit denen Sie Debugzeilen in logisch zusammenhängende Ereignisse gruppieren können, wenn zwei Zeilen innerhalb derselben Millisekunde auftreten.
- Service-Sequenznummern: Schreibt die Sequenznummer des Debugs in die Zeile. Dies ist nützlich (erforderlich), wenn Protokolle an einen Syslog-Server weitergeleitet werden. Dies ist sehr nützlich, um festzustellen, ob eine Debug-Nachricht an den Syslog-Server im Netzwerk verworfen wurde. Die Sequenznummer ist das erste Element im Debugging vor dem Zeitstempel und der Protokollmeldung. Dies unterscheidet sich von den Zeitstempel-/Sequenznummern, die Syslog-Server lokal in ihre Dateien schreiben können.
- Protokollierungspuffer: Weist den Router an, Debug-Meldungen an den lokalen Pufferspeicher zu senden. Die Puffergröße wird in Byte festgelegt. In der Konfiguration wurde die Puffergröße auf 10 MB eingestellt.
- Keine Protokollierungskonsole und kein Protokollierungsmonitor: Auf der Konsole oder dem Terminalmonitor werden keine Protokollmeldungen ausgegeben. Wenn diese Befehle nicht konfiguriert werden, können sie sich negativ auf die Leistung des Routers und die Genauigkeit der Debugausgabe auswirken.
- Voice Ice-Syslog: Aktiviert Voice Internal Error Code-Meldungen, um die Ursache für die Verbindungstrennung zu ermitteln.
Syslog-Einstellungen konfigurieren
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 Debugs im Puffer speichern, werden sie kontinuierlich gesammelt. Sie ist auf die Speichergröße beschränkt, die Sie zuweisen können. Sobald diese Speichergröße erreicht ist, umrundet der Puffer die ältesten Nachrichten und löscht sie, 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, auf dem die Syslog-Serversoftware sie in Textdateien speichert. Dies ist zwar eine gute Möglichkeit, die Debug-Ausgabe zu sammeln, ist jedoch nicht die bevorzugte Methode für die Protokollsammlung. Syslog-Server neigen dazu, aufgrund von Überlastung im Server Zeilen aus der empfangenen Ausgabe zu überspringen oder zu löschen. Da Debug-Ausgaben den Server überlasten können, können Pakete aufgrund von Netzwerkbedingungen verworfen werden. In einigen Szenarien sind Syslogs jedoch die einzige Möglichkeit, Fortschritte in einem Problem zu erzielen.
Verwenden Sie nach Möglichkeit eine zuverlässige Transportmethode wie TCP, um Datenverluste zu vermeiden, und schließen Sie den Syslog-Server als Vorschlag an den gleichen Switch an, an dem der Router angeschlossen ist, oder so nahe wie möglich am Router. Dies garantiert nicht, dass alle Daten in den Dateien gespeichert werden, reduziert jedoch die Gefahr eines Datenverlusts.
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 <port>
Nach der Konfiguration der Befehle leitet der Router die Nachrichten sofort an die IP-Adresse des Syslog-Servers weiter.
Debug-Auflistung
Sobald die Debugging-Funktion aktiviert ist, muss der Puffer gelöscht werden, bevor das Problem reproduziert werden kann. 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, um sicherzustellen, dass der Puffer gelöscht wird. Wenn auf dem 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 zusätzliche Ausgaben im Puffer zu stoppen, und 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 schließt PuTTY, da es nicht alle Ausgaben auf einmal verarbeiten kann. Dies ist normal und bedeutet nicht, dass ein Fehler aufgetreten 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 Anzeigeprotokoll auf ein externes Gerät | Redirect-Befehl:
Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt
Dieser Befehl kopiert die gesamte Pufferausgabe in eine FTP-IP-Adresse von: 192.168.1.2 mit dem Dateinamen debug.txt. Der Dateiname muss immer angegeben werden. Weitere für den Export von 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
Welche Debugging-Optionen können in Voice Routern aktiviert werden?
Jeder Anruffluss und jede Funktionsart (TDM, CUBE oder SCCP-Medienressourcen) ist unterschiedlich, und es sind bestimmte Debugs zu aktivieren. Alle erforderlichen Debugging-Vorgänge müssen gleichzeitig aktiviert werden. 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-Eingabeaufforderung, aktiviert. Hierfür müssen Sie über Berechtigungen im privilegierten Ausführungsmodus verfügen.
Es gibt grundlegende und erweiterte Debugging-Funktionen, und grundlegende Debugging-Funktionen werden zum Erfassen von Signalisierungsinformationen in SIP, H323 oder MGCP verwendet. Hier sehen Sie die Gespräche, die der Router mit seinen Peer-Geräten führt.
Erweiterte Debugs sind sehr detailliert und werden verwendet, um zusätzliche Informationen zu sammeln, wenn die internen Stapelfehler keine grundlegenden Debugs anzeigen können. Diese Fehlerbehebungen sind normalerweise CPU-intensiv.
Debuggen der internen Anrufsteuerungs-API (CCAPI)
Innerhalb jedes Cisco IOS/IOS XE Routers gibt es eine Anrufsteuerungs-API, die für die Kommunikation zwischen verschiedenen VoIP-Anwendungen oder -Protokollen zuständig ist. Die Datenebenenkomponenten wie RTP, DSP, Sprachkarten und andere erfassen Daten von dieser Ebene. Es gibt ein spezifisches Debugging, das verwendet werden kann:
debug voip ccapi inout
Es gibt andere Optionen für dieses Debuggen. deckt der Befehl debug voip ccapi inout 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 den/die Anruf(e) und seine unterschiedlichen Zustände bereitzustellen.
SIP-Anrufflüsse
Diese Debug-Protokolle werden in der Regel für SIP-Anrufverläufe verwendet und können innerhalb von CUBE- und TDM-Gateways mithilfe eines SIP-Leg zwischen dem Router und dem CUCM oder einem anderen SIP-Server oder -Proxy aktiviert werden.
Grundlegende SIP-Fehlerbehebung
debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.
Erweiterte SIP-Fehlerbehebung
debug ccsip all
debug ccsip verbose
debug voice ccapi inout
Digitale (PRI, BRI) Anrufflüsse
Diese Fehlerbehebungen gelten für Primary Rate Interfaces (PRI) T1/E1 oder Basic Rate Interfaces (BRI):
Grundlegendes digitales Debugging
debug isdn q931
Erweitertes digitales Debugging
debug isdn q921
Analoge Anrufflüsse
Diese Fehlerbehebungen werden verwendet, wenn analoge Schaltungen FXS- (Foreign eXchange Subscriber) oder FXO-Ports (Foreign eXchange Office) beinhalten:
debug vpm signal
debug voip vtsp all
MGCP-Anrufflüsse
Diese Debug-Protokolle werden verwendet, wenn MGCP als Sprachprotokoll zwischen einem Voice Gateway und CUCM verwendet wird.
Grundlegende Debugs
debug mgcp packets
debug mgcp errors
CCM-Manager-Fehlerbehebung
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 Debugging-Vorgänge werden je nach Bedarf eingesetzt 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
Erweiterte MGCP-Debugs
debug mgcp all
H323-Anrufflüsse
Obwohl H323 nicht häufig verwendet wird, gibt es dennoch einige Bereitstellungen mit konfiguriertem H323:
Grundlegende H323-Debugs
debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events
Erweiterte H323-Debugs
debug cch323 h225
debug cch323 h245
debug cch323 all
SCCP-Medienressourcen
Diese Fehlerbehebungen dienen der Behebung von Problemen mit SCCP-Medienressourcen, die MTP (Media Termination Point) oder bei einem CUCM-Server registrierte Transcoder betreffen:
Grundlegende SCCP-Debugs
debug sccp messages
debug sccp events
debug sccp errors
Erweitertes SCCP-Debugging
debug sccp all
VoIP-Nachverfolgung
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:
- SIP-Fehler
- DFÜ-Peer zugeordnet
- Zugeordnete RTP-Ports
- IEC-Fehlerkorrelation mit SIP-Signalisierung
- SIP-Nachrichten für Anrufe vom SIP-Trunk zum Trunk
- Status und Ereignisse von "Finite State Machines" (FSM)
- Ereignisse und API-Anrufe vom SIP-Layer an andere Layer in CUBE
- Anrufsteuerung (Unified Communication-Anrufverläufe werden von CUBE verarbeitet)
Einschränkungen
VoIP Trace protokolliert keine Informationen zu Out-of-Dialog-SIP-Nachrichten:
- REGISTRIEREN
- OPTIONEN
- ABONNIEREN/BENACHRICHTIGEN
- INFORMATIONEN
VoIP-Nachverfolgung in HA wird unterstützt. Es gelten jedoch folgende Einschränkungen:
- Auf dem Standby-Router ist VoIP Trace standardmäßig aktiviert. Es werden nur anwendbare Traces für den Standby-Prozess angezeigt, bis dieser aktiv wird.
- Sobald der Standby-Modus aktiv ist, enthält er KEINE vollständigen Ablaufverfolgungen von zielgerichteten Anrufen und nur neue Anrufe.
- show voip trace <key> funktioniert weiterhin auf dem Standby-Router und zeigt Cover-Puffer- und Medien-Stream-Daten für Anrufe an.
So aktivieren Sie VoIP Trace
Wie bereits erwähnt, ist diese Funktion standardmäßig aktiviert. Führen Sie folgende Befehle aus, um diese Funktion zu aktivieren:
Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#
Deaktivieren der VoIP-Ablaufverfolgung
Führen Sie folgende Befehle aus, um diese Funktion zu deaktivieren:
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
Speichergrenze konfigurieren
Die Speichergrenze bestimmt, wie viel Speicher von VoIP Trace zum Speichern von Daten verwendet wird. Standardmäßig beträgt er 10 % des verfügbaren Speichers der Plattform, kann jedoch auf maximal 1 GB und min. 10 MB eingestellt werden. Der Speicher wird dynamisch zugewiesen, da die Funktion nur bei Bedarf Speicher verwendet und vom Anrufvolumen abhängig ist. Sobald der maximal verfügbare Arbeitsspeicher erreicht ist, wird er in einer Kreisbewegung angeordnet und löscht ältere Einträge.
Wenn der Speichergrenzwert so geändert wird, dass er über dem verfügbaren Speicher von 10 % liegt, wird eine Meldung in der CLI 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.
Führen Sie den Befehl memory-limit platform aus, um den Standardwert auf 10 % Speicherauslastung festzulegen:
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]:
Anzeigen von VoIP-Ablaufverfolgungsdaten
Um die Daten von VoIP Trace anzuzeigen, müssen Sie bestimmte Befehle zum Anzeigen verwenden. Die Daten können in derselben Terminalsitzung angezeigt oder ü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.
Die SIP-Signalisierung wird pro Leg angezeigt und nicht wie bei regulären Debugging-Vorgängen kombiniert. Bei regulären Debug-Vorgängen, z. B. beim Debuggen von CCSIP-Nachrichten, wird die SIP-Signalisierung eines Anrufs in der genauen Reihenfolge der Ereignisse angezeigt. In VoIP Trace ist jeder Abschnitt separat, um die richtige Reihenfolge zu bestimmen, werden die Zeitstempel verwendet.
Führen Sie folgende Befehle aus, um die verfügbaren Daten anzuzeigen:
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
VoIP-Ablaufverfolgung alle anzeigen
Mit diesem Befehl werden alle im Puffer verfügbaren VoIP-Trace-Daten angezeigt. Mit diesem Befehl wird die Leistung des Routers beeinträchtigt. Nach Eingabe des Befehls wird eine Warnmeldung angezeigt, die Sie beim Fortfahren auf Risiken hinweist:
Router# show voip trace all
Displaying 11858 cover buffers
This may severely impact system performance.
Continue? [yes/no] no
VoIP-Trace-Cover-Puffer anzeigen
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 der protokollierten Anrufe 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 Anrufabschnitts 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 |
Die Auslösung des Ankerzweigs wird auf "Yes" (Ja) gesetzt, wenn der jeweilige Anrufzweig ein Ankerzweig im Anrufweiterleitungs-Workflow oder in der Media Proxy-Bereitstellung ist. |
| Gabelbein |
Die Einstellung für "Forked leg" lautet "Yes" (Ja), wenn es sich bei dem jeweiligen Anrufabschnitt um einen Ankerabschnitt im Anrufweiterleitungs-Workflow oder in der Media Proxy-Bereitstellung handelt. |
| Zugehörige Anruf-IDs |
Anruf-ID der zugehörigen Gabelbeine |
Führen Sie zum Filtern der Deckungspuffer die Befehle include und section aus:
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
VoIP-Trace-Anruf-ID anzeigen
In Kombination mit dem vorherigen Befehl kann show voip trace call-id verwendet werden, um Anrufe zu suchen. Nachdem die Anruf-ID identifiziert wurde, kann der nächste Befehl ausgeführt 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
VoIP-Trace-Statistik anzeigen
Dieser Befehl show zeigt detaillierte Informationen zu Status, Speicherbelegung, Fehlern/Fehleranrufen, erfolgreichen Anrufen, Zeitstempeln für die 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, der die Zeit und das Datum enthält, zu der die VoIP-Ablaufverfolgung aktiviert wurde. |
| Speicherlimit konfiguriert |
Zeigt das konfigurierte Speicherlimit an. Dies entspricht 10 % der Speichergröße des Prozessorpools. |
| Belegter Arbeitsspeicher |
Zeigt den dynamisch für die VoIP-Ablaufverfolgung belegten Arbeitsspeicher an. |
| Gesamtzahl der gelöschten Anrufeinträge |
Zeigt die Anzahl der fehlerhaften Anrufabschnitte an, die in den Protokollierungspuffer verschoben wurden. Gedumpte Anrufe beziehen sich auf Anrufabschnitte, die mit IEC-Fehlern verbunden sind. |
| Ältester versenkter Trace |
Zeigt Zeitstempel und Suchschlüssel für den ältesten fehlgeschlagenen Anruf seit Aktivierung der VoIP-Ablaufverfolgung an. |
| Letzte Spur gelöscht |
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 der VoIP-Ablaufverfolgung erfassten Abschlüsse an. |
| Verfügbare Anruflegien gesamt |
Zeigt die Gesamtzahl der verfügbaren Anrufabschnitte im Verlauf an. Dies kann im Vergleich zur Gesamtzahl der erfassten Anrufabschnitte gleich oder unterschiedlich sein. Dies hängt vom Speicherlimit ab. |
| Älteste verfügbare Nachverfolgung |
Zeigt den Zeitstempel und den Suchschlüssel des ältesten verfügbaren Deckungspuffers im Speicher an. |
| Neueste Nachverfolgung verfügbar |
Zeigt den Zeitstempel und den Suchschlüssel des neuesten Cover-Puffers an, der im Speicher verfügbar ist. |
| Verpasste Spuren gesamt |
Zeigt die Anzahl der Anrufabschnitte an, die aufgrund eines Speicherlimits verpasst wurden. |
Zusätzliche Befehle anzeigen
| 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. Sie können die lokale oder eine Remote-UUID aus dem Session-ID-Header der SIP-Nachricht verwenden, 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 der SIP-Anruf-ID an. |
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
4.0 |
17-Aug-2026
|
Aktualisierte Einführung, Rechtschreibung, Grammatik, eingefügte horizontale Linien in separate Abschnitte für Lesbarkeit, korrigierte CCW-Fehler. |
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 |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)