Wichtige Informationen zu Debugbefehlen verstehen

Einleitung

In diesem Dokument werden allgemeine Richtlinien zur Verwendung debug Befehle, einschließlich  debug ip packet auf Cisco IOS®-Plattformen zur Verfügung.

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-Debugergebnissen

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.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

Auf dieser Seite finden Sie einige allgemeine Richtlinien zur Verwendung der auf Cisco IOS-Plattformen verfügbaren Fehlerbehebungsfunktionen sowie Beispiele für die ordnungsgemäße Verwendung der debug ip packet und bedingtes Debuggen.

Die Ausgabe von debug privilegierte EXEC-Befehle stellen Diagnoseinformationen bereit, die eine Vielzahl von Netzwerkereignissen im Zusammenhang mit dem Protokollstatus und der Netzwerkaktivität im Allgemeinen umfassen.

Warnungen

Nutzung debug -Befehlen mit Bedacht. 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 ein debug -Befehls immer die Ausgabe berücksichtigen, die dieser Befehl generieren kann, und wie viel Zeit dies in Anspruch nehmen kann. Wenn Sie beispielsweise einen Router mit einer BRI (Basic Rate Interface) verwenden, debug isdn q931 schadet dem System wahrscheinlich nicht. Aber das gleiche Debuggen auf einem AS5800 mit voller E1-Konfiguration kann wahrscheinlich so viel Input generieren, dass er hängen bleibt und nicht mehr reagiert.

Vor dem Debuggen sollten Sie die CPU-Auslastung mit dem show processes cpu aus. 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 ist wie gewünscht eingestellt, und dass die Protokollierung nicht mit dem no logging console aus.

AUX-Port

Wenn Sie über einen Hilfsport verbunden sind, geben Sie terminal monitor aus. Stellen Sie außerdem sicher, dass no logging on auf dem Router nicht aktiviert wurde.

VTY-Ports

Wenn Sie über einen Hilfsport oder Telnet verbunden sind, geben Sie terminal monitor aus. Stellen Sie außerdem sicher, dass no logging on wurde nicht verwendet.

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 logging buffered Router-Konfigurationsbefehl. Dies ist die vollständige Syntax dieses Befehls:

logging buffered
no logging buffered

Die Fehlermeldung logging buffered 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 privilegierter EXEC-Modus. show logging . 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.

Die Fehlermeldung no logging buffered -Befehl die Verwendung des Puffers abbricht und Meldungen in die Konsole schreibt (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  
     
no logging  
     

Die Fehlermeldungloggingidentifiziert 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.

Die Fehlermeldung no logging 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 beispielsweise in HyperTerminal aufTransfer, und klicken Sie 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 service timestamps command:

    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 beispielsweise debug x25 alles auf einem Rechner mit 200 VCs und die Ausgabe wird im Puffer protokolliert (mit dem no logging console und logging buffered Befehlen), kann der in der Debug-Ausgabe (im Puffer) angezeigte Zeitstempel nicht die genaue Zeit sein, zu der 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 Debugging zu beenden, verwenden Sie denno debug allOderundebug all-Befehlen. Vergewissern Sie sich, dass die Debugging-Funktionen mit dem Befehlshow debug.

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

Verwenden des Befehls debug ip packet

Die Fehlermeldung debug ip packet erzeugt Informationen zu Paketen, 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 verwenden Sie nur debug ip packet unter den strengsten Kontrollen, wie in diesem Abschnitt beschrieben.

Die beste Möglichkeit, die Ausgabe von einzuschränken debug ip packet ist das Erstellen einer Zugriffsliste, die mit dem Debugging verknüpft ist. Nur Pakete, die die Zugriffslistenkriterien erfüllen, können folgenden Anforderungen unterliegen: debug ip packet . Diese Zugriffsliste muss nicht auf eine Schnittstelle angewendet werden, sondern wird auf den Debugvorgang angewendet.

Vor der Verwendung debugging ip packet Beachten Sie, 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 deaktivieren mit no ip route-cache (für Unicast-Pakete) oder no ip mroute-cache (für Multicast-Pakete). Dies muss auf die Schnittstellen angewendet werden, auf denen der Datenverkehr fließen soll. Überprüfen Sie dies mit dem show ip route aus.

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, unterliegt das Rückgabepaket nicht den 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 aktivieren debug ip packet mit der zuvor definierten Zugriffsliste (Zugriffsliste 105).

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 die normale debug serial interface , 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 >aus.

traxbol#debug interface serial 3 
Condition 1 set

Verwenden Sie show debug condition , 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> , 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 an allen Schnittstellen (bei entsprechender Bedingung) 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