[Network] 09. 라우터는 수많은 목적지의 길을 어떻게 고를까?

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

ㅁ 들어가며

호스트는 다른 네트워크로 가는 패킷을 Default Gateway에 맡긴다.

라우터는 프레임에서 IP Packet을 꺼내 Destination IP를 확인한다.

이제 패킷을 어느 인터페이스와 Next Hop으로 보낼지 결정해야 한다.

라우터의 Routing Table에 다음 경로가 있다고 생각해 보자.

0.0.0.0/0       → 우체국 A
10.0.0.0/8      → 우체국 B
10.20.0.0/16    → 우체국 C
10.20.30.0/24   → 우체국 D

목적지 10.20.30.40은 네 경로와 모두 일치한다.

그렇다면 어느 길을 선택해야 할까?

가까운 라우터를 선택할까? 먼저 등록된 경로를 선택할까?

Metric이 가장 작은 경로를 선택할까?

라우팅에서 첫 번째 기준은 따로 있다.

목적지와 가장 길게 일치하는 Prefix, 즉 가장 구체적인 경로를 선택한다.

 

이를 Longest Prefix Match(LPM)라고 한다.

이번 글에서는 Routing Table의 Route Entry가 어떤 정보를 담는지,

LPM이 왜 먼저 적용되는지, 같은 Prefix 후보 사이에서 경로 출처의 선호도와 Metric은 어떤 역할을 하는지 살펴본다.

---

ㅁ 라우팅 테이블은 전체 여행 경로일까?

우편집중국에는 목적지 지역별로 다음 배송처를 적은 표가 있다.

서울 강남구 → 수도권 남부 집중국
서울 전체   → 수도권 집중국
그 밖의 지역 → 중앙 집중국

 

이 표는 편지가 최종 목적지까지 거칠 모든 우체국을 순서대로 기록한 여행 계획이 아니다.

현재 우체국이 다음으로 어디에 넘길지를 결정하는 표다.

Routing Table도 마찬가지다.

일반적인 Route Entry에는 다음과 같은 정보가 들어 있다.

정보	의미
Destination Prefix	이 경로가 적용되는 목적지 주소 범위
Next Hop	패킷을 다음으로 전달할 라우터 주소
Outgoing Interface	패킷을 내보낼 인터페이스
Route Source	Connected, Static, OSPF, BGP 등 경로를 알게 된 출처
Preference / Distance	같은 Prefix의 여러 출처 중 어떤 경로를 신뢰할지 판단하는 값
Metric	한 출처 또는 프로토콜 안에서 더 좋은 경로를 비교하는 비용

 

모든 운영체제와 라우터가 이 정보를 같은 이름과 형식으로 보여 주는 것은 아니다. 하지만 핵심 질문은 같다.

이 목적지 범위의 패킷을 어느 인터페이스와 Next Hop으로 보낼 것인가?

라우터는 패킷마다 Destination IP를 이 표와 비교한다.

---

ㅁ 하나의 주소가 여러 구역에 포함될 수 있다

10.20.30.40이라는 목적지를 구역별로 살펴보자.

0.0.0.0/0       : 모든 IPv4 주소                → 일치
10.0.0.0/8      : 10으로 시작하는 주소          → 일치
10.20.0.0/16    : 10.20으로 시작하는 주소       → 일치
10.20.30.0/24   : 10.20.30으로 시작하는 주소    → 일치
10.20.30.40/32  : 정확히 10.20.30.40 하나       → 일치

 

큰 배송 구역 안에 더 작은 구역이 겹쳐 있는 모습이다.

모든 지역 /0
└─ 10 지역 /8
   └─ 10.20 지역 /16
      └─ 10.20.30 지역 /24
         └─ 10.20.30.40 한 주소 /32

 

목적지 주소는 이 모든 범위에 포함될 수 있다.

이때 /32가 가장 길게 일치하고 가장 구체적이다. /24, /16, /8, /0 순으로 범위가 넓어진다.

Longest Prefix Match는 일치하는 Route Entry 가운데 Prefix Length가 가장 긴 경로를 선택한다.

