VPP (FD.io)

FD.io VPP(Vector Packet Processing)를 리눅스 커널 개발자 관점에서 단일 페이지(Page)로 정리합니다. 이 프로젝트에서는 VPP 항목을 하나의 문서로 유지하고, 방대한 세부 설명은 별도 VPP 전용 문서 프로젝트로 분리합니다.

개요

VPP는 Linux Foundation 산하 FD.io 프로젝트의 고성능 사용자 공간 패킷 처리 플랫폼입니다. 핵심 목표는 범용 커널 네트워크 스택이 제공하는 폭넓은 기능을 그대로 복제하는 것이 아니라, 라우터, 게이트웨이, 방화벽(Firewall), 서비스 체이닝, NFV, DPU 같은 환경에서 반복되는 패킷 처리 경로를 CPU 친화적으로 구성하는 것입니다.

커널 네트워크 스택은 시스템 콜(System Call), 소켓(Socket), sk_buff, qdisc, Netfilter, 드라이버, 네임스페이스(Namespace), cgroup과 긴밀히 통합됩니다. 반면 VPP는 vlib_buffer_t 인덱스를 중심으로 패킷 메타데이터를 전달하고, 워커 스레드(Thread)가 poll mode로 NIC 큐를 계속 확인합니다. 이 구조는 대량 패킷 처리에서는 유리하지만, 커널이 기본 제공하는 정책과 관측 지점을 직접 설계해야 한다는 비용이 있습니다.

아키텍처

VPP는 크게 clib, vlib, vnet, 플러그인, 애플리케이션 API 계층으로 나눌 수 있습니다. clib은 벡터, 풀, 해시(Hash), 시간 측정, 원자 연산 같은 기반 자료구조를 제공합니다. vlib은 메인 루프, 노드 등록, 프레임 전달, 버퍼(Buffer) 풀, 스레드 런타임을 담당합니다. vnet은 인터페이스, FIB, L2/L3, ACL, NAT, IPsec 같은 네트워크 기능을 구현합니다.

패킷은 포인터 대신 버퍼 인덱스로 이동합니다. 각 노드는 입력 프레임에서 버퍼 인덱스 배열을 받아 필요한 헤더를 읽고, 다음 노드 인덱스와 에러 상태를 설정합니다. 같은 노드에서 여러 패킷을 연속 처리하므로 명령어 캐시가 따뜻하게 유지되고, 루프 전개와 prefetch 패턴을 적용하기 쉽습니다.

/* VPP 그래프 노드 처리 루프의 단순화된 형태 */
while (n_left_from > 0) {
    u32 bi0 = from[0];
    vlib_buffer_t *b0 = vlib_get_buffer(vm, bi0);

    /* 현재 노드는 헤더를 읽고 다음 노드를 결정합니다. */
    next0 = classify_packet(b0);
    to_next[0] = bi0;

    from += 1;
    to_next += 1;
    n_left_from -= 1;
}

데이터 경로

VPP 데이터 경로의 시작점은 보통 dpdk-input, af-packet-input, memif-input, tap-input 같은 입력 노드입니다. 이후 이더넷 파싱, VLAN 처리, L2 브릿징, L3 FIB 룩업, adjacency rewrite, output 노드를 거쳐 NIC TX 큐나 다른 인터페이스로 나갑니다.

DPDK를 사용할 때는 hugepage, IOVA 모드, VFIO 권한, NIC queue 수, RSS 해시, NUMA 배치가 성능의 기본 조건입니다. memif는 VPP 프로세스(Process)와 외부 프로세스 사이에서 공유 메모리 기반 서비스 체이닝을 구성할 때 적합하고, AF_XDP는 커널 XDP 경로와 사용자 공간 처리를 연결해야 할 때 검토합니다. TAP/TUN은 개발과 호환성에는 편하지만, 순수 성능 기준으로는 최종 배포 경로인지 반드시 재검토해야 합니다.

보안과 터널(Tunnel)링

VPP는 ACL, NAT44/NAT64, IPsec, WireGuard, COP, policer 같은 보안 기능을 플러그인과 feature arc 형태로 제공합니다. 커널의 Netfilter처럼 시스템 전체 기본 경로에 자동으로 걸리는 모델이 아니므로, 어느 인터페이스와 어느 arc에 기능을 붙일지 명시적으로 설계해야 합니다.

IPsec에서는 SPD, SAD, tunnel/interface 모드, IKEv2, ESP 암호화(Encryption), anti-replay, cryptodev 오프로드가 핵심입니다. NAT와 ACL은 라우팅 테이블(Routing Table), VRF, conntrack 유사 상태 관리, 세션 만료 정책과 함께 봐야 합니다. 투명 프록시를 구성할 때는 커널 TPROXY의 목적지 보존 모델과 달리, VPP 세션 레이어 또는 memif 서비스 체이닝 중 어느 지점에서 원본 5튜플을 보존할지 먼저 정해야 합니다.

호스트 스택

