VXLAN & Overlay Tunnels

1. Overview

VXLAN과 오버레이 터널(VXLAN & Overlay Tunnels)은 물리적인 케이블과 스위치에 종속된 낡은 네트워크(Underlay) 위에 눈에 보이지 않는 논리적인 '가상의 망(Overlay)'을 한 겹 더 덧씌워, 아프리카의 서버와 한국의 서버가 마치 같은 방 안의 공유기에 꽂혀있는 것처럼 속여버리는 클라우드 인프라의 극한 마법을 해부합니다.

학습자는 구시대 네트워크를 쪼개던 VLAN 기술이 고작 4,096개의 아이디(ID)밖에 지원하지 못해 거대 클라우드 센터에서 한계에 부딪혔던 VLAN 4K Barrier의 비극을 뜯어봅니다. 나아가 패킷을 택배 박스에 넣고 새로운 라벨을 붙여 기존 L3 인터넷망을 통과시켜버리는 **MAC-in-UDP 캡슐화(Encapsulation)**의 예술, VXLAN을 장악합니다. 마지막으로, AWS VPC와 같은 퍼블릭 클라우드 환경에서 내 서버들끼리만 격리된 안전한 가상 네트워크 공간을 창조하는 오버레이 캡슐화 역량을 확보합니다.

2. Scope & Boundaries

In-Scope

• Underlay vs Overlay Network: 물리적인 케이블 뼈대(Underlay)와 그 위에 가상으로 뚫은 논리적 터널(Overlay).
• The VLAN 4K Limit: 12비트(4,096개) VLAN ID의 한계와 클라우드 멀티테넌시(Multi-tenancy)의 붕괴.
• VXLAN (Virtual eXtensible LAN): 24비트(1,600만 개) VNI, MAC-in-UDP 캡슐화 기법, VTEP(VXLAN Tunnel End Point).
• L2 over L3: 물리적으로 라우터(L3)를 여러 개 거쳐야 하는 환경에서, 가상으론 스위치(L2) 하나로 연결된 것처럼 속이는 터널링.

Out-of-Scope

• IPsec VPN 암호화: 터널링 내부에 보안/암호화를 더하는 기술 $\rightarrow$ 10-02-02 IPsec & TLS 영역으로 위임 (VXLAN 자체는 암호화 기능이 없음).
• BGP EVPN: VXLAN 터널을 좀 더 효율적으로 제어(Control Plane)하기 위한 라우팅 확장 프로토콜 $\rightarrow$ 엔터프라이즈 네트워크 심화 과정이므로 본 문서의 범위를 초과함.

Boundaries

• VLAN vs VXLAN: VLAN(L2)은 스위치에 꽂힌 케이블을 "너네는 파란 묶음, 너네는 빨간 묶음"으로 쪼개는 '물리적' 쪼개기입니다. 스위치(L3 라우터)를 넘어가면 VLAN 묶음이 깨집니다. 반면 VXLAN은 패킷 전체를 UDP 캡슐 안에 쑤셔 넣고(L3 터널링) 인터넷 너머로 쏴버립니다. 즉, VLAN은 '같은 건물의 방 쪼개기'라면, VXLAN은 '지구 반대편의 건물과 텔레포트 포탈(Tunnel) 뚫기'라는 뚜렷한 스케일과 계층 구조의 경계를 가집니다.

3. Counterexample

• 4,096개의 벽 (VLAN의 죽음): 아마존(AWS)이 클라우드 사업을 시작했습니다. 고객(테넌트)마다 네트워크를 완벽히 분리해 줘야 하니 VLAN을 썼습니다. 그런데 고객 1명당 VLAN 1개를 줬더니, 고객이 4,096명이 넘어가자 아이디(VLAN ID가 12비트)가 고갈되어 더 이상 고객을 받을 수 없게 되었습니다. 수만 명의 테넌트를 수용해야 하는 클라우드 환경에서 1,600만 개의 ID를 지원하는 24비트 VXLAN 터널을 도입하지 않아 성장이 멈춰버린 스케일링 재앙입니다.
• L2 확장의 폭주 (Broadcast Storm): 데이터센터 A와 B가 있습니다. 두 센터를 묶기 위해 원시적인 L2 케이블 연장술로 이어버렸습니다. A 센터의 서버 한 대가 "나 게이트웨이 어딨어?" 하고 쏘아 올린 ARP(Broadcast) 핑이 A 센터를 휩쓸고, L2 케이블을 타고 B 센터까지 넘어가 10,000대의 서버에 전달되었습니다. 양쪽 센터의 네트워크 대역폭이 브로드캐스트 쓰레기로 가득 차 전체 센터가 죽어버립니다. 이를 L3 라우팅 계층(UDP)으로 끊어내고 캡슐 안에서만 통신하게 만드는 VXLAN 캡슐화 억제력을 몰랐던 인프라 자폭입니다.

