Wichtige Informationen zu Debugbefehlen verstehen

Einleitung

Dieses Dokument beschreibt allgemeine Richtlinien zur Verwendung von debug Befehlen, einschließlich des auf den debug ip packet Cisco IOS®-Plattformen verfügbaren Befehls.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Herstellen einer Verbindung zum Router über die Konsolen-, Aux- und VTY-Ports

• Allgemeine Konfigurationsprobleme mit Cisco IOS®

• Interpretieren von Cisco IOS® Debug-Ausgaben

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

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

Diese Seite enthält einige allgemeine Richtlinien zur Verwendung der auf Cisco IOS-Plattformen verfügbaren Debugging-Programme sowie Beispiele für die korrekte Verwendung des Befehls debug ip packet und des bedingten Debuggens.

Die Ausgabe debug von privilegierten EXEC-Befehlen liefert Diagnoseinformationen, die eine Vielzahl von Netzwerkereignissen bezüglich des Protokollstatus und der Netzwerkaktivität im Allgemeinen umfassen.

Warnungen

debug Vorsicht bei Befehlen. Im Allgemeinen wird empfohlen, diese Befehle nur unter Anleitung des technischen Supports Ihres Routers zu verwenden, wenn Sie spezifische Probleme beheben.

Durch Aktivieren des Debuggens kann der Betrieb des Routers unterbrochen werden, wenn in Internetworks Bedingungen mit hoher Auslastung auftreten. Wenn die Protokollierung aktiviert ist, kann sich der Zugriffsserver daher zeitweise aufhängen, sobald der Konsolenport mit Protokollmeldungen überlastet wird.

Bevor Sie debug einen Befehl starten, sollten Sie immer die Ausgabe berücksichtigen, die dieser Befehl generieren kann, und wie lange dies dauern kann.

Wenn Sie beispielsweise über einen Router mit einer BRI (Basic Rate Interface) verfügen, schadet dies debug isdn q931 wahrscheinlich nicht dem System.

Immer wenn das gleiche Debuggen auf einem AS5800 mit voller E1-Konfiguration durchgeführt wird, kann dies wahrscheinlich so viel Input generieren, dass das System hängen bleibt und nicht mehr reagiert.

Vor dem Debuggen betrachten Sie die CPU-Last mit show processes cpu dem Befehl. Stellen Sie sicher, dass genügend CPU verfügbar ist, bevor Sie mit dem Debuggen beginnen.

Weitere Informationen zum Umgang mit hoher CPU-Auslastung finden Sie unter Troubleshooting High CPU Utilization on Cisco Routers (Fehlerbehebung bei hoher CPU-Auslastung).

Wenn Sie beispielsweise einen Cisco 7200-Router mit einer ATM-Schnittstelle für Bridging verwenden, kann ein Neustart des Routers je nach konfigurierter Anzahl von Subschnittstellen viel CPU-Zeit in Anspruch nehmen.

Der Grund hierfür ist, dass für jede virtuelle Verbindung (VC) ein Bridge Protocol Data Unit (BPDU)-Paket generiert werden muss. Das Starten von Debugging-Vorgängen während einer so kritischen Zeit kann zu einem drastischen Anstieg der CPU-Auslastung und damit zu einem Absturz oder Verbindungsverlust im Netzwerk führen.

Vor dem Debuggen

Stellen Sie zusätzlich zu den oben genannten Punkten sicher, dass Sie die Auswirkungen der Debugs auf die Stabilität der Plattform verstehen. Sie müssen sich auch überlegen, mit welcher Schnittstelle des Routers Sie eine Verbindung herstellen müssen.

Dieser Abschnitt enthält einige Richtlinien.

Abrufen von Debug-Ausgaben

Router können Debug-Ausgaben für verschiedene Schnittstellen anzeigen, einschließlich der Konsolen-, Aux- und VTY-Ports. Router können Meldungen auch in einem internen Puffer auf einem externen Unix-Syslog-Server protokollieren.

Anweisungen und Hinweise zu den einzelnen Methoden werden nachfolgend erläutert:

Konsolen-Port

Wenn Sie mit der Konsole verbunden sind, müssen Sie unter normalen Konfigurationen keine zusätzlichen Arbeiten durchführen. Die Debug-Ausgabe muss automatisch angezeigt werden.

Stellen Sie jedoch sicher, dass logging console level sie wie gewünscht eingestellt sind und dass die Protokollierung mit dem Befehl nicht deaktiviert no logging console wurde.

AUX-Port

