Datacenter & Cloud - 03. 오버레이·언더레이

물리 도로 위에 가상 다리를 놓는 기술 — 오버레이와 언더레이

네트워크 fundamentals 영역에서 VLAN이 4094개까지만 만들 수 있다고 했다. 하지만 — AWS·GCP 같은 클라우드에는 수백만 명의 고객이 있고, 각 고객이 자기만의 격리된 네트워크를 원한다. 4094개로는 턱없이 부족하다. 어떻게 수백만 개의 격리된 네트워크를 만들까? 답이 오버레이 네트워크(overlay network) — 물리적 네트워크(언더레이) 위에 논리적 네트워크를 덧씌우는 기술이다. VXLAN이 그 핵심이다. 이 글은 오버레이와 언더레이의 관계, VXLAN·EVPN·Geneve가 어떻게 클라우드의 멀티테넌시를 가능하게 하는지를 다룬다.

이 글은 이전 글(DC 네트워크 토폴로지)에서 본 spine-leaf 물리 네트워크(언더레이) 위에 — 논리적 L2 네트워크(오버레이)를 얹는 방법을 다룬다. 비유하자면 — 도로(언더레이) 위에 터널(오버레이)을 놓는 것. 터널 안의 차량은 — 도로의 실제 경로를 모른 채 — 터널 입구에서 출발해 출구로 간다.

언더레이와 오버레이 — 두 개의 네트워크 층

언더레이(underlay) — 물리적 네트워크. spine-leaf 스위치·라우터·광케이블이 만드는 실제 패킷 전달 경로. IP 주소·BGP/OSPF 라우팅이 여기서 동작한다. 이전 글에서 본 것.

오버레이(overlay) — 언더레이 위에 소프트웨어로 만든 논리적 네트워크. 언더레이의 패킷 전달 능력을 이용하되 — 논리적으로 격리된 네트워크 세그먼트를 만든다. VXLAN이 대표적.

flowchart TD
    subgraph OVERLAY["오버레이 (논리적)"]
        VM1["VM-A<br/>VXLAN 10001"]
        VM2["VM-B<br/>VXLAN 10001"]
        VM1 -. 같은 논리 L2 .- VM2
    end
    subgraph UNDERLAY["언더레이 (물리적)"]
        VTEP1["VTEP 1<br/>(leaf 스위치)"]
        SPINE["Spine"]
        VTEP2["VTEP 2<br/>(leaf 스위치)"]
        VTEP1 --> SPINE --> VTEP2
    end
    VM1 --> VTEP1
    VM2 --> VTEP2

VM-A와 VM-B는 — 논리적으로 같은 L2 네트워크(VXLAN 10001)에 있다. 하지만 물리적으로는 — 다른 랙(다른 leaf 스위치)에 있을 수 있다. 오버레이가 — 물리적 거리를 논리적으로 "무시"한다.

VXLAN — VLAN의 4094 한계를 넘다

VXLAN(Virtual eXtensible LAN, RFC 7348) 은 — 2014년 VMware·Cisco가 주도로 만든 오버레이 기술. 핵심 혁신은 — VLAN의 12비트 ID(4094개) 대신 24비트 ID(1600만 개) 를 쓴다는 것. 클라우드의 수백만 테넌트를 지원하기에 충분하다.

VXLAN의 캡슐화 — L2 프레임을 UDP 패킷에 넣기

VXLAN의 핵심 메커니즘은 캡슐화(encapsulation) 다. 원래 L2 프레임(MAC 주소 기반)을 — UDP 패킷(L3, IP 주소 기반) 안에 넣어서 전송한다.

VXLAN 캡슐화 구조:
┌──────────┬──────────┬─────┬──────┬────────────┬──────────────────┐
│ 외부 IP   │ 외부 IP   │ UDP │ VXLAN│ 원본 L2    │ 원본 L2          │
│ 목적지    │ 출발지    │ 헤더│ 헤더 │ 이더넷 헤더│ 페이로드 (데이터) │
│ (VTEP IP) │ (VTEP IP) │     │(VNID)│ (MAC 등)  │                  │
└──────────┴──────────┴─────┴──────┴────────────┴──────────────────┘
                                           ↑
                                    원본 프레임 그대로 (VXLAN 안에)