목적지	선택되는 가장 구체적인 경로
10.20.30.40	10.20.30.40/32
10.20.30.50	10.20.30.0/24
10.20.40.50	10.20.0.0/16
10.30.40.50	10.0.0.0/8
192.0.2.10	0.0.0.0/0

라우터는 테이블의 첫 줄부터 읽고 처음 일치한 경로를 고르는 것이 아니다.

구현 내부에서는 효율적인 검색 구조를 사용할 수 있지만,

외부에서 보이는 선택 결과는 가장 긴 Prefix Match를 따라야 한다.

---

ㅁ 더 구체적인 안내가 먼저인 이유는 무엇일까?

우편 안내판에 다음 두 문장이 있다고 생각해 보자.

서울로 가는 모든 편지 → 수도권 집중국
서울 강남구 역삼동 편지 → 강남 지역 우체국

 

역삼동 편지는 두 규칙에 모두 해당한다. 하지만 역삼동을 정확히 가리키는 안내가 서울 전체를 가리키는 안내보다 구체적이다.

네트워크에서도 넓은 범위를 하나의 경로로 묶어 표현하면서 일부 목적지만 예외 경로로 보낼 수 있어야 한다.

10.0.0.0/8      → 기본적으로 Router B
10.20.30.0/24   → 이 구역만 Router D

LPM이 없다면 /8과 /24 가운데 무엇을 먼저 적용할지 테이블 순서나 별도 규칙에 의존해야 한다.

LPM은 Prefix의 구체성이라는 일관된 기준으로 예외 경로를 표현한다.

 

이 구조 덕분에 다음 두 목표를 함께 달성할 수 있다.

• 넓은 주소 범위는 Summary Route 하나로 줄여 Routing Table을 작게 유지한다.
• 특별한 처리가 필요한 작은 범위는 More Specific Route로 덮어쓴다.

이를 Route Aggregation과 More Specific Route의 관계로 볼 수 있다.

---

ㅁ Default Route는 왜 항상 마지막 후보일까?¡

IPv4 Default Route는 0.0.0.0/0이다.

Prefix Length가 0이므로 모든 IPv4 주소와 일치한다. 동시에 가능한 경로 가운데 가장 덜 구체적이다.

10.20.30.0/24와 일치 → /24 선택
10.20.0.0/16과만 일치 → /16 선택
구체적 경로가 없음   → /0 선택

Default Route가 Routing Table의 위에 표시되더라도 더 구체적인 경로보다 먼저 선택되지 않는다.

Default Route는 다른 길을 모두 이기는 최우선 경로가 아니다.

더 정확한 안내가 없을 때 사용하는 마지막 포괄 경로다.

---

ㅁ Metric이 낮으면 무조건 선택될까?

다음 두 경로를 보자.

10.0.0.0/8      via Router A metric 10
10.20.30.0/24   via Router B metric 100

 

목적지 10.20.30.40에는 /8과 /24가 모두 일치한다.

/8의 Metric이 10으로 더 낮지만 /24가 더 긴 Prefix다. 따라서 먼저 /24 경로가 선택된다.

 

1차 기준: Longest Prefix Match → /24 승리
Metric 비교: 서로 다른 Prefix라면 먼저 비교할 기준이 아님

Metric은 보통 같은 Destination Prefix로 가는 후보 경로를 비교할 때 의미가 있다.

10.20.30.0/24 via Router B metric 100
10.20.30.0/24 via Router C metric 20

경로 출처와 정책 조건이 같다면 더 낮은 Metric의 Router C 경로를 선호할 수 있다.

Metric이 표현하는 의미는 프로토콜마다 다르다.

• OSPF는 링크 Cost를 합산한다.
• RIP은 Hop Count를 사용한다.
• BGP는 단일한 최단거리 Metric보다 여러 Path Attribute와 정책을 비교한다.
• 운영체제의 Static Route Metric은 경로 우선순위를 나타내는 방식으로 사용될 수 있다.

그래서 서로 다른 프로토콜의 Metric 숫자를 단순 비교해 “20이 100보다 작으니 더 좋다”고 판단할 수는 없다.

---

ㅁ 서로 다른 출처가 같은 길을 알려 주면 누구를 믿을까?