Wenn Sie über einen Hilfsport verbunden sind, geben Sie den Befehl terminal monitor ein. Überprüfen Sie außerdem, ob no logging on der Befehl auf dem Router nicht aktiviert wurde.

VTY-Ports

Wenn Sie über einen Hilfsport oder über Telnet verbunden sind, geben Sie den Befehl terminal monitor ein. Überprüfen Sie außerdem, ob no logging on der Befehl nicht verwendet wurde.

Protokollieren von Nachrichten an einen internen Puffer

Das Standardprotokollierungsgerät ist die Konsole. Sofern nicht anders angegeben, werden alle Meldungen auf der Konsole angezeigt.

Um Nachrichten in einem internen Puffer zu protokollieren, verwenden Sie den Konfigurationsbefehl logging buffered therouter. Dies ist die vollständige Syntax dieses Befehls:

logging buffered no logging buffered 

logging buffered Der Befehl kopiert Protokollmeldungen in einen internen Puffer, anstatt sie in die Konsole zu schreiben. Der Puffer ist kreisförmig, sodass neuere Nachrichten ältere Nachrichten überschreiben.

Um die Meldungen anzuzeigen, die im Puffer protokolliert werden, verwenden Sie den Befehl show logging privilegierter EXEC-Modus. Die erste Meldung ist die älteste Meldung im Puffer.

Sie können die Größe des Puffers sowie den Schweregrad der zu protokollierenden Meldungen festlegen.

no logging buffered Der Befehl bricht die Verwendung des Puffers ab und schreibt Meldungen auf die Konsole (Standard).

Protokollieren von Nachrichten auf einem UNIX-Syslog-Server

Verwenden Sie den Konfigurationsbefehl logging router, um Meldungen beim Syslog-Serverhost zu protokollieren. Die vollständige Syntax dieses Befehls lautet wie folgt:

 logging <ip-address> no logging <ip-address>  

loggingDer Befehl identifiziert einen Syslog-Serverhost, der Protokollmeldungen empfangen soll. Das < ip-address>-Argument ist die IP-Adresse des Hosts.

Wenn Sie diesen Befehl mehrmals eingeben, erstellen Sie eine Liste der Syslog-Server, die Protokollierungsmeldungen empfangen.

no logging Der Befehl löscht den Syslog-Server mit der angegebenen Adresse aus der Liste der Syslogs.

Weitere Aufgaben vor dem Debuggen

1. Richten Sie die Terminal-Emulator-Software (z. B. HyperTerminal) so ein, dass die Debug-Ausgabe in einer Datei erfasst werden kann. Klicken Sie z. B. in HyperTerminal aufTransfer und dann auf Capture Text , und wählen Sie die entsprechenden Optionen aus. Weitere Informationen finden Sie unter Erfassen der Textausgabe von Hyperterminal. Informationen zu anderer Terminal-Emulator-Software finden Sie in der Softwaredokumentation.

2. Millisekunde (ms)-Zeitstempel mit dem folgenden Befehl service timestamps aktivieren:

    router(config)#service timestamps debug datetime msec 
         router(config)#service timestamps log datetime msec
   

Diese Befehle fügen den Debuggern Zeitstempel im Format MMM DD HH:MM:SS hinzu, die Datum und Uhrzeit entsprechend der Systemuhr angeben. Wenn die Systemuhr nicht eingestellt wurde, sind Datum und Uhrzeit mit einem Sternchen (*) gekennzeichnet, um anzuzeigen, dass Datum und Uhrzeit möglicherweise nicht korrekt sind.

Im Allgemeinen ist es ratsam, Millisekunden-Zeitstempel zu konfigurieren, da dies ein hohes Maß an Klarheit bei der Betrachtung von Debug-Ausgaben bietet. Millisekunden-Zeitstempel liefern eine bessere Anzeige des Timings der verschiedenen Debug-Ereignisse relativ zueinander.

Beachten Sie jedoch, dass der Konsolen-Port, wenn viele Meldungen ausgegeben werden, nicht mit dem tatsächlichen Zeitpunkt des Ereignisses korrelieren kann.

Wenn Sie z. B. debug x25 alle auf einem Gerät mit 200 VCs aktivieren und die Ausgabe im Puffer protokolliert wird (mithilfe der no logging console logging buffered Und-Befehle), kann der in der Debug-Ausgabe (im Puffer) angezeigte Zeitstempel nicht der genaue Zeitpunkt sein, zu dem das Paket die Schnittstelle passiert. Verwenden Sie daher keine msec-Zeitstempel, um Leistungsprobleme nachzuweisen, sondern um relative Informationen zum Zeitpunkt des Eintretens von Ereignissen zu erhalten.

