Linux용 추적 명령

알아야 할 사항

traceroute 명령에 포함해야 하는 유일한 매개변수는 대상의 호스트 이름 또는 IP 주소입니다.
1의 TTL로 프로브를 시작하고 ICMP "포트에 연결할 수 없음"이 발생하거나 최대 시도 값에 도달할 때까지 1씩 증가시킵니다.

이 기사는 Linux 머신에 적용 가능한 traceroute 정보를 다루고 명령 스위치 설명과 결과 해석 방법에 대한 정보를 포함합니다. Traceroute는 Windows에서 다르게 사용됩니다.

Traceroute 작동 방식

traceroute 명령은 정보 패킷이 소스에서 목적지까지 수행하는 여정을 매핑합니다. traceroute의 한 가지 용도는 네트워크 전체에서 데이터 손실이 발생하는 시점을 찾는 것입니다. 이는 노드가 다운되었음을 나타낼 수 있습니다.

레코드의 각 홉은 원래 PC와 의도한 대상 간의 새 서버 또는 라우터를 반영하기 때문에 경로 추적 검색 결과를 검토하면 네트워크 트래픽에 부정적인 영향을 미칠 수 있는 느린 지점을 식별할 수 있습니다.

Traceroute로 문제 해결

네트워크 트래픽이 따르는 특정 경로를 평가하거나 패킷을 버리는 잘못된 게이트웨이를 찾는 것은 몇 가지 문제 해결 과제를 제시합니다. Traceroute는 IP 프로토콜 수명을 사용합니다. 대상 호스트에 대한 경로를 따라 각 게이트웨이에서 ICMP TIME_EXCEEDED 응답을 요청하는 필드입니다.

traceroute 명령을 실행할 때 포함해야 하는 유일한 매개변수는 대상의 호스트 이름 또는 IP 주소입니다.

Traceroute 구문 및 스위치

Traceroute는 다음 일반 구문을 따릅니다.

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

하나 이상의 선택적 스위치를 지정하여 명령의 성능이나 출력을 변경할 수 있습니다.

추적 경로 명령 스위치 전환 설명 -f 첫 번째 나가는 프로브 패킷에 사용된 초기 TTL을 설정합니다.-F "조각화하지 않음" 비트를 설정합니다.-d 소켓 수준 디버깅을 활성화합니다.-g 느슨한 소스 경로 게이트웨이를 지정합니다(최대 8개).-i 나가는 프로브 패킷의 소스 IP 주소를 얻으려면 네트워크 인터페이스를 지정하십시오. 이것은 일반적으로 다중 홈 호스트에서만 유용합니다. (-s 참조 다른 방법으로 플래그를 지정합니다.)-I UDP 데이터그램 대신 ICMP ECHO를 사용합니다.-m 나가는 프로브 패킷에 사용되는 최대 수명(최대 홉 수)을 설정합니다. 기본값은 30홉입니다(TCP 연결에 사용되는 것과 동일한 기본값).-n 홉 주소를 기호 및 숫자가 아닌 숫자로 인쇄합니다(경로에서 찾은 각 게이트웨이에 대한 이름 서버 주소 대 이름 조회 저장).-p 프로브에 사용되는 기본 UDP 포트 번호를 설정합니다(기본값은 33434). Traceroute는 UDP 포트 base에서 아무 것도 수신 대기하지 않기를 바랍니다. 기본 + nhops - 1 목적지 호스트에서 (따라서 ICMP PORT_UNREACHABLE 메시지가 반환되어 경로 추적을 종료합니다). 기본 범위의 포트에서 무언가가 수신 대기 중인 경우 이 옵션을 사용하여 사용하지 않는 포트 범위를 선택할 수 있습니다.-r 일반 라우팅 테이블을 무시하고 연결된 네트워크의 호스트로 직접 보냅니다. 호스트가 직접 연결된 네트워크에 없으면 오류가 반환됩니다. 이 옵션은 경로가 없는 인터페이스를 통해 로컬 호스트를 ping하는 데 사용할 수 있습니다(예:routed에 의해 인터페이스가 삭제된 후 (8C)).-s 다음 IP 주소(일반적으로 호스트 이름이 아닌 IP 번호로 제공됨)를 나가는 프로브 패킷의 소스 주소로 사용합니다. 다중 홈 호스트(IP 주소가 두 개 이상인 호스트)에서 이 옵션을 사용하면 소스 주소가 프로브 패킷이 전송되는 인터페이스의 IP 주소가 아닌 다른 주소가 되도록 강제할 수 있습니다. IP 주소가 이 기기의 인터페이스 주소 중 하나가 아니면 오류가 반환되고 아무 것도 전송되지 않습니다. (-i 참조 이를 수행하는 다른 방법에 대해 플래그를 지정합니다.)-t 서비스 유형 설정 프로브 패킷에서 다음 값(기본값 0). 값은 0에서 255 사이의 10진수 정수여야 합니다. 이 옵션을 사용하여 서비스 유형에 따라 경로가 달라지는지 확인할 수 있습니다. (4.4bsd를 실행하지 않는 경우 telnet 및 ftp와 같은 일반 네트워크 서비스에서는 TOS를 제어할 수 없기 때문에 이것은 학문적일 수 있습니다.) TOS의 모든 값이 합법적이거나 의미 있는 것은 아닙니다. 정의는 IP 사양을 참조하십시오. 유용한 값은 아마도 `-t 16 '(낮은 지연) 및 `-t 8 '(높은 처리량).-v 자세한 출력. TIME_EXCEEDED 및 UNREACHABLE 이외의 수신된 ICMP 패킷이 나열됩니다.-w 프로브 응답을 기다리는 시간(초)을 설정합니다(기본값 5초).-x IP 체크섬을 전환합니다. 일반적으로 이것은 traceroute가 IP 체크섬을 계산하는 것을 방지합니다. 어떤 경우에는 운영 체제가 나가는 패킷의 일부를 덮어쓸 수 있지만 체크섬을 다시 계산할 수는 없습니다. 따라서 어떤 경우에는 기본적으로 체크섬을 계산하지 않고 -x를 사용합니다. 계산하게 만듭니다. 체크섬은 일반적으로 ICMP ECHO 프로브를 사용할 때 마지막 홉에 필요합니다(-I ), 따라서 ICMP를 사용할 때 항상 계산됩니다.-z 프로브 간 일시 중지 시간(밀리초)을 설정합니다(기본값 0). Solaris 및 Cisco의 라우터와 같은 일부 시스템은 icmp 메시지를 속도 제한합니다. 이것과 함께 사용하기에 좋은 값은 500(예:1/2초)입니다.

