08. Routing

Routing

Router 가 패킷이 이동할 최적의 경로를 결정하는 것을 Routing 이라고 한다.
LAN 을 넘어 다른 네트워크와 연결하기 위해 사용된다.

Routing 원리

Routing Table 을 바탕으로 패킷을 중계한다.

Routing Table

특정 수신지까지 도달하기 위한 정보를 명시한 표
라우터는 라우팅 테이블을 참고하여 수신지까지의 도달 경로를 판단한다.
라우팅 테이블에 포함된 정보
- 수신지 IP 주소와 서브넷 마스크: 최종으로 패킷을 전달할 대상
- 다음 홉: 최종 수신지까지 가기 위해 다음으로 거처야 할 호스트 IP 주소나 인터페이스(게이트웨이)
- NIC: 패킷을 내보낼 통로
- 메트릭: 해당 경로로 이동하는데 드는 비용

수신지 IP 주소	서브넷 마스크	게이트웨이	인터페이스	메트릭
192.168.2.0	255.255.255.0	192.168.2.1	eth0	30
0.0.0.0	0.0.0.0	192.168.0.1	eth1	30

위 예시:
- 수신지가 192.168.2.0/24인 패킷은 eth0 를 통해 192.168.2.1 에 전송하라는 뜻
- 수신지가 0인, 예를 들어 1.2.3.4인 패킷은 eth1 를 통해 192.168.0.1 에 전송하라는 뜻
- default route: 라우팅 테이블에 경로가 없을 때 기본적으로 패킷을 내보낼 경로로 일반적으로 기본 게이트웨이 주소가 default route 이다. 기본 게이트웨이는 네트워크 외부로 나가기 위한 첫 경로다.
Routing Table 을 만드는 방법:
- 정적 라우팅: 수동으로 ip route 명령어 등을 수행
- 동적 라우팅: 자동으로 라우팅 테이블을 수정
  - IGP: AS 내부용 동적 라우팅 프로토콜
  - EGP: AS 외부용 동적 라우팅 프로토콜

라우팅의 분류

정적 라우팅과 동적 라우팅

정적 라우팅: 수동으로 구성된 라우팅 테이블 항목을 통해 수행되는 라우팅
- 사용자가 수동으로 직접 채워 넣은 라우팅 테이블의 항목을 토대로 라우팅
- e.g. route add -net 10.0.0.0/24 192.168.1.1
동적 라우팅: 자동으로 테이블 항목을 만들고, 이를 이용하여 라우팅
- 라우터끼리 서로 정보를 교환하며 패킷이 이동할 최적의 경로를 찾기 위한 라우팅 프로토콜을 이용
- 라우팅 테이블 항목이 수시로 변할 수 있음

라우터들의 집단 네트워크, AS (Autonomous System)

동적 라우팅과 라우팅 프로토콜을 이해하기 위한 배경 지식
AS 는 한 회사나 단체에서 관리하는 라우터 집단을 의미하며, AS 마다 고유한 ASN 가 할당된다.
한 AS 안에는 다수의 라우터가 존재한다. 라우터들은 AS 내부에서만 통신하고 외부와 통신하기 위해선 AS 경계에서 AS 내외로 통신을 주고받을 수 있는 특별한 라우터를 이용하는데 이를 ASBR, AS Boundary Router 라고 부른다.

라우팅 프로토콜

라우터끼리 서로 정보를 교환하며 패킷이 이동할 최적의 경로를 찾기 위한 프로토콜
라우팅 프로토콜의 종류
- IGP, Interior Gateway Protocol: AS 내부에서 수행하는 RIP, OSPF 가 있다.
- EGP, Exterior Gateway Protocol: AS 외부에서 수행하는 BGP 가 있다.

대표적인 IGP: RIP 와 OSPF

RIP: 거리 벡터 기반 라우팅 프로토콜
- 거리는 패킷이 경유한 라우터의 수. 즉, 홉 수를 의미
- 특정 수신지까지 도달하기 위한 최소 홉 수의 경로를 최적의 경로라고 판단
- 홉 수가 적을수록 라우팅 테이블의 메트릭 값도 작아짐
- 주기적으로 인접 라우터끼리 경로 정보 교환, 라우팅 테이블 갱신, 수신지까지의 홉 수 계산을 수행
OSPF: 링크 상태 기반 라우팅 프로토콜
- 현재 네트워크 구성 상태를 그래프의 형태로 LSDB, Link State DB 에 저장

EGP: BGP, Border Gateway Protocol

