[📌] Linux & Network

리눅스 네트워크 격리 : Network Namespace, VETH

• OpenStack의 프로젝트 격리나 K8s Pod 격리는 리눅스 커널의 기능인 Network Namespace(netns)를 기반으로 한다.

📌 Network Namespace (netns)

• 리눅스 커널이 제공하는 프로세스 격리 기술 중 하나이다. 시스템의 네트워크 리소스를 논리적으로 분할하여, 마치 별도의 물리적인 네트워크 장비를 가진 것처럼 독립된 환경을 제공한다.
• 독립되는 리소스
  • Network Interface : 네트워크 인터페이스 카드 (NIC, veth 등)
  • Routing Table : 패킷의 경로를 결정하는 라우팅 테이블
  • ARP Table : IP 주소와 MAC 주소 매핑 정보
  • Firewall Rules (iptables/ntftables) : 패킷 필터링 규칙
  • Socket : TCP/UDP 소켓 정보
• 리눅스 부팅 시 기본적으로 존재하는 공간을 Root Namespace라고 하며, 별도로 생성하는 새로운 Namespace는 이와 완전히 격리된다. 따라서 A Namespace에서 설정한 IP나 라우팅 규칙은 B Namespace나 Root Namespace에 영향을 주지 않는다.

# Namespace(netns) 'red' 생성
ip netns add red

# 현재 시스템의 Namespace 목록 확인
ip netns list

• /var/run/netns/ 경로에 해당 이름의 파일을 생성하여 네임스페이스를 유지한다.

---

📌 VETH (Virtual Ethernet) Pair

• Namespace를 생성하면 그 안은 텅 비어 있고 외부와 단절된 상태이다. 이를 연결하기 위해 VETH Pair가 필요하다.
• 정의 : 리눅스 커널에서 지원하는 가상 네트워크 인터페이스 쌍이다. 항상 2개의 인터페이스가 한 쌍으로 생성된다.
• 특징 : 한쪽 인터페이스로 패킷이 들어오면, 커널 내부 버퍼를 통해 즉시 반대쪽 인터페이스로 전달된다. (물리적인 랜 케이블의 양쪽 끝이라고 이해하면 정확하다.)
• 용도
  • Root Namespace와 격리된 Namespace 간의 연결
  • 서로 다른 두 Namespace 간의 연결
  • Namespace와 가상 스위치(Linux Bridge) 간의 연결

# VETH Pair 생성 (2개의 가상 인터페이스 쌍을 생성, 아직 Root Namespace에 존재)
# ip link add [장치명] type veth peer name [상대방장치명]
ip link add veth-red type veth peer name veth-root

# 인터페이스 이동 (생성한 인터페이스를 특정 네임스페이스 안으로 이동시킴)
ip link set veth-red netns red

# 네임스페이스 내부 명령 실행 및 IP 할당 (ip netns exec)
# 격리된 공간인 red 안에서 명령어를 실행하려면 ip netns exec를 사용해야 한다.
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red

# red 네임스페이스 안의 veth-red 인터페이스 활성화 (up)
ip netns exec red ip link set veth-red up

# Root 네임스페이스에 남겨진 veth-root에도 IP 할당 및 활성화
ip addr add 10.0.0.1/24 dev veth-root
ip link set veth-root up

• 논리적으로 서로 다른 netns에 있는 Root와 Red가 연결되었다.
• ping : 물리 네트워크 카드를 거치지 않고, 커널 메모리 내에서 VETH Pair를 통해 직접 패킷이 복사되어 전달된다.

---

Linux Bridge