4. Prerequisites

• L2 Switch & VLAN (Basic): 브로드캐스트 도메인과 MAC 주소 테이블. (08-01-03 Link Layer)
• 캡슐화 (Basic): OSI 계층을 타고 내려오며 헤더가 붙는 개념. (08-01-01 OSI Stack)

5. Learning Map

6. Learning Topics

Basic

Core Topic 01: 물리적 선을 지워라 (Underlay vs Overlay)

• Why to Learn: 서버를 물리적 랙(Rack)과 스위치에 맞춰 배치해야 했던 낡은 종속성을 버리고, 캘리포니아와 서울에 있는 서버를 마치 1m짜리 랜선으로 연결한 것처럼 가상화하는 클라우드 네트워크의 기초를 통찰하기 위함입니다.
• What to Learn:
  • Concepts: Underlay Network (물리망), Overlay Network (논리 가상망), Tunneling (터널링), Logical Topology.
  • Skills: 라우터 3개를 거쳐야 하는(Hop=3) 10.0.0.0/8 언더레이 IP 대역 위에, 192.168.1.0/24라는 완전히 새로운 오버레이 가상 망을 덮어씌워 홉(Hop=1)처럼 속이는 개념 설계.
• How to Learn:
  • 1단계: Underlay (고속도로): 눈에 보이는 케이블, 광랜, 시스코 라우터들입니다. 이들의 목적은 딱 하나, "IP 주소 던져주면 최대한 빨리 배달하기"입니다. 절대 구조를 쉽게 바꿀 수 없습니다.
  • 2단계: Overlay (지하차도 터널): 그 고속도로 위에 '가상의 지하 터널'을 뚫습니다. 터널 입구에서 짐을 넣으면 출구로 나옵니다. 중간에 산(라우터)이 있든 강이 있든 알 바 아닙니다. 터널 안에서 통신하는 서버들은 "우리는 1<1로> 직접 연결돼 있어!"라고 착각(Illusion)합니다. 소프트웨어로 1초 만에 터널을 뚫고 지우는 궁극의 가상화(Overlay)를 해부합니다.
• Implement: 터널 핑(Ping) 딜루전(Delusion) 시뮬레이션. Physical Route: ServerA(뉴욕) $\rightarrow$ Router1 $\rightarrow$ Router2 $\rightarrow$ Router3 $\rightarrow$ ServerB(런던). (TTL -4). Overlay Tunnel: ServerA에서 ServerB의 '터널 IP'로 핑 전송. 결과 렌더링: Traceroute(경로 추적) 시 라우터 3개가 싹 은닉되고, 마치 [ServerA -> ServerB]로 한 번에 직결된 것처럼 보이는(TTL -1) 소프트웨어 터널링의 마법 시각화.

Recommended

Core Topic 02: 4,096개의 감옥, VLAN의 죽음 (The Fall of VLAN)

• Why to Learn: 네트워크 분리(Isolation)의 표준이었던 VLAN이 멀티 테넌트(Multi-tenant) 클라우드 시대가 도래하자마자 왜 끔찍한 병목이자 스케일링의 한계로 전락했는지 그 물리적 맹점을 장악하기 위함입니다.
• What to Learn:
  • Concepts: VLAN (Virtual LAN), 802.1Q Tag (12-bit limit, 4096), Multi-tenancy, Spanning Tree Protocol (STP) 병목, Broadcast Domain.
  • Skills: 거대 데이터센터에서 기업 고객(테넌트)이 5,000개가 넘을 때, 고객망이 서로 섞이지 않게 분리하려면 12비트 VLAN ID 체계로는 수용 불가능하다는 용량 계산.
• How to Learn:
  • 1단계: 12비트의 저주: 스위치가 패킷에 꼬리표(VLAN Tag)를 달 때 공간이 12비트(Bit)밖에 없습니다. $2^{12} = 4096$. 즉 한 네트워크 안에 가상 망을 4,096개밖에 못 쪼갭니다. AWS 같은 클라우드가 수십만 명의 고객 망을 분리해 줘야 하는데, 이 숫자로는 턱도 없습니다.
  • 2단계: Spanning Tree의 학대: VLAN은 L2 망입니다. 망이 루프(뺑뺑이) 도는 걸 막으려고 STP라는 걸 돌리는데, 이게 돌면 기껏 깔아놓은 물리적 선로의 절반(50%)을 막아버립니다(Block). 비싼 케이블을 깔아놓고 절반을 놀려야 하는 끔찍한 L2의 한계, 그리고 그 스위치를 뚫고 나가지 못하는 VLAN의 태생적 물리 한계를 뜯어봅니다.
