디버그 명령에 대한 중요 정보

소개

이 페이지에서는 Cisco IOS^® 플랫폼에서 사용할 수 있는 디버깅 사용에 대한 몇 가지 일반적인 지침과 를 올바르게 사용하기 위한 예를 제공합니다. debug ip packet 명령 및 조건부 디버깅.

참고: 이 문서에서는 특정 디버그 명령 및 출력을 사용하고 해석하는 방법에 대해 설명하지 않습니다. 특정 항목에 대한 자세한 내용은 해당 Cisco 디버그 명령 참조 설명서를 참조하십시오. debug 명령을 입력합니다.

출력 원본 debug privileged EXEC 명령은 일반적으로 프로토콜 상태 및 네트워크 활동과 관련된 다양한 인터네트워킹 이벤트를 포함하는 진단 정보를 제공합니다.

사전 요구 사항

요구 사항

다음 주제에 대한 지식을 보유하고 있으면 유용합니다.

• 콘솔, aux 및 vty 포트를 사용하여 라우터에 연결

• 일반 Cisco IOS 구성 문제

• Cisco IOS 디버그 출력 해석

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.

경고

Use debug 명령을 주의하십시오. 일반적으로 이러한 명령은 특정 문제를 해결할 때 라우터 기술 지원 담당자의 지시에 따라서만 사용하는 것이 좋습니다.

디버깅을 활성화하면 인터네트워크에서 로드가 많은 경우 라우터의 작동을 방해할 수 있습니다. 따라서 로깅이 활성화된 경우 콘솔 포트가 로그 메시지로 오버로드되는 즉시 액세스 서버가 간헐적으로 중단될 수 있습니다.

시작하기 전에 debug 이 명령을 사용하면 이 명령이 생성되는 출력과 이 작업에 걸리는 시간을 항상 고려하십시오. 예를 들어 기본 속도 인터페이스(BRI)가 하나인 라우터가 있는 경우 debug isdn q931 시스템을 손상시키지 않을 것입니다. 그러나 전체 E1 컨피그레이션을 사용하여 AS5800에서 동일한 디버깅을 수행하면 너무 많은 입력이 생성되어 응답이 중단되고 응답하지 않을 수 있습니다.

디버깅하기 전에 show processes cpu 명령을 실행합니다. 디버그를 시작하기 전에 사용 가능한 CPU가 충분한지 확인합니다. 높은 CPU 로드 처리 방법에 대한 자세한 내용은 Cisco 라우터의 High CPU Utilization 문제 해결을 참조하십시오. 예를 들어, 브리징을 수행하는 ATM 인터페이스가 있는 Cisco 7200 라우터가 있는 경우, 구성된 하위 인터페이스의 양에 따라 라우터를 다시 시작하면 많은 CPU를 사용할 수 있습니다. 이유는 각 VC(Virtual Circuit)에 대해 BPDU(Bridge Protocol Data Unit) 패킷을 생성해야 하기 때문입니다. 이러한 중요한 시간 동안 디버깅을 시작하면 CPU 사용률이 크게 증가하여 중단 또는 네트워크 연결이 손실될 수 있습니다.

참고: 디버그가 실행 중일 때는 일반적으로 라우터 프롬프트가 표시되지 않습니다. 특히 디버그가 많이 사용되는 경우 그렇습니다. 그러나 대부분의 경우 디버그를 중지하기 위해 no debug all 또는 undebug all 명령을 사용할 수 있습니다. 디버그를 안전하게 사용하는 방법에 대한 자세한 내용은 디버그 출력 가져오기 섹션을 참조하십시오.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

디버깅 전

위에 언급된 포인트 외에도 디버그가 플랫폼의 안정성에 미치는 영향을 이해해야 합니다. 라우터에서 어떤 인터페이스에 연결해야 할지 고려해야 합니다. 이 섹션에는 몇 가지 지침이 있습니다.

디버그 출력 가져오기

라우터는 콘솔, aux 및 vty 포트를 비롯한 다양한 인터페이스에 대한 디버그 출력을 표시할 수 있습니다. 라우터는 외부 unix syslog 서버에 내부 버퍼에 메시지를 로깅할 수도 있습니다. 각 방법에 대한 지침 및 주의 사항은 다음과 같습니다.

콘솔 포트

콘솔에 연결되어 있는 경우 일반적인 컨피그레이션에서 추가 작업을 수행할 필요가 없습니다. 디버그 출력이 자동으로 표시됩니다. 하지만 logging console level 원하는 대로 설정되며 로깅은 no logging console 명령을 실행합니다.

