Traceroute 동작원리

Traceroute는 ICMP 와 IP 헤더의 TTL필드를 사용한다. TTL필드(time-to- live)는 8 비트 필드로서 송신자는 그 값을 초기화한다. 현재 권고되고 있는 초기값은 구체적으로 64이다. 예전의 시스템은 15에서 32였다.

TTL 필드의 목적은 데이터그램이 전송도중 무한 라우팅 루프에 빠지는 것을 방지하기 위함이다. 예로서 라우터가 스톱하거나 두 라우터간의 접속이 끊겼을 경우 라우팅 프로토콜을 이용해서 잃어버린 경로를 검출하고 그것을 동작시킨다. 이 시간동안 데이터그램이 라우팅루프에서 사라지게 될 수도 있다. TTL필드는 루프를 도는 데이터그램에 상한선을 두게 된다.

만약 라우터가 TTL필드가 0또는 1인 IP 데이터그램을 받았다면, 라우터는 그 데이터그램을 포워드하지 않는다. (이와 같은 데이터그램을 수신한 목적지 호스트는 더 이상 라우트할 필요가 없으므로 이것을 응용 계층으로 보낸다. 그러나 TTL이 0인 데이터그램을 받는 호스트는 거의 없다)

대신에 라우터는 데이터그램을 버리고 원래 호스트에게 ICMP 메시지에 "시간초과"("time exceeded")를 알린다. Traceroute에 있어서의 요점은 ICMP메시지를 포함하고 있는 IP데이터그램이 송신자 주소인 라우터의 IP주소를 포함하고 있다는 것이다.

이제는 Traceroute의 동작에 대해 생각할 수 있을 것이다. 즉 TTL 이 1인 IP 데이터그램을 목적지 호스트에게 보낸다. 데이터그램을 다루는 첫번째 라우터는 TTL을 감소시키고, 데이터그램을 버리고 ICMP 시간 초과를 송신자에게 돌려보낸다. 이것을 통해 경로상에서 첫째 라우터의 위치를 발견한다. 다음에 Traceroute는 TTL 이 2인 데이터그램을 보낸다. 그리하여 두 번째 라우터의 IP 주소를 찾는다. 이것은 목적지 호스트까지 도착할 때까지 계속된다. 그러나 도착한 IP 데이터그램이 TTL 1의 값을 가진다 할 지라도 목적지 호스트는 버리려하지 않고 ICMP시간초과 메시지를 발생시킨다. 왜냐하면 데이터그램은 마지막 목적지에 도착했기 때문이다. 우리는 데이터그램이 어떻게 목적지에 도착했는지 결정할 수 있을까?

Traceroute는 목적지 호스트가 사용하지 않은 것 같은 UDP 포트 번호 (30,000 보다 큰 값)를 선택하여 데이터그램을 보낸다. 이것은 데이터그램이 도착될 때 목적지 호스트의 UDP 모듈이 ICMP "port unreachable" 에러를 발생하게 하는 원인이 된다. 모든 Traceroute는 도착된 ICMP 메시지간에 시간초과(time exceeeded)와 port unreachable를 구별하는 것이 필요하다.

Traceroute 프로그램은 출력 데이터그램의 TTL필드를 설정할 수 있어야 한다. TCP/IP로의 모든 프로그래밍 인터페이스가 이것을 제공하지는 않으며, 모든 구현이 이 능력을 지원하지 않는다. 그러나 대부분의 현재 시스템은 지원하기 때문에 Traceroute를 실행할 수 있다. 이 프로그래밍 인터페이스는 사용자가 슈퍼 유저 권한을 가질 것을 요구한다.

 

1) Traceroute 실행 결과

1-1) UNIX 환경

 

사용법: traceroute [ -m max_ttl ] [ -n ] [ -p port ] [ -q nqueries ]

[ -r ] [ -s src_addr ] [ -t tos ] [ -w ] [ -w waittime ]

host [ packetsize ]

옵션:

ㆍ-m

IP 패킷의 최대 time-to-live를 설정하는 옵션으로 기본값은 30 hops 임

ㆍ-n

홉 주소를 숫자로 표현하여 출력

ㆍ-p

사용되는 UDP port 번호(기본 33434)를 지정하는 옵션

ㆍ-r

목적 호스트가 직접 로컬로 연결되었다고 지정하는 옵션. 만약 목 적 호스트가 로컬 세그먼트가 아니면 에러를 보고

ㆍ-s

traceroute를 사용하는 호스트의 IP 주소를 지정(다른 IP로 지정가 능)하는 옵션