• Implement: VLAN 고갈 500 에러 모사. 클라우드 콘솔 가상화. 사용자가 "새로운 가상 네트워크(VPC) 생성" 클릭 4,095번 반복 $\rightarrow$ 모두 성공 (VLAN ID 1~4095 할당됨). 4,096번째 클릭 $\rightarrow$ [ERROR] No available 802.1Q VLAN Tags. Infrastructure Limit Reached. 클라우드 서비스 제공자(CSP) 입장에서 파산을 부르는 스케일 아웃 장벽 렌더링.

Practical

Core Topic 03: 택배 박스의 마법, VXLAN (MAC-in-UDP)

• Why to Learn: 4,096개의 감옥(VLAN)을 박살 내고, 1,600만 개의 격리된 방(VNI)을 만들어 내면서 거침없는 L3 인터넷망을 타고 넘어가는 궁극의 캡슐화 기술을 장악하기 위함입니다.
• What to Learn:
  • Concepts: VXLAN (Virtual eXtensible LAN), MAC-in-UDP Encapsulation, VNI (VXLAN Network Identifier, 24-bit), L2 over L3.
  • Skills: 원본 MAC + 원본 IP로 이루어진 L2 패킷을 통째로 쑤셔 넣어 VXLAN 헤더 + 새 UDP 헤더 + 새 IP 헤더라는 거대한 택배 박스로 포장(Encapsulate)하는 프로토콜 스택 도해.
• How to Learn:
  • 1단계: 24비트의 확장 (VNI): VXLAN은 꼬리표(VNI) 크기가 24비트입니다. $2^{24} = 16,777,216$. 즉 1,600만 개의 격리된 고객 가상망을 만들 수 있습니다. 4천 개와 1,600만 개, 차원이 다릅니다.
  • 2단계: MAC-in-UDP (마트료시카): 서울의 서버(MAC: AA)가 부산의 서버(MAC: BB)로 직접 패킷을 보내고 싶습니다. 중간에는 수많은 L3 라우터 인터넷망이 있습니다. VXLAN은 서울 서버가 보낸 패킷(L2)을 '안 까보고' 그대로 큰 택배 박스(UDP) 안에 쑤셔 넣습니다. 택배 박스 겉면에는 "서울 라우터 $\rightarrow$ 부산 라우터"라고 적습니다(L3). 인터넷 망(라우터들)은 택배 박스 겉면만 보고 부산까지 고속 배달합니다. 부산 라우터가 박스를 까서 속알맹이(MAC: BB)를 서버에게 던져주는, 완벽한 속임수(L2 over L3)를 해부합니다.
• Implement: 마트료시카 패킷 인스펙터(Packet Inspector). 패킷의 단면을 해부하여 렌더링. [ Outer MAC (라우터끼리) ] + [ Outer IP (터널 양끝) ] + [ UDP Port 4789 ] + [ VXLAN VNI: 5000 ] | $\rightarrow$ 여기까지가 택배 박스
  • [ Inner MAC (진짜 서버) ] + [ Inner IP (가상망 IP) ] + [ Payload (데이터) ] | $\rightarrow$ 속알맹이 원본 패킷. 인프라의 벽을 뚫어버리는 캡슐화 겹겹 층위 시각화.

Advanced

Core Topic 04: 텔레포트 게이트, VTEP (VTEP & Cloud VPC)

• Why to Learn: 이 거대한 택배 박스를 서버(OS)가 직접 포장할 것인지, 아니면 앞단의 스위치(하드웨어)가 포장해 줄 것인지 그 텔레포트 터널 입구(VTEP)의 아키텍처를 결정하기 위함입니다.
• What to Learn:
  • Concepts: VTEP (VXLAN Tunnel End Point), Encapsulation / Decapsulation, Software VTEP (Hypervisor/vSwitch), Hardware VTEP (ToR Switch).
  • Skills: AWS VPC나 쿠버네티스 Flannel CNI가 내부적으로 리눅스 커널을 VTEP으로 사용하여 패킷을 가로채고, VNI를 씌워 다른 노드로 쏴주는 클라우드 네이티브 네트워크 동작 추적.
