tail head cat sleep
QR code linking to this page

Man page  — TRACEROUTE

명칭

traceroute - 패킷이 네트워크상의 호스트까지 더듬는 경로를 표시한다

내용

서식

traceroute [ -dFISdnrvx ] [ -f first_ttl ] [ -g gateway ]
   
[ -i iface ] [ -M first_ttl ]
   
[ -m max_ttl ] [ -P proto ] [ -p port ]
   
[ -q nqueries ] [ -s src_addr ] [ -t tos ]
   
[ -w waittime ] [ -z pausemsecs ]
   
host [ packetlen ]

해설

인터넷은 네트워크 기기의 거대하고 복잡한 집합체로, 게이트웨이에 의해 서로 접속되고 있습니다. 패킷의 흐름을 추적하는 것 (혹은 패킷을 파기하는 나쁘다 게이트웨이를 찾아내는 것)는 몹시 어려운 일이 될 수 있습니다. traceroute (은)는 IP 프로토콜의 `time to live'필드를 이용해, 어느 호스트까지의 경로상의 모든 게이트웨이로부터 ICMP TIME_EXCEEDED 리스폰스를 꺼내려고 시도합니다.

유일한 필수 파라미터는 목적지의 호스트명 (IP 주소에서도 가능)입니다. 프로브 패킷의 길이는 디폴트로 40 바이트입니다만, 목적의 호스트명의 뒤에 패킷 사이즈를 (바이트 단위로) 지정하는 것에 의해 크게 할 수도 있습니다.

그 외의 옵션을 이하로 설명합니다.
-f 최초로 송출하는 프로브 패킷의 초기의 유효기간 (time-to-live)을 설정합니다.
-F 「fragment 불허가」비트를 세트 합니다.
-d 패킷레벨 디버그를 유효하게 합니다.
-g 엉성하고, 소스 루팅을 위한 게이트웨이를 지정합니다. 최대 8 개(살) 지정할 수 있습니다.
-i 송출하는 프로브 패킷에 사용하기 위한 , 시점 IP 주소를 취득하는 네트워크 인터페이스를 지정합니다. 통상, multi-homed host에서만 유용합니다 (같은 것을 실시하는 다른 방법에 대해서는 -s (을)를 참조해 주세요).
-I UDP 데이터 그램대신에 ICMP ECHO 를 사용합니다 ("-P icmp" 와 같습니다).
-M 송출되는 프로브 패킷의 time-to-live 의 초기치를 설정합니다. 디폴트는 1 이며, 최초의 호프로부터 개시하는 것을 의미합니다.
-m 송출되는 프로브 패킷의 최대 time-to-live (최대 호프수)를 세트 합니다. 디폴트는 net.inet.ip.ttl 호프 (TCP 와 같은 기본값)입니다.
-n 게이트웨이의 주소를 호스트명과 IP 주소는 아니고 IP 주소만으로 표시합니다 (네임서버에의 IP 주소로부터 호스트명에의 변환 문의를 생략합니다).
-P 지정한 IP 프로토콜의 패킷을 송출합니다. 현재 서포트되고 있는 프로토콜은 UDP, TCP, GRE, ICMP 입니다. 다른 프로토콜도 (이름 또는 수치로) 지정 가능합니다만, traceroute (은)는 이러한 패킷 포맷에 관한 특별한 지식은 실장하고 있지 않습니다. 경로상의 어느 라우터가 IP 프로토콜 번호에 따라 블록 하고 있을까를 판정하는 경우, 이 옵션이 유용합니다. 후술의 버그를 참조해 주세요.
-p 프로브에 사용하는 UDP 포트 번호 (디폴트는 33434)의 기준치 (base)를 지정합니다. traceroute (은)는 목적의 호스트에 대해, base (으)로부터 base+nhops-1 까지의 UDP 포트로 listen 하고 있지 않는 것을 기대합니다 (그리고 ICMP PORT_UNREACHABLE 메세지가 경로 추적을 종료시키기 위해서(때문에) 돌아가 옵니다). 디폴트의 범위의 포트로 listen 되고 있는 것이 있는 경우는, 이 옵션을 이용해 사용되어 있지 않은 범위의 포트를 사용할 수가 있습니다.
-q 호프 마다의 프로브 회수를 지정합니다 (디폴트는 3 회입니다).
-r 통상의 routing table를 사용하지 않습니다. 프로브 패킷이 접속되고 있는 네트워크상의 호스트에 직접 송출합니다. 그 호스트가 직접 접속된 네트워크상에 없는 경우에는 에러가 돌아갑니다. 이 옵션은, 경로를 가지지 않는 인터페이스를 개입시켜 로컬 호스트에 ping 하는 경우 (예를 들어, routed(8C) 에 의해 인터페이스가 지워진 후 )에 사용할 수가 있습니다.
-s 송출되는 프로브 패킷의 소스 주소 (송출하는 주소)로서 인수의 IP 주소 (통상, 호스트명이 아니고, 숫자로 지정합니다)를 이용합니다. multi-homed host (복수 IP 주소를 가지는 호스트)로, 프로브 패킷에 다른 소스 주소를 갖게하는데 사용할 수가 있습니다. 지정한 IP 주소가, 이 호스트의 인터페이스의 주소 중 1 개(살)이 아닌 경우, 에러가 돌려주어지고 아무것도 송출되지 않습니다 (같은 것을 실시하는 다른 방법에 대해서는 -s (을)를 참조해 주세요).
-S 각 호프에 대해, 몇개의 프로브에 대한 응답이 없었는지의 통계를 표시합니다.
-t 프로브 패킷의 type-of-service 에 인수의 값 (디폴트는 0)을 지정합니다. 값은 0 에서 255 까지의 십진수입니다. type-of-service 의 값에 의해, 경로가 다른지를 보기 위해서(때문에), 이 옵션을 사용할 수가 있습니다. (telnet 나 ftp 와 같은 통상의 네트워크 서비스는, TOS 를 제어할 수 없기 때문에, 4.4bsd 이후의 시스템이 아니면, 이 옵션의 실제적인 의미는 없습니다. ) 모든 TOS 의 값에 의미가 있는 것은 아닙니다. 정의에 대해서는 IP 의 상세를 참조해 주세요. 아마, `-t 16' (low delay)(이)나 `-t 8' (high throughput) 하지만 유익한 값이지요.
-v 장황 모드입니다. TIME_EXCEEDED 와 UNREACHABLE 이외의 수신한 ICMP 패킷을 표시합니다.
-w 프로브 패킷의 응답 시간 (디폴트는 5 초)을 (초단위로) 지정합니다.
-x IP 체크 섬을 바꿉니다. 통상 이것은, traceroute 에 의한 IP 체크 섬의 계산을 억제합니다.
operating system가 출력 패킷의 일부를 고쳐 쓰는 일이 있습니다만, 체크 섬을 재계산하지 않습니다 (그 때문에 디폴트가 체크 섬을 계산하지 않게 되어 있어, -x (을)를 사용하는 것으로써 체크 섬 계산이 유효하게 되는 경우가 있습니다). ICMP ECHO 프로브 사용시 (-I) 에는, 최종 호프에서는 통상 체크 섬이 필요한 일로 주의해 주세요. 이 때문에, ICMP 사용시에는 항상 체크 섬이 계산됩니다.
-z 프로브간의 휴지 시간 (밀리 세컨드 단위)을 설정합니다 (디폴트는 0). 예를 들면 Solaris 와 같은 시스템이나 Cisco 와 같은 라우터에서는, ICMP 메세지의 빈도에 제한을 걸고 있습니다. 이 값에는 500 (1/2 초)을 지정하면 좋을 것입니다.
이 프로그램은, IP 패킷이 어느 호스트에 도달하기까지 더듬는 경로를 추적하는 것입니다. UDP 프로브 패킷을 작은 ttl (time to live)로 송출해, 게이트웨이로부터 ICMP "time exceeded" 가 되돌아 오는 것을 기다립니다. 우선, 프로브를 ttl 1 으로부터 시작해(호스트에 도달한 것을 의미한다) ICMP "port unreachable" 를 받을 때까지, 혹은 최대 (디폴트는 net.inet.ip.ttl 그렇지만, -m 플래그로 변경할 수 있습니다) (이)가 될 때까지 ttl 를 1 씩 늘립니다. 각 ttl 에 대해서, 3 개 ( -q 플래그로 변경 가능합니다)의 프로브가 송출되어 ttl, 게이트웨이의 주소, 각 프로브의 왕복 시간을 1 행에 표시합니다. 다른 게이트웨이로부터 프로브가 되돌아 왔을 경우는, 각각의 시스템의 주소를 표시합니다. 5 초 ( -w 플래그로 변경하는) 이내에 반응이 없는 경우는, 각 프로브에 대해서 "*" 를 표시합니다.
목적의 호스트의 포트가 부적당한 값으로 설정되어 있기 위해서(때문에), UDP 프로브 패킷이 처리되어 버리는 것을 우리는 바라지 않습니다. (목적의 호스트가 그 값을 사용하고 있는 경우, -p 플래그로 변경할 수가 있습니다. )
사용과 출력의 예 :

 
[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1. 1.48), 64 hops max, 38 byte packet
 1  helios.ee.lbl.gov (128.3. 112.1)  19 ms  19 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32. 216.1)  39 ms  39 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32. 216.1)  39 ms  39 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32. 136.23)  39 ms  40 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32. 168.22)  39 ms  39 ms  39 ms
 6  128.32. 197.4 (128.32. 197.4)  40 ms  59 ms  59 ms
 7  131.119. 2.5 (131.119. 2.5)  59 ms  59 ms  59 ms
 8  129.140. 70.13 (129.140. 70.13)  99 ms  99 ms  80 ms
 9  129.140. 71.6 (129.140. 71.6)  139 ms  239 ms  319 ms
