[Network] 11. 길을 잃은 편지가 영원히 돌면 어떻게 될까?

TCP/IP를 우편 시스템으로 이해하기 — Part 3. 수많은 길 가운데 다음 길을 고르는 법

ㅁ 들어가며

경로가 없으면 라우터는 패킷을 더 이상 전달할 수 없다.

하지만 잘못된 경로가 있으면 패킷은 멈추지 않고 엉뚱한 방향으로 갈 수 있다.

R1은 목적지로 가려면 R2에게 보내야 한다고 생각하고,

R2는 같은 목적지로 가려면 R1에게 보내야 한다고 생각해 보자.

Destination Network: 10.30.0.0/24

R1 Route: 10.30.0.0/24 via R2
R2 Route: 10.30.0.0/24 via R1

 

패킷은 두 라우터 사이를 오간다.

R1 → R2 → R1 → R2 → R1 → ...

IP Packet에는 요청이 지나온 경로 목록이 없으므로 라우터는 “아까 본 패킷”이라는 이유만으로 전달을 멈추지 않는다.

 

그렇다면 패킷은 영원히 네트워크 자원을 점유할까?

IPv4 Header에는 TTL(Time To Live)이라는 안전장치가 있다.

라우터를 지날 때마다 값이 줄고, 더 이상 전달할 수 없는 순간에는 ICMP Time Exceeded가 패킷의 수명이 끝났음을 알린다.

 

이번 글에서는 Routing Loop, TTL, Hop Limit, ICMP Time Exceeded를 살펴보고,

traceroute가 이 안전장치를 이용해 보이지 않는 라우터를 발견하는 원리를 알아본다.

 

---

ㅁ 두 우체국이 서로를 다음 배송지로 가리킨다

민수의 편지가 제주도로 가야 한다고 생각해 보자.

서울 우체국의 안내표에는 다음과 같이 적혀 있다.

제주도 편지 → 대전 우체국으로

 

 

그런데 대전 우체국의 안내표에는 반대로 적혀 있다.

제주도 편지 → 서울 우체국으로

서울은 대전으로 보내고 대전은 다시 서울로 보낸다.

두 우체국 모두 자신의 안내표를 정상적으로 따르고 있지만 편지는 제주도에 가까워지지 않는다.

네트워크에서도 각 라우터의 Route Entry가 서로를 Next Hop으로 가리키면 Routing Loop가 생긴다.

 

 

다음 토폴로지를 보자.

Client ── R1 ── R2
          ↑     │
          └─────┘

목적지: 10.30.0.10

 

 

R1과 R2가 가진 경로가 다음과 같다고 하자.

R1: 10.30.0.0/24 via R2
R2: 10.30.0.0/24 via R1

R1은 Routing Table Lookup 결과에 따라 R2로 보낸다.

R2도 같은 목적지 주소를 보고 자신의 테이블에 따라 R1로 돌려보낸다.

각 결정만 보면 규칙에 맞지만 두 결정을 연결하면 원이 된다.

---

ㅁ L2 Loop와 Routing Loop는 무엇이 다를까?

앞에서 스위치 사이의 L2 Loop도 살펴보았다.

두 루프는 경로가 원을 만든다는 점은 같지만 영향을 만드는 방식이 다르다.

구분	L2 Loop	L3 Routing Loop
전달 단위	Ethernet Frame	IP Packet
대표 원인	스위치 사이의 순환 링크	라우터의 잘못되거나 수렴 중인 경로 정보
수명 제한	일반 Frame에 스위치 홉 TTL 없음	IPv4 TTL 또는 IPv6 Hop Limit 있음
대표 증상	Broadcast Storm, MAC Flapping	반복되는 Router Hop, TTL Exceeded
대표 방지·완화	STP/RSTP로 논리적 루프 제거	경로 설계·프로토콜 루프 방지와 TTL

 

L2 Loop에서는 브로드캐스트 프레임이 여러 포트로 복제되며 급격히 늘어날 수 있다.

Routing Loop에서는 일반적으로 하나의 IP Packet이 라우터 사이를 반복해 이동한다.