경고: 라우터의 콘솔 포트에 대한 디버깅을 너무 많이 수행하면 해당 포트가 정지될 수 있습니다. 이는 라우터가 다른 라우터 기능보다 먼저 콘솔 출력의 우선 순위를 자동으로 지정하기 때문입니다. 따라서 라우터가 콘솔 포트에 대한 대규모 디버그 출력을 처리하는 경우 연결이 끊길 수 있습니다. 따라서 디버그 출력이 과도하게 발생하는 경우 vty(telnet) 포트 또는 로그 버퍼를 사용하여 디버그를 가져옵니다. 자세한 내용은 아래에 나와 있습니다.

참고: 기본적으로 로깅은 콘솔 포트에서 활성화됩니다. 따라서 실제로 다른 포트 또는 메서드(예: Aux, vty 또는 buffer)를 사용하여 출력을 캡처하는 경우에도 콘솔 포트는 항상 디버그 출력을 처리합니다. 따라서 정상적인 작동 조건에서 항상 no logging console 명령을 활성화하고 다른 방법을 사용하여 디버그를 캡처하는 것이 좋습니다. 콘솔을 사용해야 하는 경우에는 로깅 콘솔을 일시적으로 다시 켜십시오.

보조 포트

보조 포트를 통해 연결된 경우 terminal monitor 명령을 실행합니다. 또한 no logging on 라우터에서 명령이 활성화되지 않았습니다.

참고: Aux 포트를 사용하여 라우터를 모니터링하는 경우 라우터가 재부팅될 때 Aux 포트가 부팅 시퀀스 출력을 표시하지 않는다는 점에 유의하십시오. 부팅 시퀀스를 보려면 콘솔 포트에 연결합니다.

VTY 포트

보조 포트 또는 텔넷을 통해 연결된 경우 terminal monitor 명령을 실행합니다. 또한 no logging on 명령이 사용되지 않았습니다.

내부 버퍼에 메시지 로깅

기본 로깅 장치는 콘솔입니다. 달리 지정되지 않는 한 모든 메시지가 콘솔에 표시됩니다.

내부 버퍼에 메시지를 로깅하려면 logging buffered router configuration 명령. 이 명령의 전체 구문은 다음과 같습니다.

logging buffered
no logging buffered

더 logging buffered 명령은 로그 메시지를 콘솔에 쓰는 대신 내부 버퍼에 복사합니다. 버퍼가 원형이므로 새 메시지가 이전 메시지를 덮어씁니다. 버퍼에 로그인한 메시지를 표시하려면 특권 EXEC 명령을 사용합니다 show logging. 표시되는 첫 번째 메시지는 버퍼에서 가장 오래된 메시지입니다. 버퍼의 크기와 로깅할 메시지의 심각도 수준을 지정할 수 있습니다.

팁: 버퍼 크기를 입력하기 전에 상자에 충분한 메모리를 사용할 수 있는지 확인합니다. Cisco IOS 사용 show proc mem 명령을 실행하여 사용 가능한 메모리를 확인합니다.

더 no logging buffered 명령은 버퍼 사용을 취소하고 콘솔(기본값)에 메시지를 씁니다.

UNIX Syslog 서버에 메시지 로깅

syslog 서버 호스트에 메시지를 로깅하려면 logging router configuration 명령을 사용합니다. 이 명령의 전체 구문은 다음과 같습니다.

logging  
     
no logging  
     

더 logging 이 명령은 로깅 메시지를 수신할 syslog 서버 호스트를 식별합니다. < ip-address> 인수는 호스트의 IP 주소입니다. 이 명령을 두 번 이상 실행하면 로깅 메시지를 수신하는 syslog 서버 목록을 작성합니다.

더 no logging 이 명령은 syslogs 목록에서 지정된 주소가 있는 syslog 서버를 삭제합니다.

기타 사전 디버그 작업

1. 디버그 출력을 파일로 캡처할 수 있도록 터미널 에뮬레이터 소프트웨어(예: HyperTerminal)를 설정합니다. 예를 들어, 하이퍼터미널에서 Transfer을 클릭한 다음 Capture Text을 누르고 적절한 옵션을 선택합니다. 자세한 내용은 하이퍼터미널에서 텍스트 출력 캡처를 참조하십시오. 다른 터미널 에뮬레이터 소프트웨어는 소프트웨어 설명서를 참조하십시오.

2. 를 사용하여 밀리초(msec) 타임스탬프를 활성화합니다. service timestamps 명령을 사용합니다:

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