같은 10.20.30.0/24 경로를 Static Route와 OSPF가 동시에 알려 줄 수 있다.

10.20.30.0/24 → Static Route
10.20.30.0/24 → OSPF Route

Prefix Length는 같다. 하지만 두 경로는 서로 다른 방식으로 학습되었다.

라우팅 시스템은 어떤 출처를 더 선호할지 나타내는 값을 사용할 수 있다. 네트워크 장비에서는 이를 흔히 Administrative Distance(AD) 또는 Route Preference라고 부른다.

 

일반적으로 값이 낮을수록 더 선호하도록 구현하는 플랫폼이 많지만 기본값과 명칭, 비교 순서는 제조사와 운영체제에 따라 다르다.

중요한 것은 AD와 Metric의 역할을 구분하는 것이다.

Route Preference / AD : 서로 다른 경로 출처 중 무엇을 신뢰할지 비교
Metric                : 선택된 출처나 프로토콜 안에서 어느 경로가 더 좋은지 비교

이를 모든 플랫폼에 동일하게 적용되는 하나의 고정 공식으로 외우면 안 된다.

Linux, 라우터 운영체제, 각 동적 라우팅 프로토콜은 경로를 설치하는 절차와 표시 방식이 다를 수 있다.

 

공통적으로 기억할 안전한 순서는 다음과 같다.

1. 패킷 전달 시 Destination IP와 가장 길게 일치하는 Prefix를 찾는다.
2. 같은 Prefix의 후보 가운데 정책과 경로 출처의 선호도를 적용한다.
3. 같은 조건의 후보 사이에서 Metric과 프로토콜별 규칙을 적용한다.

---

ㅁ 비용이 같으면 한 길만 사용해야 할까?

같은 Prefix로 가는 두 경로의 비용이 같을 수 있다.

10.20.30.0/24 via Router B metric 20
10.20.30.0/24 via Router C metric 20

장비와 설정이 지원한다면 두 경로를 모두 활성화할 수 있다.

이를 ECMP(Equal-Cost Multi-Path)라고 한다.

ECMP는 여러 Next Hop에 트래픽을 분산해 링크를 함께 사용하고 하나의 경로에 장애가 생겼을 때 대체 경로를 제공할 수 있다.

패킷을 단순히 한 장씩 번갈아 보내면 순서가 바뀔 수 있으므로 실제 장비는

보통 Source/Destination IP, Port 같은 흐름 정보를 해시해 같은 Flow가 같은 Next Hop을 사용하도록 한다.

정확한 해시 필드와 분산 방식은 장비와 설정에 따라 다르다.

ECMP가 있다고 해서 모든 링크에 정확히 같은 양의 트래픽이 흐르는 것은 아니다.

Flow의 수와 크기가 다르면 분포도 달라질 수 있다.

---

ㅁ Next Hop도 찾아갈 수 있어야 한다

Route Entry에 Next Hop 주소가 적혀 있다고 해서 바로 프레임을 만들 수 있는 것은 아니다.

 

다음 경로를 보자.

10.20.30.0/24 via 192.0.2.2 dev eth0

라우터는 192.0.2.2의 MAC 주소를 알아내야 한다.

그러려면 Next Hop이 eth0에서 On-link이거나, Next Hop 자체로 가는 경로를 다시 찾을 수 있어야 한다.

 

이를 Recursive Next-Hop Resolution이라고 한다.

목적지 10.20.30.40
   ↓ Route Lookup
10.20.30.0/24 via 192.0.2.2
   ↓ Next Hop Resolution
192.0.2.0/24 dev eth0
   ↓ Neighbor Resolution
192.0.2.2의 MAC을 ARP로 조회

Destination Prefix는 맞지만 Next Hop으로 가는 경로가 없다면 해당 Route를 실제 전달에 사용할 수 없다.

Routing Table을 볼 때 목적지 경로뿐 아니라 Next Hop이 어느 인터페이스에서 해결되는지도 함께 확인해야 한다.

---

ㅁ 더 구체적인 경로가 오히려 편지를 사라지게 할 수 있다

