Ping 및 Traceroute 명령 이해

다운로드 옵션

  • PDF     (386.1 KB)
    다양한 디바이스에서 Adobe Reader로 보기
  • ePub     (120.9 KB)
    iPhone, iPad, Android, Sony Reader 또는 Windows Phone의 다양한 앱에서 보기
  • Mobi (Kindle)     (263.7 KB)
    Kindle 디바이스에서 보기 또는 다양한 디바이스의 Kindle 앱에서 보기
업데이트:2022년 10월 4일
문서 ID:12778

편견 없는 언어

본 제품에 대한 문서 세트는 편견 없는 언어를 사용하기 위해 노력합니다. 본 설명서 세트의 목적상, 편견 없는 언어는 나이, 장애, 성별, 인종 정체성, 민족 정체성, 성적 지향성, 사회 경제적 지위 및 교차성에 기초한 차별을 의미하지 않는 언어로 정의됩니다. 제품 소프트웨어의 사용자 인터페이스에서 하드코딩된 언어, RFP 설명서에 기초한 언어 또는 참조된 서드파티 제품에서 사용하는 언어로 인해 설명서에 예외가 있을 수 있습니다. 시스코에서 어떤 방식으로 포용적인 언어를 사용하고 있는지 자세히 알아보세요.

이 번역에 관하여

Cisco는 전 세계 사용자에게 다양한 언어로 지원 콘텐츠를 제공하기 위해 기계 번역 기술과 수작업 번역을 병행하여 이 문서를 번역했습니다. 아무리 품질이 높은 기계 번역이라도 전문 번역가의 번역 결과물만큼 정확하지는 않습니다. Cisco Systems, Inc.는 이 같은 번역에 대해 어떠한 책임도 지지 않으며 항상 원본 영문 문서(링크 제공됨)를 참조할 것을 권장합니다.

    소개

    이 문서에서는 Cisco 라우터에서 ping 및 traceroute 명령의 사용을 설명합니다.

    사전 요구 사항

    요구 사항

    이 문서에 대한 특정 요건이 없습니다.

    사용되는 구성 요소

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

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

    표기 규칙

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

    배경 정보

    참고:프로덕션 라우터에서 사용되는 debug 명령은 심각한 문제를 야기할 수 있습니다. debug 명령을 실행하기 전에 debug 명령 사용 섹션을 읽어보십시오.

    이 문서에서는 이 기본 설정을 이 문서의 예시로 사용합니다.

    Basic Configuration of IPs and RoutersIP 및 라우터의 기본 설정

    ping 명령

    ping 명령은 디바이스의 접근성 문제 해결에 흔히 사용되는 방법입니다. 일련의 ICMP(Internet Control Message Protocol) 에코 메시지를 사용하여 다음을 확인합니다.

    • 원격 호스트의 활성 또는 비활성 여부.

    • 호스트와의 통신에 사용되는 왕복 지연.

    • 패킷 손실.

    ping 명령은 먼저 어떤 주소에 에코 요청 패킷을 보낸 다음 회신이 올 때까지 기다립니다. 다음과 같은 경우에만 ping이 성공합니다.

    • 에코 요청이 대상에 도달하는 경우

    • 대상이 시간 초과라는 미리 결정된 시간 내에 소스에 대한 에코 응답을 다시 가져올 수 있는 경우 이 시간 제한의 기본값은 Cisco 라우터에서 2초입니다.

    ping 패킷의 TTL 값은 변경할 수 없습니다.

    다음 코드 예시는 debug ip packet detail 명령이 활성화된 후의 ping 명령을 보여줍니다.

    경고: 프로덕션 라우터에서 debug ip packet detail 명령이 사용되면 CPU 사용률이 높아질 수 있습니다. 이로 인해 심각한 성능 저하 또는 네트워크 중단이 발생할 수 있습니다.

    Router1#debug ip packet detail 
IP packet debugging is on (detailed)

Router1#ping 172.16.0.12 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/8 ms 

Router1# 
Jan 20 15:54:47.487: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, 
  sending
Jan 20 15:54:47.491: ICMP type=8, code=0

!--- This is the ICMP packet 172.16.12.1 sent to 172.16.0.12. 
    !--- ICMP type=8 corresponds to the echo message. 
    
Jan 20 15:54:47.523: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, 
  rcvd 3
Jan 20 15:54:47.527: ICMP type=0, code=0