각 라우터가 링크에 맞는 새 L2 Frame을 만들지만 안쪽 IP Packet의 목적지는 그대로다.

 

TTL이 있으므로 한 패킷이 영원히 돌지는 않는다.

그러나 새로운 패킷이 계속 들어오면 각 패킷은 TTL이 소진될 때까지 반복 전달되므로 링크와 라우터 자원을 계속 낭비할 수 있다.

 

TTL은 Routing Loop의 원인을 고치는 기능이 아니다.

루프가 생겼을 때 한 패킷의 피해를 유한하게 만드는 최후의 안전장치다.

---

ㅁ TTL은 시간일까, 횟수일까?

TTL의 이름은 Time To Live, 즉 살아 있을 시간이다.

하지만 일반적인 IP Forwarding에서 관찰하는 핵심 동작은 라우터를 통과할 때마다 값이 최소 1씩 감소하는 것이다.

Source에서 TTL 64로 전송
Router 1 통과 후 TTL 63
Router 2 통과 후 TTL 62
Router 3 통과 후 TTL 61

 

실질적으로 패킷이 통과할 수 있는 Router Hop의 수를 제한한다.

IPv4 TTL 필드는 8비트이므로 0부터 255까지 표현할 수 있다.

송신 운영체제가 초기값을 정하며 흔히 64, 128, 255 같은 값을 볼 수 있지만 시스템과 프로토콜에 따라 달라질 수 있다.

 

초기 TTL을 보고 운영체제를 추측하는 기법도 있지만

중간 장비와 설정이 값을 바꿀 수 있으므로 확정적인 식별 방법은 아니다.

IPv6에서는 같은 목적의 필드를 Hop Limit이라고 부른다.

 

이름이 실제 동작을 더 직접적으로 표현한다.

IPv4 : TTL
IPv6 : Hop Limit

---

ㅁ 라우터는 TTL을 언제 줄일까?

라우터가 IPv4 Packet을 전달할 때의 흐름을 단순화하면 다음과 같다.

1. Ethernet Frame을 수신한다.
2. 안쪽 IPv4 Packet을 확인한다.
3. TTL을 감소시킨다.
4. TTL이 유효한지 확인한다.
5. Routing Table을 조회하고 다음 Link로 전달한다.

 

TTL이 감소해 0이 되면 라우터는 패킷을 다음 홉으로 전달하지 않고 폐기한다.

TTL은 IPv4 Header의 일부다.

값이 바뀌면 IPv4 Header Checksum도 갱신해야 한다.

Payload의 내용이나 Destination IP가 TTL 감소 때문에 바뀌는 것은 아니다.

바뀌는 값: TTL, IPv4 Header Checksum, 다음 링크의 L2 Header
유지되는 값: 일반 라우팅에서 Source IP, Destination IP, Payload

 

IPv6 기본 Header에는 IPv4와 같은 Header Checksum이 없으므로

Hop Limit 감소 때문에 IP Header Checksum을 다시 계산하는 과정은 없다.

---

ㅁ TTL 4인 패킷이 루프에 들어가면 어떻게 될까?

Client가 초기 TTL 4로 패킷을 보냈다고 하자.

Client → R1 → R2 → R1 → R2

각 라우터에서 보이는 값을 따라가 보자.

순서	패킷을 받은 라우터	수신 시 TTL	전달 시 TTL	결과
1	R1	4	3	R2로 전달
2	R2	3	2	R1로 전달
3	R1	2	1	R2로 전달
4	R2	1	0	폐기

패킷은 목적지에 도착하지 못하지만 네 번째 라우터 처리에서 수명이 끝난다.

초기 TTL이 64라면 더 오래 순환하고, 255라면 더 많은 라우터 처리를 거칠 수 있다. 그래도 한 패킷의 순환 횟수는 유한하다.

라우터는 수명이 끝난 사실을 Source에게 알리기 위해 ICMP 메시지를 만들 수 있다.

---

ㅁ 수명이 끝난 편지는 어떤 답장을 보낼까?

IPv4 Router는 Forwarding 중 TTL이 만료된 패킷을 폐기하고