VPP 호스트 스택은 애플리케이션이 커널 TCP/IP 스택 대신 VPP 세션 레이어를 사용하도록 만드는 기능입니다. VCL(VPP Communications Library)은 애플리케이션이 직접 vppcom_* API를 호출하게 하고, VLS(VPP Library Stack)는 POSIX 소켓에 가까운 래핑을 제공합니다. 기존 바이너리를 빠르게 실험할 때는 LD_PRELOAD 방식이 유용하지만, 장기 운영에서는 직접 VCL로 세션 수명, 워커 배치, FIFO 크기를 통제하는 편이 예측 가능성이 높습니다.

/* VCL TCP 서버의 매우 단순화된 흐름 */
int ls = vppcom_session_create(VPPCOM_PROTO_TCP, 0);
vppcom_session_bind(ls, &endpt);
vppcom_session_listen(ls, 1024);

for (;;) {
    int cs = vppcom_session_accept(ls, &client, 0);
    vppcom_session_read(cs, buf, sizeof(buf));
    vppcom_session_write(cs, buf, len);
}

TLS, QUIC, HTTP

VPP의 TLS는 세션 레이어 위에 전송 프로토콜처럼 붙습니다. tlsopenssl, tlsmbedtls, tlspicotls 같은 엔진 플러그인이 실제 핸드셰이크와 레코드 암복호화를 담당하고, 상위 애플리케이션은 일반 세션 읽기/쓰기와 비슷한 흐름으로 데이터를 처리합니다. QUIC은 UDP와 TLS 1.3, 스트림 멀티플렉싱이 결합된 구조이므로, 세션 배치와 패킷 손실 처리, 0-RTT 정책, ALPN 협상을 별도로 검증해야 합니다.

HTTP 게이트웨이나 HTTP/3 실험을 VPP 안에서 구현할 수는 있지만, VPP를 풀스펙 API 게이트웨이로 만드는 것은 신중해야 합니다. 라우팅, 기본 헤더 조작, 단순 캐시, 빠른 L4/L7 분류는 VPP에 어울리지만, 복잡한 인증, OpenAPI 검증, 사용자별 정책, 동적 스크립팅은 외부 프록시나 제어 평면으로 분리하는 구성이 더 안전합니다.

프록시와 SSL Inspection

VPP 기반 프록시는 크게 두 방향입니다. 첫째, VCL 애플리케이션이 TCP/TLS 세션을 직접 받아 업스트림과 다시 연결하는 인라인 프록시입니다. 둘째, VPP가 분류와 steering만 담당하고, 복호화(Decryption)와 콘텐츠 검사는 memif로 연결된 외부 프록시나 DLP 엔진에 위임하는 서비스 체이닝 방식입니다.

SSL Inspection은 기술보다 정책이 먼저입니다. 조직이 복호화할 수 있는 트래픽과 우회해야 하는 트래픽을 분리하고, 사용자 고지, 인증서 배포, 감사 로그, 키 보관, 예외 도메인, ECH(Encrypted ClientHello) 대응을 문서화해야 합니다. VPP는 빠른 데이터 경로를 제공하지만, 동적 인증서 발급과 법적 책임은 별도 시스템 설계에 속합니다.

운영과 확장

운영에서 가장 흔한 문제는 VPP 자체 기능보다 배치 조건에서 발생합니다. hugepage가 부족하거나 NUMA가 맞지 않거나, NIC queue와 worker가 일치하지 않거나, Linux IRQ가 같은 코어에 남아 있으면 벤치마크와 운영 성능이 크게 달라집니다. 따라서 startup.conf, CPU pinning, NIC RSS, queue 수, memory socket, CLI socket, API socket, log 경로를 한 번에 관리해야 합니다.

# /etc/vpp/startup.conf 예시: 역할을 보여주는 최소 골격
unix {
  nodaemon
  cli-listen /run/vpp/cli.sock
  log /var/log/vpp/vpp.log
}

cpu {
  main-core 1
  corelist-workers 2-7
}

dpdk {
  dev 0000:18:00.0
  dev 0000:18:00.1
  num-rx-queues 6
}

운영 관측은 show runtime, show interface, show errors, packet trace, event logger, stats segment, Prometheus exporter, CSIT 스타일 반복 테스트를 함께 사용합니다. 장애 대응 런북에는 인터페이스 상태, 워커별 vector rate, drop counter, buffer exhaustion, memif 연결 상태, API socket 권한, DPDK 장치 바인딩을 포함하는 편이 좋습니다.

DPU와 하드웨어 오프로드

DPU나 SmartNIC에 VPP를 배치하면 호스트 CPU에서 데이터 경로 일부를 분리할 수 있습니다. 예를 들어 BlueField 같은 장치에서는 Arm 코어 위에 VPP를 올리고, 호스트와 DPU 사이를 representor, virtio, SR-IOV, hairpin, cryptodev, memif 같은 경로로 연결할 수 있습니다. 이때 중요한 질문은 "무엇을 DPU로 옮길 것인가"입니다.