So beenden Sie das Debuggen

Um ein Debuggen zu beenden, verwenden Sie no debug allundebug alltheorcommands. Überprüfen Sie, ob die Debugging-Funktionen mit dem Befehlshow debug deaktiviert wurden.

Beachten Sie, dass der no logging console terminal no monitor BefehlSandonly die Ausgabe auf der Konsole, Aux bzw. vty verhindert. Das Debuggen wird nicht gestoppt, sodass Router-Ressourcen verbraucht werden.

Verwenden des Befehls debug ip packet

debug ip packet Der Befehl erzeugt Informationen über Pakete, die vom Router nicht schnell weitergeleitet werden. Da jedoch für jedes Paket eine Ausgabe generiert wird, kann die Ausgabe umfangreich sein und somit dazu führen, dass der Router hängen bleibt. Aus diesem Grund nur unter den strengsten Kontrollen debug ip packet verwenden, wie in diesem Abschnitt beschrieben.

Die beste Möglichkeit, die Ausgabe debug ip packet von einzuschränken, besteht darin, eine Zugriffsliste zu erstellen, die mit dem Debugging verknüpft ist. Nur Pakete, die die Zugriffslistenkriterien erfüllen, können betroffen debug ip packet sein. Diese Zugriffsliste muss nicht auf eine Schnittstelle angewendet werden, sondern wird auf den Debugvorgang angewendet.

Beachten Sie vor der Verwendung debugging ip packet , dass der Router standardmäßig Fast-Switching ausführt oder CEF-Switching durchführen kann, wenn dies konfiguriert ist. Dies bedeutet, dass das Paket nach dem Einsatz dieser Techniken nicht an den Prozessor übermittelt wird, sodass das Debuggen nichts zeigt. Damit dies funktioniert, müssen Sie das Fast-Switching auf dem Router mit no ip route-cache (für Unicast-Pakete) oder no ip mroute-cache (für Multicast-Pakete) deaktivieren. Dies muss auf die Schnittstellen angewendet werden, auf denen der Datenverkehr fließen soll. Überprüfen Sie dies mit show ip route dem Befehl.

Warnungen

• Die Deaktivierung des Fast-Switching auf einem Router, der eine große Anzahl von Paketen verarbeitet, kann dazu führen, dass die CPU-Auslastung in die Höhe schnellt, sodass das Gerät hängen bleibt oder die Verbindung zu den Peers unterbrochen wird.

• Deaktivieren Sie nicht das Fast-Switching auf einem Router, auf dem Multi Protocol Label Switching (MPLS) ausgeführt wird. MPLS wird in Verbindung mit CEF verwendet. Daher kann die Deaktivierung des Fast-Switching auf der Schnittstelle katastrophale Auswirkungen haben.

Betrachten Sie dieses Beispielszenario:

Die auf Router_122 konfigurierte Zugriffsliste lautet:

access-list 105 permit icmp host 10.10.10.2 host 10.1.1.1 access-list 105 permit icmp host 10.1.1.1 host 10.10.10.2  

Diese Zugriffsliste lässt zu, dass jedes Internet Control Message Protocol (ICMP)-Paket vom Host-Router 121 (mit der IP-Adresse 10.10.10.2) den Host-Router 123 (mit der IP-Adresse 10.1.1.1) sowie in die andere Richtung hostet.

Es ist wichtig, dass Sie die Pakete in beide Richtungen zulassen, da der Router andernfalls das zurückgegebene ICMP-Paket verwerfen kann.

Entfernen Sie Fast-Switching auf nur einer Schnittstelle auf router_122. Das bedeutet, dass Sie nur die Debug-Meldungen für die Pakete sehen können, die für diese Schnittstelle bestimmt sind, aus der Perspektive des Cisco IOS, das das Paket abfängt.

Aus den Debugs werden solche Pakete mit "d=" angezeigt. Da Sie Fast Switching auf der anderen Schnittstelle noch nicht deaktiviert haben, ist das Rückgabepaket nicht betroffen debug ip packet . Diese Ausgabe zeigt, wie Sie Fast Switching deaktivieren können:

router_122(config)#interface virtual-template 1 router_122(config-if)#no ip route-cache router_122(config-if)#end 

Sie müssen nun mit der zuvor definierten Zugriffsliste (Zugriffsliste 105) debug ip packet aktivieren.