ㆍ-t

패킷에 type-of-service를 지정하는 옵션

ㆍ-v

자세하게 보고하는 옵션

ㆍ-w

전송한 패킷을 기다리는 시간을 설정하는 옵션(기본값 : 3초)

 

다음은 유닉스상에서 Traceroute 프로그램을 이용하여 조선일보의 홈페이지로의 패킷 전송 경로를 추적한 결과이다. 패킷이 무한대로 네트워크를 돌아다니는 것을 막기 위해 30개의 홉을 최대값으로 한다. Traceroute의 출력결과는 순서대로 1, 2, 3의 숫자로 증가하며 매 홉마다 세 개의 패킷을 보내 그 시간을 측정하여 출력한다.

 

$ traceroute www.chosun.com

 

traceroute to www1.chosun.com (203.235.118.2), 30 hops max, 40 byte packets

1 fastrouter.seri.re.kr (150.183.10.1) 1.379 ms 0.891 ms 0.716 ms

2 baram-m.seri.re.kr (134.75.99.1) 1.196 ms 1.189 ms 1.176 ms

3 134.75.3.2 (134.75.3.2) 20.614 ms 4.512 ms 14.256 ms

4 krnic (202.30.94.1) 7.094 ms 6.485 ms 5.260 ms

5 KRNIC-INET-GW.ixseoul.net (203.231.82.1) 7.655 ms 8.591 ms 17.544 ms

6 inet-fddi-fm.nuri.net (203.255.114.236) 16.653 ms 10.246 ms 8.361 ms

7 www1.chosun.com (203.235.118.2) 8.725 ms 7.814 ms 10.339 ms

 

위 결과의 1번 fastrouter.seri.re.kr (150.183.10.1)까지의 도달 시간중 첫번째가 1.379 ms 두번째가 0.891 ms 세 번째가 0.716 ms 만큼의 시간이 걸리는데 그중 첫번째 패킷이 걸린 시간이 두번째와 세번째 패킷이 가는데 걸린 시간보다 큰 것은 처음 목적지인 www.chosun.com을 DNS 에 문의하여 IP를 알아오고 그리고 로컬 라우터의 MAC 주소를 resolv하는데 거리는 시간이 있기 때문이다.

 

다음은 www.microsoft.com을 Traceroute하였을 때의 결과이다. 마이크로소프트사의 홈페이지로의 패킷 전달 경로를 정확히 아는 것은 매우 어렵다는 것을 다음의 결과로서 알 수 있다. 최대 30개의 홉까지 추적한 결과만을 다음과 같이 출력한다.

 

$ traceroute www.microsoft.com

 

traceroute to www.microsoft.com (207.46.130.14), 30 hops max, 40 byte packets

1 fastrouter.seri.re.kr (150.183.10.1) 1.316 ms 0.750 ms 0.796 ms

2 baram-m.seri.re.kr (134.75.99.1) 1.203 ms 1.104 ms 1.295 ms

3 134.75.3.2 (134.75.3.2) 52.014 ms 74.105 ms 49.307 ms

4 oversea-localix-f110-b93.kix.ne.kr(202.30.94.2)15.325 ms 5.288 ms 6.750 ms

5 krnic-inet-localT3.nuri.net(203.231.80.133) 6.590 ms 10.953 ms 19.722 ms

6 203.235.123.5 (203.235.123.5) 12.041 ms 13.303 ms 9.163 ms

7 210.103.218.2 (210.103.218.2) 8.783 ms * 11.408 ms

8 * INET-PA-GW.nuri.net (203.235.119.253) 169.561 ms 170.842 ms

9 * * *

10 * 146.188.147.226 (146.188.147.226) 166.020 ms *

11 * * 189.ATM3-0.TR1.SCL1.ALTER.NET (146.188.147.118) 170.223 ms

12 146.188.137.186 (146.188.137.186) 201.210 ms 206.853 ms 201.061 ms

13 * * 299.ATM7-0.XR1.SEA1.ALTER.NET (146.188.200.109) 203.734 ms

14 146.188.201.33 (146.188.201.33) 202.809 ms 207.260 ms *

15 157.130.177.154 (157.130.177.154) 201.528 ms 205.932 ms *

16 * * *

17 * * *

18 207.46.129.131 (207.46.129.131) 207.073 ms 201.673 ms *

19 * * *

20 * * *

21 * * *

22 * * *

23 * * *

24 * * *

25 * * *

26 * * *

27 * * *

28 * * *

 

 