!--- This is the answer we get from 172.16.0.12. !--- ICMP type=0 corresponds to the echo reply message. 
    !--- By default, the repeat count is five times, so there will be five 
    !--- echo requests, and five echo replies.

    가능한 ICMP 유형 값

    ICMP 유형 리터럴
    0 echo-reply
    3 대상 연결 불가 코드 0 = 네트워크 연결 불가 1 = 호스트 연결 불가 2 = 프로토콜 연결 불가 3 = 포트 연결 불가 4 = 단편화 필요 및 DF 집합 5 = 소스 경로 실패
    4 source-quench
    5 redirect code 0 = redirect datagrams for the network 1 = redirect datagrams for the host 2 = redirect datagrams for the type of service and network 3 = redirect datagrams for the type of service and host
    6 alternate-address
    8 echo
    9 router-advertisement
    10 router-solicitation
    11 time-exceeded code 0 = time to live exceeded in transit 1 = fragment reassembly time exceeded
    12 parameter-problem
    13 timestamp-request
    14 timestamp-reply
    15 information-request
    16 information-reply
    17 mask-request
    18 mask-reply
    31 conversion-error
    32 mobile-redirect

    ping 기능의 가능한 출력 문자

    문자 설명
    ! 각 느낌표는 회신 수신을 나타냅니다.
    . 각 마침표는 네트워크 서버에서 회신을 기다릴 때 시간을 초과했음을 나타냅니다.
    U 대상에 연결할 수 없는 오류 PDU가 수신되었습니다.
    Q 소스 억제(대상이 너무 많이 사용 중임)
    M 프래그먼트 불가.
    ? 알 수 없는 패킷 유형.
    & 패킷 수명 초과.

    Ping할 수 없음

    IP 주소로 ping할 수 없는 경우 이 섹션에 나열된 원인을 고려해 보십시오.

    라우터 문제

    다음은 성공적이지 않은 ping 시도와 문제 확인 및 문제 해결을 위한 조치의 예입니다. 이 예시는 다음 네트워크 토폴로지 다이어그램과 함께 표시됩니다.

    Router Issues라우터 문제


    Router1#     
! 
interface Serial0 
ip address 172.16.12.1 255.255.255.0 
no fair-queue 
clockrate 64000 
! 

Router2# 
! 
interface Serial0 
ip address 10.0.2.23 255.255.255.0 
no fair-queue 
clockrate 64000 
! 
interface Serial1 
ip address 172.16.0.12 255.255.255.0 
! 
  

Router3# 
! 
interface Serial0 
ip address 172.16.3.34 255.255.255.0 
no fair-queue 
! 
interface Serial1 
ip address 10.0.3.23 255.255.255.0 
! 

Router4# 
! 
interface Serial0 
ip address 172.16.4.34 255.255.255.0 
no fair-queue 
clockrate 64000 
!

    Router1에서 Router4로 ping을 시도합니다.

    Router1#ping 172.16.4.34 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: 
..... 
Success rate is 0 percent (0/5)

    결과:

    Router1#debug ip packet
IP packet debugging is on

    경고: 프로덕션 라우터에서 debug ip packet 명령이 사용되면 CPU 사용률이 높아질 수 있습니다. 이로 인해 심각한 성능 저하 또는 네트워크 중단이 발생할 수 있습니다. 

    Router1#ping 172.16.4.34 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: 

Jan 20 16:00:25.603: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable.
Jan 20 16:00:27.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable.
Jan 20 16:00:29.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable.
Jan 20 16:00:31.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable.
Jan 20 16:00:33.599: IP: s=172.16.12.1 (local), d=172.16.4.34, len 100, unroutable.
Success rate is 0 percent (0/5)

    Router1에서는 라우팅 프로토콜이 실행되고 있지 않으므로 패킷을 전송할 위치를 알 수 없어 "unrouteable" 메시지가 표시됩니다.

    Router1에 정적 경로를 추가합니다.

    Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z. 
Router1(config)#ip route 0.0.0.0 0.0.0.0 Serial0

    결과:

    Router1#debug ip packet detail
IP packet debugging is on (detailed)

Router1#ping 172.16.4.34 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: 
U.U.U 
Success rate is 0 percent (0/5) 

Jan 20 16:05:30.659: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, 
  sending
Jan 20 16:05:30.663:     ICMP type=8, code=0
Jan 20 16:05:30.691: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, 
  rcvd 3
Jan 20 16:05:30.695:     ICMP type=3, code=1
Jan 20 16:05:30.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, 
  sending
Jan 20 16:05:30.703:     ICMP type=8, code=0
Jan 20 16:05:32.699: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, 
  sending
Jan 20 16:05:32.703:     ICMP type=8, code=0
Jan 20 16:05:32.731: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56, 
  rcvd 3
Jan 20 16:05:32.735:     ICMP type=3, code=1
Jan 20 16:05:32.739: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100, 
  sending