비유하자면 — 편지(원본 L2 프레임)를 — 다른 봉투(UDP 패킷) 에 넣어서 보내는 것. 겉봉투에는 배송 센터 주소(VTEP의 IP)가 적혀 있고 — 안의 편지에는 최종 수신자(MAC 주소)가 적혀 있다. 배송 센터(VTEP)가 겉봉투를 열고 — 안의 편지를 최종 수신자에게 전달한다.

VTEP — 터널의 입구와 출구

VTEP(VXLAN Tunnel Endpoint) 는 — VXLAN 터널의 양 끝점. 원본 L2 프레임을 UDP 패킷으로 캡슐화(봉투에 넣기)하고 — 수신 측에서 캡슐화를 해제(봉투 열기)하는 역할. VTEP는 보통 leaf 스위치(ToR) 또는 하이퍼바이저(host)에 구현된다.

• VTEP 송신 — VM이 보낸 L2 프레임을 받아 — VXLAN 헤더(VNID) + UDP 헤더 + 외부 IP 헤더를 추가해 — 대상 VTEP의 IP로 전송
• VTEP 수신 — UDP 패킷을 받아 — 외부 헤더를 벗기고 — 원본 L2 프레임을 목적지 VM에게 전달

VNID — 1600만 개의 논리적 네트워크

VNID(VXLAN Network Identifier) 는 — VLAN ID의 VXLAN 버전. 24비트 = 16,777,216개(약 1600만). 각 VNID가 하나의 논리적 L2 브로드캐스트 도메인. VLAN과 달리 — VNID는 언더레이의 물리적 토폴로지와 무관하다. 같은 VNID를 가진 VM은 — 다른 랙·다른 리전에 있어도 — 논리적으로 같은 L2에 있다.

특성	VLAN (802.1Q)	VXLAN
ID 길이	12비트 (4094개)	24비트 (1600만 개)
동작 계층	L2 (물리적)	L2 over L3 (오버레이)
범위 제한	같은 물리 스위치 그룹	IP가 닿는 곳 어디든
캡슐화	없음 (태그만 추가)	UDP 캡슐화 (50바이트 오버헤드)
브로드캐스트	같은 VLAN에 전파	헤드엔드 복제 또는 멀티캐스트
MTU 영향	없음	50바이트 오버헤드 → MTU 조정 필요

EVPN — VXLAN의 컨트롤 플레인

VXLAN이 "데이터 플레인(데이터 전송)"이라면 — EVPN(Ethernet VPN, RFC 7432) 은 "컨트롤 플레인(제어)"이다. VXLAN만 쓰면 — "목적지 VM의 MAC 주소가 어느 VTEP 뒤에 있나?"를 모른다. 이걸 ARP 브로드캐스트로 찾으면 — 대규모에서 브로드캐스트 폭풍이 일어난다.

EVPN은 — BGP를 이용해 — 각 VTEP가 "나는 이 MAC 주소(VM)를 갖고 있다"는 정보를 다른 VTEP에게 광고한다. BGP 컨트롤 플레인이 MAC 학습을 담당하니 — ARP 브로드캐스트가 필요 없다. 대규모 VXLAN 배포(AWS·GCP·Azure)가 EVPN을 쓴다.

flowchart LR
    subgraph CP["컨트롤 플레인 (EVPN/BGP)"]
        VTEP1["VTEP 1: MAC aa:aa는 나한테 있어"]
        VTEP2["VTEP 2: MAC bb:bb는 나한테 있어"]
        VTEP1 <-->|"BGP 광고"| VTEP2
    end
    subgraph DP["데이터 플레인 (VXLAN/UDP)"]
        VTEP1 -->|"MAC aa → bb 캡슐화 전송"| VTEP2
    end

Geneve — VXLAN의 차세대

Geneve(Generic Network Virtualization Encapsulation, RFC 8926) 은 — VXLAN과 STT의 장점을 합친 2020년 표준. VXLAN의 고정 헤더 대신 — 확장 가능한 TLV(Type-Length-Value) 헤더를 쓴다. 필요한 메타데이터를 유연하게 추가할 수 있다. OpenStack·OVN이 Geneve를 기본으로 채택했다.