LPM은 일관된 규칙이지만 경로 정보가 올바르다는 사실까지 보장하지는 않는다.

 

다음 테이블을 보자.

10.20.30.0/24    via 정상 Router
10.20.30.40/32   blackhole

10.20.30.50은 /24 경로를 따라 정상적으로 전달된다.

 

하지만 10.20.30.40은 더 구체적인 /32 Blackhole Route와 일치하므로 폐기된다.

10.20.30.40 → /32 Blackhole 선택 → 폐기
10.20.30.50 → /24 정상 경로 선택 → 전달

주변 주소는 모두 되는데 특정 IP 하나만 통신되지 않는다면 More Specific Route를 의심할 수 있다.

Blackhole Route는 트래픽을 의도적으로 조용히 폐기한다.

반복되는 잘못된 트래픽을 막거나 경로 루프를 방지하는 용도로 사용할 수 있지만, 잘못 설정하면 찾기 어려운 장애를 만든다.

운영체제에 따라 unreachable, prohibit 같은 경로 유형도 있으며

패킷을 폐기하면서 호출자에게 돌려주는 오류가 다를 수 있다.

LPM은 가장 올바른 경로가 아니라 가장 구체적으로 일치하는 경로를 고른다.

---

ㅁ RIB와 FIB는 무엇이 다를까?

라우팅 프로토콜과 정적 설정을 통해 여러 후보 경로가 들어오면 제어 영역은 최적 경로를 선택한다.

이 경로 정보를 다루는 논리적인 테이블을 흔히 RIB(Routing Information Base)라고 한다.

실제 패킷을 빠르게 전달하기 위해 선택된 경로는 전달에 적합한 형태로 FIB(Forwarding Information Base)에 반영된다.

Connected / Static / OSPF / BGP
              ↓
       RIB에서 경로 선택
              ↓
       FIB에 전달 정보 반영
              ↓
    Packet별 빠른 Forwarding Lookup

장비와 운영체제에 따라 테이블 구조와 이름은 다르지만 개념적인 역할은 구분할 수 있다.

• Control Plane은 경로를 학습하고 최적 경로를 계산한다.
• Data Plane은 선택된 정보를 사용해 실제 패킷을 전달한다.

Routing Table이라는 표현이 문맥에 따라 RIB 또는 사용자에게 보이는 선택 경로를 포괄해 사용되기도 한다.

입문 단계에서는 경로를 만드는 과정과 패킷을 전달하는 과정을 나누어 이해하는 것이 중요하다.

---

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

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

우편 시스템의 모습	네트워크 용어	의미
목적지 지역별 다음 배송처 표	Routing Table	Destination Prefix와 Next Hop, Interface를 연결한 정보
배송 구역 한 줄	Route Entry	특정 Prefix에 적용되는 하나의 경로 항목
가장 상세한 주소 안내를 우선	Longest Prefix Match	일치하는 경로 중 Prefix Length가 가장 긴 항목 선택
전국 단위의 포괄 안내	Summary Route	여러 작은 주소 범위를 하나로 묶은 경로
특정 동네만 다른 길로 보내는 예외	More Specific Route	더 긴 Prefix로 일부 목적지를 별도 처리하는 경로
안내 정보의 출처 신뢰도	Administrative Distance / Preference	같은 Prefix의 서로 다른 출처를 비교하는 기준
같은 방식의 길 가운데 드는 비용	Metric	프로토콜 안에서 경로 품질을 비교하는 값
비용이 같은 여러 배송길	ECMP	같은 비용의 여러 Next Hop을 함께 사용하는 방식
의도적으로 폐기하는 주소 안내	Blackhole Route	일치하는 패킷을 전달하지 않고 폐기하는 경로
경로 후보를 관리하는 지도	RIB	제어 영역의 라우팅 정보 기반
실제 분류 창구가 사용하는 지도	FIB	패킷 전달에 사용하는 Forwarding 정보 기반

 

경로 선택의 핵심 흐름은 다음과 같다.