AS 간의 통신에서 사용되는 대표적인 프로토콜
엄밀하게는 BGP 로 AS 내 라우터 간 통신도 가능하다.
- eBGP: AS 간 통신을 위한 BGP
- iBGP: AS 내 통신을 위한 BGP
AS 간 통신을 위한 eBGP 는 다른 AS 의 ASBR 과 Peering 이라는 과정을 거처야한다.
- Peering: 다른 AS 와 BGP 연결을 유지하기 위해 BGP 라우터끼리 피어가 되도록 연결하는 과정
BGP 는 RIP 나 OSPF 에 비해 최적의 경로를 결정하는 과정이 복잡하고, 일정하지 않은 경우가 많다
경로 결정 과정에서 수신지 주소와 더불어 다양한 속성과 정책이 고려되기 때문이다.
BGP 의 속성은 경로에 대한 부가 정보를 포함한다. 이런 점에서 경로 벡터 라우팅 프로토콜의 일종이기도함
- AS-PATH: 메시지가 수신지에 이르는 과정에서 거쳐가는 AS 의 목록
- NEXT-HOP: 다음으로 거칠 라우터의 IP 주소
- LOCAL-PREF: 지역 선호도
BGP 의 정책: AS 관리 주체에 따라 각기 다른 정책을 사용할 수 있다
- e.g. 특정 AS 우대 정책, 특정 AS 차단 정책 등
K8s Calico CNI, AWS Network: Site to Site VPN, Direct Connect, TGW 등에서 유용할 수 있는 개념

BGP

BGP, Border Gateway Protocol 이란 AS 간 라우팅 정보 교환의 표준 프로토콜이다. 인터넷=라우터+DNS 기에 인터넷 자체가 BGP 로 굴러간다고 볼 수 있다.

TCP 179 위에서 동작 (UDP/custom transport 아님, 안정성/인증/flow control 위해 TCP 채택)
path-vector 프로토콜 — distance-vector (RIP) 도 link-state (OSPF) 도 아닌 분류. 경로(AS 시퀀스) 자체를 attribute 로 전달
현재 표준 = BGP-4 (RFC 4271, 2006)

위치 = 인터넷의 control plane. data plane (실제 packet 흐름) 은 IP 라우터가 처리하지만, “어디로 보낼지” 를 결정하는 라우팅 테이블을 BGP 가 채워준다.

왜 필요한가 — 다른 프로토콜과의 차이

짧은 답 = 다른 라우팅 프로토콜은 한 조직 내부 (single administrative domain) 에서만 적합. 인터넷은 수많은 자율 조직의 모임.

라우팅 프로토콜 카테고리

분류	프로토콜	적용 범위
IGP (Interior Gateway Protocol)	OSPF, IS-IS, RIP, EIGRP	단일 AS 내부
EGP (Exterior Gateway Protocol)	BGP	AS 간

IGP 의 한계 (왜 인터넷에서 못 쓰나)

모든 라우터가 전체 토폴로지 알아야 (link-state) 또는 모든 라우터 정보 받아야 (distance-vector). 수십만 prefix·수만 AS 의 인터넷에선 scale X.
단순 metric (hop count·cost) 만. 정책 표현 X.
같은 administrative domain 가정. 다른 조직과 trust 없으면 못 씀.

인터넷의 본질

수만 개 AS (Autonomous System) 의 모임. 각자 자기 IP 대역·관리 주체·routing 정책.
서로 trust 없음 → policy 협상 필수.
“이 prefix 광고하고 저건 안 함”, “이 customer 한테는 안 알림”, “이 ISP 트래픽은 cheap link 로”

BGP 가 해결한 것

AS 단위 추상화 — AS 안의 내부 토폴로지는 안 보고 AS 간 경로만. 한 AS = 한 노드처럼.
path-vector — 전체 AS 시퀀스 (AS65001 → AS65010 → AS65020) 만 추적. loop 도 AS-Path 보고 자동 감지.
정책 표현 — Local-Pref·MED·AS-Path prepending·community 등 attribute 로 사업적 의사결정.
scale — 인터넷 라우팅 테이블 ~100만 prefix 처리. incremental update·route aggregation.
명시적 peering — TCP 179 + MD5 인증 + 세션별 정책. 신뢰 모델 명확.

→ “인터넷의 라우팅 프로토콜”. IGP 가 보조.

AS 와 ASN

AS — Autonomous System

= 단일 라우팅 정책 (single administrative authority) 을 가지는 IP 네트워크의 집합.

한 ISP = 보통 한 AS
큰 기업·CDN·클라우드도 자체 AS 운영
한 조직이 여러 AS 가질 수도 (지역별·사업별)