Jan 20 16:05:32.743:     ICMP type=8, code=0

    Router2의 문제를 살펴봅니다.

    Router2#debug ip packet detail
IP packet debugging is on (detailed)

Router2# 
Jan 20 16:10:41.907: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable
Jan 20 16:10:41.911:     ICMP type=8, code=0
Jan 20 16:10:41.915: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending
Jan 20 16:10:41.919:     ICMP type=3, code=1
Jan 20 16:10:41.947: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable
Jan 20 16:10:41.951:     ICMP type=8, code=0
Jan 20 16:10:43.943: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable
Jan 20 16:10:43.947:     ICMP type=8, code=0
Jan 20 16:10:43.951: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending
Jan 20 16:10:43.955:     ICMP type=3, code=1
Jan 20 16:10:43.983: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable
Jan 20 16:10:43.987:     ICMP type=8, code=0
Jan 20 16:10:45.979: IP: s=172.16.12.1 (Serial1), d=172.16.4.34, len 100, unroutable
Jan 20 16:10:45.983:     ICMP type=8, code=0
Jan 20 16:10:45.987: IP: s=172.16.0.12 (local), d=172.16.12.1 (Serial1), len 56, sending
Jan 20 16:10:45.991:     ICMP type=3, code=1

    Router1이 Router2에 패킷을 올바르게 전송했지만 Router2가 주소 172.16.4.34에 액세스하는 방법을 모릅니다. Router2가 Router1에 "unreachable ICMP" 메시지를 다시 전송합니다.

    Router2 및 Router3에서 RIP(Routing Information Protocol)를 활성화합니다.

    Router2# 
router rip 
 network 172.16.0.7 
 network 10.0.7.23 
Router3# 
router rip 
 network 10.0.7.23 
 network 172.16.0.34

    결과:

    Router1#debug ip packet
IP packet debugging is on

Router1#ping 172.16.4.34 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: 

Jan 20 16:16:13.367: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending.
Jan 20 16:16:15.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending.
Jan 20 16:16:17.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending.
Jan 20 16:16:19.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending.
Jan 20 16:16:21.363: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending.
Success rate is 0 percent (0/5)

    Router1이 Router4에 패킷을 전송하지만 Router4가 응답을 전송하지 않습니다.

    Router4에서 발생 가능한 문제:

    Router4#debug ip packet
IP packet debugging is on

Router4# 
Jan 20 16:18:45.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, 
  rcvd 3
Jan 20 16:18:45.911: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable
Jan 20 16:18:47.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, 
  rcvd 3
Jan 20 16:18:47.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable
Jan 20 16:18:49.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, 
  rcvd 3
Jan 20 16:18:49.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable
Jan 20 16:18:51.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, 
  rcvd 3
Jan 20 16:18:51.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable
Jan 20 16:18:53.903: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100, 
  rcvd 3
Jan 20 16:18:53.907: IP: s=172.16.4.34 (local), d=172.16.12.1, len 100, unroutable

    Router 4는 ICMP 패킷을 수신하고, 172.16.12.1에 응답하려고 시도하지만 이 네트워크에 대한 경로가 없으므로 실패합니다.

    이제 Router4에 정적 경로를 추가합니다.

    Router4(config)#ip route 0.0.0.0 0.0.0.0 Serial0

    이제는 양쪽에서 서로 액세스할 수 있습니다.

    Router1#ping 172.16.4.34 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/35/36 ms

    인터페이스 중단

    인터페이스가 더 이상 작동하지 않는 상황입니다. 다음 예에서는 Router1에서 Router4를 ping하려고 시도합니다.

    Router1#ping 172.16.4.34 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: 
U.U.U 
Success rate is 0 percent (0/5)

    라우팅이 정확하므로 단계별 문제 해결을 수행합니다. Router2를 ping합니다.

    Router1#ping 172.16.0.12 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

    이전 예에서 문제는 Router2와 Router3 사이에 있었습니다. Router3의 직렬 인터페이스가 종료되었을 가능성이 있습니다.

    Router3#show ip interface brief 
Serial0   172.16.3.34    YES manual up                      up
Serial1   10.0.3.23    YES manual administratively down   down

    이는 간단하게 수정할 수 있습니다.

    Router3#configure terminal 
Enter configuration commands, one per line.  End with CNTL/Z. 
Router3(config)#interface serial1 
Router3(config-if)#no shutdown
Router3(config-if)# 
Jan 20 16:20:53.900: %LINK-3-UPDOWN: Interface Serial1, changed state to up 
Jan 20 16:20:53.910: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1, 
  changed state to up

    access-list 명령

    이 시나리오에서는 인터페이스 Serial0을 통해 Telnet 트래픽만 Router4로 들어가도록 허용됩니다.

    Router4(config)# access-list 100 permit tcp any any eq telnet 
