해외 사용자만 서비스가 느리다는 신고가 들어왔습니다. 서버와 앱은 정상인데 중간 경로 어딘가에서 지연이나 손실이 생기고 있습니다.
traceroute와 mtr은 목적지까지의 홉을 보여줍니다. 느린 구간을 찾아야 통신사, 클라우드, 내부망 중 누구에게 넘길지 결정할 수 있습니다.
네트워크 장애 구간 추적 (traceroute / mtr)
인터넷이 느리다, 특정 서버에 접속이 안 된다 — 이런 신고를 받았을 때 어디서부터 조사해야 할까요? ping으로 도달 여부는 확인했지만 어느 구간에서 지연이 발생하는지는 알 수 없습니다. 이 챕터에서는 TTL 원리를 이용해 패킷이 거치는 모든 라우터를 열거하고, 지연 구간을 정확히 특정하는 방법을 배웁니다.
- 1TTL(Time To Live) 감소 원리와 ICMP Time Exceeded 메시지
- 2traceroute가 TTL을 이용해 각 홉을 열거하는 동작 방식
- 3traceroute 출력 해석 — 홉 번호, IP, 3개 RTT, '* * *' 의미
- 4mtr로 실시간 패킷 손실률과 지연 통계를 지속 추적하는 방법
- 5Linux/Windows/macOS 기본 프로토콜 차이 (UDP vs ICMP)
- 6지연 급증 홉 분석과 ICMP 처리 우선순위 해석
which traceroute || apt-get install -y traceroutewhich mtr || apt-get install -y mtrtraceroute google.commtr --report 모드는 일정 횟수 프로브 후 결과를 출력하며, 간헐적 장애 분석에 유용
TTL(Time To Live) 감소 원리와 traceroute 동작 방식
외부 API 호출이 간헐적으로 느려집니다. 서버도 정상, 방화벽도 문제없습니다. "네트워크 어딘가에서 지연이 생기는 것 같다"는 말 외에 더 좁힐 수가 없습니다. 이런 상황에서 traceroute를 실행하면 어느 홉(라우터)에서 지연이 발생하는지 즉시 보입니다. 그런데 TTL 동작 원리를 모르면 traceroute가 어떻게 경로를 추적하는지, 출력의 * * *가 무엇을 뜻하는지 해석할 수 없습니다.
TTL이란 무엇인가
TTL은 IP 패킷 헤더에 포함된 1바이트 정수 필드입니다. 패킷이 라우터를 하나 통과할 때마다 TTL 값이 1씩 감소하며, 값이 0이 되는 순간 해당 라우터는 패킷을 폐기하고 ICMP Type 11 — Time Exceeded 메시지를 출발지로 반환합니다.
이 메커니즘의 원래 목적은 라우팅 루프 방지입니다. 잘못된 라우팅 테이블 설정으로 패킷이 무한히 순환하는 상황을 방지하기 위해, 일정 홉 수를 초과하면 패킷을 강제로 제거합니다.
출발지 PC 라우터 A 라우터 B 목적지 서버
│ │ │ │
│ TTL=1 패킷 전송 ────────▶│ │ │
│ TTL=0 폐기 │ │
│◀─── ICMP Time Exceeded ──│ │ │
│ │ │ │
│ TTL=2 패킷 전송 ────────▶│─────────────────▶│ │
│ │ TTL=0 폐기 │
│◀───────────────────────────── ICMP Time Exceeded ──────────────│(라우터 B에서)
│ │ │ │
│ TTL=3 패킷 전송 ────────▶│─────────────────▶│──────────────────▶│
│◀──────────────────────────────────────────────── ICMP Port Unreachable
traceroute 동작 원리
traceroute는 이 원리를 역이용합니다.
- TTL=1인 패킷을 전송 → 첫 번째 라우터가 ICMP Time Exceeded 반환 → 첫 번째 홉 IP와 응답시간 기록
- TTL=2인 패킷을 전송 → 두 번째 라우터가 ICMP Time Exceeded 반환 → 두 번째 홉 IP와 응답시간 기록
- TTL=N까지 반복 → 최종적으로 목적지에 도달하면 ICMP Port Unreachable(Linux) 또는 ICMP Echo Reply(Windows) 수신
각 TTL 값마다 기본 3개의 프로브 패킷을 보내므로 출력에 3개의 응답 시간이 표시됩니다.
Linux vs Windows 기본 프로토콜 차이
같은 traceroute라도 OS마다 기본 프로토콜이 다릅니다. 방화벽 정책에 따라 UDP가 막히면 ICMP 모드로 전환하면 됩니다.
| OS | 기본 프로토콜 | 목적지 포트 |
|---|---|---|
| Linux | UDP | 33434+n |
| Windows (tracert) | ICMP Echo | — |
| macOS | UDP | 33434+n |
Linux에서 ICMP 모드를 사용하려면 traceroute -I 옵션을 사용합니다. TCP 모드는 traceroute -T -p 80처럼 지정합니다.
traceroute 출력 해석과 mtr 실시간 분석
traceroute google.com을 실행했더니 3번 홉부터 * * *가 계속 나옵니다. 목적지까지 가는지도 모르겠고, 문제가 있는 건지 정상인지도 판단이 안 됩니다. traceroute 출력을 읽을 줄 알고 mtr로 지속 모니터링하는 방법을 알아야 "어느 구간에서 패킷이 막히는가"를 실제로 답할 수 있습니다.
traceroute 출력 구조 이해
# 실습 디렉토리 준비
mkdir -p /tmp/networking/part3/exam_14 && cd /tmp/networking/part3/exam_14
$ traceroute google.com
traceroute to google.com (142.250.196.110), 30 hops max, 60 byte packets
1 192.168.1.1 (192.168.1.1) 0.812 ms 0.734 ms 0.698 ms
2 10.200.0.1 (10.200.0.1) 5.234 ms 5.180 ms 5.201 ms
3 203.0.113.1 (203.0.113.1) 8.445 ms 8.502 ms 8.387 ms
4 * * *
5 72.14.232.85 (72.14.232.85) 12.334 ms 12.298 ms 12.411 ms
6 108.170.252.1 (108.170.252.1) 11.987 ms 12.001 ms 11.956 ms
7 142.250.196.110 (142.250.196.110) 13.221 ms 13.189 ms 13.205 ms
- 핵심 출력—명령 결과에서 성공/실패를 가르는 값을 먼저 확인합니다
- 대상 식별—IP, 포트, 인터페이스, 프로세스명처럼 다음 조치를 결정하는 필드를 봅니다
- 다음 분기—결과가 기대와 다르면 어느 계층을 이어서 점검할지 정합니다
각 컬럼의 의미:
| 컬럼 | 설명 |
|---|---|
| 홉 번호(1, 2, 3...) | 출발지로부터 몇 번째 라우터인지 |
| 호스트명/IP | 해당 라우터의 역방향 DNS 이름과 IP |
| ms 값 3개 | 3번 프로브의 각 왕복 지연시간(RTT) |
* * * | ICMP 응답 없음(차단 또는 타임아웃) |
지연 분석 포인트
- 인접 홉 간 ms 차이가 크면 → 해당 구간 링크 또는 라우터에 병목 의심
- 특정 홉만 높고 이후 정상 → 해당 라우터의 ICMP 처리 우선순위가 낮은 것일 뿐, 실제 데이터 경로는 정상일 수 있음
- 모든 홉이 타임아웃 이후부터 응답 없음 → 해당 구간에서 완전한 차단
mtr — 실시간 지속 추적
mtr은 traceroute와 ping을 결합한 도구입니다. 각 홉으로 프로브를 지속 발송하면서 통계를 실시간 갱신합니다.
$ mtr google.com
My traceroute [v0.94]
hostname (192.168.1.100) 2024-01-15T10:30:00+0900
Keys: Help Display mode Restart statistics Order of fields quit
Packets Pings
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 50 0.8 0.9 0.7 1.8 0.2
2. 10.200.0.1 0.0% 50 5.1 5.2 4.9 6.3 0.3
3. 203.0.113.1 0.0% 50 8.3 8.4 8.1 9.2 0.2
4. ??? 100.0% 50 0.0 0.0 0.0 0.0 0.0
5. 72.14.232.85 0.0% 50 12.2 12.3 12.0 13.1 0.2
6. 142.250.196.110 0.0% 50 13.1 13.2 12.9 14.0 0.2
mtr 출력 컬럼 설명:
| 컬럼 | 의미 |
|---|---|
| Loss% | 패킷 손실률 |
| Snt | 전송한 프로브 수 |
| Last | 가장 최근 RTT(ms) |
| Avg | 평균 RTT(ms) |
| Best | 최소 RTT(ms) |
| Wrst | 최대 RTT(ms) |
| StDev | 표준편차(지터 지표) |
mtr에서 특정 홉의 Loss%가 높더라도 그 이후 홉에서 Loss%가 0%라면, 해당 라우터가 ICMP를 제한적으로 처리하는 것이며 실제 경로 손실이 아닙니다. 최종 목적지 홉의 Loss%가 진짜 지표입니다.
준비 사항
- Linux 시스템 (traceroute 패키지 설치 필요)
- 인터넷 접속 또는 내부 네트워크 대상 서버
traceroute 설치 확인
# 설치 여부 확인
which traceroute
# 없으면 설치
# RHEL/CentOS/Rocky Linux
sudo dnf install -y traceroute
# Ubuntu/Debian
sudo apt-get install -y traceroute
기본 traceroute 실행
# 기본 UDP 모드로 google.com까지 경로 추적
traceroute google.com
# ICMP 모드로 실행 (방화벽 환경에서 더 잘 통과하기도 함)
traceroute -I google.com
# 최대 홉 수를 15로 제한
traceroute -m 15 google.com
# 각 홉에 프로브를 5번 전송 (기본 3번)
traceroute -q 5 google.com
# DNS 역방향 조회 없이 IP만 표시 (더 빠름)
traceroute -n google.com
내부망 서버 경로 추적
# 내부 서버로 경로 추적
traceroute -n 10.0.0.100
# TCP 모드로 HTTP 포트 경로 추적 (방화벽 통과 테스트에 유용)
traceroute -T -p 80 10.0.0.100
결과 해석 연습
아래와 같은 출력을 보고 문제 구간을 찾아보세요.
1 192.168.1.1 1 ms 1 ms 1 ms
2 10.200.0.1 5 ms 5 ms 5 ms
3 203.0.113.1 9 ms 9 ms 9 ms
4 203.0.114.5 185 ms 190 ms 188 ms ← 지연 급증!
5 72.14.200.1 15 ms 14 ms 15 ms ← 이후 정상
6 142.250.10.1 18 ms 17 ms 18 ms
홉 4에서 지연이 급증했지만 홉 5부터 정상입니다. 이는 홉 4 라우터가 ICMP를 낮은 우선순위로 처리하는 것으로, 실제 데이터 경로에는 문제가 없을 가능성이 높습니다.
# 확인을 위해 목적지에 직접 ping으로 실제 RTT 측정
ping -c 10 142.250.10.1
mtr 설치 및 기본 실행
# 설치
sudo dnf install -y mtr # RHEL 계열
sudo apt-get install -y mtr # Debian 계열
# 대화형 모드로 실행
mtr google.com
# 비대화형(리포트) 모드 — 100개 패킷 후 결과 출력
mtr --report --report-cycles 100 google.com
# DNS 없이 IP만 표시
mtr -n google.com
# TCP 모드로 특정 포트 경로 추적
mtr --tcp --port 443 google.com
mtr 리포트 모드로 결과 파일 저장
# JSON 형태로 저장 (파싱 자동화에 유용)
mtr --json --report --report-cycles 50 google.com > /tmp/mtr_result.json
# 텍스트 리포트를 파일에 저장
mtr --report --report-cycles 100 google.com | tee /tmp/mtr_$(date +%Y%m%d_%H%M%S).txt
패킷 손실이 있는 경우 판별
# 비대화형 모드 실행
mtr --report --report-cycles 100 -n 8.8.8.8
예시 출력:
HOST: myserver.example.com Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 100 0.9 0.9 0.7 1.5 0.1
2. 10.200.0.1 0.0% 100 5.1 5.2 4.9 6.1 0.2
3. 203.0.113.1 30.0% 100 8.4 8.3 8.0 9.5 0.3 ← 손실!
4. 203.0.114.5 0.0% 100 12.1 12.2 11.9 13.0 0.2
5. 8.8.8.8 0.0% 100 12.5 12.6 12.2 13.4 0.2
홉 3에서 30% 손실이 있지만 홉 4, 5에서 0%입니다. 이는 홉 3 라우터의 ICMP 속도 제한(rate limiting)이며, 실제 경로는 정상입니다. 목적지(8.8.8.8)의 Loss%가 0%인 것이 핵심입니다.
반면 목적지 홉의 Loss%가 높다면 실제 패킷 손실입니다.
# 지속적으로 모니터링하며 간헐적 손실 파악
watch -n 30 'mtr --report --report-cycles 20 -n 8.8.8.8 | tail -20'
시나리오
본사 직원들로부터 "지점 서버(10.100.5.50)에 접속이 느리다"는 신고가 들어왔습니다. 네트워크 경로를 추적해 병목 구간을 찾아야 합니다.
단계 1 — 기본 연결 상태 확인
# 1. ping으로 지연시간과 손실률 먼저 확인
ping -c 20 10.100.5.50
# 예시 출력
# rtt min/avg/max/mdev = 45.2/180.3/350.1/95.4 ms
# 평균 180ms, 최대 350ms → 비정상적으로 높음
# 정상 기대치: 지점 간 전용선이면 10~30ms
단계 2 — traceroute로 경로 확인
# DNS 없이 빠르게 경로 확인
traceroute -n 10.100.5.50
# 출력 예시
# 1 192.168.1.1 1 ms 1 ms 1 ms (사무실 공유기)
# 2 10.10.0.1 2 ms 2 ms 2 ms (본사 코어 스위치)
# 3 172.16.0.1 3 ms 3 ms 3 ms (본사 엣지 라우터)
# 4 100.64.0.1 145 ms 148 ms 150 ms ← 통신사 구간 지연 급증
# 5 100.64.1.5 147 ms 149 ms 151 ms
# 6 10.100.0.1 148 ms 152 ms 149 ms (지점 엣지 라우터)
# 7 10.100.5.50 152 ms 155 ms 153 ms
홉 4(통신사 구간)에서 지연이 급증합니다. 본사-지점 전용선(MPLS/SD-WAN) 구간 문제가 의심됩니다.
단계 3 — mtr로 손실률 확인
mtr --report --report-cycles 100 -n 10.100.5.50
HOST: hq-server Loss% Snt Last Avg Best Wrst StDev
1. 192.168.1.1 0.0% 100 1.0 1.0 0.8 1.8 0.1
2. 10.10.0.1 0.0% 100 2.1 2.1 1.9 2.8 0.1
3. 172.16.0.1 0.0% 100 3.2 3.2 3.0 3.9 0.1
4. 100.64.0.1 15.0% 100 148.0 150.5 144.0 320.0 28.3 ← 손실+고지연
5. 100.64.1.5 0.0% 100 149.0 151.0 145.0 310.0 27.1
6. 10.100.5.50 0.0% 100 153.0 155.0 148.0 325.0 27.8
홉 4에서 15% 손실과 높은 표준편차(지터)가 확인됩니다. 이 경우 목적지에서도 간헐적 손실이 있을 수 있습니다.
단계 4 — 증거 수집 및 통신사 신고
# 양방향 확인 (지점에서 본사 방향도)
# 지점 서버에 SSH 접속 후
mtr --report --report-cycles 100 -n 192.168.1.100
# 결과를 타임스탬프와 함께 저장
mtr --report --report-cycles 200 -n 10.100.5.50 \
| tee /tmp/mtr_hq_to_branch_$(date +%Y%m%d_%H%M%S).txt
# 홉 4 IP로 통신사 ASN 조회
whois 100.64.0.1 | grep -E "origin|netname|OrgName"
수집된 결과(구간 IP, 손실률, 지연 시간, 타임스탬프)를 통신사 NOC에 제출합니다.
증상
$ traceroute 10.50.0.100
traceroute to 10.50.0.100 (10.50.0.100), 30 hops max, 60 byte packets
1 * * *
2 * * *
3 * * *
...
30 * * *
30홉 내내 응답이 없고 목적지에도 도달하지 못합니다.
원인 분석
가능한 원인 1 — 방화벽이 UDP/ICMP를 전면 차단
기업 방화벽이 UDP(33434~33534)와 ICMP를 모두 차단하는 경우.
# TCP 모드로 전환하여 확인
traceroute -T -p 80 10.50.0.100 # HTTP 포트
traceroute -T -p 443 10.50.0.100 # HTTPS 포트
traceroute -T -p 22 10.50.0.100 # SSH 포트
# 또는 ICMP 모드
traceroute -I 10.50.0.100
# 실제 서비스 접속이 되는지 확인
nc -zv 10.50.0.100 80
curl -v --connect-timeout 5 http://10.50.0.100/
가능한 원인 2 — 라우팅 테이블에 경로 없음
# 라우팅 테이블 확인
ip route show
ip route get 10.50.0.100 # 특정 목적지 경로 조회
# 출력 예: 경로 없음
# RTNETLINK answers: Network is unreachable
가능한 원인 3 — ARP 실패 (같은 서브넷인 경우)
# 같은 서브넷이면 ARP 테이블 확인
arp -n | grep 10.50.0.100
# 또는
ip neigh show | grep 10.50.0.100
해결 방법
- TCP 모드 traceroute로 실제 서비스 포트 경로를 추적합니다.
ip route get [목적지]명령으로 라우팅 경로를 먼저 확인합니다.ping먼저 시도하여 기본 ICMP 연결 여부를 확인합니다.nc -zv [IP] [포트]로 TCP 레벨 연결 가능 여부를 테스트합니다.
증상
mtr 리포트에서 3번 홉의 손실률이 50%로 표시되지만, 실제 서비스는 정상 동작합니다.
HOST: my-server Loss% Snt Last Avg Best Wrst
1. 192.168.1.1 0.0% 50 0.9 0.9 0.8 1.2
2. 10.200.0.1 0.0% 50 5.1 5.2 5.0 5.9
3. 203.0.113.1 50.0% 50 8.5 8.4 8.1 9.2 ← 손실?
4. 72.14.200.1 0.0% 50 12.0 12.1 11.8 12.9
5. 142.250.10.1 0.0% 50 13.2 13.3 13.0 14.0
원인
홉 3 라우터가 ICMP Time Exceeded 응답에 **속도 제한(rate limiting)**을 적용하고 있습니다. 이는 라우터 CPU 보호를 위한 정상적인 운영 정책입니다. 실제 포워딩 경로의 트래픽은 정상적으로 전달됩니다.
판단 기준
| 상황 | 의미 |
|---|---|
| 중간 홉 Loss% 높음, 목적지 Loss% = 0% | 라우터 ICMP 속도 제한 — 정상 |
| 중간 홉 Loss% 높음, 목적지 Loss% > 0% | 실제 경로 손실 — 장애 조사 필요 |
| 목적지 Loss% = 0%이지만 Wrst(최대 지연) 매우 높음 | 간헐적 지연 — 지터 문제 |
올바른 진단 방법
# 1. 목적지 홉의 Loss%와 Wrst에 집중
mtr --report --report-cycles 200 -n 목적지IP
# 2. 실제 TCP 연결 지연 측정
curl -o /dev/null -s -w \
"DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTotal: %{time_total}s\n" \
http://목적지IP/
# 3. 애플리케이션 레벨에서 응답 시간 직접 측정
time curl -s http://목적지IP/ > /dev/null
실무에서 traceroute/mtr을 사용하는 상황
1. 사용자 민원 대응
"인터넷이 느리다", "특정 사이트가 느리다"는 신고를 받으면 가장 먼저 traceroute와 mtr로 어느 구간에서 지연이 발생하는지 확인합니다. ISP 구간 문제인지, 내부망 문제인지, 목적지 서버 문제인지 신속하게 구분할 수 있습니다.
2. 신규 회선 개통 검증
새로운 인터넷 전용선이나 MPLS 회선을 개통했을 때 traceroute로 경로가 의도한 대로 구성되었는지, 지연 시간이 SLA에 부합하는지 검증합니다.
3. 통신사 장애 신고 근거 자료
통신사 NOC(Network Operations Center)에 장애를 신고할 때 mtr 리포트(타임스탬프 포함)를 첨부하면 정확한 구간 정보를 제공할 수 있어 처리가 빨라집니다.
4. 정기 모니터링 자동화
#!/bin/bash
# 매시간 mtr 리포트를 저장하는 cron 스크립트
TARGETS="8.8.8.8 10.100.5.50 203.0.113.100"
LOG_DIR="/var/log/mtr"
mkdir -p "$LOG_DIR"
for target in $TARGETS; do
filename="${LOG_DIR}/mtr_${target}_$(date +%Y%m%d_%H%M%S).txt"
mtr --report --report-cycles 50 -n "$target" > "$filename"
done
크론탭에 등록:
# crontab -e
0 * * * * /usr/local/bin/mtr-monitor.sh
자격증 시험 관련 포인트
- CCNA / CCNP: TTL 원리, ICMP Time Exceeded 메시지 구조는 필수 지식
- Linux LPIC / RHCE: traceroute, mtr 명령 옵션과 출력 해석
- AWS/GCP 인증: 클라우드 VPC 내 경로 추적, Transit Gateway 홉 분석에도 동일 원리 적용
클라우드 환경에서의 주의사항
AWS, Azure, GCP 등 클라우드 환경에서는 ICMP를 보안 그룹/방화벽 규칙으로 차단하는 경우가 많습니다. 이 경우 traceroute -T -p 443처럼 TCP 모드를 사용하거나, 클라우드 콘솔의 Network Reachability Analyzer 같은 전용 도구를 활용합니다.
핵심 명령어 정리
| 명령 | 설명 |
|---|---|
traceroute 목적지 | 기본 UDP 모드로 경로 추적 |
traceroute -n 목적지 | DNS 역조회 없이 IP로만 표시 |
traceroute -I 목적지 | ICMP 모드 |
traceroute -T -p 80 목적지 | TCP 80 포트 모드 |
traceroute -m 20 목적지 | 최대 홉 수 20으로 제한 |
mtr 목적지 | 실시간 대화형 추적 |
mtr --report -n 목적지 | 비대화형 리포트 모드 |
mtr --report-cycles 100 목적지 | 100개 패킷 후 리포트 |
mtr --tcp --port 443 목적지 | TCP 모드 mtr |
정리
- TTL 감소 원리를 이용해 traceroute는 각 홉의 라우터 IP와 응답시간을 수집합니다.
* * *는 ICMP 차단을 의미하며 반드시 장애는 아닙니다. TCP 모드로 우회 테스트합니다.- mtr은 지속적인 통계 수집으로 간헐적 패킷 손실과 지터를 파악하는 데 유용합니다.
- 중간 홉의 높은 Loss%는 ICMP 속도 제한일 수 있으며, 목적지 홉의 Loss%가 실제 장애 판단 기준입니다.
- 실무에서는 mtr 리포트를 파일로 저장하여 통신사 신고 근거로 활용합니다.