일반적으로 ICMP Time Exceeded 메시지를 Source로 보낸다.

IPv4 ICMP에서는 다음 값으로 표현한다.

Type 11 : Time Exceeded
Code 0  : Time to Live exceeded in transit

ICMP 메시지에는 문제가 발생한 원래 IP Header와 상위 계층을 식별하는 데 필요한 원래 패킷의 일부가 포함된다.

Source는 어떤 전송에 대한 오류인지 연결할 수 있다.

Router → Source
ICMP Time Exceeded
“이 패킷은 전달 중 TTL이 끝났다.”

 

하지만 ICMP 메시지도 새로운 IP Packet이다.

Source로 돌아가는 Route가 없거나 Firewall이 ICMP를 차단하면 Source는 Time Exceeded를 받지 못할 수 있다.

TTL은 원래 패킷을 폐기하는 안전장치로는 동작하지만, 오류 메시지가 반드시 송신자에게 보인다고 보장하지는 않는다.

IPv6에서는 ICMPv6 Time Exceeded가 Hop Limit 만료를 알린다.

---

ㅁ traceroute는 일부러 수명이 짧은 패킷을 보낸다

traceroute는 TTL 만료를 장애가 아니라 관찰 도구로 이용한다.

먼저 TTL 1인 Probe Packet을 보낸다.

TTL 1
Source → R1

R1이 TTL을 0으로 만들고 ICMP Time Exceeded를 돌려준다.

Source는 첫 번째 Hop이 R1이라는 단서를 얻는다.

다음에는 TTL 2인 Probe를 보낸다.

TTL 2
Source → R1 → R2

R1을 지나 TTL 1이 되고 R2에서 0이 된다. R2가 ICMP Time Exceeded를 보내면 두 번째 Hop을 알 수 있다.

이 과정을 TTL 3, 4, 5로 늘려 반복한다.

TTL 1 → 첫 번째 Router 응답
TTL 2 → 두 번째 Router 응답
TTL 3 → 세 번째 Router 응답
...

목적지에 도착하면 Probe 방식에 따라 다른 종료 응답을 받는다.

• 전통적인 UDP Probe는 닫힌 높은 Port에 도착해 ICMP Port Unreachable을 받을 수 있다.
• ICMP Echo Probe는 Echo Reply를 받을 수 있다.
• TCP Probe는 SYN-ACK 또는 RST 같은 TCP 응답을 받을 수 있다.

운영체제와 traceroute 구현, 옵션에 따라 사용하는 Probe Protocol은 다르다.

traceroute는 라우터가 가진 전체 지도를 읽어 오는 명령이 아니다.

서로 다른 TTL의 Probe를 보내고 각 수명이 끝난 위치에서 돌아온 응답을 모아 경로를 추론하는 명령이다.

---

ㅁ Routing Loop는 traceroute에서 어떻게 보일까?

R1과 R2 사이에 Loop가 있으면 Hop 목록에서 같은 주소가 반복될 수 있다.

1  192.0.2.1   R1
2  192.0.2.2   R2
3  192.0.2.1   R1
4  192.0.2.2   R2
5  192.0.2.1   R1
6  192.0.2.2   R2

TTL을 늘린 Probe가 같은 두 라우터에서 번갈아 만료되므로 반복 패턴이 나타난다.

하지만 주소 반복만으로 모든 Routing Loop를 완벽히 증명할 수 있는 것은 아니다.

• ECMP 때문에 Probe마다 다른 경로를 사용할 수 있다.
• 라우터가 ICMP 응답에 사용하는 Source IP가 예상과 다를 수 있다.
• ICMP Rate Limiting 때문에 일부 Hop이 *로 보일 수 있다.
• Firewall이 특정 Probe 또는 응답을 차단할 수 있다.
• Forward Path와 ICMP Return Path가 서로 다를 수 있다.

traceroute의 반복 패턴은 강한 단서다.

실제 각 라우터의 Route Lookup과 인터페이스 캡처를 함께 확인해야 원인을 확정할 수 있다.

---