Router4(config)#interface serial0
Router4(config-if)#ip access-group 100 in


Router1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Router1(config)#access-list 100 permit ip host 172.16.12.1 host 172.16.4.34
Router1(config)#access-list 100 permit ip host 172.16.4.34 host 172.16.12.1
Router1(config)#end
Router1#debug ip packet 100 
IP packet debugging is on
Router1#debug ip icmp
ICMP packet debugging is on

    Router4를 ping합니다.

    Router1#ping 172.16.4.34 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.4.34, timeout is 2 seconds: 
U.U.U 
Success rate is 0 percent (0/5) 

Jan 20 16:34:49.207: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending
Jan 20 16:34:49.287: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:34:49.291: ICMP: dst (172.16.12.1) administratively prohibited unreachable
 rcv from 172.16.4.34
Jan 20 16:34:49.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending
Jan 20 16:34:51.295: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending
Jan 20 16:34:51.367: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:34:51.371: ICMP: dst (172.16.12.1) administratively prohibited unreachable
 rcv from 172.16.4.34
Jan 20 16:34:51.379: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 100,
 sending

    access-list명령이 끝나면 항상 암시적 모두 거부가 적용됩니다. 즉, Router4의 Serial 0 인터페이스로 들어오는 ICMP 패킷이 거부되고, Router 4는 디버그 메시지에 표시된 것처럼 ICMP "관리적으로 금지한 도달 불가" 메시지를 원래 패킷의 소스로 전송합니다. 해결 방법은 access-list 명령에서 이 줄을 추가하는 것입니다.

    Router4(config)#access-list 100 permit icmp any any

    ARP(Address Resolution Protocol) 문제

    이 시나리오에서는 이더넷 연결입니다.

    Address Resolution Protocol IssueARP(Address Resolution Protocol) 문제

    Router4#ping 172.16.100.5 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds: 

Jan 20 17:04:05.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  sending
Jan 20 17:04:05.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  encapsulation failed.
Jan 20 17:04:07.167: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  sending
Jan 20 17:04:07.171: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  encapsulation failed.
Jan 20 17:04:09.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  sending
Jan 20 17:04:09.183: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  encapsulation failed.
Jan 20 17:04:11.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  sending
Jan 20 17:04:11.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  encapsulation failed.
Jan 20 17:04:13.175: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  sending
Jan 20 17:04:13.179: IP: s=172.16.100.4 (local), d=172.16.100.5 (Ethernet0), len 100, 
  encapsulation failed.
Success rate is 0 percent (0/5)
Router4#

    이 예시에서 "encapsulation failed" 메시지로 인해 ping이 작동하지 않습니다. 이는 라우터가 패킷을 전송해야 하는 인터페이스는 알고 있지만 패킷을 전송하는 방법은 모름을 의미합니다. 이 경우, ARP(Address Resolution Protocol)의 작동 방식을 이해해야 합니다.

    ARP는 레이어 2 주소(MAC 주소)를 레이어 3 주소(IP 주소)에 매핑하는 데 사용되는 프로토콜입니다. show arp 명령을 사용하여 이를 확인할 수 있습니다.

    Router4#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.16.100.4               -   0000.0c5d.7a0d  ARPA   Ethernet0
Internet  172.16.100.7              10   0060.5cf4.a955  ARPA   Ethernet0

    "encapsulation failed" 문제로 돌아갑니다. 이번에는 debug arp 명령을 활성화합니다.

    Router4#debug arp 
ARP packet debugging is on 

Router4#ping 172.16.100.5 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.100.5, timeout is 2 seconds: 

Jan 20 17:19:43.843: IP ARP: creating incomplete entry for IP address: 172.16.100.5 
  interface Ethernet0
Jan 20 17:19:43.847: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
                 dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:45.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
                 dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:47.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
                 dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:49.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
                 dst 172.16.100.5 0000.0000.0000 Ethernet0.
Jan 20 17:19:51.843: IP ARP: sent req src 172.16.100.4 0000.0c5d.7a0d,
                 dst 172.16.100.5 0000.0000.0000 Ethernet0.