이러한 명령은 시스템 클럭에 따라 날짜 및 시간을 나타내는 MMM DD HH:MM:SS 형식의 디버깅에 타임스탬프를 추가합니다. 시스템 시계가 설정되지 않은 경우 날짜와 시간 앞에 별표(*)가 표시되어 날짜와 시간이 정확하지 않을 수 있음을 나타냅니다.

디버그 출력을 볼 때 높은 수준의 명확성을 제공하므로 일반적으로 밀리초 타임스탬프를 구성하는 것이 좋습니다. 밀리초 타임스탬프는 서로 관련된 다양한 디버깅 이벤트의 타이밍을 더 잘 나타냅니다. 그러나 콘솔 포트가 많은 메시지를 출력할 때 실제 이벤트 타이밍과 상관관계가 없을 수 있습니다. 예를 들어, debug x25 200개의 VC가 있는 상자에 있고 출력이 버퍼에 로깅됩니다. no logging console 및 logging buffered 명령), 디버그 출력에 표시되는 타임스탬프(버퍼 내)는 패킷이 인터페이스를 통과하는 정확한 시간이 아닐 수 있습니다. 따라서 msec 타임스탬프를 사용하여 성능 문제를 입증하지 말고 이벤트가 발생할 때 관련 정보를 얻습니다.

디버깅 중지하기

디버깅을 중지하려면 no debug all 또는 undebug all 명령을 입력합니다. 명령을 사용하여 디버그가 꺼져 있는지 확인합니다. show debug.

이 명령은 no logging console 및 terminal no monitor 콘솔, Aux 또는 vty의 출력만 방지합니다. 디버깅을 중지하지 않으므로 라우터 리소스가 모두 사용됩니다.

debug ip packet 명령 사용

더 debug ip packet 이 명령은 라우터에서 빠르게 전환되지 않는 패킷에 대한 정보를 생성합니다. 그러나 모든 패킷에 대해 출력을 생성하기 때문에 출력이 광범위할 수 있으므로 라우터가 정지됩니다. 따라서 debug ip packet 이 섹션에 설명된 대로 가장 엄격한 컨트롤 아래에 있습니다.

출력을 제한하는 가장 좋은 방법 debug ip packet 디버그에 연결된 access-list를 만드는 것입니다. 액세스 목록 기준과 일치하는 패킷만 적용 debug ip packet. 이 access-list는 어떤 인터페이스에도 적용할 필요는 없지만 디버그 작업에 적용됩니다.

사용 전 debugging ip packet라우터가 기본적으로 고속 스위칭을 수행하고 있거나, CEF 스위칭을 수행하도록 구성된 경우 CEF 스위칭을 수행할 수 있습니다. 즉, 이러한 기술이 구현되면 패킷이 프로세서에 제공되지 않으므로 디버깅에 아무것도 표시되지 않습니다. 이 작업을 수행하려면 no ip route-cache (유니캐스트 패킷의 경우) 또는 no ip mroute-cache (멀티캐스트 패킷의 경우) 이는 트래픽이 흐름되어야 하는 인터페이스에 적용해야 합니다. 다음을 사용하여 확인 show ip route 명령을 실행합니다.

경고:

• 많은 수의 패킷을 처리하는 라우터에서 고속 스위칭을 비활성화하면 CPU 사용률이 급증하여 상자가 중단되거나 피어에 대한 연결이 끊어집니다.

• MPLS(Multi Protocol Label Switching)를 실행하는 라우터에서 고속 스위칭을 비활성화하지 마십시오. MPLS는 CEF와 함께 사용됩니다. 따라서 인터페이스에서 빠른 스위칭을 비활성화하면 심각한 영향을 미칠 수 있습니다.

샘플 시나리오를 살펴보겠습니다.

router_122에 구성된 액세스 목록은 다음과 같습니다.

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

이 액세스 목록은 호스트 router_121(IP 주소 10.10.10.2 포함)에서 호스트 router_123(IP 주소 13.1.1.1 포함)까지의 모든 ICMP(Internet Control Message Protocol) 패킷과 다른 방향을 허용합니다. 패킷은 어느 방향으로든 허용하는 것이 중요합니다. 그렇지 않으면 라우터가 반환 ICMP 패킷을 삭제할 수 있습니다.

router_122의 한 인터페이스에서만 고속 스위칭을 제거합니다. 즉, IOS에서 패킷을 가로채는 관점에서 볼 수 있듯이 해당 인터페이스로 향하는 패킷의 디버그만 볼 수 있습니다. 디버그에서 이러한 패킷은 "d="와 함께 나타납니다. 다른 인터페이스에서 빠른 스위칭을 아직 해제하지 않았으므로 반환 패킷은 debug ip packet. 이 출력은 빠른 스위칭을 비활성화하는 방법을 보여줍니다.

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