10  129.140. 81.7 (129.140. 81.7)  220 ms  199 ms  199 ms
11  nic.merit.edu (35.1. 1.48)  239 ms  239 ms  239 ms

2 행 째와 3 행 째가 같은 것으로 주의해 주세요. 이것은, 2번째의 시스템 - lbl-csam.arpa - 가, ttl 0 의 패킷을 전송 한다고 하는 (4.3BSD 에 포함된다) 버그를 가진 커널인 것에 의하는 것입니다. 또, NSFNet (129.140)는 주소를 호스트명으로 변환해 주지 않기 때문에, 패킷이 어느 경로를 더듬었는지를 추측할 필요가 있는 것에 주의해 주세요.

좀 더 흥미로운 예 :

 
[yak 72]% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (18.26. 0.115), 64 hops max
 1  helios.ee.lbl.gov (128.3. 112.1)  0 ms  0 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32. 216.1)  19 ms  19 ms  19 ms
 3  lilac-dmc.Berkeley.EDU (128.32. 216.1)  39 ms  19 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32. 136.23)  19 ms  39 ms  39 ms
 5  ccn-nerif22.Berkeley.EDU (128.32. 168.22)  20 ms  39 ms  39 ms
 6  128.32. 197.4 (128.32. 197.4)  59 ms  119 ms  39 ms
 7  131.119. 2.5 (131.119. 2.5)  59 ms  59 ms  39 ms
 8  129.140. 70.13 (129.140. 70.13)  80 ms  79 ms  99 ms
 9  129.140. 71.6 (129.140. 71.6)  139 ms  139 ms  159 ms