• 리눅스 커널 내부에 구현된 가상 L2 스위치. 물리적인 스위치 장비가 하는 일과 정확히 똑같은 일을 소프트웨어로 수행한다.
• 기능 : 여러 개의 네트워크 인터페이스(VETH의 한쪽 끝, 물리 NIC)를 하나의 브리지에 연걸하여, 같은 L2 세그먼트(동일한 서브넷)에 있는 것처럼 통신하게 해준다.
• 동작 원리
  • MAC Learning : 브리지 포트로 들어오는 패킷의 Source MAC Address를 보고, "이 MAC 주소는 이 포트에 연결되어 있다"라는 정보를 FDB(Forwarding Database) 테이블에 기록한다.
  • Forwarding : 패킷의 Destination MAC Address가 FDB에 있다면 해당 포트로만 패킷을 보낸다. (Unicast)
  • Flooding : Destination MAC이 FDB에 없거나 브로드캐스트 패킷(ARP 등)이라면, 들어온 포트를 제외한 모든 포트로 패킷을 뿌린다.
• 2개의 네임스페이스 red, blue를 만들고, 이 둘을 직접 연결하는 것이 아니라 br0라는 브리지를 통해 통신하도록 구성

# 브리지 br0 생성 및 활성화(=스위치 전원 켜기)
ip link add br0 type bridge
ip link set br0 up


# netns 생성
ip netns add red
ip netns add blue

# VETH Pair 생성 (red용, blue용)
ip link add veth-red type veth peer name veth-red-br
ip link add veth-blue type veth peer name veth-blud-br

# 인터페이스 네임스페이스로 이동
ip link set veth-red netns red
ip link set veth-blue netns blue

# 네임스페이스 내부에 있는 인터페이스에 IP 할당 및 활성화
ip netns exec red ip addr add 10.0.0.2/24 dev veth-red
ip netns exec red ip link set veth-red up
ip netns exec blue ip addr add 10.0.0.3/24 dev veth-blue
ip netns exec blud ip link set veth-blue up

# Root 네임스페이스에 남아 있는 각 VETH의 한쪽 끝들을 스위치(br0)의 포트에 연결
ip link set veth-red-br master br0
ip link set veth-red-br up

ip link set veth-blue-br master br0
ip link set veth-blud-br up

• 구조 : [NS red] veth-red <-> veth-red-br <-> [Bridge br0] <-> veth-blue-br <-> [NS blue] veth-blue
• 물리적으로 연결된 선이 없지만, br0가 L2 스위칭을 통해 패킷을 전달 (핑 가능)

# - FDB 테이블 조회
bridge fdb show br0
33:33:00:00:00:01 dev br0 self permanent
0a:5b:12:34:56:78 dev veth-red-br master br0
0a:5b:87:65:43:21 dev veth-blue-br master br0

• 브리지에 연결되는 인터페이스는 일반적으로 Promiscuous Mode(무차별 모드)로 동작해야 한다. 일반적인 NIC는 자신의 MAC 주소가 아닌 패킷은 버리지만, 브리지 포트는 자신에게 오지 않은 패킷이라도 브리지 로직(전달)을 수행하기 위해 모든 패킷을 받아들여야 하기 때문이다. 리눅스 브리지는 연결 시 자동으로 이를 처리하는 경우가 많다.

---

IP Forwarding & Routing Table

• 서로 다른 네트워크 대역을 연결하는 L3 라우팅과 리눅스 커널이 라우터 역할을 하게 만드는 IP Forwarding.
  • OpenStack의 Neutron L3 Agent나 K8s의 CNI 플러그인이 동작하는 기본 원리.
    
    
• 리눅스 시스템은 기본적으로 최종 목적지가 자신인 패킷만 받아들이고, 자신이 목적지가 아닌 패킷은 패기한다. 리눅스를 라우터스 시스템은 기본적으로 최종 목적지가 자신인 패킷만 받아들이고, 자신이 목적지가 아닌 패킷은 패기한다. 리눅스를 라우터처럼 쓰기 위해서는 이 기능을 활성화하고, 경로를 알려줘야 한다.

1. IP Forwarding (패킷 전달)
   • 개념 : 하나의 네트워크 인터페이스로 들어온 패킷의 목적지 IP가 자신이 아닐 때, 이를 버리지 않고 적절한 다른 인터페이스로 넘겨주는 기능
   • 리눅스 기반의 방화벽, 라우터, K8s 노드가 파드 간 통신을 중계하기 위해 반드시 켜져 있어야 하는 커널 파라미터이다.