Success rate is 0 percent (0/5)

    이전 출력은 Router4가 패킷을 브로드캐스트하고 이를 이더넷 브로드캐스트 주소 FFFF.FFFF.FFFF로 전송한다는 것을 보여줍니다. 여기서 0000.0000.0000은 Router4가 대상 172.16.100.5의 MAC 주소를 찾고 있음을 의미합니다. 이 예시에서는 ARP 요청 도중 MAC 주소를 알지 못하므로 인터페이스 Ethernet 0에서 전송된 브로드캐스트 프레임에서 0000.0000.0000을 자리 표시자로 사용하여 172.16.100.5에 해당하는 MAC 주소를 묻습니다. 응답이 없는 경우 show arp 출력의 IP 주소에 해당하는 MAC 주소는 Incomplete으로 표시됩니다.

    Router4#show arp 
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  172.16.100.4               -   0000.0c5d.7a0d  ARPA   Ethernet0
Internet  172.16.100.5               0   Incomplete      ARPA
Internet  172.16.100.7               2   0060.5cf4.a955  ARPA   Ethernet0

    사전에 정해진 시간이 지난 후에는 불완전한 항목이 ARP 테이블에서 제거됩니다. MAC 주소가 ARP 테이블에 없는 한, "encapsulation failed"의 결과로 ping이 실패합니다.

    Delay

    기본적으로 2초 내에 원격 측에서 응답을 받지 못하면 ping이 실패합니다.

    Router1#ping 172.16.0.12 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: 
..... 
Success rate is 0 percent (0/5)

    링크 속도가 느리거나 지연 시간이 긴 네트워크에서는 2초가 충분하지 않습니다. 확장 ping을 사용하여 이 기본값을 변경할 수 있습니다.

    Router1#ping 
Protocol [ip]: 
Target IP address:  172.16.0.12 
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 30 
Extended commands [n]: 
Sweep range of sizes [n]: 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 30 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 1458/2390/6066 ms

    확장 ping 명령에 대한 자세한 내용은 확장 ping 및 확장 traceroute 명령에 대한 이해를 참조하십시오.

    이전 예에서는 시간 초과가 증가하면 ping이 성공한 것이었습니다.

    참고:평균 왕복 시간은 2초를 초과합니다.

    올바른 소스 주소

    이 예시는 일반적인 시나리오입니다.

    Correct Source Address올바른 소스 주소

    Router1에 LAN 인터페이스를 추가합니다.

    Router1(config)#interface ethernet0
Router1(config-if)#ip address 10.0.0.1 255.255.255.0

    LAN의 스테이션에서 Router1로 ping을 수행할 수 있습니다. Router1에서 Router2로 ping을 수행할 수 있습니다. 하지만 LAN의 스테이션에서 Router2로 ping을 수행할 수 없습니다.

    Router1에서 Router2로 ping을 수행할 수 있는데, 기본적으로 발신 인터페이스의 IP 주소를 ICMP 패킷의 소스 주소로 사용하기 때문입니다. Router2에 이 새 LAN에 대한 정보가 없습니다. 이 네트워크로부터의 패킷에 응답해야 하는 경우, 이를 처리하는 방법을 알지 못합니다.

    Router1#debug ip packet
IP packet debugging is on

    경고: 프로덕션 라우터에서 debug ip packet 명령이 사용되면 CPU 사용률이 높아질 수 있습니다. 이로 인해 심각한 성능 저하 또는 네트워크 중단이 발생할 수 있습니다.

    Router1#ping 172.16.0.12 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/7/9 ms 
Router1# 

Jan 20 16:35:54.227: IP: s=172.16.12.1 (local), d=172.16.0.12 (Serial0), len 100, sending
Jan 20 16:35:54.259: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 100, rcvd 3

    이전의 출력 예시는 전송된 패킷의 소스 주소가 172.16.12.1이므로 작동합니다. LAN으로부터의 패킷을 시뮬레이션하려면 확장 ping을 사용해야 합니다.

    Router1#ping 
Protocol [ip]: 
Target IP address: 172.16.0.12 
Repeat count [5]: 
Datagram size [100]: 
Timeout in seconds [2]: 
Extended commands [n]: y 
Source address or interface: 10.0.0.1 
Type of service [0]: 
Set DF bit in IP header? [no]: 
Validate reply data? [no]: 
Data pattern [0xABCD]: 
Loose, Strict, Record, Timestamp, Verbose[none]: 
Sweep range of sizes [n]: 
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: 

Jan 20 16:40:18.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100,
 sending.
Jan 20 16:40:20.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100,
 sending.
Jan 20 16:40:22.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100,
 sending.
Jan 20 16:40:24.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100,
 sending
Jan 20 16:40:26.303: IP: s=10.0.0.1 (local), d=172.16.0.12 (Serial0), len 100,
 sending.