ㅁ TTL을 크게 늘리면 통신이 될까?

Routing Loop에서 TTL이 만료되므로 TTL을 크게 설정하면 목적지에 도착할 것처럼 생각할 수 있다.

하지만 경로 정보가 서로를 가리키는 한 패킷은 목적지 방향으로 나아가지 않는다. TTL을 늘리면 더 오래 순환할 뿐이다.

TTL 64  → Loop를 64 Hop 이내에서 종료
TTL 255 → 더 오래 순환한 뒤 종료

TTL을 높이는 것은 Routing Loop의 해결책이 아니다.

 

고쳐야 하는 것은 잘못된 Route Entry다.

잘못된 상태
R1: 10.30.0.0/24 via R2
R2: 10.30.0.0/24 via R1

해결 방향 예시
R2: 10.30.0.0/24를 실제 목적지 Interface 또는 올바른 Next Hop으로
R1: R2를 통해 정상 경로 사용

모르는 목적지를 서로의 Default Route로 넘기는 구조도 Loop를 만들 수 있다.

경로를 삭제하는 것과 Blackhole 또는 Unreachable Route로 명시적으로 종료하는 것 가운데

어떤 방법이 적절한지는 설계 목적에 따라 달라진다.

---

ㅁ Routing Loop는 왜 생길까?

Routing Loop는 여러 상황에서 발생할 수 있다.

 

ㅇ 잘못된 Static Route

두 라우터가 특정 Prefix 또는 Default Route를 서로에게 향하도록 설정할 수 있다.

 

ㅇ 경로가 바뀌는 동안의 정보 불일치

링크 장애 뒤 일부 라우터는 새 상태를 알고 다른 라우터는 이전 상태를 유지할 수 있다. 네트워크가 아직 Convergence하지 않은 순간에 임시 Loop가 생길 수 있다.

 

ㅇ Route Redistribution과 Summary 설계 오류

여러 Routing Protocol 사이에 경로를 재배포하거나 넓은 Summary Route를 만들 때 경로의 출처와 실제 도달성을 잘못 표현하면 패킷이 되돌아올 수 있다.

 

ㅇ 잘못된 Policy Routing

일반 Destination Route와 별도로 Source, Mark, Interface에 따른 정책이 서로 충돌해 예상하지 못한 순환을 만들 수 있다.

동적 라우팅 프로토콜은 Loop를 줄이기 위한 여러 장치를 갖는다.

• Distance Vector 계열의 Split Horizon과 Route Poisoning
• Link State 계열의 공통 Topology Database와 SPF 계산
• BGP의 AS_PATH를 이용한 Autonomous System Loop 탐지

하지만 잘못된 설정과 정책까지 모든 Loop를 자동으로 막아 주는 것은 아니다.

이 장치들은 다음 글의 동적 라우팅에서 더 자세히 살펴본다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.

우편 시스템의 모습	네트워크 용어	의미
두 우체국이 서로를 다음 배송지로 가리킴	Routing Loop	Route Entry가 순환하는 Next Hop을 만드는 상태
봉투에 적힌 남은 중계 횟수	TTL	IPv4 Packet이 통과할 수 있는 Router Hop을 제한하는 필드
IPv6 봉투의 남은 중계 횟수	Hop Limit	IPv6에서 TTL과 같은 역할을 하는 필드
횟수가 끝난 편지를 폐기	TTL Expiration	TTL 감소 결과가 0이 되어 Forwarding을 중단하는 동작
수명이 끝났다는 반송 안내	ICMP Time Exceeded	TTL 만료를 Source에 알리는 제어 메시지
짧은 수명의 편지를 차례로 보냄	traceroute	TTL을 증가시키며 각 Hop의 응답을 수집하는 경로 추론
모든 우체국이 같은 새 지도를 갖게 됨	Convergence	경로 변화 후 Routing 정보가 안정된 상태

 

 

Routing Loop 안에서 한 Packet이 끝나는 과정은 다음과 같다.