1-2) Windows 환경

 

사용법 : tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name

 

옵션 :

ㆍ-d

주소를 호스트 이름에 결합하지 않습니다.

 

ㆍ-h

maximum_hops 대상을 검색할 홉의 최대 개수입니다.

ㆍ-j

host-list host-list를 따라 원본 경로를 늦춥니다.

 

ㆍ-w

timeout 각각의 응답 대기 제한 시간(밀리초)입니다.

 

다음은 Windows95/98 도스창에서 tracert 프로그램을 실행한 결과이다.

 

C:WINDOWS>tracert www.hitel.co.kr

 

최대 30개의 홉에서 www.hitel.co.kr [204.252.145.1]로의 경로를 추적하는 중입니다.

1 1 ms 1 ms 1 ms fastrouter.seri.re.kr [150.183.10.1]

2 1 ms 1 ms 1 ms baram-m.seri.re.kr [134.75.99.1]

3 22 ms 22 ms 10 ms gurum.seri.re.kr [134.75.3.2]

4 27 ms 15 ms 18 ms localix-oversea-f50-b91.kix.ne.kr [202.30.94.1]

5 15 ms 23 ms * KRNIC-INET-GW.ixseoul.net [203.231.82.1]

6 12 ms 19 ms * 203.231.82.206

7 10 ms 13 ms 10 ms 210.114.0.66

8 14 ms 10 ms 15 ms www.hitel.co.kr [204.252.145.1]

추적이 완료되었습니다.

 

2). 관련표준

2-1). 개요 - RFC 792 (ICMP)

TRACERT

: 송신측 컴퓨터로부터 목적지 컴퓨터까지 경로상의 라우터 확인 및 지연 시간 검사

- TRACERT를 실행하는 컴퓨터는 TTL값을 1씩 증가하면서 IP 패킷을 송출

- 라우터들은 수신된 IP 패킷을 다음 라우터로 전달하기 전에 IP헤더의 TTL값을 1 감소

- TTL 값을 1감소 시킨 결과가 0이면 라우터는 그 패킷을 버린 후,

   그 패킷의 송신측 컴퓨터에 time exceeded error ICMP 패킷으로 응답

1. 동작원리

 

목적지까지 찾아가는 경로를 파악할 수 있음. 그러나 귀환경로를 알려주는 것은 아님. 즉, 목적지에서 출발지로 traceroute 하면 경로가 다를 수 있다.

 

Win95/98/NT/2K/XP에서는 tracert를 이용. Unix/Linux에서는 traceroute를 이용. (traceroute는 UDP, tracert는 ICMP를 사용) Sam Spade, VisualRoute를 이용하면 보다 시각적으로 결과를 알 수 있음.

 

Traceroute의 동작원리는 다음과 같음

1.1.1.1에서 목적지 10.10.10.10에 대해 TTL=1인 ICMP echo request를 생성/전달 (기본적으로 3개의 UDP 패킷을 보냄)

첫번째 IP네트웍장비가 TTL을 1을 감소시키고 TTL=0이 되므로 TTL이 모자라 더 이상 packet을 전달할 수 없다는 ICMP time exceeded를 1.1.1.1에게 전달

1.1.1.1에서는 이 ICMP time exceeded를 보고 목적지까지 가는 경로상의 첫번째 장비 ip address와 delay를 알아냄.

1.1.1.1에서 TTL=2인 ICMP echo request를 던짐. 목적지까지 가는 경로상의 두번째 장비가 ICMP time exceeded를 발생시키고 1.1.1.1에서는 이것으로 두번째 장비까지의 delay를 알아냄.

이것이 목적지까지 계속됨

 

2. * timeout

 

종종 목적지 중간경로에 있는 장비에서 timeout 현상(별표 *가 나타나는 현상)이 발생하는데 이것이 source와 destination간의 네트웍상태를 정확히 알려주는 것은 아님.

 

몇몇 IP네트웍장비에서는 ICMP packet이 아닌 다른 일반적인 packet에 보다 많은 시간을 할애하도록 설계된 경우가 있는데 해당 IP네트웍장비가 매우 바쁠경우에는 TTL=0인 packet에 대해서 ICMP time exceed등을 생성/전달하지 않는 경우가 많음. 또는 ICMP 메시지의 우선순위가 매우 낮아서 적절한 시간내에 돌아오지 않는 경우도 있음.

 