결과 해석

Traceroute는 작은 TTL로 UDP 프로브 패킷을 시작한 다음 게이트웨이에서 ICMP "시간 초과" 응답을 수신하여 IP 패킷이 인터넷 호스트로 가는 경로를 간략하게 설명합니다. 1의 TTL로 프로브를 시작하고 ICMP "포트에 연결할 수 없음"(패킷이 목적지에 도착했음을 의미)이 될 때까지 1씩 증가시키거나 최대 시도 값(기본값은 30 홉으로 설정되며 다음으로 변경할 수 있음)에 도달합니다. 강한>-m 플래그.

traceroute가 실행되면 각 TTL 설정에서 세 개의 프로브를 보낸 다음 TTL, 게이트웨이 주소 및 각 프로브의 왕복 시간을 보여주는 라인을 콘솔에 인쇄합니다. 프로브 응답이 다른 게이트웨이에서 오는 경우 각 응답 시스템의 주소가 인쇄됩니다. traceroute가 5초 이내에 응답을 받지 못하는 경우( -w로 변경됨 플래그), 해당 프로브에 대한 별표를 인쇄합니다.

UDP 프로브 패킷 처리가 대상 호스트를 압도하는 것을 방지하기 위해 traceroute는 대상 포트를 장치가 사용하지 않을 값으로 설정합니다. 대상의 네트워크 또는 서비스가 해당 포트를 사용하는 경우 -p를 사용하여 값을 변경합니다. 플래그.

Traceroute 결과 예

샘플 사용 및 출력은 다음 예와 유사한 결과를 반환합니다.

[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), 30 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

두 번째와 세 번째 줄은 동일합니다. 이 결과는 TTL이 0인 패킷을 전달하는 두 번째 홉 시스템(lbl-csam.arpa)의 버그가 있는 커널(4.3 BSD 분산 버전의 버그)과 관련이 있습니다. NSFNet(129.140)이 NSS에 대한 주소 대 이름 변환을 제공하지 않기 때문에 패킷이 국가를 가로질러 가는 경로를 추측해야 합니다.

자동 게이트웨이 예

더 흥미로운 예는 다음과 같습니다.

[yak 72]% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 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

Note that the gateways at 12, 14, 15, 16, and 17 hops away either don't send ICMP "time exceeded" messages or send them with a TTL too small to reach us. Lines 14 through 17 are running the MIT C Gateway code that doesn't send "time exceeded" messages.

The silent gateway 12 in the above example may be the result of a bug in the 4.[23]BSD network code and its derivatives: Machines running 4.3 code and earlier send an unreachable message using whatever TTL remains in the original datagram. For gateways, the remaining TTL is zero, the ICMP "time exceeded" is guaranteed to not make it back to us.

Destination System Silent Gateway Example

The behavior of this bug is slightly more interesting when it appears on the destination system:

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 !

Notice that 12 "gateways" exist (13 is the final destination), and the last half of them are missing. What's really happening is that the server named rip (a Sun-3 running Sun OS 3.5) is using the TTL from our arriving datagram as the TTL in its ICMP reply. So, the reply will time out on the return path (with no notice sent to anyone since ICMPs aren't sent for ICMPs) until we probe with a TTL that's at least twice the path length—in other words, rip is really only seven hops away.

A reply that returns with a TTL of 1 is a clue this problem exists. Traceroute prints a ! after the time if the TTL is less than or equal to 1. Since vendors ship a lot of obsolete (DEC's Ultrix, Sun 3.x) or non-standard (HPUX) software, expect to see this problem frequently and take care picking the target host of your probes.

Other possible annotations after the time are !H, !N, or !P (host, network, or protocol unreachable), !S (source route failed), !F- (fragmentation needed—the RFC1191 Path MTU Discovery value is displayed), !X (communication administratively prohibited), !V (host precedence violation), !C (precedence cutoff in effect), or ! (ICMP unreachable code). These codes are defined by RFC1812, which supersedes RFC1716. If almost all the probes result in some kind of unreachable host, traceroute will give up and exit.

This program is intended for use in network testing, measurement, and management. It should be used primarily for manual fault isolation. Because of the load it could impose on the network, it's unwise to use traceroute during normal operations or from automated scripts.