2. Routing Table
   • 개념 : 이 목적지 IP로 가려면 어느 인터페이스로 나가야 하고, 누구(Gateway)에게 줘야 하는지가 적혀 있는 테이블
   • 동작 : 패킷을 보낼 때 커널은 목적지 IP와 라우팅 테이블을 규칙을 대조하여 가장 적합한 경로를 선택한다.

# 브리지 없이, 리눅스 호스트(Root Namespace)를 라우터로 사용하여
# 서로 다른 IP 대역을 가진 두 네임스페이스를 통신
ip netns add net1
ip netns add net2

ip link add veth-net1 type veth peer name veth-net1-host
ip link set veth-net1 netns net1
ip link add veth-net2 type veth peer name veth-net2-host
ip link set veth-net2 netns net2

ip netns exec net1 ip addr add 10.0.1.2/24 dev veth-net1
ip netnx exec net1 ip link set veth-net1 up
ip netns exec net2 ip addr add 10.0.2.2/24 dev veth-net2
ip netnx exec net2 ip link set veth-net2 up

# 호스트 측 veth-net1/2-host에 각 대역에 맞는 IP를 게이트웨이 역할로 할당
ip addr add 10.0.1.1/24 dev veth-net1-host
ip link set veth-net1-host up
ip addr add 10.0.2.1/24 dev veth-net2-host
ip link set veth-net2-host up

# 리눅스는 기본적으로 라우팅 기능을 하지 않으므로 이를 켜준다
# 현재 설정 확인 (0이면 비활성)
cat /proc/sys/net/ipv4/ip_forward
sysctl -w net.ipv4.ip_forward=1

# net1과 net2는 독립된 공간이므로 자신의 대역 밖으로 나가는 패킷을 어디로 보낼지 모른다
# 모르는 곳으로 갈 때는 무조건 호스트(게이트웨이)로 보내는 규칙을 추가
# 목적지가 라우팅 테이블에 명시되지 않은 모든 패킷을 Gateway IP로 보냄
ip netns exec net1 ip route add default via 10.0.1.1
ip netns exec net2 ip route add default via 10.0.2.1

ip netns exec net1 ping 10.0.2.2

---

Netfilter & iptables

K8s Pod가 외부 인터넷을 쓰고, 외부에서 ClusterIP로 접근하고, OpenStack 인스턴스가 Floating IP를 갖는 기술적 배경에는 패킷 필터링과 NAT가 있다.

리눅스 커널은 네트워크 패킷을 처리하기 위해 Netfilter라는 프레임워크를 내장하고 있다.

• Netfilter : 커널의 네트워크 스택 내부의 특정 지점(Hook)에 콜백 함수를 등록하여, 패킷을 가로채고 조작할 수 있게 해준다.
• iptables : 유저 공간에서 이 Netfilter의 규칙을 설정하는 도구

  리눅스 시스템의 메모리는 크게 두 영역으로 나뉜다.

  • 커널 공간
    • 운영체제의 핵심인 커널이 실행되는 메모리 영역
    • CPU의 Ring 0 (가장 높은 특권 레벨)에서 동작
    • 모든 하드웨어에 직접 접근하고 제어할 수 있는 권한을 가진다
    • 이곳에서 코드가 실행되다가 오류가 발생하면, 시스템 전체가 멈춘다. Netfilter는 커널 공간의 네트워크 스택에서 동작하며 실시간으로 흐르는 패킷을 처리한다.
  • 유저 공간
    • 사용자가 실행하는 일반적인 애플리케이션들이 실행되는 메모리 영역
    • CPU의 Ring 3 (가장 낮은 특권 레벨)에서 동작
    • 하드웨어에 직접 접근할 수 없다. 하드웨어 자원이 필요하면 반드시 커널에 요청해야 한다.
    • 프로그램이 충돌해도 해당 프로세스만 종료될 뿐, 운영체제 전체엔은 영향을 주지 않는다.