1. Destination IP와 일치하는 Prefix를 모두 찾는다.
2. Longest Prefix Match로 가장 구체적인 Prefix를 선택한다.
3. 같은 Prefix 후보에 경로 출처의 Preference와 정책을 적용한다.
4. 같은 조건의 후보를 Metric과 프로토콜 규칙으로 비교한다.
5. 선택된 Next Hop과 Outgoing Interface로 패킷을 전달한다.

---

ㅁ 직접 경로를 골라 보기

다음 Routing Table을 보고 각 목적지에 선택될 경로를 찾아보자.

0.0.0.0/0        via A
172.16.0.0/12    via B
172.16.0.0/16    via C
172.16.10.0/24   via D
172.16.10.128/25 via E

 

목적지	일치하는 가장 긴 Prefix	선택 Next Hop
8.8.8.8	0.0.0.0/0	A
172.20.1.1	172.16.0.0/12	B
172.16.200.1	172.16.0.0/16	C
172.16.10.20	172.16.10.0/24	D
172.16.10.200	172.16.10.128/25	E

 

/12의 범위는 두 번째 옥텟 기준으로 16~31이므로 172.20.1.1도 포함한다.

Linux에서는 Main Routing Table을 확인할 수 있다.

ip -4 route show table main

특정 목적지에 실제 선택되는 경로를 확인한다.

ip route get 8.8.8.8
ip route get 172.16.10.200

출력에서 via, dev, src를 살펴본다.

via : 선택된 Next Hop
dev : Outgoing Interface
src : 패킷에 사용할 Source IP

현재 테이블에 예제 Prefix가 없다면 실제 결과는 예제 표와 다르다. 명령의 목적은 시스템이 가진 경로에서 특정 Destination IP에 어떤 Route를 선택하는지 확인하는 것이다.

라우팅 설정을 추가하거나 Blackhole Route를 만드는 작업은 실제 통신을 끊을 수 있으므로 운영 환경에서는 읽기 명령으로만 관찰한다.

---

ㅁ 핵심 정리

• Routing Table의 Route Entry는 Destination Prefix, Next Hop, Interface, Source와 비용 정보를 담는다.
• 하나의 Destination IP는 여러 Prefix와 동시에 일치할 수 있다.
• 라우터는 가장 긴 Prefix가 일치하는 경로를 먼저 선택한다.
• Default Route /0은 모든 주소와 일치하지만 가장 덜 구체적인 마지막 후보다.
• 서로 다른 Prefix에서는 Metric이 낮다는 이유로 더 구체적인 경로를 이길 수 없다.
• 같은 Prefix 후보 사이에서는 경로 출처의 Preference, 정책, Metric과 프로토콜 규칙이 적용된다.
• 동일 비용 경로는 장비와 설정에 따라 ECMP로 함께 사용할 수 있다.
• Next Hop 자체도 연결된 경로나 다른 Route를 통해 해결할 수 있어야 한다.
• 잘못된 More Specific Route는 특정 목적지만 사라지는 장애를 만들 수 있다.
• RIB는 경로 학습과 선택에, FIB는 실제 Packet Forwarding에 초점을 둔다.

핵심 용어: Routing Table, Route Entry, Destination Prefix, Longest Prefix Match, Summary Route, More Specific Route, Administrative Distance, Route Preference, Metric, ECMP, Recursive Next-Hop Resolution, Blackhole Route, RIB, FIB, Control Plane, Data Plane

라우터는 가장 가까워 보이는 길을 고르지 않는다. 목적지 주소와 가장 구체적으로 일치하는 안내를 먼저 따른다.

---

ㅁ 다음 이야기

라우터는 Longest Prefix Match를 사용해 요청 패킷의 다음 길을 선택했다.

그렇다면 요청이 목적지에 도착한 순간 통신도 성공한 것일까?

응답 패킷은 요청이 지나온 길을 기억해 그대로 되돌아가는 것이 아니다.

목적지 호스트와 각 라우터는 응답의 Destination IP를 기준으로 새로운 경로 선택을 수행한다.

다음 글에서는 「가는 길이 있으면 돌아오는 길도 있는 것일까?」라는 질문을 통해

Forward Path, Return Path, Asymmetric Routing과 Missing Route가 만드는 장애를 살펴본다.