Success rate is 0 percent (0/5)

    이번에는 소스 주소가 10.0.0.1이며, 작동하지 않습니다. 패킷이 전송되지만 응답이 수신되지 않습니다. 이 문제를 해결하려면 Router2의 10.0.0.0에 경로를 추가해야 합니다. 기본 규칙은 ping된 디바이스가 ping 소스에 응답을 보내는 방법도 알아야 한다는 것입니다.

    높은 입력 대기열 삭제

    패킷이 라우터에 진입하면 라우터는 인터럽트 레벨에서 패킷을 전달하려고 시도합니다. 해당 캐시 테이블에서 일치하는 항목을 찾을 수 없는 경우, 패킷은 수신 인터페이스의 입력 대기열에 대기하며 처리되기를 기다립니다. 일부 패킷은 항상 처리됩니다. 그러나 처리되는 패킷 비율 때문에 입력 대기열이 혼잡해지는 일이 없도록 적절한 컨피그레이션과 안정된 네트워크를 사용하십시오. 입력 대기열이 꽉 차면 패킷이 삭제됩니다.

    인터페이스가 가동 중이지만 높은 입력 대기열 삭제로 인해 디바이스로 ping을 수행하지 못할 수 있습니다. show interface 명령을 사용하여 입력 삭제를 확인할 수 있습니다.

    Router1#show interface Serial0/0/0

Serial0/0/0 is up, line protocol is up 
  
  MTU 1500 bytes, BW 1984 Kbit, DLY 20000 usec, 
     reliability 255/255, txload 69/255, rxload 43/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:02, output 00:00:00, output hang never
  Last clearing of "show interface" counters 01:28:49
  Input queue: 76/75/5553/0 (size/max/drops/flushes);
     Total output drops: 1760
  Queueing strategy: Class-based queueing
  Output queue: 29/1000/64/1760 (size/max total/threshold/drops) 
     Conversations  7/129/256 (active/max active/max total)
     Reserved Conversations 4/4 (allocated/max allocated)
     Available Bandwidth 1289 kilobits/sec
  

!--- Output supressed

    출력에서 표시된 것과 같이 입력 대기열 삭제가 높습니다. 입력/출력 대기열 삭제 문제를 해결하려면 입력 대기열 삭제 및 출력 대기열 삭제 문제 해결을 참조하십시오.

    traceroute 명령

    traceroute 명령은 패킷이 대상 주소로 이동할 때 실제로 사용하는 경로를 검색하는 데 사용됩니다. 디바이스(예: 라우터 또는 PC)가 UDP(User Datagram Protocol) 데이터그램 시퀀스를 원격 호스트의 잘못된 포트 주소로 전송합니다.

    3개의 데이터그램을 보내는데, 각각 TTL(Time-to-Live) 필드 값이 1로 설정되어 있습니다. TTL 값이 1이면 경로의 첫 번째 라우터에 도달하는 즉시 데이터그램이 "시간 초과"됩니다. 그러면 이 라우터는 데이터그램이 만료되었음을 나타내는 ICMP TEM(Time Exceeded Message)으로 응답합니다.

    TTL 값이 각각 2로 설정된 또 다른 3 개의 UDP 메시지가 전송되어 두 번째 라우터가 ICMP TEM을 반환합니다. 이 프로세스는 패킷이 실제로 다른 대상에 도달할 때까지 계속됩니다. 이러한 데이터그램이 대상 호스트의 잘못된 포트에 액세스하려 하기 때문에 ICMP Port Unreachable Message가 반환되어 연결할 수 없는 포트를 나타냅니다. 이 이벤트는 트레이스라우트(traceroute) 프로그램의 종료를 나타냅니다.

    그 목적은 패킷이 대상에 도달한 경로를 추적하기 위해 각 ICMP Time Exceeded Message의 소스를 기록하는 것입니다.

    Router1#traceroute 172.16.4.34 

Type escape sequence to abort. 
Tracing the route to 172.16.4.34 

  1 172.16.0.12 4 msec 4 msec 4 msec 
  2 10.0.3.23 20 msec 16 msec 16 msec 
  3 172.16.4.34 16 msec *  16 msec 
  
Jan 20 16:42:48.611: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.615:     UDP src=39911, dst=33434
Jan 20 16:42:48.635: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.639:     ICMP type=11, code=0                     

!--- ICMP Time Exceeded Message from Router2.

Jan 20 16:42:48.643: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.647:     UDP src=34237, dst=33435
Jan 20 16:42:48.667: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.671:     ICMP type=11, code=0
Jan 20 16:42:48.675: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.679:     UDP src=33420, dst=33436
Jan 20 16:42:48.699: IP: s=172.16.0.12 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.703:     ICMP type=11, code=0

    TTL=1로 전송하는 패킷의 첫 번째 시퀀스입니다. 첫 번째 라우터(이 경우에는 Router2(172.16.0.12))는 패킷을 삭제하고 소스(172.16.12.1)에 type=11 ICMP 메시지를 다시 전송합니다. 이는 TEM(Time Exceeded Message)에 해당합니다.

    Jan 20 16:42:48.707: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.711:     UDP src=35734, dst=33437