1. Netfilter의 5가지 Hook Point
   • NF_IP_PRE_ROUTING (PREROUTING)
     • NIC로부터 패킷을 수신한 직후, 라우팅 결정이 일어나기 전 단계
     • DANT를 수행한다. 목적지 IP를 변경해야 한다면, 라우팅을 수행하기 전에 변경해야 변경된 IP를 기준으로 올바른 경로를 찾을 수 있기 때문이다.
   • NF_IP_LOCAL_IN (INPUT)
     • 라우팅 결과, 패킷의 목적지가 로컬 시스템(자신)인 경우 도달하는 단계
     • 이 단계를 통과하면 패킷은 상위 계층(L4 -TCP/UDP)으로 전달되어 로컬 프로세스가 수신한다.
   • NF_IP_FORWARD (FORWARD)
     • 라우팅 결과, 패킷의 목적지가 로컬 시스템이 아니고 다른 호스트인 경우 도달하는 단계
     • 방화벽 역할 시 주로 여기서 필터링을 수행한다.
   • NF_IP_LOCAL_OUT (OUTPUT)
     • 로컬 프로세스에서 생성된 패킷이 네트워크 스택으로 내려와 라우팅 결정을 마친 직후의 단계
   • NF_IP_POST_ROUTING (POSTROUTING)
     • 모든 라우팅 결정과 필터링이 끝나고, 네트워크 인터페이스로 패킷이 전송되기 직전 단계
     • SNAT를 수행한다. 패킷이 나갈 인터페이스가 결정된 상태이므로, 해당 인터페이스의 IP에 맞춰 출발지 주소를 변경한다.

---

2. Connection Tracking (conntrack)
   • NAT가 설정된 환경에서 양방향 통신이 가능한 이유는 리눅스 커널의 nf_conntrack 모듈 때문이다.
   • 상태 저장(Statefull) : NAT 규칙은 보통 첫 번째 패킷에만 적용된다.
   • 테이블 기록 : 첫 패킷이 NAT를 거칠 때, 커널은 메모리 내의 상태 테이블에 [원본 출발지/목적지 IP:Port] 와 [변환된 출발지/목적기 IP:Port]의 매핑 정보를 기록한다.
   • 응답 패킷 처리 : 외부에서 응답 패킷이 들어오면, 커널은 이 테이블을 조회한다. 매칭되는 세션 정보가 있다면 별도의 iptables 규칙을 다시 타지 않고 자동으로 역변환을 수행하여 원래의 요청자에게 패킷을 전달한다.

iptables -t nat -A POSTROUTING -s 10.0.1.0/24 -o eth0 -j MQSQUERADE

# -t nat : 커널의 Netfilter 테이블 중 NAT 처리를 담당하는 테이블을 선택합니다.
# -A POSTROUTING : POSTROUTING 훅 지점에 규칙을 추가한다. 즉, 라우팅이 끝나고 인터페이스로 나가기 직전에 이 규칙을 적용한다.
# -s 10.0.1.0/24 : IP 헤더의 Source Address가 10.0.1.0/24 범위에 속하는지 검사
# -o eth0 : 라우팅 테이블 조회 결과, 패킷이 나갈 인터페이스가 eth0인지 검사
# -j MASQUERADE : 위 조건이 일치하면 패킷의 Source Address를 eth0 인터페이스의 현재 IP 주소로 덮어쓴다. 
   # 동시에 커널의 conntrack 테이블에 이 변환 정보를 기록하여, 돌아오는 응답 패킷이 역변환될 수 있도록 한다.

---

VXLAN / Tunneling

물리적으로 떨어져 있는 서버들을 논리적으로 하나의 L2 네트워크로 묶어주는 역할

