traceroute가 TTL을 하나씩 늘리는 이유와 중간 홉의 응답이 없을 때의 해석은 무엇인가요?

IPv4 라우터는 packet이 지나갈 때 TTL을 줄이고, 0이 되면 packet을 버린 뒤 ICMP Time Exceeded type 11/code 0을 보낼 수 있습니다. traceroute는 이 규칙을 이용해 TTL 1, 2, 3처럼 probe의 초기 TTL을 늘립니다. TTL 1은 첫 라우터에서, TTL 2는 둘째 라우터에서 만료되므로 각 응답의 source를 중간 홉의 관찰값으로 사용할 수 있습니다.

예를 들어 TTL 1 probe가 R1에서 만료되고 type 11/code 0을 받았다면 R1까지는 갔다는 뜻입니다. TTL 2 probe가 R2에서 같은 응답을 받으면 R1을 지나 R2까지의 관찰이 추가됩니다. UDP 방식에서는 목적지의 사용하지 않는 port에 도달했을 때 type 3/code 3이 최종 종료 신호가 될 수 있습니다. 하지만 이 결과는 특정 probe 경로의 제어 응답이지 애플리케이션 요청의 완전한 경로와 같지는 않습니다.

중간 홉의 *는 그 probe의 ICMP 응답을 관찰하지 못했다는 뜻입니다. 라우터의 ICMP rate limit, 방화벽, 비대칭 반환 경로, ECMP, 응답 우선순위 때문에 forwarding은 계속되는데 응답만 없을 수 있습니다. 그러므로 그 홉부터 단절됐다고 단정하지 않고 뒤 홉과 실제 서비스 요청의 성공 여부를 함께 봅니다.

또한 같은 TTL을 세 번 보내도 세 응답이 같은 라우터에서 오지 않을 수 있습니다. ECMP가 probe의 흐름 키를 다르게 해 다른 경로를 선택할 수 있기 때문입니다. 분석자는 hop 번호별 첫 주소만 고정하지 말고 probe별 source, 응답 지연, 최종 서비스 성공을 함께 저장해야 합니다. 그래야 제어 plane의 응답 제한을 경로 단절로 오인하지 않습니다.

TTL 1과 TTL 2의 응답이 모두 없더라도 첫 홉부터 고장이라고 단정할 수 없습니다. 반환 경로에서 ICMP만 차단되었거나 라우터가 제어 메시지를 낮은 우선순위로 처리할 수 있기 때문입니다. 반대로 뒤 홉과 최종 서비스가 계속 응답한다면 forwarding 경로는 살아 있고 관찰 채널만 제한됐을 가능성이 큽니다.