Jan 20 16:42:48.743: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3   
Jan 20 16:42:48.747:     ICMP type=11, code=0         

!--- ICMP Time Exceeded Message from Router3.

Jan 20 16:42:48.751: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.755:     UDP src=36753, dst=33438
Jan 20 16:42:48.787: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.791:     ICMP type=11, code=0
Jan 20 16:42:48.795: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.799:     UDP src=36561, dst=33439
Jan 20 16:42:48.827: IP: s=10.0.3.23 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.831:     ICMP type=11, code=0

    TTL=2인 Router3(10.0.3.23)에서도 동일한 프로세스가 발생합니다.

    Jan 20 16:42:48.839: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.843:     UDP src=34327, dst=33440
Jan 20 16:42:48.887: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:48.891:     ICMP type=3, code=3

!--- Port Unreachable message from Router4.
                      
Jan 20 16:42:48.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:48.899:     UDP src=37534, dst=33441
Jan 20 16:42:51.895: IP: s=172.16.12.1 (local), d=172.16.4.34 (Serial0), len 28,
 sending
Jan 20 16:42:51.899:     UDP src=37181, dst=33442
Jan 20 16:42:51.943: IP: s=172.16.4.34 (Serial0), d=172.16.12.1 (Serial0), len 56,
 rcvd 3
Jan 20 16:42:51.947:     ICMP type=3, code=3

    TTL=3인 경우 최종적으로 Router4에 연결됩니다. 이번에는 포트가 유효하지 않으므로 Router4는 type=3(Destination Unreachable Message), code=3(포트 연결 불가를 의미)인 ICMP 메시지를 Router1로 보냅니다.

    다음 표에는 traceroute 명령 출력에 표시될 수 있는 문자가 나열되어 있습니다.

    IP Traceroute 텍스트 문자

    문자 설명
    nn msec 각 노드에서 지정된 수의 프로브가 왕복하는 데 걸린 시간(밀리초)입니다.
    * 프로브 시간 초과
    A 관리상 금지됨(예: access-list)
    Q 소스 억제(대상이 너무 많이 사용 중임)
    I 사용자가 테스트를 중단
    U 포트 연결 불가
    H 호스트 연결 불가
    네트워킹 네트워크 연결 불가
    P 프로토콜 연결 불가
    T Timeout(시간 초과)
    ? 알 수 없는 패킷 유형

    Performance

    ping 및 traceroute 명령을 사용하여 RTT(Round-Trip Time)를 획득할 수 있습니다. 이 시간은 에코 패킷을 전송하고 응답을 받는 데 필요한 시간입니다. 이를 통해 링크의 지연에 대해 대략적으로 파악할 수 있습니다. 하지만 이러한 수치는 성능 평가에 사용할 정도로 정확하지 않습니다.

    패킷 대상이 라우터 자체인 경우 이 패킷은 프로세스 전환되어야 합니다. 프로세서에서 이 패킷의 정보를 처리하고 응답을 다시 전송해야 합니다. 이는 라우터의 주요 목표가 아닙니다. 정의상 라우터는 패킷을 라우팅하기 위해 구축됩니다. ping 응답은 최선의 서비스로 제공됩니다.

    이를 설명하기 위해 Router1에서 Router2로 ping을 수행하는 예시를 들 수 있습니다.

    Router1#ping 172.16.0.12 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 ms

    RTT는 약 4밀리초입니다. Router2에서 일부 프로세스 집약적 기능을 활성화한 후 Router1에서 Router2로 ping을 수행합니다.

    Router1#ping 172.16.0.12 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.0.12, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/25/28 ms

    이 부분에서 RTT가 크게 증가했습니다. Router2는 사용량이 많아 ping에 응답하는 것이 우선순위가 아닙니다. 라우터 성능을 테스트하는 더 좋은 방법은 라우터를 통과하는 트래픽을 사용하는 것입니다.

    Traffic Through the Router라우터를 통과하는 트래픽

    이후 트래픽에서 빠른 전환이 이루어지며, 우선순위가 가장 높은 라우터에서 처리됩니다. 기본 네트워크는 다음을 보여줍니다.

    Basic Network with 3 Routers3개의 라우터가 있는 기본 네트워크

    Router1에서 Router3으로 ping을 수행합니다.

    Router1#ping 10.0.3.23 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/32 ms

    트래픽이 Router2를 통과하고 있으며, 이제 빠른 전환이 이루어집니다. Router2에서 프로세스 집약적 기능을 활성화합니다.

    Router1#ping 10.0.3.23 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 10.0.3.23, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/32/36 ms

    차이는 거의 없습니다. Router2에서 패킷이 이제 인터럽트 레벨에서 처리되기 때문입니다.

    debug 명령 사용

    debug 명령을 사용하기 전에 debug 명령에 대한 중요한 정보를 참조하십시오.

    이 문서에서 사용되는 여러 debug 명령은 ping 또는 traceroute 명령이 사용될 때 발생하는 상황을 보여줍니다. 이러한 명령은 문제를 해결하는 데 도움이 될 수 있습니다. 하지만 생산 환경에서 디버그는 신중하게 사용해야 합니다. CPU가 강력하지 않거나 프로세스 전환 패킷이 많은 경우에는 디바이스가 쉽게 중단될 수 있습니다. debug 명령이 라우터에 미치는 영향을 최소화하는 몇 가지 방법이 있습니다. 한 가지 방법은 액세스 목록을 사용하여 모니터링할 특정 트래픽을 좁히는 것입니다.

    예를 들면 다음과 같습니다.

    Router4#debug ip packet ? 
  <1-199>      Access list 
  <1300-2699>  Access list (expanded range) 
  detail       Print more debugging detail 
   