특성	VXLAN	Geneve
표준	RFC 7348 (2014)	RFC 8926 (2020)
헤더 구조	고정 (8바이트)	가변 (TLV 확장 가능)
메타데이터	VNID만	옵션 필드로 추가 가능
컨트롤 플레인	EVPN (BGP)	EVPN 또는 OVN
채택	VMware NSX, Cisco ACI	OpenStack, OVN

왜 오버레이가 필요한가 — 클라우드의 멀티테넌시

클라우드의 핵심 요구사항 — 각 고객(테넌트)의 네트워크가 서로 완전히 격리돼야 한다. 고객 A의 VM이 고객 B의 네트워크 트래픽을 보면 안 된다.

물리적 네트워크(언더레이)만으로는 — 이 격리를 만들기 어렵다. VLAN 4094개 한계도 있고, 물리 스위치를 매번 설정하는 건 비현실적이다. 오버레이(VXLAN)가 이 문제를 푼다:

• 각 테넌트에 고유 VNID를 할당 — 다른 VNID의 트래픽과 격리
• VM이 다른 호스트로 마이그레이션해도 — 같은 VNID면 같은 논리 네트워크 (물리 위치 무관)
• 언더레이는 — 그저 VTEP 간 UDP 패킷을 전달하기만 하면 됨 — 언더레이 설정 변경 불필요

캡슐화 오버헤드 — MTU 조정이 필수인 이유

VXLAN은 원본 프레임에 50바이트(외부 IP 20 + UDP 8 + VXLAN 8 + 이더넷 14)를 추가한다. 표준 이더넷 MTU 1500바이트에서 — VXLAN 오버헤드 50바이트를 빼면 — VM이 실제로 쓸 수 있는 MTU는 1450바이트. 이걸 모르면 — 패킷 단편화(fragmentation)가 일어나고 성능이 떨어진다.

해결책 — 언더레이 네트워크의 MTU를 1500에서 1600+으로 올린다(jumbo frame). 그러면 VM은 1500바이트 MTU를 그대로 쓰고 — VXLAN 오버헤드 50바이트가 언더레이의 여유 공간에 흡수된다. 데이터센터 네트워크에서 jumbo frame(MTU 9000)이 표준인 이유 중 하나다.

실습 — 오버레이 상태 확인

1. VXLAN 인터페이스 확인 (Linux 호스트)

# VXLAN 인터페이스가 있는지
ip -d link show type vxlan
# 또는
ip link show | grep vxlan

확인할 것: vxlan0 같은 인터페이스와 — vxlan id 10001 ... dev eth0 dstport 4789 설정. id가 VNID, dstport 4789가 VXLAN의 표준 UDP 포트(IANA 할당).

2. 캡슐화 패킷 직접 보기

# VXLAN 캡슐화 패킷 캡처 (VXLAN 트래픽이 있는 환경)
sudo tcpdump -i eth0 -n 'udp port 4789' -c 5

확인할 것: UDP 포트 4789 패킷이 보이면 — VXLAN 오버레이가 동작하고 있는 것. 패킷 안에 VXLAN 헤더(VNID)가 들어 있다.

3. MTU 확인

# 인터페이스 MTU
ip link show eth0 | grep mtu
# VXLAN 인터페이스의 MTU (언더레이보다 50 작아야)
ip link show vxlan0 2>/dev/null | grep mtu

확인할 것: 언더레이 eth0이 MTU 9000이면 — VXLAN 인터페이스는 8950(9000 - 50). 이 차이가 안 나면 — 패킷 단편화 위험.

미검증: VXLAN 인터페이스는 VXLAN을 설정한 환경(OpenStack·NSX·OVS)에서만 보임. 일반 Linux VM이나 클라우드 EC2에서는 VXLAN이 벤더에게 숨겨져 있어 직접 확인이 어려움. tcpdump로 포트 4789를 잡으면 간접적으로 확인 가능.

판단 표 — VLAN vs VXLAN vs Geneve