1. Source가 초기 TTL을 설정해 Packet을 보낸다.
2. 각 Router는 Forwarding 전에 TTL을 감소시킨다.
3. 잘못된 Route 때문에 Packet이 같은 Router들을 반복한다.
4. TTL이 0이 된 Router가 Packet을 폐기한다.
5. 가능하면 ICMP Time Exceeded를 Source로 보낸다.

---

ㅁ 직접 관찰해 보기

먼저 일반적인 경로를 숫자 주소로 확인한다.

traceroute -n 8.8.8.8

 

최대 Hop 수를 작게 제한해 관찰할 수도 있다.

traceroute -n -m 5 8.8.8.8

 

Linux의 tracepath가 설치되어 있다면 권한 없이 경로와 PMTU 정보를 함께 관찰할 수 있다.

tracepath -n 8.8.8.8

 

Linux ping 구현에서는 TTL을 작게 설정한 Echo Request를 보낼 수 있다.

ping -c 1 -t 1 8.8.8.8

첫 Router가 ICMP Time Exceeded를 보내고 Return Path와 정책이 허용한다면 응답을 볼 수 있다.

macOS ping에서는 TTL 지정 옵션이 다를 수 있으므로 해당 시스템의 man ping을 확인한다.

 

 

ICMP 메시지와 IP TTL을 패킷 수준에서 보려면 다음처럼 캡처할 수 있다.

sudo tcpdump -n -vv -i eth0 icmp

인터페이스 이름과 권한은 환경에 맞게 조정한다.

공용 목적지에 대한 경로는 네트워크 정책, VPN, 방화벽, ECMP에 따라 달라진다.

반복되는 Hop이나 *를 발견해도 운영 환경의 Routing Loop라고 즉시 단정하지 않는다.

의도적으로 잘못된 Route를 추가해 Loop를 만드는 실험은 공유 네트워크와 운영 장비에 영향을 줄 수 있다. 격리된 개인 실습 환경이 아니라면 읽기와 패킷 관찰만 수행한다.

---

ㅁ 핵심 정리

• Routing Loop는 여러 Router의 Route Entry가 Packet을 순환시키는 상태다.
• L2 Loop의 일반 Ethernet Frame과 달리 IP Packet에는 TTL 또는 Hop Limit이 있다.
• IPv4 TTL은 Router를 통과할 때마다 감소하며 0이 되면 Packet을 폐기한다.
• TTL 변경 시 IPv4 Header Checksum도 갱신된다.
• Router는 TTL 만료를 ICMP Type 11 Code 0 Time Exceeded로 알릴 수 있다.
• ICMP 응답도 Return Route와 정책이 필요하므로 Source에 반드시 도착하는 것은 아니다.
• traceroute는 TTL을 1부터 늘린 Probe의 만료 응답을 모아 Hop을 추론한다.
• TTL을 크게 설정해도 잘못된 Route는 고쳐지지 않고 Packet이 더 오래 순환할 뿐이다.
• 동적 Routing Protocol은 여러 Loop 방지 장치를 갖지만 잘못된 정책과 설정까지 모두 막지는 못한다.

 

핵심 용어: Routing Loop, TTL, Hop Limit, TTL Expiration, ICMP Time Exceeded, ICMP Type 11 Code 0, traceroute, Router Hop, Convergence, Split Horizon, Route Poisoning, AS_PATH

 

TTL은 패킷을 목적지로 안내하지 않는다. 잘못된 안내가 네트워크 자원을 영원히 점유하지 못하게 끝을 정한다.

---

ㅁ 다음 이야기

Static Route만 사용하는 작은 네트워크에서는 관리자가 잘못된 경로를 직접 찾아 고칠 수 있다.

하지만 수백, 수천 개의 라우터가 연결된 네트워크에서 링크가 바뀔 때마다 모든 Routing Table을 사람이 수정할 수는 없다.

라우터들은 새로운 길과 사라진 길을 어떻게 서로 알릴까?

다음 글에서는 「길이 바뀌면 지도는 어떻게 새로 그려질까?」라는 질문을 통해

Static Routing과 Dynamic Routing의 차이, OSPF의 Link State, BGP의 Path Vector와 Convergence를 살펴본다.