router_122# debug ip packet  detail 105 IP packet debugging is on (detailed) for access list 105 router_122# 00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0  ! -- ICMP packet from 10.1.1.1 to 10.10.10.2. ! -- This packet is displayed because it matches the ! -- source and destination requirements in access list 105  00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0 00:10:01: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:10:01: ICMP type=0, code=0

Entfernen Sie nun das Fast-Switching auf der anderen Schnittstelle (auf Router_122). Das bedeutet, dass alle Pakete über diese beiden Schnittstellen jetzt paketvermittelt werden (was eine Voraussetzung für debug ip packet )

router_122(config)#interface serial 3/0 router_122(config-if)#no ip route-cache router_122(config-if)#end router_122# 00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=10.1.1.1 (Serial3/0), g=172.16.1.6, len 100, forward 00:11:57: ICMP type=8, code=0  ! -- ICMP packet (echo) from 10.10.10.2 to 10.1.1.1  00:11:57: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:11:57: ICMP type=0, code=0  ! -- ICMP return packet (echo-reply) from 10.1.1.1 to 10.10.10.2  00:11:57: IP: s=10.10.10.2 (Virtual-Access1), d=10.1.1.1 (Serial3/0), g=172.16.1.6, len 100, forward 00:11:57: ICMP type=8, code=0 00:11:57: IP: s=10.1.1.1 (Serial3/0), d=10.10.10.2 (Virtual-Access1), g=10.10.10.2, len 100, forward 00:11:57: ICMP type=0, code=0

Beachten Sie, dass die Ausgabe von debug ip packet keine Pakete anzeigt, die nicht den Kriterien der Zugriffsliste entsprechen.

Weitere Informationen zu diesem Verfahren finden Sie unter Verstehen der Ping- und Traceroute-Befehle.

Weitere Informationen zum Erstellen von Zugriffslisten finden Sie unter Standard-IP-Zugriffslistenprotokollierung.

Bedingt ausgelöste Debugs

Wenn die Funktion für bedingt ausgelöstes Debuggen aktiviert ist, generiert der Router Debugging-Meldungen für Pakete, die in den Router an einer bestimmten Schnittstelle ein- oder ausgehen. Der Router generiert keine Debugging-Ausgabe für Pakete, die über eine andere Schnittstelle ein- oder ausgehen.

Sehen Sie sich eine einfache Implementierung von bedingten Debugging an. Betrachten Sie folgendes Szenario: Der als Nächstes dargestellte Router (Trabol) verfügt über zwei Schnittstellen (seriell 0 und seriell 3), auf denen beide HDLC-Kapselung ausgeführt wird.

Sie können den Befehl debug serial interface normal verwenden, um die auf allen Schnittstellen empfangenen HDLC-Keepalives zu beobachten. Sie können die Keepalives auf beiden Schnittstellen beobachten.

traxbol#debug serial interface Serial network interface debugging is on traxbol# *Mar 8 09:42:34.851: Serial0: HDLC myseq 28, mineseen 28*, yourseen 41, line up  ! -- HDLC keeplaive on interface Serial 0  *Mar 8 09:42:34.855: Serial3: HDLC myseq 26, mineseen 26*, yourseen 27, line up  ! -- HDLC keeplaive on interface Serial 3  *Mar 8 09:42:44.851: Serial0: HDLC myseq 29, mineseen 29*, yourseen 42, line up *Mar 8 09:42:44.855: Serial3: HDLC myseq 27, mineseen 27*, yourseen 28, line up

Aktivieren Sie bedingtes Debuggen für die serielle Schnittstelle 3. Dies bedeutet, dass nur Debug-Meldungen für die serielle Schnittstelle 3 angezeigt werden. Verwenden Sie debug interface <interface_type interface_number >den Befehl.

traxbol#debug interface serial 3 Condition 1 set

Verwenden Sie show debug condition den Befehl, um zu überprüfen, ob das bedingte Debuggen aktiv ist. Beachten Sie, dass eine Bedingung für die serielle Schnittstelle 3 aktiv ist.

traxbol#show debug condition Condition 1: interface Se3 (1 flags triggered) Flags: Se3 traxbol#

Beachten Sie, dass jetzt nur die Fehlerbehebungen für die serielle Schnittstelle 3 angezeigt werden.

*Mar 8 09:43:04.855: Serial3: HDLC myseq 29, mineseen 29*, yourseen 30, line up *Mar 8 09:43:14.855: Serial3: HDLC myseq 30, mineseen 30*, yourseen 31, line up

Verwenden Sie undebug interface <interface_type interface_number> den Befehl, um das bedingte Debuggen zu entfernen. Es wird empfohlen, die Debugs zu deaktivieren (z. B. mit underbug all), bevor Sie den bedingten Trigger entfernen.