다른 경우는 중간경로에 있는 IP네트웍장비가 아예 ICMP echo reply 혹은 ICMP time exceeded를 발생하지 않는(막는) 경우인데 주로 이러한 장비들은 Firewall 인 경우가 많음. 그러나 Firewall이라고 해서 ICMP echo reply, ICMP time exceed를 생성하지 않는 것은 아니며, 관리자의 설정에 따라 좌우됨. 또한 몇몇 오래된 라우터는 TTL 값이 0 임에도 불구하고 패킷을 계속 전달하는 경우도 있음.

 

이러한 이유로 traceroute 수행시 중간경로상의 timeout 현상에 대해서는 무시해도 좋으며, 최종목적지와 ping의 상태가 좋은지를 파악하는 것이 보다 중요함.

 

 

3. no resolve

 

traceroute 의 수행상태가 매우 늦게 보여질 때 그 이유는?

source에서 기본적으로 reverse domain name을 점검하기 때문

따라서 noresolve 를 지정하면 결과가 보다 빠르게 보여짐

 

예)

traceroute –n 164.124.116.4 // UNIX

tracert –d 164.124.116.4 // Windows

[ unix : /usr/sbin ] traceroute 211.169.248.190

traceroute to 211.169.248.190 (211.169.248.190), 30 hops max, 40 byte packets

1 ysnacb81-e4-0.rt.dacom.net (164.124.102.3) 3 ms 1 ms 1 ms

2 211.60.241.2 (211.60.241.2) 1 ms 1 ms 1 ms

3 ysng12bb2-pos7-0.rt.bora.net (210.120.255.117) 1 ms 1 ms 2 ms

4 kidcg5-pos9-0.rt.bora.net (210.120.192.198) 2 ms 3 ms 1 ms

5 kidcg6-ge8-0.rt.bora.net (210.92.194.238) 1 ms 1 ms 1 ms

6 211.169.248.254 (211.169.248.254) 1 ms 1 ms 1 ms

7 211.169.248.216 (211.169.248.216) 2 ms 2 ms 2 ms

8 211.169.248.190 (211.169.248.190) 2 ms 2 ms 1 ms

 

[ win: /usr/sbin ] traceroute -n 211.169.248.190

traceroute to 211.169.248.190 (211.169.248.190), 30 hops max, 40 byte packets

1 164.124.102.3 3 ms 1 ms 1 ms

2 211.60.241.2 1 ms 1 ms 1 ms

3 210.120.255.117 1 ms 1 ms 1 ms

4 210.120.192.198 1 ms 1 ms 1 ms

5 210.92.194.238 1 ms 1 ms 1 ms

6 211.169.248.254 1 ms 1 ms 1 ms

7 211.169.248.216 2 ms 2 ms 2 ms

8 211.169.248.190 1 ms 1 ms 1 ms

 

4.

몇 가지 라우팅 문제가 있을 수 있다.

어떤 경우 traceroute는 행의 끝에 느낌표와 한 개의 문자 형식으로 된 추가 메시지를 덧붙인다.

 

!H, !N, !P 는 각각 호스트, 네트웍, 프로토콜에 도달하지 못했음을 나타냄.

!F 는 패킷 분할이 필요함. !S 는 소스 라우팅 실패를 나타냄.

 

sol:/hosting/elca% traceroute 210.116.117.100

traceroute 210.116.117.100

traceroute to 210.116.117.100 (210.116.117.100), 30 hops max, 40 byte packets

1 210.116.105.126 (210.116.105.126) 1 ms 1 ms 1 ms

2 203.231.224.246 (203.231.224.246) 1 ms 1 ms 1 ms

3 203.231.224.190 (203.231.224.190) 1 ms !H * 1 ms !H

 

5. Traceroute Options

 

-m : Set maximum TTL (default 30)

TTL 필드는 8비트 숫자로 되어 있어 255개 까지 홉을 지정할 수 있다.

대부분의 traceroute 구현은 30개 까지의 홉을 시도하고 중단한다.

 

-n : Report IP addresses only (not hostnames)

 

-q : Set the number of queries at each TTL (default 3)

보통 traceroute는 각 TTL 값에 3개의 검사용 패킷을 보내는 데 -q 옵션으로 한 집합 당 패킷의 개수를 변경할 수 있다.

 

-v : Verbose. 더 많은 정보(Source 주소 및 패킷 크기)를 보여준다.

 

-w : Set timeout for replies (default 5 sec)

 

-A : Report AS# at each hop

 

* 위의 옵션은 Unix (Solaris)를 기준으로 한 것임. Linux나 Windows의 경우 다른 옵션을 가지고 있음.