기준	VLAN	VXLAN	Geneve
네트워크 수	4094	1600만	1600만
범위	같은 L2 세그먼트	IP가 닿는 곳	IP가 닿는 곳
캡슐화	없음	UDP 50바이트	UDP 가변
컨트롤 플레인	없음 (스위치 MAC 학습)	EVPN/BGP	EVPN/BGP 또는 OVN
적합 규모	소규모 (~수백 네트워크)	대규모 (클라우드)	대규모 (OpenStack)
전형 사례	사무실, 기업 DC	VMware NSX, AWS VPC	OpenStack, OVN

오버레이는 물리를 논리로 바꾼다

오버레이(VXLAN·EVPN·Geneve)는 — 물리적 네트워크의 제약(거리·VLAN 수·설정 복잡도)을 — 소프트웨어로 극복하는 기술이다. 언더레이(spine-leaf)가 "도로"라면 — 오버레이는 "도로 위의 터널". 터널 안에서는 — 도로의 실제 경로를 모른 채 — 논리적으로 연결된 세계에 있는 것처럼 통신한다. 이게 — 클라우드의 수백만 고객이 각자 격리된 네트워크를 갖는 것을 가능하게 하는 기반 기술이다.

오버레이와 언더레이의 분리 — 왜 강력한가

오버레이/언더레이 분리의 핵심 이점은 — 두 층이 독립적으로 진화할 수 있다는 것이다. 언더레이의 스위치를 교체하거나 토폴로지를 바꿔도 — 오버레이(VXLAN VNID·EVPN MAC 테이블)는 그대로 작동한다. 반대로 — 새 VXLAN 세그먼트를 추가해도 — 언더레이 스위치 설정을 변경할 필요가 없다.

이 독립성이 — 클라우드의 민첩성(agility) 을 만든다. 고객이 VPC를 새로 만들면 — 클라우드 벤더의 컨트롤 플레인이 새 VNID를 할당하고 — EVPN으로 VTEP에 광고한다. 언더레이는 — 그저 UDP 패킷을 전달하기만 하면 되니 — 아무것도 몰라도 된다. 수백만 VPC가 실시간으로 만들어지고 삭제되는 게 가능한 이유다.

멀티캐스트 vs 유니캐스트 헤드엔드 복제

VXLAN에서 브로드캐스트(ARP·DHCP)를 어떻게 전달할 것인가가 문제다. 원래 L2에서는 — 브로드캐스트가 같은 VLAN의 모든 포트로 플러딩됐다. VXLAN에서는 — 세 가지 방법이 있다:

1. 멀티캐스트(Multicast) — 언더레이에서 IP 멀티캐스트 그룹을 만들어 — 같은 VNID의 VTEP들이 가입. 브로드캐스트를 멀티캐스트로 전송. 언더레이가 멀티캐스트를 지원해야 해서 복잡.
2. 유니캐스트 헤드엔드 복제(Head-End Replication, HER) — 송신 VTEP가 — 같은 VNID의 모든 VTEP에게 개별적으로 유니캐스트로 복사본을 보냄. 멀티캐스트 불필요하지만 — VTEP 수가 많으면 트래픽이 증가.
3. EVPN(BGP) — 컨트롤 플레인으로 MAC/IP 위치를 미리 학습. 브로드캐스트 자체가 필요 없음. 현대의 표준.

현대 데이터센터(VMware NSX·Cisco ACI·OpenStack)는 — 대부분 EVPN + HER 조합을 쓴다. 멀티캐스트는 — 언더레이 설정이 복잡해서 기피된다.

AWS·GCP의 오버레이 — 사용자에게 보이지 않는 층

AWS EC2의 VPC, GCP의 VPC 네트워크는 — 내부적으로 VXLAN(또는 유사 기술)로 구현돼 있다. 하지만 — 사용자는 VXLAN을 직접 설정하지 않는다. 사용자는 "서브넷 만들기" 버튼을 누르고 — 클라우드 컨트롤 플레인이 알아서 VXLAN VNID를 할당하고 VTEP를 설정한다. foundations 06의 IaC 철학("인프라를 소프트웨어로")이 — 네트워크 가상화에 완전히 적용된 것이다.

다음 글에서는 클라우드 네트워킹의 기초를 다룬다 — VPC. AWS·GCP·Azure에서 사용자가 직접 다루는 가상 네트워크가 — 오버레이 기술 위에 어떻게 만들어지는지.