Router4#configure terminal
Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34 
Router4(config)#^Z 

Router4#debug ip packet 150 
IP packet debugging is on for access list 150 

Router4#show debug 
Generic IP: 
  IP packet debugging is on for access list 150 

Router4#show access-list 
Extended IP access list 150 
    permit ip host 172.16.12.1 host 172.16.4.34 (5 matches)

    이 설정을 사용하는 경우 Router4가 access-list 150과 일치하는 디버그 메시지만 출력합니다. Router1에서 ping이 수신되면 다음 메시지가 표시됩니다.

    Router4# 
Jan 20 16:51:16.911: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:51:17.003: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:51:17.095: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:51:17.187: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:51:17.279: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3

    이러한 패킷은 access-list와 일치하지 않으므로 Router4로부터 문제에 대한 응답이 오지 않습니다. 이를 확인하려면 다음을 추가합니다.

    Router4(config)#access-list 150 permit ip host 172.16.12.1 host 172.16.4.34 
Router4(config)#access-list 150 permit ip host 172.16.4.34 host 172.16.12.1

    결과:

    Jan 20 16:53:16.527: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.531: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
 sending
Jan 20 16:53:16.627: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.635: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
 sending
Jan 20 16:53:16.727: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.731: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
 sending
Jan 20 16:53:16.823: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.827: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
 sending
Jan 20 16:53:16.919: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3
Jan 20 16:53:16.923: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
 sending

    debug 명령의 영향을 줄이는 또 다른 방법은 디버그 메시지를 버퍼링하고 디버그가 해제되면 show log 명령을 사용하여 이를 표시하는 것입니다.

    Router4#configure terminal
Router4(config)#no logging console 
Router4(config)#logging buffered 5000 
Router4(config)#^Z 
  
Router4#debug ip packet 
IP packet debugging is on 
Router4#ping 172.16.12.1 

Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.12.1, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/36/37 ms 
  
Router4#undebug all 
All possible debugging has been turned off 
  
Router4#show log 
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns) 
    Console logging: disabled 
    Monitor logging: level debugging, 0 messages logged 
    Buffer logging: level debugging, 61 messages logged 
    Trap logging: level informational, 59 message lines logged 

Log Buffer (5000 bytes): 
 
Jan 20 16:55:46.587: IP: s=172.16.4.34 (local), d=172.16.12.1 (Serial0), len 100,
 sending
Jan 20 16:55:46.679: IP: s=172.16.12.1 (Serial0), d=172.16.4.34 (Serial0), len 100,
 rcvd 3

    ping과 traceroute 명령은 네트워크 액세스 문제 해결에 사용할 수 있는 유용한 유틸리티입니다. 또한 사용하기 매우 쉽습니다. 이 두 명령은 네트워크 엔지니어가 많이 사용합니다.

    관련 정보

    개정 이력

    개정 게시 날짜 의견
    2.0
    04-Oct-2022
    재인증
    1.0
    10-Dec-2001
    최초 릴리스
    TAC Authored

    Cisco 엔지니어가 작성

    • 훌리오 히메네스
      Cisco TAC 엔지니어

    이 문서가 도움이 되셨습니까?

    Feedback피드백

    지원 문의

    이 문서가 적용되는 제품