10  129.140. 81.7 (129.140. 81.7)  199 ms  180 ms  300 ms
11  129.140. 72.17 (129.140. 72.17)  300 ms  239 ms  239 ms
12  * * *
13  128.121. 54.72 (128.121. 54.72)  259 ms  499 ms  279 ms
14  * * *
15  * * *
16  * * *
17  * * *
18  ALLSPICE.LCS.MIT.EDU (18.26. 0.115)  339 ms  279 ms  279 ms

l2, 14, 15, 16, 17 번째의 게이트웨이가 ICMP "time exceeded" 메세지를 송출하고 있지 않는지, 혹은 송출된 ICMP "time exceeded" 메세지의 ttl 가 작기 위해(때문에), 이쪽에 도달하지 않을 것입니다. 14 에서 17 번째의 호스트에서는,"time exceeded" 를 송출하지 않는다 MIT C Gateway 코드가 가동하고 있습니다. 12 번째로 무엇이 일어나고 있는지는, 신만 아는 곳(중)입니다.

상기의 12 번째의 게이트웨이가 반응하지 않는 것은, 4. [23] BSD 네트워크 코드 (과소의 파생 프로그램)의 버그의 탓이지요. 4. x (x <= 3)에서는, 원의 데이터 그램에 남아 있는 ttl 가 어떤 값이어도, 그것을 이용해 unreachable 메세지를 송출합니다. 따라서, 게이트웨이에 대해서 남아 있는 ttl는 0 이므로, ICMP "time exceeded" 가 돌아오지 않는 것이 프로텍션됩니다. 이 버그가 목적의 시스템상에서 나타났을 경우, 한층 더 좀 더 흥미로운 것이 됩니다.

 
 1  helios.ee.lbl.gov (128.3. 112.1)  0 ms  0 ms  0 ms
 2  lilac-dmc.Berkeley.EDU (128.32. 216.1)  39 ms  19 ms  39 ms
 3  lilac-dmc.Berkeley.EDU (128.32. 216.1)  19 ms  39 ms  19 ms
 4  ccngw-ner-cc.Berkeley.EDU (128.32. 136.23)  39 ms  40 ms  19 ms
 5  ccn-nerif35.Berkeley.EDU (128.32. 168.35)  39 ms  39 ms  39 ms
 6  csgw.Berkeley.EDU (128.32. 133.254)  39 ms  59 ms  39 ms
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  rip.Berkeley.EDU (128.32. 131.22)  59 ms !   39 ms !   39 ms !