L2/L3 steering, 기본 ACL, IPsec ESP, TLS 암호화 일부, SSL Inspection 보조 경로는 DPU에 어울릴 수 있습니다. 반면 복잡한 L7 정책, 동적 인증서 생성, 사용자별 감사, 외부 데이터베이스 조회는 DPU 코어에서 처리하면 병목(Bottleneck)이 되기 쉽습니다. DPU는 빠른 패킷 경로와 암호 가속을 담당하고, 복잡한 정책 판단은 호스트나 제어 평면에 남기는 분리가 현실적입니다.

커널과의 연결 지점

리눅스 커널 개발자 관점에서 VPP를 볼 때 가장 중요한 연결 지점은 드라이버와 사용자 공간 경계입니다. DPDK는 VFIO/UIO와 hugepage에 의존하고, AF_XDP는 XDP 및 네트워크 드라이버의 zero-copy 지원 여부에 의존합니다. TAP/TUN과 vhost-user는 커널 가상 네트워크와 VM 연결을 이해해야 안정적으로 운영할 수 있습니다.

• 메모리: hugepage, IOMMU, IOVA, NUMA, DMA mapping을 함께 봅니다.
• 네트워크: NIC queue, RSS, checksum offload, TSO/GRO, XDP, SR-IOV를 확인합니다.
• 보안: VFIO 장치 권한, API socket, memif socket, TLS key material, 감사 로그를 관리합니다.
• 관측성: 커널의 ethtool, perf, ftrace와 VPP의 show 명령, stats segment를 함께 사용합니다.

배포 체크리스트

VPP 최신 릴리스 하이라이트 (25.06, 25.10)

FD.io VPP는 분기 릴리스 주기를 유지하며 2025년에는 25.02, 25.06, 25.10 순으로 발표되었습니다. 주요 기능 변화는 다음과 같으며 상세 릴리스 노트는 s3-docs.fd.io/vpp/<버전>/aboutvpp/releasenotes/에서 확인할 수 있습니다.

2026년 관점에서 주목할 영역

• linux-cp(Control Plane) — VPP 인터페이스를 TUN/TAP으로 미러링하여 기존 리눅스 제어 플레인(FRR, BIRD, iproute2)이 라우팅/ARP/ND 학습을 담당하도록 하는 플러그인. 2025년 연간 개선을 통해 네임스페이스별 미러링 안정화 및 netlink 이벤트 동기화 개선.
• HTTP/2와 QUIC 호스트 스택 — VPP 25.06 QUIC 엔진 API 재정비로 ngtcp2/quiche 같은 외부 라이브러리와의 어댑터 구성이 단순화. 서비스 메시 데이터 평면 후보로 재부상.
• Snort 플러그인(25.10) — VPP 그래프 노드에서 Snort 3 IDS로 패킷을 위탁하는 오픈소스 연동. NGFW 기능을 VPP + Snort 조합으로 구축하는 레퍼런스가 확장됨.
• DPDK 25.x 연동 — VPP의 DPDK 플러그인은 업스트림 DPDK 25.03/25.07 변경(Intel 드라이버 재편, dmadev 확장)을 반영. 빌드 시스템(Build System)은 meson 기반 자동 감지로 호환성 유지.
• CNF / Kubernetes 배포 — Calico/VPP 데이터 평면과 L3 CNI 사례가 지속 확장. memif 소켓 기반 SFC(서비스 기능 체이닝)가 25.10에서 성능 개선.

사용 판단 기준

VPP는 모든 네트워크 문제의 기본 답이 아닙니다. 커널 네트워크 스택으로 충분한 트래픽, 복잡한 네임스페이스와 cgroup 통합이 중요한 환경, 배포 자동화와 보안 정책이 커널 도구에 이미 묶인 환경에서는 커널 경로가 더 단순합니다. 반대로 고정된 데이터 경로에서 수십 Mpps, 낮은 tail latency, NFV 서비스 체이닝, DPU 오프로드, 전용 L3/L4 게이트웨이를 목표로 한다면 VPP가 강한 후보가 됩니다.

참고자료

• FD.io VPP Documentation
• FDio/vpp GitHub mirror
• FD.io VPP source repository
• VPP generated API documentation
• VPP (FD.io) 정리 /with MINZKN — 분리된 장문 VPP 전용 문서 프로젝트

관련 문서

• DPDK — 유저스페이스 패킷 처리와 PMD
• AF_XDP — XDP 기반 사용자 공간 패킷 처리
• sk_buff — 커널 네트워크 패킷 버퍼
• Netfilter — 커널 패킷 필터링과 NAT
• TPROXY — 원본 목적지 보존 투명 프록시
• IPSec & xfrm — 커널 IPsec 데이터 경로
• kTLS — 커널 TLS 데이터 경로
• SmartNIC / DPU — 하드웨어 오프로드 배치

오픈소스 코드 인용 고지