• How to Learn:
  • 1단계: 터널의 입구 (VTEP): 패킷을 박스에 넣고(Encapsulation), 목적지에서 박스를 뜯어주는(Decapsulation) 담당자가 VTEP입니다. 가상 세계와 물리 세계의 경계선, 즉 텔레포트 입구입니다.
  • 2단계: VTEP의 위치: 이 입구를 물리 스위치(ToR 스위치)에 두면 하드웨어 가속(ASIC)을 받아 미친 듯이 빠릅니다. 반면, 서버 안에 깔려있는 가상 머신(Hypervisor, vSwitch)에 두면 소프트웨어로 처리하므로 조금 느리지만 제어가 엄청나게 유연해집니다. AWS VPC나 K8s는 서버 내부의 가상 스위치(Software VTEP)를 이용해, 서버 안의 도커 컨테이너가 뱉은 패킷을 그 자리에서 즉시 VXLAN 박스로 포장해 인터넷으로 쏴버리는 궁극의 소프트웨어 정의 오버레이(Overlay)를 뜯어봅니다.
• Implement: Kubernetes Flannel (VXLAN) Node-to-Node 캡슐화 로직 모사. Node1 (IP 10.0.1.5)의 PodA $\rightarrow$ Node2 (IP 10.0.2.8)의 PodB로 Ping 전송. PodA는 순진하게 Ping PodB 전송. Node1 커널의 flannel.1 (VTEP 인터페이스)이 패킷을 낚아챔. UDP 캡슐 씌우고 겉면에 Dst IP: 10.0.2.8 (Node2) 부착 후 물리 망(Underlay)으로 방출 $\rightarrow$ Node2가 받아서 캡슐 해제 후 PodB에 꽂아주는 클라우드 네이티브 오버레이 파이프라인 렌더링.

7. Terminology

8. References

Primary

• [P1] CS2023 - Networking and Communication (NC) - Virtualization and Overlay Networks
• [P5] SFIA - Network Design (NTDS) - Data Center Networking and Virtualization

Secondary

• [Cloud Native Data Center Networking] Dinesh G. Dutt - Overlays, VXLAN, and EVPN
• [Building Data Centers with VXLAN BGP EVPN] David Jansen - VXLAN Fundamentals

Industry

• [IETF RFC 7348] - Virtual eXtensible Local Area Network (VXLAN)
• [Cisco White Paper] - VXLAN Overview
• [AWS Documentation] - Amazon VPC Under the Hood (Mapping Service and Encapsulation)

9. Final Checklist

Primary

• 눈에 보이는 케이블과 하드웨어 라우터 장비들로 구성된 기반 망(Underlay Network)과, 그 위를 터널링(Tunneling) 기법으로 가로질러 소프트웨어적으로 그려낸 가상 망(Overlay Network)의 계층적 차이를 설명할 수 있는가?
• 거대한 퍼블릭 클라우드 데이터센터에서 고객(테넌트)들을 물리적 분리 없이 가상으로 쪼개줄 때, 12비트(4096개)의 한계를 가진 VLAN 대신 24비트(1,600만 개) VNI를 가진 VXLAN이 도입될 수밖에 없었던 용량적(Scaling) 이유를 증명할 수 있는가?

Secondary

• 원본 L2 이더넷 프레임을 건드리지 않고 전체를 캡슐화하여 새로운 UDP/IP 헤더를 뒤집어씌우는 'MAC-in-UDP (L2 over L3)' 구조를 통해, 거리가 먼 스위치 간에도 텔레포트처럼 브로드캐스트 도메인을 연장하는 원리를 해부할 수 있는가?
• VXLAN 터널의 입출구 역할을 하는 VTEP(VXLAN Tunnel End Point)이 원본 패킷을 포장(Encapsulate)하고 해제(Decapsulate)하는 과정을 스니핑(Sniffing)된 와이어샤크(Wireshark) 구조도로 그려낼 수 있는가?

Industry

• 데이터센터 내 트래픽이 커질 때 캡슐화를 수행하는 주체(VTEP)를 서버의 하이퍼바이저(소프트웨어 VTEP)에 둘 것인지, 아니면 랙 상단(ToR) 스위치의 전용 ASIC 칩(하드웨어 VTEP)에 둘 것인지에 대한 CPU 병목 트레이드오프를 평가할 수 있는가?
• 멀티캐스트(Multicast)를 지원하지 않는 AWS 같은 퍼블릭 클라우드 환경에서 쿠버네티스를 돌릴 때, Flannel이나 Calico 같은 CNI 플러그인이 VXLAN을 이용해 노드(Node) 간 파드(Pod) 통신을 어떻게 터널링하여 이어주는지 아키텍처를 설계할 수 있는가?