ASN — AS Number

IANA → RIR (APNIC·RIPE·ARIN 등) → ISP 순으로 할당
16-bit ASN (0-65535) = 옛 표준. 고갈됨.
32-bit ASN (65536-4294967295, RFC 6793) = 현재 표준
private ASN = 인터넷에 광고 못 함. 내부·실습용
- 16-bit private = 64512 ~ 65534
- 32-bit private = 4200000000 ~ 4294967294

유명 ASN

ASN	조직
AS15169	Google
AS16509	Amazon (AWS)
AS32934	Meta (Facebook)
AS13335	Cloudflare
AS4766	KT
AS9318	SK Broadband
AS9644	LG U+
조회 = `whois AS15169` 또는 bgp.he.net.

eBGP vs iBGP

같은 BGP 프로토콜이지만 peer 가 같은 AS 인지 다른 AS 인지에 따라 동작 다름.

항목	EBGP	IBGP
Peer 의 AS	다른 AS	같은 AS
용도	AS 간 경로 교환	AS 내부에서 EBGP 로 배운 경로 공유
기본 TTL	1 (직접 연결만)	255 (어디든)
AS-Path 변경	본인 ASN 추가	변경 X
`Next-Hop` 변경	본인 IP 로 변경	변경 X (그래서 IGP 로 reachable 해야)
Loop prevention	AS-Path 검사 (자기 ASN 있으면 reject)	“received from IBGP peer → IBGP peer 에 재광고 X” 룰 → full mesh 필요

iBGP full mesh 문제

IBGP 는 received-from-IBGP route 를 다른 IBGP peer 에 재광고 안 함 (loop 방지). 그래서 같은 AS 안 모든 IBGP 라우터가 서로 직접 peer 해야 (“full mesh”). N 라우터 → N(N-1)/2 세션.

→ 100 라우터 = 4950 세션. 안 됨.

해결:

Route Reflector (RR) = 한 라우터가 hub. client 들이 RR 와만 peer. RR 가 client 끼리 광고 중계.
Confederation = AS 를 sub-AS 로 쪼개고 sub-AS 간 EBGP. 복잡, 잘 안 씀.

동작 — 메시지·라우팅 결정

메시지 4 종

메시지	용도
`OPEN`	세션 협상 — version·ASN·hold time·capabilities
`UPDATE`	prefix 광고·withdraw + path attribute
`KEEPALIVE`	세션 유지 (hold time 의 1/3 마다)
`NOTIFICATION`	error 또는 의도적 종료

세션 state machine

Idle → Connect → OpenSent → OpenConfirm → Established
        │                                       │
        └──── error 시 NOTIFICATION ─────────────┘

Established 도달해야 UPDATE 주고받기 시작.

라우팅 결정 우선순위

여러 경로가 같은 prefix 에 있을 때 어느 것 채택할지 — 위에서 아래로 순차 평가, 같은 값이면 다음 기준.

Weight (Cisco 전용, 로컬 라우터)
Local-Pref (높을수록 선호 — AS 내부 정책)
본인이 originate 한 경로
AS-Path 길이 (짧을수록 선호)
Origin (IGP < EGP < incomplete)
MED (낮을수록 선호 — 인접 AS 에 힌트)
EBGP > IBGP
IGP cost to Next-Hop (낮을수록 선호)
oldest route 또는 lowest Router ID (tie-break)

→ 정책 표현이 attribute 로 모두 가능. 사업 결정 → 라우팅 결정으로 직결.

주요 path attribute

AS-Path = 경로의 AS 시퀀스. loop 방지 + 길이 기반 선호
Next-Hop = 다음 hop IP. EBGP 는 변경, IBGP 는 유지
Local-Pref = AS 내부 선호도. 높을수록 우선. IBGP 만 전파
MED = Multi-Exit Discriminator. 인접 AS 가 “여러 진입로 중 이거 우선” 알리기
Community = 그룹 태그. 정책 구현용 (예: 65001:100 = “이 prefix 는 customer 한테만 광고”)

실제 활용 — 인터넷·데이터센터·클라우드·K8s

인터넷 backbone

ISP 끼리 EBGP peering. tier 1·tier 2·CDN·콘텐츠 사업자가 그물망
종류 = settlement-free peering (대등) vs transit (한쪽이 돈 내고 다른 쪽 통해 인터넷 도달)
IXP (Internet Exchange Point) = 한 곳에서 여러 AS 가 BGP peering 하는 facility
CDN anycast = 같은 IP 를 여러 PoP 에서 BGP 로 광고 → 가장 가까운 PoP 으로 라우팅