• 터널링 (Tunneling)
  • 어떤 네트워크 프로토콜의 패킷을 다른 네트워크의 프로토콜의 데이터(Payload) 영역에 실어서 전송하는 기술. (=캡슐화)
  • OSI 7계층의 특정 계층 PDU(Protocl Data Unit)를 하위나 동위, 혹은 상위 계층의 PDU 안에 감싸는 행위
  • 왜 필요한가
    • 서로 다른 네트워크 간의 연결 : 물리적으로 분리된 두 개의 사설 네트워크를 공용 네트워크를 통해 연결할 때 필요하다. 중간 경로는 사설 IP를 라우팅할 수 없으므로, 라우팅 가능한 공인 IP 헤더로 감싸야 한다. (ex. VPN)
    • 프로토콜 호환성 극복 : IPv6 패킷을 IPv4 네트워크 망을 통해서 보내야 할 때, IPv6 패킷을 IPv4 패킷 안에 넣어서 보낸다.
    • 오버레이 네트워크 구성 : 물리적인 네트워크 토폴로지와 상관없이, 논리적인 네트워크 토폴로지를 구성하기 위해 사용한다. (VXLAN의 주 목적)
  • 리눅스에서 어떻게 쓰이는가
    • IPIP : IP 패킷 안에 IP 패킷을 넣는 가장 단순한 터널링
    • GRE (Generic Routing Encapsulation) : IP 뿐만 아니라 다양한 프로토콜을 IP 안에 넣을 수 있는 시스코가 개발한 표준
    • VXLAN : 이더넷 프레임(L2)을 UDP/IP 안에 넣는 기술

---

• VXLAN (Virtual Extensible LAN)
  • L2 이더넷 프레임을 L3 UDP 패킷 안에 캡슐화하여 전송하는 터널링 프로토콜.
    • 물리 네트워크가 L3(IP) 기반으로 되어 있어도, 그 위에서 논리적으로 L2(이더넷) 통신을 가능하게 한다.
  • 왜 필요한가 (클라우드 데이터센터 환경에서 기존의 VLAN 기술은 한계가 있다)
  • VLAN ID 개수의 한계
    • VLAN 헤더의 ID 필드는 12비트이다. 즉, 최대 4096개의 네트워크만 구분할 수 있다.
    • 수만 명의 고객이 있는 퍼블릭/프라이빗 클라우드에서는 턱없이 부족하다.
    • VXLAN 해결책 : 24비트의 VNI(VXLAN Network Idetifier)를 사용하여 약 1600만 개의 네트워크 세그먼트를 만들 수 있다.
  • MAC 주소 테이블의 폭발
    • 물리적 스위치는 연결된 모든 VM의 MAC 주소를 학습해야 한다. 수십만 개의 VM이 있는 환경에서는 물리 스위치의 메모리가 가득 차서 성능이 저하된다.
    • VXLAN 해결책 : 물리 스위치는 터널의 양 끝단(물리 서버의 IP)만 알면 된다. VM의 MAC 주소는 캡슐화되어 내부 데이터로 취급되므로 물리 스위치는 이를 몰라도 된다.
  • L2 확장의 제약
    • 전통적인 L2 네트워크는 루프 방지를 위해 Spanning Tree Protocol(STP)을 사용하여 특정 경로를 차단한다. 이는 대여폭 낭비를 유발한다.
    • 데이터센터는 모든 경로를 사용하는 L3 라우팅(ECMP) 구조를 선호한다.
    • VXLAN 해결책 : 물리망은 L3로 구성하여 모든 경로를 효율적으로 쓰고, 그 위에서 VXLAN으로 L2 통신을 흉내 낸다.

---

