traceroute / MTR 판정

한 홉의 숫자가 아니라 이후 홉까지 전파되는지를 본다

traceroute의 각 RTT는 해당 홉까지의 왕복 probe 시간, 되돌아오는 경로, 장비의 진단 응답 처리 시간이 섞인 값입니다. 중간 홉 하나의 높은 숫자보다 목적지까지 지속되는 패턴이 더 강한 증거입니다.

Hop 1-2 기준선 낮은 RTT와 0% 손실이 비교 기준이 된다.

Hop 3 응답 없음 이후 홉이 살아 있으면 제한 신호로 먼저 본다.

Hop 4 단일 스파이크 다음 홉에서 회복되면 장애 증거가 약하다.

Hop 7-8 손실 전파 지연과 손실이 뒤쪽 홉까지 이어지는지 본다.

목적지 최종 판정 사용자 체감 장애와 함께 결론을 좁힌다.

baseline Hop 1-2 낮은 RTT와 0% 손실이 반복되면 로컬·초기 ISP 기준선으로 둔다.

mute Hop 3 별표가 떠도 이후 홉이 응답하면 포워딩 장애로 단정하지 않는다.

spike Hop 4 한 홉만 높고 다음 홉이 낮으면 control-plane 지연 후보로 본다.

spread Hop 7-9 손실과 지연이 목적지까지 유지될 때 경로 문제 후보가 된다.

sample evidence map

목적지까지 이어지는지 표 안에서 검증한다

Hop 1-2 기준선 RTT 1-12ms · Loss 0% 로컬·초기 ISP 정상 범위

Hop 3 응답 제한 * * * 뒤에 Hop 4+ 응답 포워딩 장애 단정 금지

Hop 4→5 단일 스파이크 160ms 뒤 32ms 회복 진단 응답 처리 지연

Hop 7-9 전파 신호 180ms대 · Loss 8% 지속 경로 병목 후보

* * *

중간 홉이 Time Exceeded를 보내지 않아도 이후 홉과 목적지가 응답하면 패킷 전달 자체는 이어졌을 가능성이 큽니다.

single-hop spike

라우터가 실제 전달보다 ICMP/UDP 진단 응답 생성을 낮은 우선순위로 처리하거나 제한할 수 있습니다.

propagated loss

특정 홉 이후 지연, 손실, Wrst 상승이 함께 지속되면 그 구간의 혼잡, 품질 저하, 라우팅 우회를 우선 확인합니다.

판정 매트릭스

관찰 단정하지 말 것 다음 확인

중간 홉 Loss 60%, 목적지 Loss 0% 그 홉이 실제로 60%를 버린다고 결론 내리지 않기 목적지 ping/MTR, TCP traceroute로 비교

Hop 4 RTT 160ms, Hop 5 32ms Hop 4 링크가 160ms라고 해석하지 않기 여러 시간대 재측정, probe 방식 변경

Hop 7부터 목적지까지 180ms + 8% Loss 단일 장비 장애로 바로 축소하지 않기 양방향 경로, ISP/peering 구간, 기준선 비교

baseline

몇 ms 이상이라는 절대값보다 평소 대비 상승, 시간대, 재현성을 봅니다.

destination

사용자 체감 장애는 마지막 홉과 실제 서비스 응답에서 확인합니다.

probe mode

UDP, ICMP, TCP probe는 ACL, 방화벽, ECMP 경로 선택의 영향을 받습니다.

corroborate

traceroute, MTR, ping, 애플리케이션 로그를 함께 봐야 원인을 좁힙니다.