오버레이 네트워크의 핵심 — 물리 네트워크(언더레이) 위에 소프트웨어로 논리적 네트워크를 만드는 것. VXLAN이 VLAN의 4094 한계를 1600만으로 넘어섰고, EVPN이 BGP로 MAC 학습을 자동화했으며, Geneve가 유연한 헤더 구조로 진화했다. 클라우드의 수백만 VPC가 — 이 오버레이 기술 위에 만들어진다. 사용자는 VXLAN을 직접 다루지 않지만 — 클라우드의 모든 네트워크 격리가 결국 이 기술로 구현된다.

오버레이의 한계 — 캡슐화 오버헤드와 디버깅 어려움

오버레이가 만능은 아니다. 두 가지 현실적 한계가 있다.

캡슐화 오버헤드 — VXLAN이 50바이트를 추가하므로 — 언더레이 MTU를 1500에서 1600+으로 올려야 한다(jumbo frame). MTU 설정이 안 맞으면 — 패킷 단편화가 일어나고 성능이 급락한다. 클라우드 벤더가 알아서 설정하지만 — 자체 구축 환경에서는 반드시 확인해야 함.

디버깅 어려움 — 오버레이가 언더레이 위에 캡슐화되므로 — "패킷이 어디서 손실됐는가?"를 찾기 어렵다. tcpdump로 보이는 건 — 겉봉투(VXLAN 헤더)만이고 — 안의 원본 프레임은 보이지 않는다. VTEP 간 통신 문제·EVPN BGP 오류·MTU 불일치 — 이런 문제를 디버깅하려면 — 오버레이와 언더레이 양쪽을 모두 봐야 한다. foundations 03의 "의존성 그래프"가 복잡해지는 지점이다.

EVPN의 동작 — BGP로 MAC 주소를 학습한다

EVPN이 없는 순수 VXLAN은 — 브로드캐스트(ARP·DHCP)를 어떻게 전달할지가 문제다. 원래 L2에서는 — ARP가 같은 VLAN의 모든 포트로 플러딩된다. VXLAN에서 이걸 그대로 하면 — 같은 VNID의 모든 VTEP에 복제해 보내야 한다(head-end replication). VTEP가 수백 개면 — ARP 하나에 수백 개의 패킷이 만들어진다.

EVPN은 — BGP를 이용해 MAC 주소 위치를 미리 학습한다. 각 VTEP가 — 자기 뒤에 있는 VM의 MAC 주소를 BGP로 광고한다. "MAC aa:aa:bb:bb:cc:cc는 VNID 10001의 나(VTEP 10.0.0.1)한테 있다." 다른 VTEP는 이걸 BGP로 받아 — 자기 MAC 테이블에 저장한다.

이렇게 하면 — ARP를 브로드캐스트할 필요가 없다. 송신 VTEP가 — BGP 테이블에서 목적지 MAC의 위치(VTEP IP)를 바로 찾아 — 유니캐스트로 한 번에 보낸다. "전화번호부를 미리 갖고 있으니 — 114에 안 물어봐도 된다"는 것이다. 수만 VM 규모에서 — 브로드캐스트 억제가 성능에 결정적이다.

VXLAN과 클라우드 — 사용자에게 보이지 않는 층

AWS EC2의 VPC, GCP의 VPC 네트워크는 — 내부적으로 VXLAN(또는 유사 기술)로 구현돼 있다. 사용자가 "서브넷 만들기"를 누르면 — 클라우드 컨트롤 플레인이 알아서 VXLAN VNID를 할당하고 VTEP를 설정한다. 사용자는 VXLAN을 직접 다루지 않는다 — 그 아래의 기술이 보이지 않게 추상화돼 있다. 이 추상화가 — 클라우드를 쉽게 만드는 핵심이다. 사용자는 — VPC CIDR·서브넷·보안 그룹만 설정하면 되고 — VXLAN·EVPN·MTU 조정은 벤더가 알아서 한다.

Geneve — VXLAN의 유연한 후계