Dadurch soll eine Flut von Debugausgaben vermieden werden, wenn die Bedingung entfernt wird.

traxbol#undebug interface serial 3  This condition is the last interface condition set. Removing all conditions can cause a flood of debugging messages to result, unless specific debugging flags are first removed. Proceed with removal? [yes/no]: y Condition 1 has been removed traxbol

Sie können nun beobachten, dass die Fehlersuche sowohl für die serielle Schnittstelle 0 als auch für die serielle Schnittstelle 3 angezeigt wird.

*Mar 8 09:43:34.927: Serial3: HDLC myseq 32, mineseen 32*, yourseen 33, line up *Mar 8 09:43:44.923: Serial0: HDLC myseq 35, mineseen 35*, yourseen 48, line up

In diesem Abschnitt wird die richtige Vorgehensweise zum Beschränken des Debuggens von ATM-Paketen auf eine Subschnittstelle beschrieben:

arielle-nrp2#debug atm packet interface atm 0/0/0.1  !--- Note that you explicitly specify the sub-interface to be used for debugging  ATM packets debugging is on Displaying packets on interface ATM0/0/0.1 only arielle-nrp2# *Dec 21 10:16:51.891: ATM0/0/0.1(O): VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:16:51.891: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 01FE 0000 FF11 61C8 0A30 *Dec 21 10:16:51.891: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 0015 23B7 0000 8000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.891: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:16:51.895: arielle-nrp2#

Wenn Sie versuchen, atm debugging auf allen Schnittstellen (mit einer entsprechenden Bedingung) zu aktivieren, kann der Router hängen bleiben, wenn er über eine große Anzahl von ATM-Subschnittstellen verfügt. Ein Beispiel für die falsche Methode zum ATM-Debuggen wird angezeigt.

In diesem Fall können Sie sehen, dass eine Bedingung angewendet wird, aber Sie sehen auch, dass dies keine Auswirkungen hat. Sie können das Paket immer noch von der anderen Schnittstelle aus sehen. In diesem Übungsszenario haben Sie nur zwei Schnittstellen und sehr wenig Datenverkehr.

Wenn die Anzahl der Schnittstellen hoch ist, ist die Debug-Ausgabe für alle Schnittstellen extrem hoch und kann dazu führen, dass der Router hängen bleibt.

arielle-nrp2#show debugging condition Condition 1: interface AT0/0/0.1 (1 flags triggered) Flags: AT0/0/0.1  ! -- A condition for a specific interface.  arielle-nrp2#debug atm packet ATM packets debugging is on Displaying all ATM packets arielle-nrp2# *Dec 21 10:22:06.727: ATM0/0/0.2(O):  ! -- You see debugs from interface ATM0/0/0/.2, even though the condition ! -- specified ONLY AT0/0/0.1  VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:06.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:06.727: 0002 000F 0000 *Dec 21 10:22:06.727: un a *Dec 21 10:22:08.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:08.727: 0000 0000 0180 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:08.727: 0002 000F 0000 *Dec 21 10:22:08.727: ll *Dec 21 10:22:10.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:10.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:10.727: 0002 000F 0000 *Dec 21 10:22:10.727: *Dec 21 10:22:12.727: ATM0/0/0.2(O): VCD:0x2 VPI:0x5 VCI:0x37 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:000E Length:0x2F *Dec 21 10:22:12.727: 0000 0000 0080 0000 107B B9BD C400 0000 0080 0000 107B B9BD C480 0800 0014 *Dec 21 10:22:12.727: 0002 000F 0000 *Dec 21 10:22:12.727: *Dec 21 10:22:13.931: ATM0/0/0.1(O):  !--- You also see debugs for interface ATM0/0/0.1 as you wanted.  VCD:0x1 VPI:0x1 VCI:0x21 DM:0x100 SAP:AAAA CTL:03 OUI:0080C2 TYPE:0007 Length:0x278 *Dec 21 10:22:13.931: 0000 FFFF FFFF FFFF 0010 7BB9 BDC4 0800 4500 025C 027F 0000 FF11 6147 0A30 *Dec 21 10:22:13.931: 4B9B FFFF FFFF 0044 0043 0248 0000 0101 0600 001A 4481 0000 8000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0010 7BB9 BDC3 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.931: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 *Dec 21 10:22:13.935: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

Zugehörige Informationen

• Unterstützung von Einwahl- und Zugriffstechnologie
• Technischer Support und Downloads von Cisco