12 의 게이트웨이 (13 번째는 최종 목적의 호스트입니다)가 있어, 정확히 반의 게이트웨이가 실패하고 있습니다. 이것은, rip (Sun OS3. 5 의 가동하고 있는 Sun-3)가, 도착한 데이터 그램의 ttl 를 ICMP 응답의 ttl 로서 그대로 사용하는 것 에 의하는 것입니다. 경로의 길이가 적어도 2 배의 ttl 의 프로브가 송출될 때까지, ( ICMP 에 대해서 ICMP 는 송출되지 않기 때문에, 누구에게도 깨달아지고 하지않고서) 귀가의 경로상에서 응답이 타임 아웃 합니다. 즉, 실제로는 rip 까지 7 호프 밖에 없습니다. ttl가 1 의 응답은, 문제 해결의 실마리가 됩니다. ttl가 1 이하의 경우, traceroute (은)는 시간의 뒤에 "! " (을)를 표시합니다. vender는 구식의 (DEC 의 Ultrix, Sun 3. x) 혹은 표준이 아니다 (HPUX) 소프트웨어를 많이 사용하고 있으므로, 자주 이 문제가 일어나는 것을 알아, 프로브의 목표의 호스트는 주의해 선택해 주세요.

시간의 뒤를 뒤따르는 그 외의 주석에는, !H, !N, !P (호스트, 네트워크, 프로토콜에 도달 불능)(이)나, !S (소스 루팅에 실패)(이)나, ! F-<pmtu> (fragmentation가 필요 - RFC1191 Path MTU Discovery 치를 표시)(이)나, ! X (관리상, 통신이 금지되고 있다)(이)나, ! V (호스트 순서 위반)(이)나, ! C (순서 절단이 된), 나, ! <num> (ICMP 는 코드 num 에서는 도달할 수 없다)(이)가 있습니다. 이것들은 RFC1812 (RFC1716 에 취해 대표했습니다)로 정의되고 있습니다. 거의 모든 프로브가 도달 불능이면, traceroute (은)는 송출을 멈춤 종료합니다.

이 명령은 네트워크의 검사, 측정, 관리를 위해서(때문에) 사용하는 것입니다. 본래는 수동으로 장해를 떼어내기 위해서(때문에) 사용되어야 할 것입니다. 네트워크에 걸리는 부하가 크기 때문에, traceroute (을)를 통상의 조작이나 자동적인 스크립트로 사용하는 것은 어리석은 일입니다.

관련 항목

pathchar(8), netstat(1), ping(8)

저자

Steve Deering 의 제안에 근거해 Van Jacobson 에 의해 실장되었습니다. 디버그는 몇천의 사람들, 특히 C.Philip Wood, Tim Seaver 와 Ken Adelman 에 의한 설득력이 있는 제안과 수정에 의해 행해졌습니다.

현재의 버젼은 익명 ftp 를 사용해 이하의 곳부터 입수할 수 있습니다.

ftp://ftp.ee.lbl.gov/traceroute.tar.gz

버그

UDP 이외의 프로토콜을 사용하는 경우, 기능이 제한됩니다. 특히, 마지막 패킷이 자주 없어진 것처럼 보입니다. 왜냐하면, 마지막 패킷이 행선지 호스트에 도달했다고 해도, ICMP 메세지는 돌려 보내지지 않기 때문에, 그것을 알 방법이 없기 때문입니다. TCP 의 경우, traceroute (은)는 행선지 호스트 (또는 패킷을 필터 하고 있는 중간 라우터)로부터의 RST (을)를 봐야 합니다가, 아직 실장되고 있지 않습니다.

버그 리포트는, traceroute@ee.lbl.gov 에 보내 주세요.


21 September 2000 TRACEROUTE (8)

tail head cat sleep
QR code linking to this page


Ben Bullock이 유닉스 매뉴얼 페이지에서 서비스에 대한 의견을 주시기 바랍니다. Privacy policy.