데이터센터 leaf-spine (RFC 7938)

옛 = L2 spanning tree (취약·non-scalable, single broadcast domain). 현대 = L3 routing 모든 곳까지. leaf-spine + 각 라우터 자체 ASN + IBGP/EBGP → ECMP, failure isolation, scale.

        [spine1]  [spine2]  [spine3]
           │\\       /│       /│
           │ \\____ / │      / │
           │ /     \\│       / │
        [leaf1]  [leaf2]  [leaf3]
           │       │        │
        [rack]   [rack]   [rack]

각 leaf = ToR (Top of Rack) 라우터. 자체 ASN
각 spine = 자체 ASN
모든 leaf↔spine 링크가 ECMP 로 load balanced
표준 = Cumulus·Arista·SONiC

AWS

Direct Connect = on-prem ↔ AWS VPC 전용선. BGP 로 routing 교환
Transit Gateway = 여러 VPC·VPN·DX 의 라우팅 hub. BGP 동적 라우팅 지원
Site-to-Site VPN = customer gateway 와 BGP session (또는 static)

Kubernetes CNI

Calico BGP 모드 = 각 노드의 calico-node 가 BGP 데몬. Pod CIDR 을 외부 라우터에 광고. ToR 라우터가 Pod IP 로 직접 routing
Cilium BGP Control Plane = 비슷한 패턴, eBPF 기반
MetalLB BGP 모드 = on-prem K8s 에서 LoadBalancer Service IP 를 외부 라우터에 광고

→ Pod IP·LB IP 가 사내망에서 진짜 routable. AWS 의 aws-vpc-cni 가 ENI 로 같은 효과를 내는 것과 대비. cross-ref = 17. EKS Platform Architecture.

실습 — FRR + Docker bridge

실제 라우터 (Cisco·Juniper) 없이 BGP 토폴로지 학습하려면 FRR + Docker 가 가장 가볍다.

FRR (Free Range Routing)

Quagga 의 fork. 오픈소스 라우팅 스택
Linux 위에서 데몬 (bgpd, ospfd, zebra 등) 으로 실행
진짜 ISP·데이터센터에서도 production 으로 씀 (Cumulus·SONiC 의 라우팅 엔진)
vty shell (vtysh) = Cisco IOS-like CLI

단순 토폴로지 예 (3-AS full mesh EBGP)

       +-----------------+
       |  docker bridge  |  (172.20.0.0/16)
       +-----------------+
          │      │      │
       [R1]   [R2]   [R3]
       AS65001 AS65002 AS65003
       FRR    FRR    FRR

컨테이너 3 대, 각각 FRR 실행
각자 다른 ASN
같은 docker bridge 에 붙어 같은 L2 segment
FRR 설정으로 서로 BGP peer 설정 → EBGP session

핵심 명령 (vtysh 안)

# 세션 상태
show bgp summary
# 받은 prefix
show ip bgp
# 특정 prefix 상세 (어느 path 선택했나)
show ip bgp 10.10.10.0/24
# neighbor 상태
show bgp neighbor 172.20.0.2

다른 실습 도구

Containerlab = declarative 네트워크 토폴로지 (.clab.yml). FRR·SONiC·VyOS·진짜 Cisco/Juniper 이미지까지. 학습·테스트에 매우 좋음.
GNS3 / EVE-NG = Cisco IOS·Juniper 같은 진짜 라우터 OS 가상화. 라이선스·setup 부담.
Mininet = SDN·OpenFlow 중심. BGP 도 가능.

추천 동선 = Docker + FRR 로 단순 3-AS peering 부터 → Containerlab 으로 확장 (leaf-spine 4-router 정도) → 실제 AWS Direct Connect·Calico BGP 로 확장.

References

RFC 4271 — A Border Gateway Protocol 4 (BGP-4)
RFC 7938 — Use of BGP for Routing in Large-Scale Data Centers
RFC 6793 — BGP Support for Four-Octet ASN
FRR Routing | frrouting.org
Containerlab | containerlab.dev
AWS Direct Connect BGP routing | AWS docs
Calico BGP | Tigera docs
Cilium BGP Control Plane | docs.cilium.io
bgp.he.net — Hurricane Electric BGP Toolkit
BGP from FRR + Docker bridge 실습 블로그
17. EKS Platform Architecture — Calico BGP·Pod IP·VPC routable 컨텍스트
04. TCP & UDP — BGP 가 TCP 179 위에서 동작하는 이유
03. IP — IP routing 기초

meatsby.github.io

Explorer