핵심 요약
- traceroute 명령 실행 시 반드시 지정해야 하는 유일한 인수는 목적지의 호스트 이름 또는 IP 주소입니다.
- 프로브는 TTL 1부터 시작하여 ICMP 'port unreachable' 응답을 받거나 최대 시도 횟수에 도달할 때까지 하나씩 증가시키며 진행됩니다.
이 글에서는 리눅스 환경에서 사용하는 traceroute 명령어를 다룹니다. 명령 스위치(옵션)에 대한 자세한 설명과 함께 결과를 해석하는 방법까지 소개하며, 윈도우에서는 traceroute가 다른 방식으로 사용된다는 점을 참고하세요.
Traceroute 작동 원리
traceroute 명령은 정보 패킷이 출발지에서 목적지까지 이동하는 경로를 추적해 보여줍니다. 이를 활용하면 네트워크 전반에서 데이터 손실이 발생하는 지점을 찾아낼 수 있으며, 이는 특정 노드가 다운되었음을 의미할 수 있습니다.
기록된 각 홉(hop)은 출발 PC와 목표 지점 사이에 존재하는 새로운 서버나 라우터를 나타냅니다. 따라서 traceroute 스캔 결과를 검토하면 네트워크 트래픽에 악영향을 줄 수 있는 병목 지점을 파악할 수 있습니다.
Traceroute를 활용한 문제 해결
네트워크 트래픽이 거치는 실제 경로를 분석하거나, 패킷을 버리고 있는 문제의 게이트웨이를 찾아내는 것은 여러 난제를 동반합니다. traceroute는 IP 프로토콜의 TTL(time to live) 필드를 활용해 목적지 호스트까지의 경로에 있는 각 게이트웨이로부터 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 ]
하나 이상의 선택적 옵션(switch)을 지정하여 명령의 성능이나 출력 결과를 조정할 수 있습니다.
주요 옵션 한눈에 보기
| 옵션 | 설명 |
|---|---|
| -f | 첫 번째 발신 프로브 패킷에 사용할 초기 TTL(time-to-live) 값을 설정합니다. |
| -F | '조각화 금지(don't fragment)' 비트를 설정합니다. |
| -d | 소켓 수준 디버깅을 활성화합니다. |
| -g | 느슨한 소스 라우팅(loose source route) 게이트웨이를 지정합니다(최대 8개). |
| -i | 발신 프로브 패킷의 소스 IP 주소를 얻을 네트워크 인터페이스를 지정합니다. 주로 여러 IP를 가진 멀티홈(multi-homed) 호스트에서 유용합니다. (-s 옵션으로도 같은 작업이 가능합니다.) |
| -I | UDP 데이터그램 대신 ICMP ECHO를 사용합니다. |
| -m | 발신 프로브 패킷의 최대 TTL(최대 홉 수)을 설정합니다. 기본값은 30홉입니다(TCP 연결의 기본값과 동일). |
| -n | 홉 주소를 도메인명 없이 숫자로만 출력합니다. 경로상 각 게이트웨이마다 네임서버 조회를 생략하므로 속도가 빨라집니다. |
| -p | 프로브에 사용할 기본 UDP 포트 번호를 설정합니다(기본값 33434). traceroute는 목적지 호스트의 base부터 base + nhops - 1까지의 UDP 포트에 아무것도 리스닝하지 않기를 기대합니다(ICMP PORT_UNREACHABLE 메시지가 반환되어 경로 추적이 종료됨). 해당 범위의 포트를 이미 사용 중이라면 이 옵션으로 미사용 포트 범위를 지정하세요. |
| -r | 일반 라우팅 테이블을 우회하고 직접 연결된 네트워크의 호스트로 바로 전송합니다. 호스트가 직접 연결된 네트워크에 없으면 오류가 반환됩니다. 라우트가 제거된 인터페이스를 통해 로컬 호스트에 ping을 보낼 때 유용합니다. |
| -s | 발신 프로브 패킷의 소스 주소로 사용할 IP 주소를 지정합니다(보통 호스트명이 아닌 IP 숫자 형태). 멀티홈 호스트에서 프로브가 전송되는 인터페이스의 IP가 아닌 다른 소스 주소를 강제로 지정할 수 있습니다. 지정한 IP가 해당 머신의 인터페이스 주소가 아니면 오류가 반환되고 아무것도 전송되지 않습니다. |
| -t | 프로브 패킷의 type-of-service(TOS) 값을 설정합니다(기본값 0). 값은 0~255 범위의 십진 정수여야 하며, 서로 다른 TOS 값에 따라 경로가 달라지는지 확인하는 데 사용할 수 있습니다. 유용한 값으로는 -t 16(낮은 지연)과 -t 8(높은 처리량)이 있습니다. |
| -v | 상세(verbose) 출력 모드입니다. TIME_EXCEEDED와 UNREACHABLE 외에 수신된 ICMP 패킷도 함께 표시합니다. |
| -w | 프로브 응답 대기 시간을 초 단위로 설정합니다(기본값 5초). |
| -x | IP 체크섬 계산 여부를 전환합니다. 운영체제가 발신 패킷의 일부를 덮어쓰면서 체크섬을 재계산하지 않는 경우가 있어, 기본적으로 체크섬을 계산하지 않으며 -x를 사용하면 계산이 활성화됩니다. ICMP ECHO 프로브(-I) 사용 시 마지막 홉에는 체크섬이 필요하므로 ICMP 사용 시에는 항상 계산됩니다. |
| -z | 프로브 사이의 대기 시간을 밀리초 단위로 설정합니다(기본값 0). Solaris나 Cisco 라우터 등 일부 시스템은 ICMP 메시지에 속도 제한(rate limit)을 두므로, 500(0.5초) 정도의 값을 사용하는 것이 좋습니다. |
결과 해석 방법
traceroute는 작은 TTL 값을 가진 UDP 프로브 패킷을 발사하고 게이트웨이로부터 ICMP 'time exceeded' 응답을 수신함으로써, IP 패킷이 인터넷 호스트까지 이동하는 경로를 그려냅니다. TTL 1부터 프로브를 시작해 하나씩 증가시키며, ICMP 'port unreachable' 응답(패킷이 목적지에 도착했음을 의미)을 받거나 최대 시도 횟수에 도달할 때까지 진행됩니다. 기본 최대값은 30홉이며 -m 옵션으로 변경할 수 있습니다.
traceroute가 실행되면 각 TTL 설정마다 세 개의 프로브를 전송하고, 콘솔에 TTL 값, 게이트웨이 주소, 각 프로브의 왕복 시간(RTT)을 담은 한 줄을 출력합니다. 프로브 응답이 서로 다른 게이트웨이에서 온 경우 각 응답 시스템의 주소가 모두 표시됩니다. 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
두 번째와 세 번째 줄이 동일하게 표시되는데, 이는 두 번째 홉 시스템(lbl-csam.arpa)의 커널 버그 때문입니다. 해당 시스템이 TTL이 0인 패킷을 전달하는 버그(배포판 4.3 BSD의 알려진 문제)가 있는 것입니다. NSFNet(129.140)이 NSS에 대한 주소-이름 변환을 제공하지 않기 때문에, 패킷이 국가를 가로질러 어떤 경로로 이동했는지는 추측만 가능합니다.
무응답 게이트웨이(Silent Gateway) 예시
더 흥미로운 예시를 살펴보겠습니다:
[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
12번, 14번, 15번, 16번, 17번 홉의 게이트웨이들은 ICMP 'time exceeded' 메시지를 보내지 않거나, 너무 작은 TTL로 메시지를 보내 우리에게 도달하지 못한 경우입니다. 14번부터 17번 줄은 'time exceeded' 메시지를 전송하지 않는 MIT C Gateway 코드를 실행 중인 시스템들입니다.
위 예시에서 12번 게이트웨이가 무응답인 것은 4.[23]BSD 네트워크 코드와 그 파생 버전의 버그 때문일 수 있습니다. 4.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 OS 3.5를 실행하는 Sun-3)가 도착한 데이터그램의 TTL을 자신의 ICMP 응답에 그대로 사용한다는 점입니다. 그 결과 응답은 돌아오는 경로에서 타임아웃됩니다(ICMP에 대한 ICMP는 전송되지 않으므로 아무 통지도 없음). 결국 경로 길이의 최소 두 배에 해당하는 TTL로 프로브를 보내야만 하며, 즉 rip은 실제로는 단 7홉 거리에 있는 셈입니다.
TTL이 1로 돌아오는 응답은 이러한 문제가 존재한다는 단서입니다. TTL이 1 이하이면 traceroute는 시간 뒤에 '!'를 출력합니다. 벤더들이 오래된 소프트웨어(DEC의 Ultrix, Sun 3.x)나 비표준 소프트웨어(HPUX)를 많이 배포하기 때문에 이 문제는 자주 마주칠 수 있으니, 프로브 대상 호스트를 신중하게 선택하는 것이 좋습니다.
시간 뒤에 표시될 수 있는 다른 기호들도 있습니다: !H, !N, !P(호스트/네트워크/프로토콜 도달 불가), !S(소스 라우트 실패), !F-(조각화 필요 — RFC1191 Path MTU Discovery 값 표시), !X(관리적으로 통신 금지), !V(호스트 우선순위 위반), !C(우선순위 컷오프 적용), !(ICMP unreachable 코드). 이 코드들은 RFC1716을 대체한 RFC1812에 정의되어 있습니다. 거의 모든 프로브가 일종의 unreachable 호스트로 끝난다면 traceroute는 포기하고 종료합니다.
이 프로그램은 네트워크 테스트, 측정, 관리 목적으로 설계되었습니다. 주로 수동 장애 격리(fault isolation)에 사용해야 하며, 네트워크에 부하를 줄 수 있으므로 평상시 운영 중이나 자동화 스크립트에서 사용하는 것은 바람직하지 않습니다.