이제 활성화해야 합니다. debug ip packet 액세스 목록 정의 이전(access-list 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=13.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 13.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=13.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=13.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

이제 다른 인터페이스(router_122)에서 고속 스위칭을 제거하겠습니다. 즉, 두 인터페이스의 모든 패킷이 이제 패킷 스위치로 전환됩니다(이는 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=13.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 13.1.1.1

00:11:57: IP: s=13.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 13.1.1.1 to 10.10.10.2

00:11:57:  IP: s=10.10.10.2 (Virtual-Access1), d=13.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=13.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

debug ip packet 출력에는 access-list 기준과 일치하지 않는 패킷이 표시되지 않습니다. 이 절차에 대한 자세한 내용은 Ping 및 Traceroute 명령 이해를 참조하십시오.

액세스 목록을 작성하는 방법에 대한 자세한 내용은 표준 IP 액세스 목록 로깅을 참조하십시오.

조건부로 트리거된 디버그

조건부로 트리거된 디버깅 기능이 활성화되면 라우터는 지정된 인터페이스에서 라우터를 들어오거나 나가는 패킷에 대한 디버깅 메시지를 생성합니다. 라우터는 다른 인터페이스를 통해 들어오거나 나가는 패킷에 대한 디버깅 출력을 생성하지 않습니다. 

조건부 디버깅의 간단한 구현을 살펴봅니다. 다음 시나리오를 고려해 보십시오. 아래 표시된 라우터(trabol)에는 HDLC 캡슐화를 실행하는 두 개의 인터페이스(직렬 0 및 직렬 3)가 있습니다.

일반적인 debug serial interface 명령을 사용하여 모든 인터페이스에서 수신된 HDLC keepalive를 확인합니다. 두 인터페이스에서 keepalive를 관찰할 수 있습니다.

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

인터페이스 직렬 3에 대해 조건부 디버깅을 사용합니다. 즉, 인터페이스 직렬 3에 대한 디버깅만 표시됩니다. 사용 debug interface <interface_type interface_number> 명령을 실행합니다.

traxbol#debug interface serial 3 
Condition 1 set

사용 show debug condition 명령 - 조건 디버그가 활성 상태인지 확인합니다. 인터페이스 직렬 3에 대한 조건이 활성 상태입니다.

traxbol#show debug condition 

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

이제 인터페이스 직렬 3의 디버그만 표시됩니다.

*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

사용 undebug interface <interface_type interface_number> 명령을 사용하여 조건부 디버그를 제거합니다. 조건 트리거를 제거하기 전에 디버깅(예: undebug all 사용)을 끄는 것이 좋습니다. 이는 조건이 제거될 때 디버그 출력이 넘쳐나는 것을 방지하기 위한 것입니다.

traxbol#undebug interface serial 3 
This condition is the last interface condition set. 
Removing all conditions may 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

이제 인터페이스 직렬 0과 직렬 3에 대한 디버그가 표시되는지 확인할 수 있습니다.

*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

경고: 일부 디버깅 작업은 자체적으로 조건적입니다. 예를 들면 atm 디버깅입니다. ATM 디버깅을 사용하면 모든 atm 인터페이스에서 디버그를 활성화하고 조건을 지정하는 대신 디버그를 사용할 인터페이스를 명시적으로 지정해야 합니다.

이 섹션에서는 ATM 패킷 디버깅을 하나의 하위 인터페이스로 제한하는 올바른 방법을 보여줍니다.

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#

활성화하려는 경우 atm debugging 모든 인터페이스(적용된 조건 포함)에서 라우터가 많은 ATM 하위 인터페이스가 있는 경우 정지될 수 있습니다. 잘못된 atm 디버깅 방법의 예가 표시됩니다.

이 경우 조건이 적용되었음을 확인할 수 있지만 효과가 없음을 확인할 수도 있습니다. 다른 인터페이스에서 패킷을 볼 수 있습니다. 이 실습 시나리오에서는 인터페이스가 2개이고 트래픽이 매우 적습니다. 인터페이스 수가 많으면 모든 인터페이스의 디버그 출력이 매우 높으므로 라우터가 정지될 수 있습니다.

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

관련 정보

• 전화 접속 및 액세스 기술 지원
• 기술 지원 및 문서 − Cisco Systems