• VTEP (VXLAN Tunnel EndPoint)
  • VXLAN 처리를 수행하는 주체. 리눅스에서는 VXLAN 인터페이스가 VTEP 역할을 한다. 하드웨어 스위치가 VTEP이 될 수 있고, 하이퍼바이저가 VTEP이 될 수도 있다.
  • Ingress VTEP (입구) : VM에서 온 패킷을 캡슐화하여 물리망으로 쏘는 역할.
  • Egress VTEP (출구) : 물리망에서 온 UDP 패킷을 받아서, VXLAN 헤더를 떼고 VM에게 전달하는 역할.

    상대방 찾기
    VM A가 VM B(IP: 10.10.10.2)로 패킷을 보내려는데, VM B가 어느 물리 서버(VTEP) 위에 있는지 아는 방법

    • 방법 A: 멀티캐스트 (Multicast - Flood & Learn)
      • VM A가 ARP 요청(Broadcast)을 보내면, VTEP A는 이를 멀티캐스트 IP로 캡슐화해서 네트워크 전체에 뿌린다.
      • 해당 멀티캐스트 그룹에 가입된 모든 VTEP이 패킷을 받고, 그중에 VM B를 데리고 있는 VTEP B만 응답한다.
      • 이 과정에서 VTEP A는 "VM B는 VTEP B에 있다"라고 학습한다.
        
        
    • 방법 B: 컨트롤 플레인 사용 (SDN 방식 - OpenStack/K8s)
      • 중앙 컨트롤러(OpenStack Neutron Server, K8s API Server/CNI)가 모든 VM의 위치 정보를 이미 알고 있다.
      • 컨트롤러가 VTEP(각 노드의 에이전트)에게 미리 알려준다
      • "MAC 주소 aa:bb:cc... 가진 VM은 물리 서버 192.168.1.50에 있다."
      • 따라서 브로드캐스팅(Flooding) 없이 바로 유니캐스트(Unicast)로 캡슐화해서 보낸다. 네트워크 잡음을 획기적으로 줄여준다.

---

개념 정리

Q. 어떻게 L2(이더넷)을 L3/L4(IP/UDP) 안에 넣을 수 있는가?

• 컴퓨터 입장에서 데이터(Payload)는 0과 1로 이루어진 이진수 데이일 뿐이다.
• 원래의 통신 : 웹 브라우저가 데이터를 보내면 [HTTP 헤더][데이터]가 만들어진다. 이 전체를 TCP가 가져다가 자신의 데이터로 취급하여 앞에 [TCP 헤더]를 붙인다.
• VXLAN : VM이 만든 [이더넷 헤더][IP 헤더][데이터]라는 완성된 L2 프레임 전체를 호스트 OS는 그냥 데이터 덩어리로 취급한다.
• 캡술화 : 호스트 OS는 이 데이터 덩어리 앞에 [UDP 헤더]와 [IP 헤더]를 새로 붙인다.

---

Q. 물리 네트워크가 L3 기반으로 되어있다

• 전통적인 사무실 네트워크는 L2 스위치들로 연결하여 구성하는 것과 달리 데이터센터의 스위치들은 단순한 L2 스위치가 아니라 라우터(L3) 기능을 하도록 설정했다는 의미
• L2 구성 : 스위치 A에서 보낸 브로드캐스트가 스위치 B, C, D로 다 퍼진다. (불필요한 트래픽 폭증)
• L3 구성 : 스위치와 스위치 사이가 서로 다른 네트워크 대역(IP Subnet)으로 분리된다. 라우팅 테이블을 보고 정확히 찾아간다.
• 즉, 데이터센터의 케이블과 장비 연결 방식(물리망)은 IP 주소를 보고 길을 찾는 라우팅 방식(L3)으로 동작하게 만든다는 의미.

---

Q. VLAN 헤더가 12비트인 이유와 의미

• 옛날에는 한 네트워크 장비에서 4096개 이상의 그룹을 나눌 일이 없을 거라 생각하고 헤더의 크기를 최소화하기 위해 12비트만 할당했다. 이것이 하드웨어 표준으로 굳어졌다.
• 클라우드 환경이라도 관리용 네트워크, 스토리지용 네트워크, 서버용 네트워크 등을 물리적으로 구분해야 할 때가 있는데, 이때는 여전히 VLAN을 쓴다.
• 하지만 고객용 네트워크(Tenant Network)는 고객이 수만 명일 수 있으므로 VLAN 대신 VXLAN을 사용한다.

---

Q. VNI와 Network Segment

• Network Segment : 서로 통신 가능한 하나의 격리된 그룹
  • A팀의 클라우드 서버들끼리만 통신하고, B 팀의 서버와는 통신이 안 되도록 구성. A팀 그룹이 하나의 세그먼트.
