지식
[Network] mtr 사용법 — 같은 서버에서 1.1.1.1은 6ms, 8.8.8.8은 50ms가 나오는 이유
요약
mtr은 traceroute와 ping을 합친 네트워크 경로 진단 도구다. 사용법 자체는 5분이면 익히는데, 출력을 읽는 법은 따로 배우지 않으면 계속 오독한다 — 중간 홉의 패킷 손실 90%를 보고 "게이트웨이가 죽어간다"고 결론 내리는 식이다. 이 글은 사용법을 정리한 뒤, 학내망에 물린 리눅스 서버에서 1.1.1.1(Cloudflare) · 8.8.8.8(Google) · github.com 세 곳을 각각 100회씩 실측한 기록을 같이 읽는다. 같은 서버에서 쟀는데 1.1.1.1은 6ms, 8.8.8.8은 50ms가 나온다. 둘 다 정상이고, 그 차이가 mtr이 보여주는 것의 전부다.
mtr이 뭔가
traceroute는 목적지까지의 경로(홉 목록)를 한 번 찍고 끝난다. ping은 목적지 하나에만 반복해서 쏜다. mtr(My Traceroute)은 둘을 합쳤다 — 경로상 모든 홉을 찾아낸 뒤, 각 홉에 계속 패킷을 보내며 홉별 손실률·RTT 통계를 누적한다. 그래서 "어느 구간부터 느려지는가", "손실이 어느 홉에서 시작되는가"를 시간 축까지 포함해 볼 수 있다.
설치는 대부분의 배포판에 패키지로 있다:
sudo apt install mtr-tiny # Debian/Ubuntu (CLI만)
sudo dnf install mtr # RHEL 계열
brew install mtr # macOS기본 사용법
mtr 8.8.8.8이게 전부다. 인터랙티브 TUI가 뜨고 통계가 실시간 갱신된다. q로 종료.
기록·공유용으로는 리포트 모드가 낫다. 이 글의 실측도 전부 이 형태다:
mtr -rwbz -c 100 8.8.8.8| 옵션 | 의미 |
|---|---|
-r |
리포트 모드 — 지정 횟수만 보내고 결과 표만 출력 (스크립트·기록용) |
-w |
wide — 호스트명을 자르지 않음 |
-b |
호스트명과 IP를 둘 다 표시 |
-z |
각 홉의 AS 번호 표시 — 경로가 어느 사업자를 지나는지 보인다 |
-c 100 |
100 사이클 (기본 10 — 손실률 통계를 보려면 100 이상 권장) |
-n |
DNS 역방향 조회 생략 (빠르고, DNS 문제와 분리해서 볼 때) |
-i 0.2 |
패킷 간격 0.2초 — 빨리 끝내고 싶을 때 (기본 1초) |
ICMP가 막힌 구간이 의심되면 프로토콜을 바꿀 수 있다:
mtr -T -P 443 example.com # TCP 443으로 측정 — 실제 서비스 경로와 동일 취급을 받는다
mtr -u example.com # UDP (전통적 traceroute 방식)출력 읽는 법 — 열의 의미
HOST: myserver Loss% Snt Last Avg Best Wrst StDev- Loss% — 그 홉의 응답 손실률. 이 열이 가장 많이 오독된다. 뒤에서 다룬다.
- Snt — 보낸 패킷 수
- Last / Avg / Best / Wrst — 최근 / 평균 / 최소 / 최대 RTT(ms)
- StDev — RTT 표준편차. 지터 지표다. Avg가 낮아도 StDev가 크면 그 홉은 불안정하다.
중요한 전제 하나: 각 홉의 RTT는 "그 라우터까지 갔다 온 시간"이지, 구간별 소요 시간의 누적이 아니다. 게다가 라우터가 자기 앞으로 온 TTL 만료 응답(ICMP Time Exceeded)을 생성하는 건 한가할 때 처리하는 부업이라, 중간 홉의 수치는 얼마든지 최종 홉보다 나쁘게 나올 수 있다.
실측 1 — 1.1.1.1 (Cloudflare): 6ms, 국내에서 끝나는 경로
학내망 서버에서 100 사이클. 교내 구간의 호스트명·공인 IP는 마스킹했다.
HOST: myserver Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway (192.168.0.1) 41.0% 100 0.6 0.6 0.5 0.7 0.1
2. AS(교내) <교내 게이트웨이 A> 0.0% 100 1.1 1.0 0.7 1.3 0.1
3. AS??? 10.100.100.85 0.0% 100 0.9 1.0 0.7 7.6 0.9
4. AS??? 10.100.1.65 0.0% 100 0.8 1.1 0.5 15.8 1.7
5. AS(교내) <교내 게이트웨이 B> 0.0% 100 1.0 1.3 0.7 15.4 1.8
6. AS??? 10.100.1.1 0.0% 100 1.2 1.6 0.9 27.3 3.0
7. AS4766 211.35.241.93 0.0% 100 1.3 4.7 1.1 60.4 7.3
8. AS4766 112.189.225.89 0.0% 100 1.8 3.0 1.7 45.3 4.7
9. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11. AS4766 218.145.42.210 1.0% 100 7.0 8.3 5.7 23.8 3.9
12. AS13335 141.101.82.14 0.0% 100 6.9 12.7 5.9 98.0 13.8
13. AS13335 one.one.one.one (1.1.1.1) 0.0% 100 5.8 5.9 5.4 12.5 1.0읽어보자.
- 경로: 사설 게이트웨이 → 대학 자체 AS(마스킹) 교내 구간 → KT(AS4766) 백본 → Cloudflare(AS13335).
-z덕에 사업자 전환 지점이 그대로 보인다. 참고로 대학은 자기 ASN을 갖는 경우가 많아서, AS 번호 하나가 기관 식별자가 된다 — 그래서 이 글에서는 마스킹했다. - 최종 홉이 판정 기준이다: 1.1.1.1은 손실 0%, 평균 5.9ms, StDev 1.0. 이 경로는 건강하다. 국내(KT–Cloudflare 피어링, 서울)에서 끝나는 경로라 한 자릿수 ms가 나온다.
- 1번 홉의 손실 41%는 가짜다. 목적지 손실이 0%인데 첫 홉만 41%라는 건, 경유 트래픽은 다 통과시키면서 자기 앞으로 온 ICMP 응답 생성만 rate-limit 하고 있다는 뜻이다. 공유기·게이트웨이의 지극히 정상적인 행동이다.
- 9–10번 홉의
???도 문제가 아니다. ICMP Time Exceeded를 아예 안 돌려주는(또는 MPLS 터널 안의) 장비다. 그 뒤 홉들이 멀쩡히 응답하고 목적지 손실이 0%이면 신경 쓸 것 없다. - 12번 홉: Avg 12.7ms에 Wrst 98ms, StDev 13.8 — 그런데 13번(최종)은 5.9ms로 잠잠하다. 중간 홉 수치가 최종보다 나쁜 전형적인 사례다. 저 라우터의 ICMP 응답 처리가 느린 것이지 경유 트래픽이 느린 게 아니다. 12번만 보고 "Cloudflare 입구가 막힌다"고 하면 오진이다.
실측 2 — 8.8.8.8 (Google): 같은 서버인데 50ms
HOST: myserver Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway (192.168.0.1) 97.0% 100 0.6 0.6 0.6 0.6 0.0
2. AS(교내) <교내 게이트웨이 A> 0.0% 100 1.1 1.0 0.8 1.5 0.1
3. AS??? 10.100.100.85 0.0% 100 0.9 1.1 0.7 8.0 1.2
4. AS??? 10.100.1.65 0.0% 100 0.8 1.1 0.6 14.6 1.6
5. AS(교내) <교내 게이트웨이 B> 0.0% 100 1.0 1.4 0.6 27.7 3.3
6. AS??? 10.100.1.1 0.0% 100 1.4 1.5 1.0 19.2 2.4
7. AS1237 210.98.55.9 0.0% 100 1.3 1.8 1.1 35.0 3.4
8. AS1237 134.75.8.121 0.0% 100 3.1 3.4 2.7 24.1 2.4
9. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10. AS17579 hong-rtr--daej-rtr1kreonet2.net 0.0% 100 51.7 51.9 51.5 59.0 0.9
11. AS17579 134.75.108.98 0.0% 100 46.4 46.6 46.1 63.8 1.9
12. AS15169 142.250.60.155 0.0% 100 51.4 51.5 51.0 58.3 1.0
13. AS15169 216.239.47.17 0.0% 100 47.1 47.1 46.8 52.0 0.6
14. AS15169 dns.google (8.8.8.8) 0.0% 100 50.4 50.6 50.2 59.8 1.0- 7번 홉부터 경로가 갈렸다. 1.1.1.1은 KT(AS4766)로 나갔는데, 8.8.8.8은 KREONET(AS1237, 국가과학기술연구망)으로 나간다. 이 학내망은 상용망과 연구망에 이중으로 물려 있고, 목적지에 따라 출구가 달라진다는 게 mtr 한 방에 드러난다.
- 10번 홉에서 RTT가 3ms → 52ms로 점프한다. 홉 이름이 스포일러다:
hong-rtr--daej-rtr1kreonet2— 대전과 홍콩을 잇는 KREONET2 국제 회선이다. 대략 왕복 2,000km대의 해저 구간이니 +48ms는 물리 법칙(빛의 속도)이지 장애가 아니다. - 8.8.8.8은 anycast 주소다. 어느 Google 엣지가 응답할지는 경로가 결정한다. KREONET 경로의 Google 피어링 지점이 홍콩이라 홍콩 엣지가 응답했고, 그래서 50ms다. KT로 나갔다면 국내 캐시 노드가 몇 ms에 응답했을 것이다. "8.8.8.8 핑이 느리니 인터넷이 느리다"는 진단이 위험한 이유이기도 하다 — 그건 그 anycast 목적지까지의 특정 경로가 멀다는 뜻일 뿐이다.
- 참고로 11번(46.6ms)이 10번(51.9ms)보다 가깝게 나온다. 홉 순서와 RTT가 단조증가하지 않는 것 역시 정상이다 — 응답이 돌아오는 경로나 라우터의 응답 처리 시간이 홉마다 다르기 때문이다.
- 1번 홉 손실이 이번엔 97%다. 같은 게이트웨이가 측정 시점에 따라 41%로도 97%로도 나온다는 것 자체가 rate-limit의 증거다. 목적지는 세 측정 모두 0%다.
실측 3 — github.com: 침묵의 5개 홉 뒤에 멀쩡한 목적지
HOST: myserver Loss% Snt Last Avg Best Wrst StDev
1. AS??? _gateway (192.168.0.1) 57.0% 100 0.7 0.6 0.4 0.7 0.1
2. AS(교내) <교내 게이트웨이 A> 0.0% 100 1.2 1.0 0.7 1.4 0.1
3. AS??? 10.100.100.85 0.0% 100 0.9 1.1 0.6 7.9 1.2
4. AS??? 10.100.1.65 0.0% 100 0.9 0.9 0.6 6.6 0.8
5. AS(교내) <교내 게이트웨이 B> 0.0% 100 1.3 1.1 0.8 7.8 0.8
6. AS??? 10.100.1.1 0.0% 100 1.3 1.3 0.9 7.9 0.7
7. AS4766 211.35.241.93 0.0% 100 1.5 2.4 1.3 21.1 3.2
8. AS4766 112.189.225.73 0.0% 100 1.7 3.2 1.3 22.6 4.3
9. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
10. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
11. AS4766 218.145.33.10 7.0% 100 6.2 7.1 5.3 44.5 6.1
12. AS8075 po25.rwa04.sel30.ntwk.msn.net 0.0% 100 6.2 6.2 5.7 20.6 1.5
13. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
14. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
15. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
16. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
17. AS??? ??? 100.0 100 0.0 0.0 0.0 0.0 0.0
18. AS8075 20.200.245.247 0.0% 100 6.0 6.6 5.7 37.0 3.6- 경로: 다시 KT(AS4766)로 나가서 Microsoft(AS8075)로 넘어간다. 12번 홉 이름의
sel30은 서울 PoP이라는 뜻이고, 실제로 최종 RTT가 6.6ms다 — github.com이 이 지역에서는 국내(Azure 서울)에서 서빙된다는 얘기다. GitHub가 Microsoft 소유라는 사실이 AS 번호로도 보인다. - 13–17번, 다섯 홉 연속
???. Microsoft 내부망은 ICMP Time Exceeded를 일절 돌려주지 않는다. 다섯 홉이 침묵해도 18번(최종)이 손실 0%·6.6ms로 응답하므로 아무 문제가 없다. "중간이 안 보인다"와 "중간이 끊겼다"는 다른 말이다 — 끊겼다면 최종 홉도 같이 죽는다. - 11번 홉의 손실 7%는 진짜일까? 판정법은 하나다: 그 손실이 이후 홉으로 이어지는가. 12번과 18번이 모두 0%이므로 이것도 ICMP rate-limit이다. 진짜 경로 손실이라면 그 홉을 지나는 모든 후속 홉에 같은 수준 이상의 손실이 찍혀야 한다.
세 측정을 겹쳐 읽으면
| 목적지 | 출구망 | 응답 위치(추정) | 최종 RTT | 최종 손실 |
|---|---|---|---|---|
| 1.1.1.1 | KT (AS4766) | 국내 (KT–Cloudflare 피어링) | 5.9ms | 0% |
| 8.8.8.8 | KREONET (AS1237→17579) | 홍콩 (KREONET2 국제 회선) | 50.6ms | 0% |
| github.com | KT (AS4766) → Microsoft | 서울 (Azure) | 6.6ms | 0% |
같은 서버, 같은 시각의 측정인데 목적지에 따라 출구 사업자도, 응답 대륙도 다르다. "핑이 몇 ms냐"는 질문은 "어느 목적지로, 어느 경로로"를 붙여야 의미가 생긴다.
오독 방지 3원칙
실측에서 반복해 확인한 규칙을 정리하면:
- 판정은 항상 최종 홉으로 한다. 최종 홉이 손실 0%·RTT 안정이면 중간 홉의 손실·지연·
???는 전부 무시해도 된다. - 중간 홉만의 손실은 rate-limit이다. 진짜 손실은 발생 홉부터 최종 홉까지 연속으로 이어진다. 이번 실측의 1번 홉(41%/97%/57%)과 11번 홉(7%)이 전자의 표본이다.
- RTT 점프는 지리부터 의심한다. +48ms 점프의 원인은 장애가 아니라 홍콩행 해저 케이블이었다. 홉의 역방향 DNS 이름(
hong-rtr--daej-…)에 답이 적혀 있는 경우가 많다.
여기에 하나 더 — 문제를 실제로 잡을 때는 양방향 측정이 원칙이다. mtr이 보여주는 건 왕복 시간이지만 경로는 편도(가는 길)만 보인다. 돌아오는 길은 다른 경로일 수 있으므로, 진짜 장애 분석은 상대편에서 내 쪽으로도 mtr을 떠서 맞춰봐야 완성된다.
조회 0댓글 0
댓글
아직 댓글이 없습니다. 첫 댓글을 남겨보세요.