traceroute 명령

The traceroute 명령은 네트워크 테스트, 측정 및 관리에 사용됩니다.

ping 명령으로 IP 네트워크 접속 가능성을 확인할 수는 있지만, 일부 고립된 문제점은 정확히 파악하여 개선할 수 없습니다. 다음과 같은 상황을 고려하십시오.

  • 사용자 시스템과 대상 사이에 여러 개의 홉(예: 게이트웨이 또는 라우트)이 있고 경로상의 어딘가에 문제가 있는 것으로 판단되는 경우. 대상 시스템에서 문제점이 발생한 것일 수 있지만, 패킷이 실제로 유실된 위치를 알고 있어야 합니다.
  • ping 명령이 수행 중에 중단되고 패킷 유실 이유를 보고하지 않는 경우
traceroute 명령으로 패킷이 있는 위치와 라우트가 유실된 이유를 알 수 있습니다. 패킷이 다른 기관이나 회사에 소속되어 관리되는 라우터와 링크를 통과해야 하는 경우, telnet 명령을 통해서는 관련 라우터를 검사하기 어렵습니다. traceroute 명령은 ping 명령을 보완해 줍니다.
참고: traceroute 명령은 주로 수동 결함 격리에 사용해야 합니다. traceroute 명령은 네트워크 로드를 일으키므로 일반적인 조작 중에 사용하거나 자동화된 스크립트에서 사용하지 마십시오.

성공한 traceroute 예

traceroute 명령은 UDP 패킷과 ICMP 오류 보고 기능을 사용하며, UDP 패킷을 경로상의 각 게이트웨이나 라우터에 세 번 전송합니다. 또한 가장 가까운 게이트웨이에서 시작하여 한 홉씩 검색을 확장합니다. 최종적으로 검색이 대상 시스템에 도달합니다. 출력에는 게이트웨이 이름, 게이트웨이의 IP 주소 및 게이트웨이에 대한 세 번의 왕복 시간이 표시됩니다. 다음 예를 참조하십시오.
# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  5 ms  3 ms  2 ms
 2  aix1 (10.53.153.120)  5 ms  5 ms  5 ms
다음과 같은 예도 있습니다.
# traceroute aix1
trying to get source for aix1
source should be 10.53.155.187
traceroute to aix1.austin.ibm.com (10.53.153.120) from 10.53.155.187 (10.53.155.187), 30 hops max
outgoing MTU = 1500
 1  10.111.154.1 (10.111.154.1)  10 ms  2 ms  3 ms
 2  aix1 (10.53.153.120)  8 ms  7 ms  5 ms

주소 해석 프로토콜(ARP) 항목이 만기된 후 동일한 명령이 반복되었습니다. 첫 번째 패킷에서 각 게이트웨이 또는 대상까지의 왕복 시간은 더 오래 걸렸습니다. 이는 ARP로 인해 발생한 오버헤드 때문입니다. 공중 교환망(WAN)이 라우트에 포함된 경우, 연결 구축을 위해 첫 번째 패킷이 많은 메모리를 소비하므로 시간종료가 발생할 수도 있습니다. 각 패킷에 대한 디폴트 시간종료는 3초입니다. 이 값은 -w 옵션을 사용하여 변경할 수 있습니다.

처음 10ms는 소스 시스템(9.53.155.187)과 게이트웨이 9.111.154.1 간의 ARP 때문입니다. 두 번째 8ms는 게이트웨이와 최종 대상(웨이브) 간의 ARP 때문입니다. 이 경우 DNS를 사용하고 있으므로 traceroute 명령이 패킷을 전송하기 전에 항상 DNS 서버가 검색됩니다.

실패한 raceroute 예

대상까지의 경로가 길거나 네트워크 라우트가 복잡한 경우, traceroute 명령과 관련하여 많은 문제점이 발생할 수 있습니다. 많은 문제점이 구현에 따른 것이므로, 문제점을 검색하는 것은 시간 낭비일 뿐입니다. 관련된 모든 라우터나 시스템을 사용자가 제어할 수 있는 경우 문제점을 완벽하게 조사할 수 있습니다.

게이트웨이(라우터) 문제점

다음 예에서는 시스템 9.53.155.187에서 패킷이 전송되었습니다. 브릿지까지의 경로에 두 개의 라우터 시스템이 있습니다. no 명령의 ipforwarding 옵션을 0으로 설정하여 두 번째 라우터 시스템에서 의도적으로 라우팅 기능을 제거했습니다.
# traceroute lamar
trying to get source for lamar
source should be 9.53.155.187
traceroute to lamar.austin.ibm.com (9.3.200.141) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  9.111.154.1 (9.111.154.1)  12 ms  3 ms  2 ms
 2  9.111.154.1 (9.111.154.1)  3 ms !H *  6 ms !H

ICMP 오류 메시지(Time ExceededPort Unreachable 제외)는 다음과 같이 표시됩니다.

!H
호스트에 연결할 수 없음
!N
네트워크에 연결할 수 없음
!P
프로토콜에 연결할 수 없음
!S
소스 라우트 실패
!F
프래그먼트화 필요

Destination system problem

대상 시스템이 3초의 시간종료 간격 내에 응답하지 않을 경우, 모든 조회가 시간종료되며 결과는 별표(*)와 함께 표시됩니다.
# traceroute chuys
trying to get source for chuys
source should be 9.53.155.187
traceroute to chuys.austin.ibm.com (9.53.155.188) from 9.53.155.187 (9.53.155.187), 30 hops max
outgoing MTU = 1500
 1  * * *
 2  * * *
 3  * * *
^C#

통신 링크로 인한 문제점일 경우 -w 플래그를 사용하여 더 긴 시간종료 기간을 사용하십시오. 드물기는 하지만, 조회된 포트가 모두 사용되었을 수 있습니다. 포트를 변경한 후 다시 시도할 수 있습니다.

대상까지의 "홉" 수

또 다른 출력 예는 다음과 같습니다.
# traceroute mysystem.university.edu (129.2.130.22)
traceroute to mysystem.university.edu (129.2.130.22), 30 hops max
1 helios.ee.lbl.gov (129.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.university.edu (129.2.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.university.edu (129.2.215.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.university.edu (129.2.135.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.university.edu (129.2.167.35) 39 ms 39 ms 39 ms
6 csgw/university.edu (129.2.132.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.university.EDU (129.2.130.22) 59 ms! 39 ms! 39 ms!