Geneve는 VXLAN의 고정 헤더(8바이트, VNID만) 대신 — TLV(Type-Length-Value) 구조로 — 필요한 메타데이터를 유연하게 추가한다. 예를 들어 — 보안 정책 ID·테넌트 ID·서비스 체인 정보를 Geneve 헤더에 실을 수 있다. VXLAN은 이런 확장이 불가능하다. OpenStack·OVN이 Geneve를 기본으로 채택한 이유다. 하지만 — 상용 클라우드(AWS·GCP)는 여전히 VXLAN(또는 자체 변형)을 쓴다. 호환성과 안정성이 중요해서다. Geneve는 — 새 클라우드 구축(OpenStack 기반)에서 인기를 끌고 있다.

EVPN 라우트 타입 — 무엇을 광고하는가

EVPN은 BGP를 확장해 — MAC 주소뿐 아니라 IP 주소·멀티캐스트 그룹 정보까지 광고한다. 주요 라우트 타입:

타입	이름	내용	용도
Type 2	MAC/IP Route	"MAC aa는 VTEP 10.0.0.1에 있다"	MAC/IP 학습 (가장 많이 쓰임)
Type 3	IMET Route	"나는 VNID 10001에 참여한다"	VTEP 간 자동 발견 (head-end 복제용)
Type 5	IP Prefix Route	"10.0.1.0/24은 여기로"	L3 라우팅 (서브넷 간 통신)

Type 2가 핵심이다 — 이게 MAC 주소를 BGP로 학습시키는 역할. Type 3은 — 새 VTEP가 "나 같은 VNID에 있어"라고 알리는 것(자동 발견). Type 5는 — L3 라우팅을 오버레이 안에서 처리하는 것(VLAN 간 통신을 라우터 없이).

이 라우트 타입들이 — 대규모 VXLAN 배포를 가능하게 한다. 브로드캐스트 없이, BGP 컨트롤 플레인만으로 — 수만 VM의 MAC/IP를 관리할 수 있다. foundations 04의 라우팅 글에서 본 BGP가 — VXLAN 세계에서도 핵심 역할을 하는 것이다.

오버레이는 — 물리를 논리로, 하드웨어를 소프트웨어로 바꾸는 기술이다.
클라우드의 모든 네트워크 격리가 결국 이 기술로 구현된다.

VXLAN·EVPN·Geneve — 이 세 가지가 현대 클라우드 네트워크 가상화의 핵심이다.
AWS·GCP·Azure가 내부적으로 쓰고, OpenStack이 자체 구축 환경에서 쓴다.
물리 네트워크 위에 논리 네트워크를 만드는 이 기술이 없으면 —
클라우드의 멀티테넌시는 불가능하다.

오버레이를 이해하면 — 클라우드의 네트워크 격리가 소프트웨어로 만들어진다는 게 보인다. 사용자는 "서브넷 만들기" 버튼을 누르지만 — 그 뒤에서는 VXLAN VNID가 할당되고 EVPN이 MAC을 학습하고 VTEP가 캡슐화를 수행한다. 이 보이지 않는 기술 층이 — 클라우드를 가능하게 하는 기반이다.

오버레이 기술의 핵심 — 물리 네트워크 위에 소프트웨어로 논리적 네트워크를 만드는 것.
VXLAN이 VLAN의 한계를, EVPN이 브로드캐스트 문제를, Geneve가 유연성을 해결한다.

---

참고

• RFC 7348, Mahalingam, M. et al. "Virtual eXtensible Local Area Network (VXLAN)", 2014 — VXLAN 표준. 접근 2026-07-21
• RFC 7432, Sajassi, A. et al. "BGP MPLS-Based Ethernet VPN", 2015 — EVPN 표준. 접근 2026-07-21
• RFC 8926, Gross, J. et al. "Geneve: Generic Network Virtualization Encapsulation", 2020 — Geneve 표준. 접근 2026-07-21
• VMware, "VXLAN Overview" white paper, 2014 — VXLAN 개념. 접근 2026-07-21
• Drutskoy, D. et al. "Scalability of Microservices-Based Applications", 2013 — 오버레이 확장성 분석. 접근 2026-07-21
• Cisco, "VXLAN Network with BGP EVPN" design guide, 2020 — EVPN 실전 설계. 접근 2026-07-21
• VMware, "NSX-V to NSX-T Migration Guide" — VXLAN 구현 사례. 접근 2026-07-21