| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | |||
| 5 | 6 | 7 | 8 | 9 | 10 | 11 |
| 12 | 13 | 14 | 15 | 16 | 17 | 18 |
| 19 | 20 | 21 | 22 | 23 | 24 | 25 |
| 26 | 27 | 28 | 29 | 30 | 31 |
- PETERICA
- golang
- Network
- 코틀린 코루틴의 정석
- SRE
- 티스토리챌린지
- 공부
- CloudWatch
- Spring
- kotlin coroutine
- Claude
- CKA
- kotlin
- aws
- 오블완
- 기록으로 실력을 쌓자
- 바이브코딩
- AI
- minikube
- go
- Kubernetes
- tucker의 go 언어 프로그래밍
- AWS EKS
- Java
- 정보처리기사 실기 기출문제
- MySQL
- Rag
- CKA 기출문제
- LLM
- docker
- Today
- Total
피터의 개발이야기
[Network] 12. 길이 바뀌면 지도는 어떻게 새로 그려질까? 본문

TCP/IP를 우편 시스템으로 이해하기 — Part 3. 수많은 길 가운데 다음 길을 고르는 법
ㅁ 들어가며
Routing Loop가 생겨도 TTL은 한 패킷이 영원히 돌지 않도록 끝을 만든다.
하지만 TTL은 잘못된 Route를 고치지 않는다.
다음 패킷도 같은 Loop에 들어가 TTL이 끝날 때까지 네트워크 자원을 사용한다.
근본적인 해결은 라우터들이 실제 연결 상태에 맞는 경로를 갖는 것이다.
라우터가 세 대뿐이라면 관리자가 Static Route를 직접 수정할 수 있다.
R1 ── R2 ── R3
그러나 라우터가 수백 대이고 링크가 계속 생기고 사라진다면 어떻게 될까?
장애가 날 때마다 모든 장비에 접속해 경로를 고치는 동안 네트워크는 오래 멈춰 있을 것이다.
서로 다른 관리자가 동시에 수정하면 경로가 일치하지 않아 Loop가 생길 수도 있다.
라우터들이 이웃과 도달 가능한 네트워크 정보를 교환하고, 변화가 생기면 각자의 Routing Table을 다시 계산할 방법이 필요하다.
이를 Dynamic Routing이라고 한다.
이번 글에서는 Static Routing과 Dynamic Routing의 차이, 한 조직 안에서 지도를 공유하는 OSPF, 조직 사이에서 도달 경로와 정책을 교환하는 BGP, 변화 후 네트워크가 다시 안정되는 Convergence를 살펴본다.
ㅁ 손으로 적은 배송표는 언제 유용할까?
Static Route는 관리자가 Destination Prefix와 Next Hop을 직접 지정한 경로다.
10.30.0.0/24 via 192.0.2.2
작은 지점 네트워크처럼 출구가 하나뿐이라면 단순하고 예측하기 쉽다.
ㅇ Static Routing의 장점
- 경로가 관리자의 의도 없이 바뀌지 않는다.
- 라우팅 프로토콜을 위한 제어 트래픽과 계산이 필요 없다.
- 작은 토폴로지에서는 동작과 장애 범위를 이해하기 쉽다.
- 기본 경로, 특정 관리망, 의도적인 Blackhole처럼 명확한 목적에 적합하다.
ㅇ Static Routing의 한계
- 링크 장애를 발견해도 대체 경로로 자동 변경되지 않는다.
- 네트워크가 커질수록 장비마다 설정해야 할 Route가 늘어난다.
- 추가·삭제 작업의 누락과 잘못된 Next Hop이 장애를 만들 수 있다.
- 여러 관리자가 가진 네트워크 지식을 일관되게 유지하기 어렵다.
Static Routing은 오래된 방식이라서 나쁜 것이 아니다.
변화가 적고 경로가 단순한 곳에서는 여전히 적절하다.
문제는 사람이 관리해야 하는 변화의 수가 감당할 수 있는 범위를 넘어설 때다.
ㅁ Dynamic Routing은 패킷을 대신 배달할까?
Dynamic Routing Protocol은 애플리케이션의 데이터 패킷을 직접 운반하는 프로토콜이 아니다.
라우터들이 다음 정보를 서로 교환하기 위한 Control Plane Protocol이다.
- 어떤 Prefix에 도달할 수 있는가?
- 그 Prefix는 어느 이웃을 통해 배웠는가?
- 경로의 비용과 속성은 무엇인가?
- 기존 경로가 사라졌는가?
라우터는 받은 정보와 자신의 연결 상태를 바탕으로 최적 경로를 계산해 RIB에 반영하고, 실제 전달에 사용할 경로를 FIB에 설치한다.
Routing Protocol Message
↓
경로 학습과 선택 — Control Plane / RIB
↓
전달 정보 설치 — FIB
↓
일반 IP Packet 전달 — Data Plane
동적 라우팅은 모든 패킷에 길을 물어보는 방식이 아니다.
Control Plane에서 미리 지도를 만들고, Data Plane은 그 결과를 사용해 패킷을 빠르게 전달한다.
ㅁ 경로가 바뀌면 어떤 일이 일어날까?
다음처럼 두 개의 경로가 있는 네트워크를 생각해 보자.
R2
/ \
Client R1 R4 Server
\ /
R3
평상시에는 R1-R2-R4 경로의 비용이 더 낮아 사용한다고 하자.
R2와 R4 사이의 링크가 끊어지면 라우팅 프로토콜은 대략 다음 과정을 거친다.
1. 링크 또는 이웃의 장애를 감지한다.
2. 기존 경로가 더 이상 유효하지 않다는 정보를 전파한다.
3. 각 Router가 대체 경로를 계산한다.
4. 새로운 Route를 RIB와 FIB에 반영한다.
5. R1-R3-R4 경로로 Packet을 전달한다.
변화를 감지한 순간부터 관련 라우터들이 일관된 새 경로를 사용하기까지의 과정을 Convergence라고 한다.
Convergence 중에는 모든 라우터가 같은 순간에 정보를 갱신하지 않는다.
- 일부 라우터는 이전 경로를 사용할 수 있다.
- 일부 라우터는 새 경로를 이미 설치했을 수 있다.
- 짧은 Packet Loss나 일시적 Routing Loop가 생길 수 있다.
- Stateful Session은 경로 변경의 영향을 받을 수 있다.
따라서 동적 라우팅의 목표는 단지 변화를 알아내는 것이 아니다.
변화를 빠르고 안정적으로 공유해 다시 일관된 전달 상태에 도달하는 것이다.
ㅁ 모든 라우터가 같은 방식으로 지도를 만들까?
Dynamic Routing Protocol은 네트워크의 범위와 해결하려는 문제에 따라 나뉜다.
ㅇ 한 관리 영역 안의 경로 — IGP
하나의 조직이 관리하는 네트워크 내부에서 사용하는 프로토콜을 IGP(Interior Gateway Protocol)라고 한다.
대표적으로 OSPF, IS-IS, RIP 등이 있다.
조직은 내부 링크의 상태와 비용을 바탕으로 빠르게 경로를 계산하려 한다.
ㅇ 서로 다른 관리 영역 사이의 경로 — EGP
인터넷처럼 서로 다른 조직의 네트워크가 연결될 때는 단순한 내부 최단거리만으로 경로를 정할 수 없다.
각 조직은 비용, 계약, 보안, 트래픽 엔지니어링 정책에 따라 어떤 경로를 받아들이고 알릴지 결정한다.
현재 인터넷의 대표적인 Inter-domain Routing Protocol은 BGP(Border Gateway Protocol)다.
각 관리 영역을 AS(Autonomous System)라고 하고 번호인 ASN(Autonomous System Number)으로 식별한다.
AS 65001 ── BGP ── AS 65002 ── BGP ── AS 65003
OSPF와 BGP는 둘 다 경로를 동적으로 교환하지만 문제의 범위와 판단 기준이 다르다.
ㅁ OSPF는 동네의 도로 상태를 함께 그린다
OSPF(Open Shortest Path First)는 Link State 방식의 IGP다.
라우터는 단순히 “이 목적지는 나를 통해 가라”고만 알리지 않는다.
자신의 링크와 이웃 상태를 나타내는 정보를 공유하고,
같은 OSPF Area의 라우터들이 공통된 토폴로지 지도를 만들도록 한다.
OSPF의 기본 흐름을 살펴보자.
ㅇ 1단계: 이웃을 발견한다 — Hello
OSPF Router는 Hello Packet을 교환해 같은 Link에 있는 OSPF 이웃을 찾고 설정이 맞는지 확인한다.
Area, Hello/Dead Timer, 인증과 네트워크 설정 등 중요한 조건이 맞지 않으면 정상적인 Neighbor 관계를 만들지 못할 수 있다.
OSPF는 TCP나 UDP Port를 사용하지 않고 IP Protocol Number 89를 사용한다.
ㅇ 2단계: 필요한 이웃과 인접 관계를 만든다 — Adjacency
라우터들은 Link State Database를 동기화하기 위한 Adjacency를 형성한다.
Broadcast Network에서는 모든 Router가 서로 완전한 Adjacency를 맺어 교환량이 커지지 않도록 DR과 BDR을 선출하는 구조를 사용할 수 있다.
ㅇ 3단계: 링크 상태를 알린다 — LSA
라우터는 자신의 연결 정보와 도달 가능한 Prefix 등을 LSA(Link-State Advertisement)로 알린다.
LSA는 필요한 범위에 Flooding되어 같은 Area의 라우터들이 Link State 정보를 공유하도록 한다.
ㅇ 4단계: 공통 지도를 만든다 — LSDB
라우터들은 받은 LSA를 LSDB(Link-State Database)에 저장한다.
같은 Area의 정상적으로 수렴한 Router들은 해당 Area에 대해 일관된 Link State 정보를 갖는 것을 목표로 한다.
ㅇ 5단계: 자신을 기준으로 최단 경로를 계산한다 — SPF
각 Router는 자신의 LSDB에 SPF(Shortest Path First) 알고리즘을 적용한다. 흔히 Dijkstra Algorithm으로 설명한다.
링크의 OSPF Cost를 바탕으로 각 목적지까지 가장 낮은 비용의 경로를 계산하고 Routing Table에 반영한다.
Hello → Neighbor / Adjacency
LSA Flooding → LSDB 동기화
SPF Calculation → Best Route
RIB / FIB Install → Packet Forwarding
라우터들은 같은 지도를 공유하지만 출발점이 서로 다르므로 각자 자신의 위치를 기준으로 경로를 계산한다.
ㅁ OSPF Area는 왜 필요할까?
모든 Router가 모든 Link 변화를 하나의 거대한 LSDB에 담으면 규모가 커질수록 Flooding과 SPF 계산 부담도 커진다.
OSPF는 네트워크를 Area로 나눠 Link State 정보의 범위를 계층화할 수 있다.
Area 1 ── Area 0 ── Area 2
Area 0은 Backbone Area 역할을 한다.
다른 일반 Area 사이의 연결은 기본적으로 Backbone을 중심으로 설계한다.
Area 경계의 Router는 영역 사이의 경로 정보를 전달하고 Summary를 적용할 수 있다.
Area를 나누면 다음 효과를 기대할 수 있다.
- Link 변화의 Flooding 범위를 제한한다.
- Router가 유지할 LSDB와 SPF 계산 범위를 줄인다.
- 주소 Summary를 통해 Route 수를 줄일 수 있다.
하지만 Area 설계가 복잡하거나 연결 규칙을 어기면 도달성 문제와 비효율적인 경로를 만들 수 있다.
작은 네트워크에서는 무리하게 여러 Area로 나누는 것보다 단순한 Area 0 구성이 이해하기 쉬울 수 있다.
ㅁ BGP는 전체 도로 지도를 공유할까?
인터넷을 연결하는 조직들은 내부의 모든 Router와 Link 상태를 서로 공개하지 않는다.
대신 다음과 같은 도달 가능성을 알린다.
203.0.113.0/24 Prefix는
AS 65003, AS 65002를 거쳐 도달할 수 있다.
BGP는 Prefix와 함께 경로 속성을 전달하는 Path Vector Protocol로 설명한다.
BGP Update에는 도달 가능한 Prefix 정보인 NLRI(Network Layer Reachability Information)와
경로 선택에 사용하는 여러 Path Attribute가 포함될 수 있다.
대표적인 속성은 다음과 같다.
| 속성 | 역할 |
| AS_PATH | 목적지 Prefix 광고가 거쳐 온 AS 번호의 경로 |
| NEXT_HOP | 해당 BGP Route를 전달할 다음 홉 주소 |
| LOCAL_PREF | 한 AS 내부에서 외부로 나갈 경로의 선호도를 표현 |
| MED | 이웃 AS에 여러 진입점의 상대적 선호를 제안 |
| ORIGIN | 경로 정보가 BGP에 들어온 기원을 표현 |
BGP Router는 단순히 물리적 거리가 가장 짧은 경로를 고르지 않는다.
조직의 Import/Export Policy와 Path Attribute를 바탕으로 경로를 선택하고 광고한다.
OSPF의 중심 질문: 내부 토폴로지에서 비용이 낮은 길은 무엇인가?
BGP의 중심 질문 : 어떤 경로를 받아들이고 선택하고 이웃에게 알릴 것인가?
정확한 BGP Best Path 선택 순서와 기본 정책은 구현 및 설정에 따라 차이가 있다.
입문 단계에서는 BGP가 인터넷 조직 사이의 정책 기반 도달성 교환이라는 점이 중요하다.
ㅁ BGP의 AS_PATH는 Loop를 어떻게 발견할까?
Prefix 광고가 AS를 지날 때 eBGP Router는 일반적으로 자신의 ASN을 AS_PATH에 추가한다.
AS 65003에서 시작
AS_PATH: 65003
AS 65002를 통과
AS_PATH: 65002 65003
AS 65001에 도착
AS_PATH: 65002 65003
AS 65001이 이 경로를 다시 광고하면 자신의 ASN이 추가될 수 있다.
어떤 AS가 받은 광고의 AS_PATH에서 자신의 ASN을 발견하면 해당 경로가 자신을 거쳐 되돌아온 것으로 판단해 일반적으로 거부한다.
이는 AS 수준의 Routing Loop를 막는 BGP의 핵심 장치다.
하지만 AS_PATH가 없애는 것은 BGP 경로 광고의 AS Loop다.
잘못된 Static Route, Route Redistribution, 내부 Policy로 생기는
모든 Data Plane Loop까지 자동으로 해결하는 것은 아니다.
ㅁ BGP Session이 연결되면 경로도 자동으로 생길까?
BGP Peer는 TCP Port 179를 사용해 Session을 맺는다.
Session 상태가 Established라면 두 Router 사이의 BGP 메시지 교환 채널이 준비되었다는 뜻이다.
그러나 Established가 곧 원하는 Route가 Routing Table에 있다는 뜻은 아니다.
다음 단계가 각각 성립해야 한다.
1. 광고할 Prefix가 BGP에 들어와 있는가?
2. Export Policy가 이웃에게 광고를 허용하는가?
3. Peer가 Update를 수신했는가?
4. Import Policy가 경로를 허용하는가?
5. NEXT_HOP에 도달할 수 있는가?
6. Best Path로 선택되었는가?
7. RIB와 FIB에 설치될 조건을 만족하는가?
그래서 BGP 장애는 다음처럼 나누어 확인해야 한다.
TCP/Peer Session 문제
→ Route Advertisement 문제
→ Policy Filtering 문제
→ Best Path Selection 문제
→ Next-Hop Resolution 문제
→ RIB/FIB Install 문제
“BGP가 Established인데 통신이 안 된다”는 상황은 모순이 아니다. 제어 채널 뒤의 경로 처리 단계가 별도로 남아 있다.
ㅁ eBGP와 iBGP는 무엇이 다를까?
서로 다른 AS 사이의 BGP Session을 eBGP(External BGP)라고 한다.
AS 65001 ── eBGP ── AS 65002
같은 AS 안에서 BGP Route를 공유하는 Session을 iBGP(Internal BGP)라고 한다.
AS 65001 내부
Router A ── iBGP ── Router B
BGP가 EGP 역할을 한다고 해서 모든 BGP Session이 AS 경계를 넘는 것은 아니다.
외부에서 받은 경로를 조직 내부의 BGP Router에 전달하기 위해 iBGP를 사용한다.
대규모 iBGP에서는 모든 Router 사이의 Full Mesh 부담을 줄이기 위해 Route Reflector 같은 구조를 사용할 수 있다.
OSPF와 iBGP도 경쟁 관계로만 볼 수 없다.
- OSPF는 AS 내부의 Router와 BGP NEXT_HOP에 도달할 기반 경로를 제공할 수 있다.
- iBGP는 외부 Prefix와 정책 정보를 AS 내부에 전달한다.
서로 다른 문제를 맡아 함께 동작할 수 있다.
ㅁ 빠르게 바뀌는 지도가 항상 좋은 것일까?
링크 장애를 빨리 감지하고 새 경로를 빨리 설치하면 Packet Loss 시간을 줄일 수 있다.
하지만 지나치게 민감하면 짧은 흔들림에도 경로가 계속 바뀌는 Route Flapping이 발생할 수 있다.
경로 변화마다 다음 작업이 반복될 수 있다.
- Neighbor 상태 변경
- Update 또는 LSA 전파
- Best Path 또는 SPF 재계산
- RIB/FIB 갱신
- Stateful Flow의 경로 변화
네트워크 규모가 클수록 변화의 파급도 커질 수 있다.
따라서 Dynamic Routing은 속도와 안정성 사이의 균형을 다룬다.
- 장애 감지를 빠르게 하는 Timer와 BFD
- 변화가 연속될 때 계산을 조절하는 SPF Throttling
- Route Flapping의 영향을 제한하는 정책
- Summary와 Area로 변화 범위를 줄이는 설계
구체적인 기본값과 적절한 조정 값은 프로토콜, 장비, 토폴로지에 따라 다르다.
단순히 Timer를 가장 짧게 만드는 것이 항상 좋은 설계는 아니다.
ㅁ Dynamic Routing을 사용하면 Static Route는 사라질까?
실제 네트워크에서는 여러 경로 출처를 함께 사용할 수 있다.
Connected Route : 인터페이스에 직접 연결된 네트워크
Static Route : 관리자가 명시한 특별 경로
OSPF Route : 조직 내부에서 동적으로 학습한 경로
BGP Route : 다른 AS 또는 BGP Peer에서 학습한 경로
Default Route : 더 구체적인 경로가 없을 때 사용할 출구
지점 Router는 내부 Prefix를 OSPF로 배우고 인터넷 방향은 Static Default Route를 사용할 수 있다.
경계 Router는 BGP로 외부 경로를 받고 내부에는 Default Route만 알릴 수도 있다.
문제는 서로 다른 출처의 Route를 아무 계획 없이 재배포할 때 생긴다.
Route Redistribution은 한 Routing Domain의 경로를 다른 Protocol에 넣는 기능이다.
연결에는 유용하지만 경로 출처가 흐려지고 Metric 변환, Loop, 피드백 문제가 생길 수 있다.
OSPF Route를 BGP로 재배포
↓
BGP Route를 다시 OSPF로 재배포
↓
원래 경로가 다른 출처로 되돌아올 위험
Tagging, Filtering, Summary와 명확한 단방향 정책 없이 재배포하면 Control Plane Loop 또는 잘못된 우선순위를 만들 수 있다.
동적 라우팅은 자동이지만 설계 의도까지 자동으로 만들어 주지는 않는다.
ㅁ 우편 비유를 네트워크 용어로 바꾸면
지금까지의 장면을 실제 네트워크 용어와 연결하면 다음과 같다.
| 우편 시스템의 모습 | 네트워크 용어 | 의미 |
| 관리자가 손으로 적은 배송표 | Static Route | 운영자가 Destination과 Next Hop을 직접 지정한 경로 |
| 우체국끼리 자동으로 변경 정보를 교환 | Dynamic Routing | Protocol로 도달성과 경로 변화를 학습하는 방식 |
| 한 조직 내부의 배송 체계 | IGP | 하나의 관리 영역 안에서 사용하는 Routing Protocol 범주 |
| 내부 도로 상태를 함께 그린 지도 | OSPF Link State | LSA와 LSDB를 이용해 내부 토폴로지를 공유하는 방식 |
| 서로 다른 물류 회사의 관리 영역 | Autonomous System | 하나의 Routing Policy 아래 관리되는 네트워크 집합 |
| 회사 사이의 배송 가능 지역과 정책 교환 | BGP Path Vector | Prefix와 Path Attribute를 교환하는 Inter-domain 방식 |
| 바뀐 길을 모두 반영해 다시 안정됨 | Convergence | 변화 후 일관된 새 Forwarding 상태에 도달하는 과정 |
| 계속 생겼다 사라지는 배송 안내 | Route Flapping | 경로가 반복해서 광고되고 철회되는 현상 |
| 서로 다른 지도 체계 사이에 경로 전달 | Route Redistribution | 한 Protocol의 Route를 다른 Protocol로 주입하는 기능 |
Dynamic Routing의 전체 흐름은 다음처럼 정리할 수 있다.
1. Neighbor 또는 Peer 관계를 만든다.
2. Prefix와 Topology 또는 Path 정보를 교환한다.
3. Protocol별 규칙과 Policy로 Best Path를 선택한다.
4. 선택 경로를 RIB와 FIB에 반영한다.
5. 변화가 생기면 정보를 갱신하고 다시 Converge한다.
ㅁ 직접 지도의 변화를 따라가 보기
다음 OSPF 토폴로지를 종이에 그려 보자.
R2
10/ \10
/ \
R1 R4
\ /
30\ /30
R3
R1에서 R4까지 두 후보를 계산한다.
R1 → R2 → R4 = 10 + 10 = 20
R1 → R3 → R4 = 30 + 30 = 60
정상 상태에서는 비용 20인 R2 경로가 선택된다.
R2-R4 링크가 끊어지면 다음 질문을 순서대로 생각해 보자.
- 어떤 Router가 Link Down을 먼저 감지하는가?
- 변경된 Link State는 어떤 이웃에게 전달되는가?
- 각 Router의 LSDB는 어떻게 바뀌는가?
- R1의 SPF 결과는 어느 경로로 바뀌는가?
- FIB가 갱신되기 전까지 어떤 Packet Loss가 생길 수 있는가?
Linux에서는 Kernel Routing Table의 경로 출처와 Next Hop을 관찰한다.
ip -4 route show
ip route get 203.0.113.10
FRRouting이 이미 구성된 개인 실습 환경이라면 읽기 명령으로 Control Plane 상태를 볼 수 있다.
sudo vtysh -c 'show ip ospf neighbor'
sudo vtysh -c 'show ip ospf database'
sudo vtysh -c 'show ip route'
sudo vtysh -c 'show bgp summary'
각 명령은 다음 질문에 답한다.
OSPF Neighbor : 이웃 관계가 형성되었는가?
OSPF Database : Link State 정보가 동기화되었는가?
IP Route : Best Route가 선택되었는가?
BGP Summary : Peer Session과 받은 Prefix 상태는 어떤가?
FRRouting이 설치·구성되지 않은 일반 호스트에서는 명령이 없거나 결과가 비어 있는 것이 정상이다.
관찰을 위해 OSPF/BGP Timer, Route Redistribution, BGP Policy를 운영 장비에서 변경하면
광범위한 경로 장애를 만들 수 있으므로 읽기 명령으로만 상태를 확인한다.
ㅁ 핵심 정리
- Static Route는 단순하고 예측 가능하지만 변화가 생겨도 자동으로 갱신되지 않는다.
- Dynamic Routing Protocol은 Control Plane에서 경로 정보를 교환하고 RIB/FIB를 갱신한다.
- 장애 감지부터 새 경로가 안정적으로 사용되기까지의 과정을 Convergence라고 한다.
- OSPF는 IGP이며 Hello, Adjacency, LSA, LSDB, SPF를 통해 Link State 경로를 계산한다.
- OSPF Area는 Link State 정보와 계산 범위를 계층화하며 Area 0이 Backbone 역할을 한다.
- BGP는 Prefix와 AS_PATH, NEXT_HOP 같은 Path Attribute를 교환하는 정책 기반 Path Vector Protocol이다.
- BGP Established는 메시지 채널이 준비되었다는 뜻이며 원하는 Route의 광고·선택·설치를 보장하지 않는다.
- eBGP는 AS 사이에, iBGP는 같은 AS 안에서 BGP Route를 교환한다.
- 빠른 장애 감지와 안정적인 Control Plane 사이에는 균형이 필요하다.
- Dynamic Route, Static Route, Default Route는 설계 목적에 따라 함께 사용될 수 있다.
- Route Redistribution은 유용하지만 출처와 Loop를 통제할 명확한 정책이 필요하다.
핵심 용어: Static Routing, Dynamic Routing, Control Plane, Data Plane, Convergence, IGP, OSPF, Hello, Adjacency, LSA, LSDB, SPF, Area 0, AS, ASN, BGP, NLRI, AS_PATH, Path Attribute, eBGP, iBGP, Route Flapping, Route Redistribution
동적 라우팅은 정답 지도를 한 번 배포하는 기술이 아니다. 계속 변하는 연결 상태를 공유하고 각 라우터가 다시 길을 계산하게 하는 약속이다.
ㅁ 다음 이야기
이제 편지는 같은 동네의 MAC 주소를 찾고, Gateway를 지나, 여러 Router가 계산한 경로를 따라 원격 네트워크까지 갈 수 있다.
하지만 사용자는 웹사이트에 접속할 때 203.0.113.10 같은 숫자 주소를 입력하지 않는다.
example.com이라는 이름만 알고도 실제 IP 주소를 어떻게 찾을까?
다음 글에서는 「우리는 왜 숫자 대신 이름으로 접속할까?」라는 질문을 통해 DNS Stub Resolver, Recursive Resolver, Root·TLD·Authoritative Name Server, Record와 Cache TTL을 살펴본다.
'DevOps > Network' 카테고리의 다른 글
| [Network] 11. 길을 잃은 편지가 영원히 돌면 어떻게 될까? (0) | 2026.07.16 |
|---|---|
| [Network] 10. 가는 길이 있으면 돌아오는 길도 있는 것일까? (0) | 2026.07.16 |
| [Network] 09. 라우터는 수많은 목적지의 길을 어떻게 고를까? (0) | 2026.07.16 |
| [Network] 08. 다른 동네의 편지는 누구에게 맡겨야 할까? (0) | 2026.07.16 |
| [Network] 07. 같은 동네와 다른 동네는 누가 판단할까? (0) | 2026.07.15 |
