traceroute 결과 읽는 법

traceroute는 네트워크 도구 중에 가장 많이 오해받습니다. 별표가 줄줄이 찍힌 걸 보고 “여기서 끊겼다”고 결론 내린 뒤, 애초에 원인이 아니었던 홉을 반나절 쫓는 일이 흔합니다. 결과에서 불안해 보이는 것의 대부분은 장애가 아니라 도구가 동작하는 방식 때문에 생기는 현상입니다.

실제로 하는 일

모든 IP 패킷에는 TTL이라는 카운터가 있습니다. 패킷을 전달하는 라우터마다 1씩 줄이고, 0으로 만든 라우터는 그 패킷을 버리면서 “시간 초과” 메시지를 돌려보냅니다.

traceroute는 이걸 일부러 악용합니다. TTL을 1로 보내면 첫 번째 라우터에서 죽으면서 그 라우터가 응답합니다. 그다음 2로 보내면 두 번째에서 죽고요. 이렇게 계속합니다.

즉 화면에 보이는 목록은 도구가 따라간 경로가 아닙니다. 각각 한 번씩 항의한 라우터들을 순서대로 세워놓은 것입니다. 아래 헷갈리는 것들이 전부 이 차이에서 나옵니다.

정상적인 결과 읽기

traceroute to example.net (203.0.113.10), 30 hops max
 1  192.168.1.1              1.2 ms   1.1 ms   1.3 ms
 2  10.20.0.1               11.4 ms  10.9 ms  11.2 ms
 3  * * *
 4  198.51.100.9            14.8 ms  15.1 ms  14.6 ms
 5  198.51.100.42           38.2 ms  37.9 ms  38.4 ms
 6  203.0.113.10            39.1 ms  38.8 ms  39.0 ms

1번은 본인 공유기입니다. 2번은 보통 ISP의 첫 장비고요. 숫자 세 개는 각각 다른 시도이므로, 그 홉이 계속 느린 건지 한 번만 튄 건지 구분할 수 있습니다.

이건 건강한 결과입니다. 목적지까지 도달했고, 지연시간이 거리에 맞춰 완만하게 올라갑니다.

별표는 대개 문제가 아닙니다

* * *는 그 라우터가 응답을 안 보냈다는 뜻입니다. 그 라우터가 내린 결정이지, 트래픽이 거기서 멈췄다는 증거가 아닙니다.

라우터는 TTL 초과 메시지 생성을 자기가 하는 일 중 가장 낮은 우선순위로 취급합니다. 바쁜 코어 라우터는 실제 트래픽은 전속력으로 넘기면서 이 탐지 패킷은 무시합니다. 응답을 만드는 데는 CPU가 들지만 전달에는 안 들거든요. 아예 차단해 버리는 사업자도 많습니다.

판단 기준은 그다음 홉들이 응답하느냐입니다. 위 예시에서 3번은 조용하지만 4·5·6번이 정상 응답합니다. 즉 트래픽은 3번을 문제없이 통과했습니다. 중간에 하나 조용한 건 그냥 잡음입니다.

의미 있는 건 끝까지 계속되는 별표입니다. 그건 경로가 실제로 더 나아가지 못한다는 뜻입니다.

튀었다가 다시 내려가는 지연시간

200ms 다음 홉이 40ms인 게 말이 안 돼 보입니다. 숫자가 누적된다고 가정하면 그렇죠. 누적되지 않습니다.

각 숫자는 나 ↔ 그 라우터 한 곳과의 독립적인 왕복 시간입니다. 응답 생성이 굼뜬 라우터는 지나가는 트래픽에 아무 지연도 더하지 않으면서 큰 숫자를 만들어냅니다. 그래서 한 홉에서만 튀고 뒤로 이어지지 않는 값은 그 라우터의 사정일 뿐 내 연결 상태가 아닙니다.

끝까지 이어지는 상승만이 진짜 지연 증가입니다.

돌아오는 길은 안 보입니다

traceroute는 왕복 시간을 재지만 보여주는 건 나가는 절반뿐입니다. 돌아오는 경로는 전혀 다를 수 있고 실제로 자주 다릅니다. 느려 보이는 홉이 사실은 응답만 멀리 돌아오는 라우터일 수 있습니다.

그래서 나에게서 서버로 잰 것과 서버에서 나에게로 잰 것이 완전히 달라도 둘 다 맞을 수 있습니다. 사업자에 문제를 제기한다면 가능하면 양방향으로 재서 보내세요.

진짜 신호인 경우

대응할 가치가 있는 패턴은 네 가지입니다.

• 경로가 멈춘 뒤 복구되지 않음. 특정 홉부터 끝까지 별표가, 여러 번 돌려도 똑같이.
• 마지막 홉에서의 손실. 중간 손실은 위의 우선순위 문제인 경우가 대부분이지만, 목적지에서의 손실은 실제로 내 트래픽이 버려지는 것입니다.
• 올라간 채로 유지되는 지연시간. 한 홉에서 계단식으로 뛰고 그 뒤 홉들이 전부 그걸 물려받는 경우.
• 돌릴 때마다 경로가 바뀜. 어느 정도는 정상적인 부하 분산이지만, 전혀 안정되지 않으면 라우팅 문제일 수 있습니다.

한 번 돌린 결과로는 거의 아무것도 알 수 없습니다. 결론 내리기 전에 서너 번 돌리세요.

명령어

macOS와 Linux:

traceroute example.net

Windows:

tracert example.net

중간에 멈춰버리면 ICMP로 강제하세요. 기본값인 UDP보다 관대하게 취급하는 네트워크가 있습니다:

sudo traceroute -I example.net

이 모든 것보다 나은 건 mtr입니다. traceroute를 계속 돌리면서 홉별 손실률과 지연시간을 실시간 표로 보여줍니다. “이 홉이 계속 나쁜 건가 방금 한 번 그런 건가”를 반복 실행 없이 답해줍니다:

mtr example.net

기본 설치는 아닙니다. Debian·Ubuntu는 sudo apt install mtr, macOS는 brew install mtr입니다. Windows는 WinMTR을 따로 받아야 합니다.

명령어 전체와 각각에서 무엇을 봐야 하는지는 로컬 점검 명령어 페이지에 정리해뒀습니다.

기술지원에 보낼 것

에스컬레이션한다면 이걸 담으세요: 서로 다른 세 번의 실행 결과, 실행한 시각, 상시인지 간헐적인지, 그리고 사람들이 꼭 빼먹는 것 — 잘 되는 목적지로 실행한 결과. 안 되는 곳으로 간 traceroute 하나만으로는 상대가 알 수 있는 게 거의 없습니다. 특정 홉에서 갈라지는 두 개를 같이 주면 어디를 봐야 할지가 바로 나옵니다.

네트워크 리포트가 브라우저 쪽 절반을 대신 모아줍니다. 원하시면 주소를 가린 채로요.