• VNI (VXLAN Network Identifier) : VXLAN에 붙는 그룹 ID 태그
  • 24비트이므로, 약 1,600만 개의 ID를 만들 수 있다. 1,600만 개의 서로 다른 팀(세그먼트)를 격리해서 만들 수 있다는 뜻

---

Q. VM에도 MAC 주소가 할당되고, 해당 MAC 주소를 물리 스위치가 학습해야 하는가?

• VM의 MAC : VM도 OS 입장에서는 진짜 컴퓨터여야 하므로, 가상의 랜카드(vNIC)에 가상의 MAC주소가 무작위로 부여된다.
• 물리 스위치의 학습
  • VXLAN을 안 쓰면 : VM이 보낸 패킷이 물리 스위치로 그대로 나간다. 물리 스위치는 특정 포트에서 특정 MAC주소가 신호를 보낸다는 것을 기억하기 위해 학습한다. VM이 10만 개면 10만 개를 다 기억해야 해서 스위치 메모리가 부족해진다.
  • VXLAN을 쓰면 : 물리 스위치에게는 [Outer IP 헤더]만 보인다. 즉, 물리 서버(Host)의 IP와 MAC만 보인다. 안에 VM의 MAC이 들어있는지 모른다. 그래서 물리 스위치는 물리 서버들의 주소만 기억하면 된다.

---

Q. 터널이란

• 터널 : 복잡한 중간 경로(수많은 스위치와 라우터)를 무시하고, 입구(Host A)와 출구(Host B)가 직접 연결된 것처럼 보이게 만드는 논리적인 파이프

---

Q. L2 네트워크 루프를 STP 차단하는 이유, ECMP, VXLAN으로 L2 통신을 흉내 내는 이유

• L2의 문제
  • L2 스위치는 모르는 목적지의 패킷이 오면 일단 연결된 모든 곳으로 복사해서 보낸다.(Flooding)
  • 만약 선이 이중화로 연결되어 있으면, 복사된 패킷이 무한루프가 발생해 네트워크가 다운된다.
  • STP (Spanning Tree Protocol) : 이를 막기 위해 강제로 한쪽 선을 사용 못하게 막아버린다.
• L3 ECMP (Equal-Cost Multi-Path)
  • L3 라우터는 목적지로 가는 길이 2개가 있음 알고, 두 길 다 써서 반반씩 보내기가 가능하다.
  • 루프 걱정 없이 대역폭을 100% 활용할 수 있다. 그래서 현대 데이터센터는 물리망을 L3로 구성한다.
• VXLAN 없이 L3 물리망만 사용할 경우
  • 물리 서버 A는 10.1.1.0/24 대역(Rack 1)에 있고, 물리 서버 B는 10.1.2.0/24 대역(Rack 2)에 있다. (L3는 라우팅을 위해 대역을 쪼개야 하기 때문.)
  • VM이 서버 A에서 B로 넘어가면, IP 주소를 10.1.1.5에서 10.1.2.5로 바꿔야 한다.
  • IP가 바뀌면 실행 중이던 서비스 연결이 끊기고, DNS를 갱신해야 하는 등의 처리가 필요해진다.
• VXLAN으로 L2를 흉내 낼 경우
  • 물리적으로는 다른 대역(Rack 1 -> Rack 2)으로 이동했지만, 논리적으로는 VXLAN 100번이라는 가상의 긴 랜선에 계속 꽂혀 있는 상태이다.
  • VM 입장에서는 자신이 어디로 갔는지 모른다. IP 주소(10.1.1.5)를 그대로 유지한 채 몸만 이동할 수 있다.
  • 물리망은 VXLAN 패킷의 목적지가 A 서버에서 B 서버로 바뀐 것을 인식하고 배송지(Outer IP)만 바꿔주면 끝이다.
• 하나의 라우터 아래에서 똑같은 IP 2개가 존재할 수 없다. 하지만 VXLAN을 쓰면 VNI 100, VNI 200을 할당하여 물리적으로는 같은 스위치를 타고 흐르지만, 캡슐화된 패킷에 찍힌 ID(VNI)가 다르므로 서로 격리된다.