VPP (FD.io) — 고성능 유저스페이스 패킷(Packet) 처리

FD.io VPP(Vector Packet Processing) 프레임워크: 벡터 패킷 처리 모델, 그래프 노드 아키텍처, DPDK 통합, 플러그인 시스템, TAP/TUN·vhost-user·AF_PACKET·AF_XDP 커널 인터페이스, L2/L3/ACL/NAT/IPsec/SRv6 기능, CLI/API, 성능 최적화, 활용 사례 종합 가이드. 커널 내부 데이터 경로, 핵심 자료구조/API, 운영 환경 튜닝 포인트와 장애 디버깅(Debugging) 절차까지 실무 관점으로 다룹니다.

VPP 개요

VPP(Vector Packet Processing)는 Linux Foundation 산하 FD.io(Fast Data Input/Output) 프로젝트의 핵심 구성 요소로, 고성능 유저스페이스 패킷 처리 플랫폼입니다. 원래 Cisco에서 개발한 상용 코드를 2016년에 오픈소스로 공개하였으며, 현재 Linux Foundation이 호스팅하는 커뮤니티 주도 프로젝트입니다. 주요 기능은 메일링 리스트와 공개 리뷰를 거치는 패치(Patch) 시리즈를 통해 계속 확장됩니다.

VPP의 핵심 설계 철학은 벡터 패킷 처리(Vector Packet Processing)입니다. 전통적인 커널 네트워크 스택이 패킷 하나씩 전체 처리 경로를 순회하는 scalar 방식인 반면, VPP는 여러 패킷을 하나의 벡터(배열)로 묶어서 동일한 처리 노드를 일괄 통과시킵니다. 이를 통해 CPU의 명령어 캐시(I-cache) 히트율을 극대화하고, 분기 예측(branch prediction) 효율을 높여 범용 x86 CPU에서도 초당 수천만 패킷(수십 Mpps)을 처리할 수 있습니다.

FD.io / Linux Foundation 역사

패킷 처리 프레임워크 비교

벡터 패킷 처리 모델

Scalar 처리 vs Vector 처리

전통적인 커널 네트워크 스택의 Scalar 처리는 패킷 하나를 수신하면 L2 → L3 → L4 → 소켓(Socket) 전달까지 전체 경로를 완주한 후 다음 패킷을 처리합니다. 각 단계마다 다른 함수 코드가 I-cache에 로드되므로 캐시 미스가 빈번합니다.

VPP의 Vector 처리는 다수의 패킷(벡터)을 동시에 한 노드에서 처리한 후, 다음 노드로 벡터 전체를 넘깁니다. 동일한 코드가 수백 패킷에 반복 적용되므로 I-cache에 상주하며, 분기 예측이 안정되어 파이프라인(Pipeline) 버블이 최소화됩니다.

캐시 효율성과 성능

VPP의 성능 우위는 CPU 마이크로아키텍처 수준의 최적화에서 비롯됩니다:

• I-cache 최적화: 하나의 그래프 노드 함수가 256개 패킷에 반복 적용되므로, 명령어가 L1 I-cache에 상주합니다. 커널 스택에서는 패킷마다 수십 개의 함수를 순회하며 I-cache가 지속적으로 교체됩니다.
• D-cache 프리페칭: VPP는 현재 패킷을 처리하는 동안 다음 패킷의 데이터를 CLIB_PREFETCH() 매크로(Macro)로 미리 캐시에 로드합니다.
• 분기 예측: 동일한 코드 경로가 수백 번 반복 실행되므로 CPU의 Branch Target Buffer(BTB)가 안정화됩니다.
• 듀얼/쿼드 루프: VPP 노드는 패킷을 2개 또는 4개씩 묶어서 처리하는 dual-loop/quad-loop 패턴을 사용해 루프 오버헤드(Overhead)를 줄이고 ILP(Instruction-Level Parallelism)를 극대화합니다.

/* VPP 노드의 전형적인 dual-loop 패턴 (간략화) */
while (n_left_from >= 4) {
    /* 다음 2개 패킷 프리페치 */
    vlib_buffer_t *p2, *p3;
    p2 = vlib_get_buffer(vm, from[2]);
    p3 = vlib_get_buffer(vm, from[3]);
    CLIB_PREFETCH(p2->data, CLIB_CACHE_LINE_BYTES, LOAD);
    CLIB_PREFETCH(p3->data, CLIB_CACHE_LINE_BYTES, LOAD);

    /* 현재 2개 패킷 처리 */
    vlib_buffer_t *b0, *b1;
    b0 = vlib_get_buffer(vm, from[0]);
    b1 = vlib_get_buffer(vm, from[1]);

    /* 패킷 처리 로직... */
    next0 = process_packet(b0);
    next1 = process_packet(b1);

    vlib_validate_buffer_enqueue_x2(vm, node, next_index,
                                     to_next, n_left_to_next,
                                     bi0, bi1, next0, next1);
    from += 2;
    n_left_from -= 2;
}

쿼드 루프 패턴과 SIMD 최적화

VPP 노드의 가장 최적화된 형태는 quad-loop 패턴입니다. 4개의 패킷을 동시에 처리하여 CPU의 ILP(Instruction-Level Parallelism)를 극대화하고, 프리페치 거리를 확보합니다. 컴파일러가 SIMD 벡터화를 적용할 가능성도 높아집니다.

/* quad-loop 패턴 — 최고 성능 경로 */
while (n_left_from >= 8) {
    /* 8개 앞 패킷 프리페치 (4개 처리 동안 캐시 로드) */
    CLIB_PREFETCH(vlib_get_buffer(vm, from[4])->data,
                  CLIB_CACHE_LINE_BYTES, LOAD);
    CLIB_PREFETCH(vlib_get_buffer(vm, from[5])->data,
                  CLIB_CACHE_LINE_BYTES, LOAD);
    CLIB_PREFETCH(vlib_get_buffer(vm, from[6])->data,
                  CLIB_CACHE_LINE_BYTES, LOAD);
    CLIB_PREFETCH(vlib_get_buffer(vm, from[7])->data,
                  CLIB_CACHE_LINE_BYTES, LOAD);

    /* 현재 4개 패킷 일괄 처리 */
    vlib_buffer_t *b0, *b1, *b2, *b3;
    b0 = vlib_get_buffer(vm, from[0]);
    b1 = vlib_get_buffer(vm, from[1]);
    b2 = vlib_get_buffer(vm, from[2]);
    b3 = vlib_get_buffer(vm, from[3]);

    next0 = process_packet(b0);
    next1 = process_packet(b1);
    next2 = process_packet(b2);
    next3 = process_packet(b3);

    vlib_validate_buffer_enqueue_x4(vm, node, next_index,
        to_next, n_left_to_next,
        bi0, bi1, bi2, bi3, next0, next1, next2, next3);
    from += 4;
    n_left_from -= 4;
}

/* single-loop: 나머지 패킷 처리 (1~3개) */
while (n_left_from > 0) {
    vlib_buffer_t *b0 = vlib_get_buffer(vm, from[0]);
    next0 = process_packet(b0);
    vlib_validate_buffer_enqueue_x1(vm, node, next_index,
        to_next, n_left_to_next, bi0, next0);
    from += 1;
    n_left_from -= 1;
}

벡터 크기 튜닝과 영향

VLIB_FRAME_SIZE는 한 번에 노드에 전달되는 최대 패킷 수를 결정합니다. 기본값 256은 대부분의 상황에서 최적이지만, 특수 워크로드에서는 조정이 필요할 수 있습니다.

VPP 아키텍처

패킷 처리 그래프 (Graph Node Architecture)

VPP의 핵심은 방향성 비순환 그래프(DAG) 기반 패킷 처리 엔진입니다. 각 처리 단계는 노드(Node)로 구현되며, 노드 간 연결은 arc로 표현됩니다. 패킷(벡터)은 노드에서 노드로 arc를 따라 이동하며, 각 노드는 패킷의 다음 목적지 노드를 결정합니다.

/* 그래프 노드 등록 예제 — src/vnet/ethernet/node.c */
VLIB_REGISTER_NODE (ethernet_input_node) = {
    .function = ethernet_input,          /* 노드 처리 함수 */
    .name = "ethernet-input",
    .vector_size = sizeof(u32),          /* 벡터 원소 크기 (버퍼 인덱스) */
    .n_errors = ETHERNET_N_ERROR,
    .error_strings = ethernet_error_strings,
    .n_next_nodes = ETHERNET_INPUT_N_NEXT,
    .next_nodes = {
        [ETHERNET_INPUT_NEXT_IP4_INPUT] = "ip4-input",
        [ETHERNET_INPUT_NEXT_IP6_INPUT] = "ip6-input",
        [ETHERNET_INPUT_NEXT_L2_INPUT]  = "l2-input",
        [ETHERNET_INPUT_NEXT_DROP]      = "error-drop",
    },
};

노드 유형 (INTERNAL, INPUT, PROCESS, PRE_INPUT)

벡터 크기와 처리 흐름

VPP의 벡터 프레임 크기는 VLIB_FRAME_SIZE로 정의되며, 기본값은 256입니다. 메인 루프(vlib_main_loop)는 다음 순서로 동작합니다:

1. PRE_INPUT 노드 실행 (epoll 이벤트 수집 등)
2. INPUT 노드 실행 (dpdk-input이 NIC에서 패킷 수집 → 벡터 생성)
3. INTERNAL 노드: 보류 중인 프레임이 있는 노드를 순회하며 벡터 처리
4. PROCESS 노드: 타이머/이벤트 만료된 코루틴 실행
5. 1번으로 돌아감 (busy-loop 또는 sleep)

vlib_buffer_t 구조체(Struct) 상세

vlib_buffer_t는 VPP에서 패킷 데이터를 관리하는 핵심 구조체로, 커널의 sk_buff에 대응합니다. 정확히 2개의 캐시라인(128바이트)으로 설계되어 캐시 효율을 극대화합니다.

/* vlib_buffer_t 핵심 접근 API */

/* 버퍼 인덱스(u32)로 버퍼 포인터 획득 */
vlib_buffer_t *b = vlib_get_buffer(vm, buffer_index);

/* 현재 데이터 시작 포인터 */
void *data = vlib_buffer_get_current(b);

/* 헤더 추가/제거 (current_data 이동) */
vlib_buffer_advance(b, -sizeof(ethernet_header_t));  /* 헤더 추가 */
vlib_buffer_advance(b, sizeof(ip4_header_t));       /* 헤더 제거 */

/* 체인 버퍼의 전체 길이 */
u32 total = vlib_buffer_length_in_chain(vm, b);

/* 버퍼 복제 (멀티캐스트 등) */
u32 clone_bi;
vlib_buffer_clone(vm, buffer_index, &clone_bi, 1, CLIB_CACHE_LINE_BYTES);

/* opaque 영역 사용 예: ip4 노드가 저장하는 메타데이터 */
typedef struct {
    ip4_header_t *ip_header;
    u32 adj_index;
    u32 flow_hash;
    u32 fib_index;
} ip4_buffer_opaque_t;

/* opaque 접근 매크로 */
#define vnet_buffer(b) ((vnet_buffer_opaque_t *)(b)->opaque)
#define vnet_buffer2(b) ((vnet_buffer_opaque2_t *)(b)->opaque2)

메인 루프 내부 동작

VPP의 vlib_main_loop()는 모든 패킷 처리의 진입점(Entry Point)입니다. 단일 스레드(Thread) 내에서 4단계를 반복 실행하며, 각 단계의 순서가 성능에 직접 영향을 미칩니다.

/* vlib_main_loop 의사코드 (src/vlib/main.c) */
static void
vlib_main_loop (vlib_main_t *vm) {
    while (1) {
        /* 1단계: PRE_INPUT — epoll, 시그널 체크 */
        vlib_node_runtime_update_stats(vm);
        dispatch_pre_input_nodes(vm);

        /* 2단계: INPUT — NIC 폴링, 벡터 수집 */
        dispatch_input_nodes(vm);
        /* dpdk-input이 NIC RX 링에서 패킷 배치를 가져와
           ethernet-input으로 향하는 프레임을 생성 */

        /* 3단계: INTERNAL — 보류 프레임 디스패치 */
        for (pending_frame in vm->pending_frames) {
            node = pending_frame->node;
            frame = pending_frame->frame;
            node->function(vm, node, frame);
            /* 노드가 새 프레임을 생성하면 pending 추가 */
        }

        /* 4단계: PROCESS — 코루틴 타이머/이벤트 체크 */
        dispatch_process_nodes(vm);

        /* 유휴 시 선택적 sleep */
        if (no_work && vm->poll_sleep_usec)
            usleep(vm->poll_sleep_usec);
    }
}

Feature Arc 메커니즘

Feature Arc는 VPP의 핵심 확장 메커니즘으로, 패킷 처리 경로에 기능을 동적으로 삽입하거나 제거할 수 있게 합니다. 커널의 Netfilter 후크(Hook) 체인과 유사한 개념이지만, 컴파일 타임이 아닌 런타임에 노드 체인을 재구성합니다.

/* Feature Arc에 노드 등록 (VNET_FEATURE_INIT 매크로) */
VNET_FEATURE_INIT (my_acl_feature, static) = {
    .arc_name = "ip4-unicast",       /* 소속 Feature Arc */
    .node_name = "my-acl-node",       /* 노드 이름 */
    .runs_before = VNET_FEATURES("ip4-lookup"),  /* 이 노드보다 먼저 실행 */
    .runs_after  = VNET_FEATURES("ip4-input-no-checksum"),
};

/* 런타임에 인터페이스별 Feature 활성화 */
vpp# set interface feature GigabitEthernet0/8/0 my-acl-node arc ip4-unicast

/* Feature Arc 상태 확인 */
vpp# show features verbose

패킷 1개가 RX 디스크립터에서 TX 큐까지 가는 실제 경로

VPP를 처음 접할 때 가장 헷갈리는 지점은 "패킷이 정확히 어느 시점에 vlib_buffer_t가 되고, 어느 시점에 next 인덱스가 바뀌며, 어느 시점에 실제 NIC 송신 큐에 들어가는가"입니다. 아래 흐름을 기준으로 보면, 추상적인 그래프 모델과 실제 구현 객체가 한 번에 연결됩니다.

1. NIC가 RX 디스크립터를 채웁니다. 하드웨어는 DMA로 패킷을 메모리에 써 두고, RX 링의 소유권을 소프트웨어 쪽으로 넘깁니다.
2. dpdk-input이 burst 단위로 회수합니다. 이 시점에 성능은 rx_burst 크기, 디스크립터 수, NUMA 일치 여부에 크게 좌우됩니다.
3. 패킷은 vlib_buffer_t로 표현됩니다. 실제 데이터는 이미 hugepage 메모리에 존재하고, 이후 그래프는 주로 버퍼 인덱스 배열을 이동시킵니다.
4. ethernet-input이 첫 분류를 수행합니다. EtherType과 VLAN을 읽고 ip4-input, ip6-input, l2-input 중 어느 경로로 보낼지 결정합니다.
5. ip4-input과 Feature Arc가 정책을 적용합니다. ACL, NAT, IPsec, 사용자 플러그인이 이 구간에 삽입되며, 패킷을 드롭하거나 메타데이터를 보강할 수 있습니다.
6. ip4-lookup이 FIB를 조회합니다. 결과는 adjacency 인덱스로 정리되어 vnet_buffer(b0) 계열 메타데이터에 저장됩니다.
7. ip4-rewrite와 interface-output이 송신을 마무리합니다. 최종 L2 헤더를 재작성한 뒤 per-thread TX 프레임에 넣고, 마지막에 NIC TX 링으로 burst 송신합니다.

핵심 그래프 노드 내부 구현

VPP 패킷 그래프의 핵심 노드들은 고성능을 위해 정교하게 최적화된 내부 구현을 가지고 있습니다. 각 노드의 처리 함수는 quad-loop 또는 dual-loop 패턴을 사용하여 IPC(Instructions Per Cycle)를 극대화합니다.

ethernet-input 노드 (node.c)

ethernet-input 노드는 패킷 그래프의 최초 L2 처리 지점으로, 이더넷 프레임의 EtherType을 분류하여 적절한 다음 노드로 디스패치합니다. 핵심 구현은 ethernet_input_inline() 함수에 있으며, sparse vector를 이용한 O(1) EtherType 룩업이 특징입니다.

VLAN 태그 처리에서는 single tagging(802.1Q)과 double tagging(QinQ/802.1ad)을 모두 지원합니다. VLAN 태그가 감지되면 외부 태그를 파싱하여 VLAN ID와 우선순위(Priority)를 추출하고, 내부 EtherType을 기반으로 최종 디스패치를 수행합니다.

/* ethernet_input_inline() — quad-loop 패턴 (simplified pseudo-code) */
static_always_inline uword
ethernet_input_inline (vlib_main_t *vm,
                       vlib_node_runtime_t *node,
                       vlib_frame_t *frame)
{
  u32 n_left, *from, *to_next;
  u32 next_index;

  from = vlib_frame_vector_args (frame);
  n_left = frame->n_vectors;

  /* Quad-loop: 4개 패킷 동시 처리 */
  while (n_left >= 4)
    {
      vlib_buffer_t *b0, *b1, *b2, *b3;
      u16 type0, type1, type2, type3;

      /* 프리페치: 다음 4개 패킷 메타데이터 미리 로드 */
      vlib_prefetch_buffer_header (b[4], LOAD);
      vlib_prefetch_buffer_header (b[5], LOAD);
      vlib_prefetch_buffer_header (b[6], LOAD);
      vlib_prefetch_buffer_header (b[7], LOAD);

      b0 = vlib_get_buffer (vm, from[0]);
      b1 = vlib_get_buffer (vm, from[1]);
      b2 = vlib_get_buffer (vm, from[2]);
      b3 = vlib_get_buffer (vm, from[3]);

      /* 이더넷 헤더에서 EtherType 추출 */
      ethernet_header_t *e0 = vlib_buffer_get_current (b0);
      type0 = clib_net_to_host_u16 (e0->type);

      /* VLAN 태그 확인 및 처리 */
      if (PREDICT_FALSE (type0 == ETHERNET_TYPE_VLAN
                         || type0 == ETHERNET_TYPE_DOT1AD))
        {
          /* VLAN 헤더 파싱: tag, priority, inner EtherType */
          ethernet_vlan_header_t *v0 = (e0 + 1);
          u16 inner_type = clib_net_to_host_u16 (v0->type);

          /* QinQ: 이중 태그인 경우 한 단계 더 파싱 */
          if (inner_type == ETHERNET_TYPE_VLAN)
            inner_type = parse_second_vlan_tag (v0);

          type0 = inner_type;
          vlib_buffer_advance (b0, sizeof(*v0));
        }

      /* Sparse vector O(1) 룩업으로 다음 노드 결정 */
      next0 = sparse_vec_index (em->l3_next.input_next_by_type, type0);

      /* ... b1, b2, b3도 동일 패턴 반복 ... */

      vlib_validate_buffer_enqueue_x4 (vm, node, next_index,
                                        to_next, n_left_to_next,
                                        bi0, bi1, bi2, bi3,
                                        next0, next1, next2, next3);
      n_left -= 4;
      from += 4;
    }

  /* 잔여 패킷 single-loop 처리 */
  while (n_left > 0)
    { /* ... 단일 패킷 처리 ... */ }

  return frame->n_vectors;
}

ip4-input 노드 (ip4_input.c)

ip4-input 노드는 IPv4 패킷의 유효성을 검증하는 L3 진입점입니다. IP 헤더의 버전, 헤더 길이(IHL), 체크섬, TTL 등을 검사하며, 유효하지 않은 패킷은 ip4-drop 노드로 전달합니다. Feature arc가 활성화된 인터페이스에서는 vnet_feature_arc_start()를 호출하여 feature 체인을 시작합니다.

/* ip4_input_inline() — 헤더 검증 로직 (simplified pseudo-code) */
static_always_inline uword
ip4_input_inline (vlib_main_t *vm,
                  vlib_node_runtime_t *node,
                  vlib_frame_t *frame,
                  int verify_checksum)
{
  u32 n_left, *from;
  ip4_input_next_t next;

  from = vlib_frame_vector_args (frame);
  n_left = frame->n_vectors;

  while (n_left > 0)
    {
      vlib_buffer_t *b0 = vlib_get_buffer (vm, from[0]);
      ip4_header_t *ip0 = vlib_buffer_get_current (b0);

      /* 1단계: IP 버전 및 헤더 길이 검증 */
      u8 version0 = (ip0->ip_version_and_header_length >> 4);
      u8 ihl0 = (ip0->ip_version_and_header_length & 0xF);

      if (PREDICT_FALSE (version0 != 4 || ihl0 < 5))
        {
          next = IP4_INPUT_NEXT_DROP;
          b0->error = node->errors[IP4_ERROR_BAD_VERSION];
          goto enqueue;
        }

      /* 2단계: 체크섬 검증 (하드웨어 오프로드 안 된 경우) */
      if (verify_checksum)
        {
          u16 sum0 = ip4_header_checksum (ip0);
          if (PREDICT_FALSE (sum0 != ip0->checksum))
            {
              next = IP4_INPUT_NEXT_DROP;
              b0->error = node->errors[IP4_ERROR_BAD_CHECKSUM];
              goto enqueue;
            }
        }

      /* 3단계: TTL 검사 */
      if (PREDICT_FALSE (ip0->ttl == 0))
        {
          next = IP4_INPUT_NEXT_ICMP_ERROR;
          b0->error = node->errors[IP4_ERROR_TTL_EXPIRED];
          goto enqueue;
        }

      /* 4단계: Feature arc 시작 (인터페이스에 feature 설정 시) */
      if (PREDICT_FALSE (b0->feature_arc_index != ~0))
        {
          vnet_feature_arc_start (im->feat_arc_index,
                                 b0->sw_if_index[VLIB_RX],
                                 &next, b0);
        }
      else
        next = IP4_INPUT_NEXT_LOOKUP;

    enqueue:
      vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
                                        to_next, n_left_to_next,
                                        bi0, next);
      n_left--;
      from++;
    }

  return frame->n_vectors;
}

ip4-lookup 노드 (ip4_forward.c)

ip4-lookup 노드는 목적지 IP 주소를 기반으로 FIB(Forwarding Information Base) 검색을 수행합니다. VPP는 mtrie(Multibit Trie) 자료구조를 사용하여 최장 접두사 매칭(LPM)을 수행하며, 검색 결과로 load-balance 객체를 얻습니다. 다중 경로(ECMP)인 경우 5-tuple flow hash를 계산하여 특정 adjacency를 선택합니다.

mtrie 검색은 3단계로 진행됩니다. 먼저 상위 16비트로 첫 번째 플라이(ply)를 검색하고, 결과가 리프가 아니면 다음 8비트로 두 번째 플라이, 마지막 8비트로 세 번째 플라이를 검색합니다. 대부분의 경로는 첫 번째 또는 두 번째 단계에서 리프에 도달하므로 매우 빠릅니다.

/* ip4_lookup_inline() — mtrie 검색 및 ECMP (simplified pseudo-code) */
static_always_inline uword
ip4_lookup_inline (vlib_main_t *vm,
                   vlib_node_runtime_t *node,
                   vlib_frame_t *frame)
{
  ip4_fib_mtrie_t *mtrie0;
  u32 n_left, *from;

  from = vlib_frame_vector_args (frame);
  n_left = frame->n_vectors;

  while (n_left >= 4)
    {
      vlib_buffer_t *b0, *b1;
      ip4_header_t *ip0, *ip1;
      ip4_fib_mtrie_leaf_t leaf0, leaf1;

      /* 프리페치: 다음 패킷의 IP 헤더를 캐시에 미리 로드 */
      {
        vlib_buffer_t *p2, *p3;
        p2 = vlib_get_buffer (vm, from[2]);
        p3 = vlib_get_buffer (vm, from[3]);
        vlib_prefetch_buffer_header (p2, LOAD);
        vlib_prefetch_buffer_header (p3, LOAD);
        clib_prefetch_load (p2->data);
        clib_prefetch_load (p3->data);
      }

      b0 = vlib_get_buffer (vm, from[0]);
      b1 = vlib_get_buffer (vm, from[1]);
      ip0 = vlib_buffer_get_current (b0);
      ip1 = vlib_buffer_get_current (b1);

      /* 1단계: FIB 테이블 선택 (VRF 기반) */
      u32 fib_index0 = vec_elt (im->fib_index_by_sw_if_index,
                               b0->sw_if_index[VLIB_RX]);
      mtrie0 = &ip4_fib_get(fib_index0)->mtrie;

      /* 2단계: mtrie 검색 (최장 접두사 매칭) */
      leaf0 = ip4_fib_mtrie_lookup_step_one (mtrie0, &ip0->dst_address);
      leaf0 = ip4_fib_mtrie_lookup_step (mtrie0, leaf0,
                                          &ip0->dst_address, 2);
      leaf0 = ip4_fib_mtrie_lookup_step (mtrie0, leaf0,
                                          &ip0->dst_address, 3);

      /* 3단계: load-balance 객체 획득 */
      u32 lbi0 = ip4_fib_mtrie_leaf_get_adj_index (leaf0);
      load_balance_t *lb0 = load_balance_get (lbi0);

      /* 4단계: ECMP — flow hash로 경로 선택 */
      u32 hash0;
      if (PREDICT_FALSE (lb0->lb_n_buckets > 1))
        {
          /* 5-tuple hash: src_ip, dst_ip, proto, src_port, dst_port */
          hash0 = ip4_compute_flow_hash (ip0, lb0->lb_hash_config);
          /* hash 값으로 버킷 인덱스 계산 */
          hash0 = hash0 % lb0->lb_n_buckets;
        }
      else
        hash0 = 0;

      /* 5단계: adjacency 선택 → 다음 노드 결정 */
      dpo_id_t *dpo0 = load_balance_get_bucket_i (lb0, hash0);
      next0 = dpo0->dpoi_next_node;
      vnet_buffer(b0)->ip.adj_index[VLIB_TX] = dpo0->dpoi_index;

      /* ... b1도 동일 패턴 ... */

      vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                                        to_next, n_left_to_next,
                                        bi0, bi1, next0, next1);
      n_left -= 2;
      from += 2;
    }

  return frame->n_vectors;
}

ip4-rewrite 노드 (ip4_forward.c)

ip4-rewrite 노드는 패킷 전달의 마지막 L3 처리 단계로, adjacency에 저장된 rewrite data를 패킷에 적용합니다. MAC 주소 재작성, TTL 감소, IP 체크섬 incremental 업데이트를 수행하며, 완료된 패킷을 interface-output 노드로 전달합니다.

체크섬 업데이트는 전체 재계산 대신 incremental 방식을 사용합니다. TTL이 1 감소하면 체크섬에 0x0100을 더하는 것으로 충분하며, 이는 전체 헤더를 다시 순회하는 것보다 훨씬 빠릅니다. vnet_rewrite_one_header()와 vnet_rewrite_two_headers()는 adjacency의 rewrite string을 이더넷 헤더 위치에 복사하여 목적지/소스 MAC 주소와 EtherType을 한 번에 기록합니다.

/* ip4_rewrite_inline() — dual-loop 패턴 (simplified pseudo-code) */
static_always_inline uword
ip4_rewrite_inline (vlib_main_t *vm,
                    vlib_node_runtime_t *node,
                    vlib_frame_t *frame,
                    int do_counters, int is_midchain, int is_mcast)
{
  u32 n_left, *from;
  ip_adjacency_t *adj0, *adj1;

  from = vlib_frame_vector_args (frame);
  n_left = frame->n_vectors;

  while (n_left >= 2)
    {
      vlib_buffer_t *b0, *b1;
      ip4_header_t *ip0, *ip1;
      u32 adj_index0, adj_index1;
      u32 next0, next1;

      /* 프리페치: 다음 패킷 및 adjacency 데이터 */
      vlib_prefetch_buffer_header (b[2], LOAD);
      vlib_prefetch_buffer_header (b[3], LOAD);

      b0 = vlib_get_buffer (vm, from[0]);
      b1 = vlib_get_buffer (vm, from[1]);
      ip0 = vlib_buffer_get_current (b0);
      ip1 = vlib_buffer_get_current (b1);

      /* 1단계: adjacency 획득 (lookup에서 설정한 인덱스) */
      adj_index0 = vnet_buffer(b0)->ip.adj_index[VLIB_TX];
      adj0 = adj_get (adj_index0);

      /* 2단계: TTL 감소 */
      ip0->ttl -= 1;

      /* 3단계: 체크섬 incremental 업데이트
       * TTL 1 감소 = 체크섬에 0x0100 가산 (one's complement) */
      u32 sum0 = ip0->checksum + clib_host_to_net_u16 (0x0100);
      sum0 += (sum0 >= 0xFFFF);  /* carry 처리 */
      ip0->checksum = sum0;

      /* 4단계: TTL 만료 확인 → ICMP 생성 */
      if (PREDICT_FALSE (ip0->ttl == 0))
        {
          next0 = IP4_REWRITE_NEXT_ICMP_ERROR;
          goto enqueue;
        }

      /* 5단계: MAC 헤더 재작성 (adjacency rewrite data 복사) */
      vnet_rewrite_two_headers (adj0[0], adj1[0], ip0, ip1,
                               sizeof (ethernet_header_t));

      /* rewrite_two_headers는 다음을 수행합니다:
       * - 버퍼 포인터를 L2 헤더 시작으로 후퇴
       * - adjacency의 rewrite_data를 복사 (dst MAC + src MAC + EtherType)
       * - 두 패킷을 동시 처리하여 캐시 활용 극대화 */

      /* 6단계: 출력 인터페이스 설정 */
      vnet_buffer(b0)->sw_if_index[VLIB_TX] = adj0->rewrite_header.sw_if_index;
      next0 = adj0->rewrite_header.next_index;  /* → interface-output */

    enqueue:
      vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                                        to_next, n_left_to_next,
                                        bi0, bi1, next0, next1);
      n_left -= 2;
      from += 2;
    }

  /* 잔여 패킷 single-loop 처리 */
  while (n_left > 0)
    { /* ... 단일 패킷 처리 ... */ }

  return frame->n_vectors;
}

추가 그래프 노드 내부 구현

앞서 살펴본 ethernet-input, ip4-input, ip4-lookup, ip4-rewrite 외에도 VPP 그래프에는 수십 개의 핵심 노드가 존재합니다. 이 절에서는 DPDK 입력, TCP 처리, NAT44, L2 포워딩 노드의 내부 구현을 상세히 분석합니다.

dpdk-input 노드 (dpdk/device/dpdk.h)

dpdk-input은 INPUT 타입 노드로, 그래프의 최상단에서 NIC 수신 링을 폴링하여 패킷 벡터를 생성합니다. VPP의 모든 패킷 처리는 이 노드에서 시작됩니다.

INPUT 노드 폴링 메커니즘은 다음과 같이 동작합니다:

• rte_eth_rx_burst() 호출: DPDK의 PMD(Poll Mode Driver)를 통해 NIC RX 링에서 최대 VLIB_FRAME_SIZE(256)개의 패킷을 배치로 수집합니다. 이 호출은 커널 인터럽트 없이 직접 하드웨어 디스크립터를 읽습니다.
• rte_mbuf → vlib_buffer_t 변환: DPDK의 rte_mbuf 메타데이터를 VPP 내부의 vlib_buffer_t 구조체로 변환합니다. 버퍼 풀에서 사전 할당된 공유 메모리 영역을 사용하므로 복사 없이 포인터 산술로 변환이 완료됩니다.
• 벡터 프레임 생성: 변환된 버퍼 인덱스 배열을 vlib_frame_t에 채우고, 다음 노드인 ethernet-input으로 전달합니다. 이때 프레임의 n_vectors 필드가 실제 수집된 패킷 수로 설정됩니다.
• Adaptive polling: 연속으로 패킷이 없는 상황이 감지되면 인터럽트 모드로 전환하여 CPU 사용률을 줄입니다. 패킷이 다시 도착하면 즉시 폴링 모드로 복귀합니다. 이 동작은 dpdk { ... } 설정의 poll-sleep-usec로 조정할 수 있습니다.

/* dpdk_device_input() — DPDK RX 폴링 및 벡터 생성 (simplified pseudo-code) */
static uword
dpdk_device_input (vlib_main_t *vm, dpdk_device_t *xd,
                    vlib_node_runtime_t *node, u16 queue_id)
{
  u32 n_buffers, n_left;
  u32 next_index = VNET_DEVICE_INPUT_NEXT_ETHERNET_INPUT;
  u32 buffer_indices[VLIB_FRAME_SIZE];
  struct rte_mbuf *mbufs[VLIB_FRAME_SIZE];

  /* 1단계: DPDK PMD를 통해 NIC RX 링에서 패킷 배치 수집 */
  n_buffers = rte_eth_rx_burst (xd->port_id, queue_id,
                                mbufs, VLIB_FRAME_SIZE);
  if (n_buffers == 0)
    {
      /* adaptive polling: 패킷 없으면 인터럽트 모드 전환 고려 */
      if (xd->flags & DPDK_DEVICE_FLAG_INT_SUPPORTED)
        dpdk_device_enable_interrupt (xd, queue_id);
      return 0;
    }

  /* 2단계: rte_mbuf → vlib_buffer_t 변환 (제로 카피) */
  for (int i = 0; i < n_buffers; i++)
    {
      vlib_buffer_t *b;
      /* mbuf 주소에서 vlib_buffer_t 오프셋 계산 (공유 메모리) */
      b = vlib_buffer_from_rte_mbuf (mbufs[i]);
      buffer_indices[i] = vlib_get_buffer_index (vm, b);

      /* 버퍼 메타데이터 초기화 */
      b->current_length = mbufs[i]->pkt_len;
      b->current_data = 0;
      b->total_length_not_including_first_buffer = 0;

      /* 오프로드 플래그 전파: checksum, VLAN 등 */
      if (mbufs[i]->ol_flags & RTE_MBUF_F_RX_IP_CKSUM_GOOD)
        b->flags |= VNET_BUFFER_F_L4_CHECKSUM_COMPUTED;
    }

  /* 3단계: 벡터 프레임 생성 및 ethernet-input으로 enqueue */
  n_left = n_buffers;
  while (n_left > 0)
    {
      u32 *to_next, n_left_to_next;
      vlib_get_next_frame (vm, node, next_index,
                           to_next, n_left_to_next);

      u32 n_copy = clib_min (n_left, n_left_to_next);
      clib_memcpy_fast (to_next,
                        buffer_indices + (n_buffers - n_left),
                        n_copy * sizeof (u32));
      n_left_to_next -= n_copy;
      n_left -= n_copy;

      vlib_put_next_frame (vm, node, next_index, n_left_to_next);
    }

  /* 인터페이스 카운터 갱신 */
  vlib_increment_combined_counter (
    &vnet_main.interface_main.combined_sw_if_counters
      [VNET_INTERFACE_COUNTER_RX],
    vm->thread_index, xd->sw_if_index,
    n_buffers, /* packets */
    total_bytes  /* bytes */);

  return n_buffers;
}

tcp-input 노드 (tcp_input.c)

tcp-input 노드는 VPP의 호스트 스택(Host Stack) 내에서 TCP 세그먼트를 수신하고 상태 머신을 구동하는 핵심 노드입니다. 일반적인 커널 TCP 스택과 달리 VPP는 사용자 공간에서 세션 레이어를 직접 관리합니다.

TCP 상태 머신 처리 흐름은 다음과 같습니다:

• tcp_input_inline() 함수: 수신 세그먼트의 TCP 헤더를 파싱하고, 4-tuple(src/dst IP, src/dst port) 해시로 기존 연결을 검색합니다. 연결이 존재하면 해당 tcp_connection_t의 현재 상태에 따라 처리 함수를 디스패치합니다.
• 상태별 디스패치: ESTABLISHED 상태는 fast-path로 처리되어 대부분의 데이터 전송 세그먼트가 최소 분기로 처리됩니다. SYN_RCVD, FIN_WAIT_1, FIN_WAIT_2, CLOSE_WAIT, CLOSING, LAST_ACK, TIME_WAIT 상태는 각각 전용 핸들러(Handler)에서 처리됩니다.
• ACK 처리: tcp_rcv_ack()에서 SACK(Selective ACK) 스코어보드를 갱신하고, 확인된 바이트에 대한 congestion window를 조정합니다. Reno, CUBIC, NewReno 등 혼잡 제어 알고리즘을 플러그인 방식으로 교체할 수 있습니다.
• 재전송 타이머와 RTO 계산: 각 연결의 SRTT(Smoothed RTT)와 RTTVAR를 갱신하고, RFC 6298 기반으로 RTO(Retransmission Timeout)를 계산합니다. 타이머 만료 시 tcp-timer 프로세스 노드가 재전송을 트리거합니다.

/* tcp_input_inline() — ESTABLISHED fast-path (simplified pseudo-code) */
static uword
tcp_input_inline (vlib_main_t *vm, vlib_node_runtime_t *node,
                   vlib_frame_t *frame, u8 is_ip4)
{
  u32 n_left = frame->n_vectors;
  u32 *from = vlib_frame_vector_args (frame);

  while (n_left > 0)
    {
      vlib_buffer_t *b = vlib_get_buffer (vm, from[0]);
      tcp_header_t *tcp = vlib_buffer_get_current (b);
      tcp_connection_t *tc;

      /* 4-tuple 해시로 기존 연결 검색 */
      tc = tcp_lookup_connection (b, vm->thread_index, is_ip4);
      if (PREDICT_FALSE (!tc))
        {
          /* SYN 패킷이면 tcp-listen으로, 아니면 RST 전송 */
          goto next_packet;
        }

      /* ESTABLISHED 상태 fast-path */
      if (PREDICT_TRUE (tc->state == TCP_STATE_ESTABLISHED))
        {
          /* 시퀀스 번호 검증 */
          if (PREDICT_FALSE (
                !tcp_segment_in_rcv_wnd (tc, tcp)))
            {
              tcp_send_ack (tc);
              goto next_packet;
            }

          /* ACK 처리: snd_una 전진, 혼잡 윈도우 갱신 */
          if (tcp->flags & TCP_FLAG_ACK)
            {
              tcp_rcv_ack (tc, tcp, b);
              /* SACK 스코어보드 갱신 */
              if (tcp_opts_sack_present (&tc->rcv_opts))
                tcp_rcv_sacks (tc, tc->snd_una);
            }

          /* 데이터 수신: 순서대로면 즉시 전달, 아니면 재정렬 큐 */
          if (data_len > 0)
            {
              if (PREDICT_TRUE (
                    seq == tc->rcv_nxt))
                tcp_session_enqueue_data (tc, b, data_len);
              else
                tcp_session_enqueue_ooo (tc, b, data_len);

              /* 지연 ACK 타이머 시작 또는 즉시 ACK */
              tcp_maybe_send_ack (tc);
            }

          /* RTT 샘플 갱신 (RFC 6298) */
          if (tc->rtt_ts && tcp_ack_is_newer (tc, tcp))
            {
              f64 rtt_sample = tcp_time_now () - tc->rtt_ts;
              tcp_update_rto (tc, rtt_sample);
            }
        }
      else
        {
          /* slow-path: 상태별 핸들러 디스패치 */
          switch (tc->state)
            {
            case TCP_STATE_SYN_RCVD:
              tcp_rcv_state_syn_rcvd (tc, tcp, b);
              break;
            case TCP_STATE_FIN_WAIT_1:
              tcp_rcv_state_fin_wait_1 (tc, tcp, b);
              break;
            case TCP_STATE_FIN_WAIT_2:
              tcp_rcv_state_fin_wait_2 (tc, tcp, b);
              break;
            case TCP_STATE_CLOSE_WAIT:
              tcp_rcv_state_close_wait (tc, tcp, b);
              break;
            case TCP_STATE_TIME_WAIT:
              tcp_rcv_state_time_wait (tc, tcp, b);
              break;
            default:
              break;
            }
        }

    next_packet:
      from++;
      n_left--;
    }

  return frame->n_vectors;
}

nat44-in2out / nat44-out2in 노드

NAT44 ED(Endpoint-Dependent) 모드는 VPP의 고성능 NAT 구현으로, 전체 5-tuple을 기반으로 세션을 관리합니다. nat44-in2out은 내부에서 외부 방향, nat44-out2in은 외부에서 내부 방향의 주소 변환(NAT)을 수행합니다.

NAT44 Endpoint-Dependent 처리 흐름은 다음과 같습니다:

• nat44_ed_in2out_node_fn_inline(): 패킷의 source IP/port, destination IP/port, protocol 5-tuple을 추출하고, 세션 테이블에서 기존 매핑을 검색합니다.
• 세션 테이블 룩업: clib_bihash(bounded-index extensible hash) 기반 해시 테이블에서 5-tuple 키로 snat_session_t를 검색합니다. 히트 시 기존 변환 규칙을 즉시 적용합니다.
• 세션 미스 시 동적 할당: 주소 풀에서 가용 외부 IP를 선택하고, 포트 범위 내에서 사용 가능한 포트를 할당합니다. 할당된 매핑으로 새 snat_session_t를 생성하고 in2out/out2in 양방향 해시에 삽입합니다.
• 패킷 변환: source IP와 source port를 할당된 외부 주소/포트로 교체하고, IP 헤더 체크섬과 L4(TCP/UDP) 체크섬을 incremental update 방식으로 갱신합니다. 전체 재계산 대신 변경된 필드의 차분만 반영하여 성능을 최적화합니다.

/* nat44_ed_in2out_node_fn_inline() — NAT44 ED in2out 처리 (simplified pseudo-code) */
static uword
nat44_ed_in2out_node_fn_inline (vlib_main_t *vm,
                                 vlib_node_runtime_t *node,
                                 vlib_frame_t *frame,
                                 int is_slow_path)
{
  snat_main_t *sm = &snat_main;
  u32 n_left = frame->n_vectors;
  u32 *from = vlib_frame_vector_args (frame);
  u32 thread_index = vm->thread_index;

  while (n_left > 0)
    {
      vlib_buffer_t *b = vlib_get_buffer (vm, from[0]);
      ip4_header_t *ip = vlib_buffer_get_current (b);
      snat_session_t *s;
      u32 next = NAT44_ED_IN2OUT_NEXT_LOOKUP;

      /* 1단계: 5-tuple 추출 (src/dst IP, src/dst port, protocol) */
      nat_ed_ses_key_t kv;
      nat44_ed_make_key (&kv, ip->src_address, ip->dst_address,
                          ip4_get_src_port (ip),
                          ip4_get_dst_port (ip),
                          ip->protocol,
                          vnet_buffer(b)->sw_if_index[VLIB_RX]);

      /* 2단계: 세션 테이블 룩업 (clib_bihash) */
      if (clib_bihash_search_16_8 (&sm->flow_hash,
                                    &kv, &value) == 0)
        {
          /* 세션 히트: 기존 매핑 적용 */
          s = pool_elt_at_index (
                sm->per_thread_data[thread_index].sessions,
                value.value);
        }
      else
        {
          /* 세션 미스: 새 매핑 생성 (slow-path) */
          if (!is_slow_path)
            {
              next = NAT44_ED_IN2OUT_NEXT_SLOW_PATH;
              goto enqueue;
            }

          /* 주소 풀에서 외부 IP 선택 */
          snat_address_t *a;
          u16 ext_port;
          nat44_ed_alloc_addr_and_port (
            sm, thread_index, ip->protocol,
            &a, &ext_port);

          /* 새 세션 생성 및 양방향 해시 삽입 */
          s = nat44_ed_session_alloc (sm, thread_index);
          s->in2out.addr = ip->src_address;
          s->in2out.port = ip4_get_src_port (ip);
          s->out2in.addr = a->addr;
          s->out2in.port = ext_port;
          s->ext_host_addr = ip->dst_address;
          s->ext_host_port = ip4_get_dst_port (ip);

          /* in2out 방향 해시 삽입 */
          nat44_ed_session_add_to_flow_hash (sm, s, thread_index);
        }

      /* 3단계: 패킷 변환 — src IP/port 교체 */
      ip4_address_t old_addr = ip->src_address;
      u16 old_port = ip4_get_src_port (ip);
      ip->src_address = s->out2in.addr;
      ip4_set_src_port (ip, s->out2in.port);

      /* 4단계: 체크섬 incremental update */
      ip_csum_update (ip->checksum,
                      old_addr.as_u32, s->out2in.addr.as_u32,
                      ip4_header_t,
                      src_address);
      /* L4 체크섬도 incremental update (TCP/UDP) */
      tcp_udp_csum_update (ip, old_addr, old_port,
                           s->out2in.addr, s->out2in.port);

      /* 세션 타임스탬프 갱신 (LRU 에이징용) */
      s->last_heard = vlib_time_now (vm);

    enqueue:
      vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
                                        to_next, n_left_to_next,
                                        from[0], next);
      from++;
      n_left--;
    }

  return frame->n_vectors;
}

l2-input / l2-fwd 노드

VPP의 L2 브릿지 도메인(Bridge Domain)은 전통적인 스위치의 포워딩 기능을 사용자 공간에서 구현합니다. l2-input 노드가 L2 처리 파이프라인의 진입점이고, l2-fwd 노드가 MAC 테이블 기반 포워딩을 수행합니다.

L2 브릿지 도메인 처리 흐름은 다음과 같습니다:

• l2_input_node_fn(): 인터페이스의 sw_if_index에서 소속 bridge-domain을 확인하고, 해당 bridge-domain의 feature arc(learning, forwarding, flooding, ARP termination 등)를 설정합니다. Feature bitmap에 따라 활성화된 기능 노드들이 순차 실행됩니다.
• l2_fwd_node_fn(): destination MAC 주소로 MAC 테이블을 룩업하여 출력 인터페이스를 결정합니다. MAC 테이블은 clib_bihash 기반으로 구현되어 수백만 엔트리를 효율적으로 검색합니다.
• MAC 러닝: source MAC 주소가 테이블에 없으면 현재 입력 인터페이스와 매핑하여 새 엔트리를 삽입합니다. 에이징 타이머(기본 300초)가 만료되면 엔트리가 자동 삭제됩니다.
• BUM 트래픽 플러딩: Broadcast, Unknown unicast, Multicast 트래픽은 l2-flood 노드로 전달되어 bridge-domain 내 모든 멤버 인터페이스로 복제됩니다. 입력 인터페이스는 플러딩 대상에서 제외됩니다.

/* l2_fwd_node_fn() — L2 MAC 룩업 포워딩 (simplified pseudo-code) */
static uword
l2_fwd_node_fn (vlib_main_t *vm,
                vlib_node_runtime_t *node,
                vlib_frame_t *frame)
{
  l2fib_main_t *fm = &l2fib_main;
  u32 n_left = frame->n_vectors;
  u32 *from = vlib_frame_vector_args (frame);

  while (n_left > 0)
    {
      vlib_buffer_t *b = vlib_get_buffer (vm, from[0]);
      ethernet_header_t *eth = vlib_buffer_get_current (b);
      u32 bd_index = vnet_buffer(b)->l2.bd_index;
      u32 next;

      /* 1단계: destination MAC으로 L2 FIB 검색 */
      l2fib_entry_key_t key;
      l2fib_entry_result_t result;
      l2fib_make_key (&key, eth->dst_address, bd_index);

      if (clib_bihash_search_8_8 (&fm->mac_table,
                                   &key, &result) == 0)
        {
          /* MAC 히트: 출력 인터페이스 결정 */
          u32 sw_if_index = result.fields.sw_if_index;

          /* 입력 = 출력이면 드롭 (split-horizon) */
          if (PREDICT_FALSE (
                sw_if_index == vnet_buffer(b)->sw_if_index[VLIB_RX]))
            {
              next = L2FWD_NEXT_DROP;
              goto enqueue;
            }

          /* 출력 인터페이스 설정 */
          vnet_buffer(b)->sw_if_index[VLIB_TX] = sw_if_index;
          next = L2FWD_NEXT_L2_OUTPUT;

          /* 필터링 엔트리이면 드롭 */
          if (PREDICT_FALSE (result.fields.filter))
            next = L2FWD_NEXT_DROP;

          /* 정적 엔트리가 아니면 에이징 타임스탬프 갱신 */
          if (!result.fields.static_mac)
            result.fields.timestamp = l2fib_cur_age (fm);
        }
      else
        {
          /* MAC 미스: BUM 트래픽으로 간주, flood 경로 */
          next = L2FWD_NEXT_FLOOD;
        }

      /* 2단계: source MAC 러닝 */
      if (PREDICT_TRUE (
            vnet_buffer(b)->l2.feature_bitmap & L2INPUT_FEAT_LEARN))
        {
          l2fib_entry_key_t src_key;
          l2fib_entry_result_t src_result;
          l2fib_make_key (&src_key, eth->src_address, bd_index);

          if (clib_bihash_search_8_8 (&fm->mac_table,
                                       &src_key, &src_result) != 0)
            {
              /* 새 source MAC: 엔트리 삽입 (러닝) */
              src_result.fields.sw_if_index =
                vnet_buffer(b)->sw_if_index[VLIB_RX];
              src_result.fields.static_mac = 0;
              src_result.fields.timestamp = l2fib_cur_age (fm);
              clib_bihash_add_del_8_8 (&fm->mac_table,
                                        &src_key, &src_result,
                                        1 /* is_add */);

              /* MAC 러닝 이벤트 로그 */
              l2fib_learn_event (fm, eth->src_address,
                                  bd_index,
                                  vnet_buffer(b)->sw_if_index[VLIB_RX]);
            }
          else if (src_result.fields.sw_if_index !=
                     vnet_buffer(b)->sw_if_index[VLIB_RX])
            {
              /* MAC 이동: 인터페이스 갱신 */
              src_result.fields.sw_if_index =
                vnet_buffer(b)->sw_if_index[VLIB_RX];
              clib_bihash_add_del_8_8 (&fm->mac_table,
                                        &src_key, &src_result,
                                        1);
            }
        }

    enqueue:
      vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
                                        to_next, n_left_to_next,
                                        from[0], next);
      from++;
      n_left--;
    }

  return frame->n_vectors;
}

메모리 관리(Memory Management) 아키텍처

힙(Heap)/mheap 관리

VPP는 여러 개의 독립적인 메모리 영역을 관리합니다. 모든 영역은 hugepage 위에 할당되며, clib_mem 인프라가 NUMA 인식 할당을 제공합니다.

# VPP 메모리 사용량 확인
vpp# show memory main-heap
Thread 0 vpp_main
  base 0x7f8a00000000, size 1g, locked, unmap-on-destroy
    page stats: page-size 2M, total 512, mapped 310, not-mapped 202
    total: 1073741824, used: 536870912, free: 536870912

vpp# show memory api-segment
  Shared API segment:
    base 0x7f8900000000, size 64m

# NUMA별 메모리 분포
vpp# show memory numa

버퍼 풀 아키텍처

VPP 버퍼 풀은 고성능 패킷 처리의 핵심입니다. NUMA 노드별로 독립된 풀을 유지하여 원격 메모리 접근을 방지하고, 프리 리스트와 재활용(Recycling) 메커니즘으로 할당/해제 오버헤드를 최소화합니다.

/* 버퍼 풀 생성과 생명주기 */

/* 1. 시작 시: hugepage 위에 버퍼 풀 사전 할당 */
/*    buffers { buffers-per-numa 32768 } → NUMA별 32768개 버퍼 */

/* 2. INPUT 노드: 버퍼 할당 */
u32 n_alloc = vlib_buffer_alloc(vm, buffer_indices, n_buffers);
/* 스레드 로컬 캐시에서 먼저 할당 → 부족 시 글로벌 free list에서 보충 */

/* 3. 패킷 처리 중: 버퍼 체인 (점보 프레임 등) */
if (b->flags & VLIB_BUFFER_NEXT_PRESENT)
    next_b = vlib_get_buffer(vm, b->next_buffer);

/* 4. 처리 완료: 버퍼 해제 (free list 반환) */
vlib_buffer_free(vm, buffer_indices, n_buffers);
/* 로컬 캐시가 가득 차면 글로벌 free list로 반환 */

멀티스레딩 아키텍처

워커 스레드 모델

VPP는 메인 스레드 + N개 워커 스레드 모델을 사용합니다. 메인 스레드는 CLI/API 처리와 제어 평면을 담당하고, 워커 스레드는 데이터 평면(패킷 처리)에 전담합니다. 각 워커는 독립된 메인 루프를 실행합니다.

/* startup.conf — 스레딩 설정 */
cpu {
    main-core 0                /* 메인 스레드: 코어 0 */
    corelist-workers 2,4,6,8   /* 워커 4개: 물리 코어만 (HT 제외) */
    skip-cores 1               /* 코어 1 건너뛰기 (OS 예약) */
    scheduler-policy fifo      /* RT 스케줄링 (선택) */
    scheduler-priority 50      /* RT 우선순위 */
}

/* 워커 수에 따라 NIC RX 큐를 자동 매핑 */
dpdk {
    dev 0000:03:00.0 {
        num-rx-queues 4        /* 워커 수와 일치 */
    }
}

프레임 핸드오프

NIC의 RSS(Receive Side Scaling)는 5-tuple 해시를 기반으로 수신 큐를 분산합니다. 하지만 NAT44 세션 룩업, IPsec SA 선택, TCP 세그먼트 재조립 등 상태 기반 처리(Stateful Processing)는 동일 플로우의 모든 패킷이 반드시 같은 워커에서 처리되어야 합니다. RSS 해시가 이를 보장하지 못할 때, VPP의 frame handoff 메커니즘이 패킷을 올바른 워커로 재분배합니다.

Handoff 동작 원리

VPP의 handoff는 그래프 노드로 구현되며, 다음과 같은 단계로 동작합니다:

1. 플로우 해시 계산: handoff 노드가 패킷의 5-tuple(src IP, dst IP, src port, dst port, protocol)로부터 해시를 계산합니다.
2. 대상 워커 결정: hash % n_workers 연산으로 패킷이 처리될 워커 인덱스를 결정합니다.
3. 바이패스 최적화: 패킷이 이미 올바른 워커에 있으면 handoff 없이 다음 노드로 직접 전달합니다. 이 경우 추가 비용이 발생하지 않습니다.
4. 크로스 워커 전달: 다른 워커로 이동해야 하면, 해당 워커의 per-worker lockfree ring에 버퍼 인덱스를 enqueue합니다.
5. 대상 워커 수신: 대상 워커가 다음 메인 루프(main loop) 반복에서 자신의 ring을 dequeue하여 패킷을 수신하고 그래프 처리를 계속합니다.
6. Symmetrical 모드: symmetrical 옵션을 활성화하면, 양방향 플로우(A→B와 B→A)가 동일한 해시를 생성하여 같은 워커에서 처리됩니다. 이를 위해 src/dst를 정렬한 후 해시를 계산합니다.

핵심 구조체: vlib_frame_queue_t

Handoff의 핵심은 per-worker lockfree ring buffer인 vlib_frame_queue_t 구조체입니다. 각 워커마다 하나의 ring이 존재하며, 다른 워커들이 이 ring에 패킷을 enqueue합니다:

/* vlib_buffer_enqueue_to_thread() — 핵심 handoff 함수 (의사 코드) */
static_always_inline u32
vlib_buffer_enqueue_to_thread (vlib_main_t *vm,
                               vlib_node_runtime_t *node,
                               u32 *buffers, u16 *thread_indices,
                               u32 n_packets, u32 drop_on_full)
{
  vlib_frame_queue_t *fq;
  u32 n_left = n_packets;

  while (n_left)
  {
    u16 target_thread = thread_indices[0];

    /* 같은 워커이면 bypass — handoff 비용 없음 */
    if (target_thread == vm->thread_index)
    {
      /* 현재 노드의 next로 직접 enqueue */
      vlib_buffer_enqueue_to_next (vm, node, buffers, nexts, count);
      continue;
    }

    /* 대상 워커의 frame queue 획득 */
    fq = vlib_get_frame_queue (vm, fq_index, target_thread);

    /* ring tail을 atomic CAS로 확보 */
    u32 tail = __atomic_load_n (&fq->tail, __ATOMIC_ACQUIRE);
    u32 new_tail = tail + 1;

    /* 오버플로 검사 */
    if (PREDICT_FALSE (new_tail - fq->head >= fq->nelts))
    {
      if (drop_on_full)
        vlib_buffer_free (vm, buffers, count);
      continue;
    }

    /* 버퍼 인덱스를 ring 슬롯에 복사 */
    vlib_frame_queue_elt_t *elt = &fq->elts[tail & (fq->nelts - 1)];
    clib_memcpy_fast (elt->buffer_index, buffers, count * sizeof (u32));
    elt->n_vectors = count;

    /* tail 전진 (atomic store) — 대상 워커가 볼 수 있게 됨 */
    __atomic_store_n (&fq->tail, new_tail, __ATOMIC_RELEASE);

    /* 대상 워커의 pending interrupt 신호 */
    vlib_node_set_interrupt_pending (
        vlib_get_main_by_index (target_thread), node->node_index);
  }

  return n_packets;
}

Handoff CLI 명령

# handoff 노드 삽입 (nat44 이전에 플로우 해시 기반 재분배)
vpp# set interface handoff GigabitEthernet0/8/0 workers 0-3 symmetrical

# handoff 큐 상태 확인
vpp# show handoff
  worker 0: 250000 frames, 0 drops
  worker 1: 248000 frames, 0 drops
  worker 2: 251000 frames, 0 drops
  worker 3: 249000 frames, 0 drops

Handoff 성능 영향

실전 시나리오별 Handoff 설정

배리어 동기화

VPP의 데이터 평면은 lockfree로 동작하지만, FIB 업데이트나 인터페이스 추가 같은 제어 평면 변경은 모든 워커를 일시 정지시키는 배리어 동기화가 필요합니다.

큐 어피니티(Queue Affinity)와 플로우 스티키

큐 어피니티(Queue Affinity)는 특정 플로우의 패킷이 항상 동일한 워커 스레드에서 처리되도록 보장하는 메커니즘입니다. NIC의 RSS, 플로우 디렉터(Flow Director), DPDK rte_flow API, VPP의 핸드오프(handoff) 노드 등 여러 계층에서 구현됩니다. 이를 통해 세션 상태의 경합 없는 처리와 캐시 지역성(Cache Locality)을 극대화합니다.

RSS(Receive Side Scaling) 상세

RSS는 NIC 하드웨어에서 Toeplitz 해시 함수를 사용하여 5-tuple(소스 IP, 목적지 IP, 소스 포트, 목적지 포트, 프로토콜)에 대한 해시값을 계산하고, 그 결과를 인다이렉션 테이블(Indirection Table)을 통해 RX 큐에 매핑합니다.

/* Toeplitz 해시 계산 과정 (개념적 수도코드) */
static u32 toeplitz_hash(const u8 *key, const u8 *input, int len)
{
    u32 hash = 0;
    for (int i = 0; i < len * 8; i++) {
        if (input[i / 8] & (1 << (7 - (i % 8))))
            hash ^= get_key_word(key, i);
    }
    return hash;
}

/* 해시 → 큐 매핑 */
queue_index = indirection_table[hash & (table_size - 1)];

# VPP startup.conf에서 RSS 설정
dpdk {
    dev 0000:03:00.0 {
        num-rx-queues 4           # 워커 수에 맞춰 큐 수 설정
        rss-fn ipv4-tcp           # TCP/IPv4에 대해 RSS 활성화
    }
}

Flow Director / rte_flow 기반 정밀 제어

Flow Director는 NIC 하드웨어에서 exact-match 또는 prefix-match 규칙으로 특정 플로우를 지정된 큐로 스티어링(steering)합니다. DPDK의 rte_flow API는 이를 프로그래밍 가능한 방식으로 추상화합니다.

/* rte_flow API로 특정 VIP 트래픽을 큐 2로 스티어링하는 예시 */
struct rte_flow_attr attr = { .ingress = 1 };
struct rte_flow_item pattern[] = {
    { .type = RTE_FLOW_ITEM_TYPE_ETH },
    { .type = RTE_FLOW_ITEM_TYPE_IPV4,
      .spec = &(struct rte_flow_item_ipv4){
          .hdr.dst_addr = rte_cpu_to_be_32(RTE_IPV4(10,0,0,100))
      }},
    { .type = RTE_FLOW_ITEM_TYPE_END },
};
struct rte_flow_action actions[] = {
    { .type = RTE_FLOW_ACTION_TYPE_QUEUE,
      .conf = &(struct rte_flow_action_queue){ .index = 2 }},
    { .type = RTE_FLOW_ACTION_TYPE_END },
};
flow = rte_flow_create(port_id, &attr, pattern, actions, &error);

# VPP CLI에서 DPDK 플로우 분류 설정
set dpdk flow-classify interface GigabitEthernet3/0/0 \
    ip4-table 0

# 사용 사례: 특정 VIP(10.0.0.100) 트래픽을 전용 워커에 할당
# → NIC 하드웨어가 패킷을 지정 큐로 스티어링
# → 해당 큐에 매핑된 워커가 전담 처리

VPP 세션 워커 어피니티

TCP/TLS 세션은 accept 또는 connect 시점에 현재 워커 스레드에 바인딩됩니다. session_alloc() 함수가 vlib_get_thread_index()로 현재 워커 인덱스를 확인하고, 해당 세션을 그 워커에 고정합니다. 세션의 전체 생명주기(lifetime) 동안 워커 변경은 불가능하며, 이는 FIFO 버퍼를 스레드 간에 공유하지 않기 때문입니다.

/* src/vnet/session/session.c — 세션 할당과 워커 바인딩 */
session_t *
session_alloc (u32 thread_index)
{
    session_worker_t *wrk = &session_main.wrk[thread_index];
    session_t *s;

    /* per-worker 풀에서 세션 할당 — 락 불필요 */
    pool_get_aligned(wrk->sessions, s, CLIB_CACHE_LINE_BYTES);
    clib_memset(s, 0, sizeof(*s));
    s->session_index = s - wrk->sessions;
    s->thread_index = thread_index;  /* 현재 워커에 고정 */

    return s;
}

/* handoff 노드 — RSS 불일치 보정 */
/* 패킷이 잘못된 워커에 도착하면 올바른 워커로 재전달 */
static uword
session_queue_node_fn (vlib_main_t *vm, ...)
{
    /* session의 thread_index와 현재 thread_index 비교 */
    if (s->thread_index != thread_index)
        session_send_rpc_evt_to_thread(s->thread_index, ...);
        /* → 올바른 워커로 handoff */
}

대칭 플로우 해시(Symmetrical Flow Hash)

symmetrical 옵션을 사용하면 소스와 목적지를 교환(src↔dst swap)해도 동일한 해시값이 나오도록 보장합니다. 이 기능은 NAT, IPsec 등에서 인바운드/아웃바운드 경로가 같은 워커에서 처리되도록 하는 데 필수적입니다.

/* src/vnet/ip/ip4_forward.c — 대칭 해시 구현 */
static inline u32
ip4_compute_flow_hash (const ip4_header_t *ip,
                        flow_hash_config_t cfg)
{
    u32 a, b, c;
    u32 src = clib_net_to_host_u32(ip->src_address.as_u32);
    u32 dst = clib_net_to_host_u32(ip->dst_address.as_u32);

    /* 대칭 해시: src/dst를 정렬하여 방향 무관하게 동일 해시 */
    if (cfg & IP_FLOW_HASH_SYMMETRIC) {
        if (src > dst) {
            u32 tmp = src; src = dst; dst = tmp;
        }
    }
    a = src; b = dst; c = ip->protocol;
    hash_v3_mix32(&a, &b, &c);
    return c;
}

# VPP CLI에서 대칭 해시 활성화
set ip flow-hash table 0 src dst sport dport proto symmetric

# 확인
show ip flow-hash table 0
# 출력: src dst sport dport proto symmetric

실전 설정 가이드

문제 진단 CLI 명령

# NIC 큐 ↔ 워커 매핑 확인
vpp# show interface placement
Thread 1 (vpp_wk_0):
  GigabitEthernet3/0/0 queue 0
Thread 2 (vpp_wk_1):
  GigabitEthernet3/0/0 queue 1

# 핸드오프 통계 — 큐 불일치로 인한 핸드오프 빈도 확인
vpp# show handoff
  worker 0: 15234 handoffs
  worker 1: 12891 handoffs

# 세션별 워커 확인 — 세션이 어느 워커에 바인딩되었는지 확인
vpp# show session verbose
  [0:0] 10.0.0.1:80->10.0.0.2:54321 ESTABLISHED thread 1
  [0:1] 10.0.0.1:80->10.0.0.3:54322 ESTABLISHED thread 2

# DPDK 큐 배치 — DPDK 레벨 큐-코어 매핑
vpp# show dpdk interface placement
  GigabitEthernet3/0/0
    queue 0 -> core 2 (worker 0)
    queue 1 -> core 4 (worker 1)
    queue 2 -> core 6 (worker 2)
    queue 3 -> core 8 (worker 3)

DPDK 통합

VPP는 DPDK(Data Plane Development Kit)를 기본 패킷 I/O 백엔드로 사용합니다. DPDK는 커널의 네트워크 드라이버를 우회하여 NIC 하드웨어에 직접 접근하는 Poll Mode Driver(PMD)를 제공합니다.

DPDK 드라이버 바인딩

DPDK PMD를 사용하려면 NIC를 커널 드라이버에서 분리(unbind)하고 UIO 또는 VFIO 드라이버에 바인딩해야 합니다:

# 현재 NIC 드라이버 확인
$ lspci -k -s 0000:03:00.0
03:00.0 Ethernet controller: Intel Corporation 82599ES ...
    Kernel driver in use: ixgbe

# VFIO-PCI 드라이버로 바인딩 (IOMMU 필요)
$ modprobe vfio-pci
$ dpdk-devbind --bind=vfio-pci 0000:03:00.0

# 또는 UIO 드라이버 (IOMMU 불필요, 보안 취약)
$ modprobe uio_pci_generic
$ dpdk-devbind --bind=uio_pci_generic 0000:03:00.0

# 상태 확인
$ dpdk-devbind --status

Hugepages 설정

DPDK와 VPP는 Hugepages를 사용하여 TLB 미스를 줄이고 메모리 접근 성능을 높입니다. 커널의 hugetlbfs(fs/hugetlbfs/)를 활용합니다:

# 부팅 시 1GB hugepage 할당 (GRUB)
GRUB_CMDLINE_LINUX="default_hugepagesz=1G hugepagesz=1G hugepages=4 iommu=pt intel_iommu=on"

# 런타임 2MB hugepage 할당
$ echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# hugetlbfs 마운트 (VPP가 자동으로 사용)
$ mount -t hugetlbfs none /dev/hugepages

# 할당 상태 확인
$ cat /proc/meminfo | grep -i huge
HugePages_Total:    1024
HugePages_Free:      512
Hugepagesize:       2048 kB

멀티큐와 RSS

최신 NIC은 여러 개의 RX/TX 큐를 제공하며, RSS(Receive Side Scaling)를 통해 패킷을 큐에 분산합니다. VPP는 각 워커 스레드에 큐를 할당하여 병렬 처리합니다:

/* startup.conf — DPDK 멀티큐 설정 */
dpdk {
    dev 0000:03:00.0 {
        num-rx-queues 4        /* RX 큐 4개 */
        num-tx-queues 4        /* TX 큐 4개 */
    }
}

cpu {
    main-core 0                /* 메인 스레드: 코어 0 */
    corelist-workers 1-3       /* 워커 스레드: 코어 1,2,3 */
}

실전 DPDK 기동 절차

실무에서 가장 자주 실패하는 구간은 "드라이버를 VFIO로 바인딩했습니다"에서 끝내는 경우입니다. 실제로는 리눅스 준비, Hugepage와 큐 수 설계, 워커 배치, 기동 직후 검증이 한 번에 맞아야 합니다. 아래 절차는 2포트 NIC와 워커 4개를 기준으로 한 전형적인 기동 순서입니다.

# 1. 리눅스 준비
sudo systemctl stop irqbalance
echo 2048 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
sudo mkdir -p /dev/hugepages
sudo mount -t hugetlbfs none /dev/hugepages

# 2. VFIO 바인딩
sudo modprobe vfio-pci
sudo dpdk-devbind --bind=vfio-pci 0000:18:00.0 0000:18:00.1
dpdk-devbind --status

# 3. startup.conf 예시
cat <<'EOF' | sudo tee /etc/vpp/startup.conf
unix {
    cli-listen /run/vpp/cli.sock
    log /var/log/vpp/vpp.log
}
cpu {
    main-core 2
    corelist-workers 4-7
}
dpdk {
    dev 0000:18:00.0 {
        num-rx-queues 4
        num-tx-queues 4
        num-rx-desc 1024
        num-tx-desc 1024
    }
    dev 0000:18:00.1 {
        num-rx-queues 4
        num-tx-queues 4
    }
}
buffers {
    buffers-per-numa 65536
    default data-size 2048
}
EOF

# 4. VPP 기동 후 즉시 확인
sudo systemctl restart vpp
vppctl show threads
vppctl show hardware-interfaces detail
vppctl show interface rx-placement
vppctl show runtime
vppctl show buffers

DPDK Crypto 디바이스 연동

VPP는 DPDK의 Cryptodev API를 통해 하드웨어/소프트웨어 암호화(Encryption) 가속을 지원합니다. IPsec의 AES-GCM, ChaCha20-Poly1305 등의 암호화 연산을 전용 하드웨어(QAT, Mellanox ConnectX 등)로 오프로드하거나, 소프트웨어 라이브러리(IPSec-MB, OpenSSL)를 사용합니다.

/* startup.conf — Crypto 디바이스 설정 */
dpdk {
    dev 0000:03:00.0             /* 네트워크 NIC */
    dev 0000:0b:00.0 {           /* Intel QAT 디바이스 */
        num-rx-queues 2
    }
    uio-driver vfio-pci
}

/* VPP crypto 엔진 설정 */
vpp# set crypto handler aes-256-gcm ipsecmb
vpp# show crypto handlers

플러그인 시스템

VPP는 모듈식 플러그인 아키텍처를 채택하여 기능을 동적으로 확장할 수 있습니다. 각 플러그인은 공유 라이브러리(Shared Library)(.so)로 빌드되며, VPP 시작 시 /usr/lib/vpp_plugins/에서 자동 로드됩니다.

플러그인 구조

VPP 플러그인의 기본 디렉터리 구조:

VPP 초기화 시퀀스

VPP는 vpp_main() 함수에서 시작하여, 메모리 초기화, UNIX 환경 설정, 플러그인 로딩, 노드 그래프 구성을 순차적으로 수행한 뒤 메인 루프에 진입합니다.

플러그인 로딩 메커니즘

VPP의 플러그인 시스템은 dlopen() 기반의 동적 로딩 방식을 사용합니다. 각 플러그인은 독립적인 SO 파일로 컴파일되며, 초기화 함수들은 매크로를 통해 등록됩니다.

/* 1. 플러그인 등록 매크로 (constructor로 자동 실행) */
VLIB_PLUGIN_REGISTER() = {
    .version = "1.0",
    .description = "My Custom Plugin",
    .default_disabled = 0,
};

/* 2. 초기화 함수 — 의존성 지정으로 실행 순서 보장 */
static clib_error_t *
my_plugin_init (vlib_main_t *vm)
{
    my_plugin_main_t *mp = &my_plugin_main;
    mp->vlib_main = vm;
    mp->vnet_main = vnet_get_main();
    pool_alloc(mp->sessions, 1024);
    return 0;
}
VLIB_INIT_FUNCTION(my_plugin_init) = {
    .runs_after = VLIB_INITS("ip4_init", "ip6_init"),
};

/* 3. 워커 스레드별 초기화 */
static clib_error_t *
my_plugin_worker_init (vlib_main_t *vm)
{
    /* 워커별 캐시, 통계 카운터 초기화 */
    return 0;
}
VLIB_WORKER_INIT_FUNCTION(my_plugin_worker_init);

/* 4. 메인 루프 진입 시 콜백 — 모든 초기화 완료 후 실행 */
static clib_error_t *
my_plugin_main_loop_enter (vlib_main_t *vm)
{
    vnet_feature_enable_disable(
        "ip4-unicast", "my-plugin-node",
        sw_if_index, 1, 0, 0);
    return 0;
}
VLIB_MAIN_LOOP_ENTER_FUNCTION(my_plugin_main_loop_enter);

커스텀 플러그인 개발

/* my_plugin.c — 플러그인 초기화 */
#include <vnet/vnet.h>
#include <vlib/vlib.h>
#include <vpp/app/version.h>

typedef struct {
    u32 sw_if_index;
    u32 next_index;
} my_plugin_main_t;

my_plugin_main_t my_plugin_main;

static clib_error_t *
my_plugin_init (vlib_main_t *vm) {
    my_plugin_main_t *mpm = &my_plugin_main;
    mpm->sw_if_index = ~0;
    return 0;
}

VLIB_INIT_FUNCTION(my_plugin_init);

/* 플러그인 등록 매크로 */
VLIB_PLUGIN_REGISTER() = {
    .version = VPP_BUILD_VER,
    .description = "My Custom Plugin",
};

/* node.c — 커스텀 그래프 노드 */
#include <vlib/vlib.h>
#include <vnet/vnet.h>

typedef enum {
    MY_NODE_NEXT_DROP,
    MY_NODE_NEXT_IFACE_OUTPUT,
    MY_NODE_N_NEXT,
} my_node_next_t;

static uword
my_node_fn (vlib_main_t *vm, vlib_node_runtime_t *node,
            vlib_frame_t *frame) {
    u32 n_left_from, *from, *to_next;
    my_node_next_t next_index;

    from = vlib_frame_vector_args(frame);
    n_left_from = frame->n_vectors;
    next_index = node->cached_next_index;

    while (n_left_from > 0) {
        u32 n_left_to_next;
        vlib_get_next_frame(vm, node, next_index,
                           to_next, n_left_to_next);

        while (n_left_from > 0 && n_left_to_next > 0) {
            u32 bi0 = from[0];
            vlib_buffer_t *b0 = vlib_get_buffer(vm, bi0);
            u32 next0 = MY_NODE_NEXT_IFACE_OUTPUT;

            /* 패킷 처리 로직 */
            /* ... */

            to_next[0] = bi0;
            from += 1;
            to_next += 1;
            n_left_from -= 1;
            n_left_to_next -= 1;

            vlib_validate_buffer_enqueue_x1(vm, node, next_index,
                to_next, n_left_to_next, bi0, next0);
        }
        vlib_put_next_frame(vm, node, next_index, n_left_to_next);
    }
    return frame->n_vectors;
}

VLIB_REGISTER_NODE(my_node) = {
    .function = my_node_fn,
    .name = "my-custom-node",
    .vector_size = sizeof(u32),
    .type = VLIB_NODE_TYPE_INTERNAL,
    .n_next_nodes = MY_NODE_N_NEXT,
    .next_nodes = {
        [MY_NODE_NEXT_DROP] = "error-drop",
        [MY_NODE_NEXT_IFACE_OUTPUT] = "interface-output",
    },
};

커널 인터페이스

VPP는 유저스페이스에서 동작하지만, 커널 네트워크 스택과의 연동이 필수적인 경우가 많습니다. VPP는 다양한 커널 인터페이스를 통해 커널과 패킷을 교환합니다.

TAP/TUN 인터페이스

TAP 인터페이스는 VPP와 커널 네트워크 스택 간 L2/L3 패킷을 교환하는 가장 일반적인 방법입니다. 커널의 drivers/net/tun.c가 구현합니다.

/* VPP CLI: TAP 인터페이스 생성 */
vpp# create tap id 0 host-if-name vpp-tap0 host-ip4-addr 192.168.1.1/24

/* 호스트에서 확인 */
$ ip addr show vpp-tap0
vpp-tap0: <BROADCAST,MULTICAST,UP> mtu 1500 ...
    inet 192.168.1.1/24 scope global vpp-tap0

/* VPP 측 IP 할당 */
vpp# set interface ip address tap0 192.168.1.2/24
vpp# set interface state tap0 up

vhost-user / virtio

vhost-user는 VM과 VPP 간 고성능 패킷 교환을 위한 메커니즘입니다. 공유 메모리와 virtio 링을 사용하여 데이터 복사 없이 패킷을 전달합니다. 커널의 drivers/vhost/ 서브시스템과 유사한 개념이지만, VPP는 유저스페이스에서 vhost 백엔드를 직접 구현합니다.

/* VPP: vhost-user 인터페이스 생성 (서버 모드) */
vpp# create vhost-user socket /var/run/vpp/sock0.sock server
vpp# set interface state VirtualEthernet0/0/0 up

/* QEMU VM 연결 */
$ qemu-system-x86_64 \
    -chardev socket,id=char0,path=/var/run/vpp/sock0.sock \
    -netdev vhost-user,id=net0,chardev=char0 \
    -device virtio-net-pci,netdev=net0

AF_PACKET

AF_PACKET은 커널의 기존 네트워크 인터페이스를 통해 raw 패킷을 송수신하는 소켓 인터페이스입니다(net/packet/af_packet.c). DPDK처럼 NIC를 독점하지 않으므로 기존 커널 스택과 공존 가능합니다.

/* VPP: AF_PACKET 인터페이스 (커널의 eth1에 연결) */
vpp# create host-interface name eth1
vpp# set interface state host-eth1 up
vpp# set interface ip address host-eth1 10.0.0.1/24

Netlink 연동

VPP의 linux-cp(Linux Control Plane) 플러그인은 Netlink를 통해 커널 라우팅 테이블(Routing Table), ARP 엔트리, 인터페이스 상태를 VPP와 동기화합니다. 이를 통해 커널의 ip route, ip neigh 등의 명령이 VPP에도 반영됩니다.

/* linux-cp 플러그인 활성화 (startup.conf) */
plugins {
    plugin linux_cp_plugin.so { enable }
    plugin linux_cp_unittest_plugin.so { enable }
}

linux-cp {
    default netns dataplane
}

/* VPP CLI: 리눅스 인터페이스 미러링 */
vpp# lcp create tap0 host-if lcp-tap0

linux-cp 플러그인 내부 구현

linux-cp 플러그인의 핵심 개념은 미러링(Mirroring)입니다. VPP의 각 하드웨어 인터페이스에 대응하는 TAP 디바이스를 커널 네트워크 네임스페이스에 생성하고, Netlink 메시지를 통해 양방향으로 상태를 동기화합니다. 이를 통해 VPP가 커널의 라우팅 데몬(FRR, BIRD 등)과 투명하게 연동할 수 있습니다.

linux-cp의 핵심 자료구조는 lcp_itf_pair_t입니다. 이 구조체는 VPP 하드웨어 인터페이스(sw_if_index)와 커널 TAP 인터페이스(host_if_index)의 매핑을 유지합니다. 플러그인이 활성화되면 VPP는 다음 두 방향으로 동기화를 수행합니다:

• VPP → Kernel: VPP의 FIB에 경로가 설치되면 Netlink RTM_NEWROUTE 메시지로 커널 라우팅 테이블에 반영합니다. 이를 통해 ip route show로 VPP 경로를 확인할 수 있습니다.
• Kernel → VPP: 커널에서 FRR 같은 라우팅 데몬이 경로를 설치하면 Netlink 알림을 수신하여 VPP FIB에 반영합니다. ARP/ND 엔트리도 동일하게 동기화됩니다.

linux-cp 설정과 운영

linux-cp 플러그인을 사용하려면 먼저 startup.conf에서 플러그인을 활성화한 후, VPP CLI에서 각 인터페이스에 대한 LCP 쌍(Pair)을 생성해야 합니다.

# 1. startup.conf에 linux-cp 플러그인 활성화
plugins {
    plugin linux_cp_plugin.so { enable }
    plugin linux_cp_unittest_plugin.so { enable }
}

linux-cp {
    default netns dataplane    # LCP 인터페이스가 생성될 네임스페이스
    lcp-sync                   # 커널 → VPP 동기화 활성화
    lcp-auto-subint            # 서브인터페이스 자동 미러링
}

# 2. VPP 시작 후 LCP 쌍 생성
vpp# lcp create GigabitEthernet0/8/0 host-if eth0
vpp# lcp create GigabitEthernet0/9/0 host-if eth1

# 3. 생성된 LCP 쌍 확인
vpp# show lcp
 lcp-pair: [0] GigabitEthernet0/8/0 phy-sw-if-idx 1 host-if eth0 lip-sw-if-idx 3
 lcp-pair: [1] GigabitEthernet0/9/0 phy-sw-if-idx 2 host-if eth1 lip-sw-if-idx 4

# 4. 커널에서 미러 인터페이스 확인
$ ip -n dataplane link show
3: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 ...
4: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 ...

# 5. 커널에서 IP 주소 설정 → VPP에 자동 반영
$ ip -n dataplane addr add 10.0.1.1/24 dev eth0
vpp# show interface addr GigabitEthernet0/8/0
GigabitEthernet0/8/0: 10.0.1.1/24

Netlink 메시지 처리의 내부 흐름은 다음과 같습니다:

/* linux-cp Netlink 수신 처리 의사 코드 */
static void
lcp_nl_route_add (struct nl_msg *msg)
{
    struct rtmsg *rtm = nlmsg_data (nlmsg_hdr (msg));
    fib_prefix_t pfx;
    fib_route_path_t *rpaths = NULL;

    /* 1. Netlink 메시지에서 prefix, gateway, oif 파싱 */
    lcp_nl_mk_prefix (rtm, msg, &pfx);
    lcp_nl_mk_paths (rtm, msg, &rpaths);

    /* 2. host-if index → VPP sw_if_index 변환
     *    LCP 쌍 DB에서 매핑 조회 */
    lcp_nl_remap_paths (rpaths);

    /* 3. VPP FIB에 경로 설치 */
    fib_table_entry_path_add2 (
        fib_index, &pfx,
        FIB_SOURCE_NL,     /* Netlink 소스 표시 */
        FIB_ENTRY_FLAG_NONE,
        rpaths);

    vec_free (rpaths);
}

linux-cp 사용 시나리오

linux-cp 플러그인이 필요한 대표적인 상황은 VPP 라우터에서 표준 리눅스 라우팅 데몬을 실행하는 경우입니다. FRR(Free Range Routing)이나 BIRD 같은 라우팅 소프트웨어는 커널 네트워크 인터페이스와 라우팅 테이블을 통해 동작하므로, VPP의 인터페이스와 경로를 커널에 미러링해야 합니다.

• BGP 라우터: FRR의 bgpd가 BGP 피어와 세션을 맺고, 학습한 경로를 커널 FIB에 설치 → linux-cp가 VPP FIB에 동기화
• OSPF 라우터: FRR의 ospfd가 OSPF 인접 관계를 형성하고 SPF 결과를 커널에 반영 → VPP로 전파
• 관리 평면: ping, traceroute, ssh 등 표준 도구로 VPP 인터페이스 진단
• 모니터링: SNMP, NetFlow 에이전트 등 커널 인터페이스 통계를 읽는 도구 활용

위 구성에서 패킷 흐름은 두 가지 경로로 나뉩니다:

• 데이터 플레인 경로: NIC → dpdk-input → ip4-lookup → ip4-rewrite → NIC (VPP 노드 그래프 처리, 고속)
• 제어 플레인 경로: BGP 패킷(TCP 179)은 lcp-punt 노드에서 TAP으로 전달 → FRR의 bgpd가 수신 → zebra가 경로를 커널 FIB에 설치 → linux-cp가 Netlink로 감지 → VPP FIB에 동기화

host-interface (AF_XDP)

AF_XDP(net/xdp/xsk.c)는 커널 5.4+에서 사용 가능한 고성능 패킷 I/O 인터페이스입니다. eBPF/XDP 프로그램과 연계하여 커널 네트워크 스택을 우회하면서도 NIC 드라이버를 교체할 필요가 없습니다.

/* VPP: AF_XDP 인터페이스 생성 */
vpp# create interface af_xdp host-if eth0 num-rx-queues 4
vpp# set interface state af_xdp-eth0 up

memif 내부 구현 상세

memif(Memory Interface)는 VPP 인스턴스 간 또는 VPP와 사용자 공간 애플리케이션 간의 고성능 패킷 교환을 위해 설계된 공유 메모리 기반 인터페이스입니다. 커널을 완전히 우회하며, 공유 메모리 링 버퍼(Shared Memory Ring Buffer)를 통해 제로 카피(Zero-copy) 방식으로 패킷을 전달합니다.

/* memif 공유 메모리 링 디스크립터 구조 */
typedef struct {
  uint16_t flags;          /* 디스크립터 플래그 (NEXT 체인 등) */
  uint16_t region;         /* 버퍼가 위치한 공유 메모리 리전 인덱스 */
  uint32_t length;         /* 패킷 데이터 길이 (바이트) */
  uint64_t offset;         /* 리전 시작부터 버퍼까지의 오프셋 */
  uint32_t metadata;       /* 사용자 정의 메타데이터 */
} memif_desc_t;

/* 공유 메모리 링 구조 */
typedef struct {
  volatile uint16_t head;  /* 생산자가 증가 (다음 쓰기 위치) */
  volatile uint16_t tail;  /* 소비자가 증가 (다음 읽기 위치) */
  uint16_t cookie;         /* 버전 검증용 매직 값 (0xD00D) */
  uint16_t flags;          /* 링 플래그 (인터럽트 모드 등) */
  memif_desc_t desc[0];    /* 가변 길이 디스크립터 배열 */
} memif_ring_t;

memif 연결 설정과 링 초기화

memif 연결은 마스터/슬레이브(Master/Slave) 모델을 따릅니다. 마스터가 유닉스 도메인 소켓에서 대기하고, 슬레이브가 연결을 시도합니다. 연결이 수립되면 마스터가 공유 메모리 파일(/dev/shm/memif-*)을 생성하고 파일 디스크립터를 SCM_RIGHTS 앵커리 메시지로 슬레이브에게 전달합니다.

# VPP 인스턴스 A (Master)
vpp# create memif socket id 1 filename /run/vpp/memif.sock
vpp# create interface memif id 0 socket-id 1 master \
    ring-size 1024 buffer-size 2048 rx-queues 2 tx-queues 2
vpp# set interface state memif1/0 up
vpp# set interface ip address memif1/0 10.0.0.1/24

# VPP 인스턴스 B (Slave)
vpp# create memif socket id 1 filename /run/vpp/memif.sock
vpp# create interface memif id 0 socket-id 1 slave \
    ring-size 1024 buffer-size 2048 rx-queues 2 tx-queues 2
vpp# set interface state memif1/0 up
vpp# set interface ip address memif1/0 10.0.0.2/24

# 연결 상태 확인
vpp# show memif

AF_XDP 내부 동작 상세

AF_XDP(Address Family XDP)는 리눅스 커널 4.18에서 도입된 소켓 인터페이스로, XDP 프로그램과 사용자 공간 애플리케이션 사이의 고성능 패킷 교환 채널을 제공합니다. 커널 네트워크 스택을 부분적으로 우회하면서도, 커널이 여전히 NIC 드라이버와 하드웨어를 관리하므로 DPDK와 달리 커널의 보안 모델과 자원 관리를 유지합니다.

AF_XDP의 핵심은 4개의 링 버퍼와 1개의 공유 메모리 영역(UMEM)으로 구성된 아키텍처입니다:

• FILL Ring: 사용자 공간이 커널에게 "이 UMEM 프레임에 수신 패킷을 써도 됩니다"라고 알려주는 링입니다
• RX Ring: 커널이 사용자 공간에게 "이 UMEM 프레임에 패킷이 도착했습니다"라고 알려주는 링입니다
• TX Ring: 사용자 공간이 커널에게 "이 UMEM 프레임의 패킷을 전송해 주세요"라고 요청하는 링입니다
• COMPLETION Ring: 커널이 사용자 공간에게 "TX 전송이 완료되었으니 이 UMEM 프레임을 재사용해도 됩니다"라고 알려주는 링입니다

AF_XDP vs DPDK 비교

커널 인터페이스 선택 가이드

주요 기능

L2 브릿징/스위칭

VPP는 커널의 net/bridge/와 유사한 L2 브릿지 도메인을 제공합니다. MAC 학습, 플러딩, BUM(Broadcast/Unknown unicast/Multicast) 트래픽 처리를 지원합니다.

브릿지 도메인 내부적으로 VPP는 해시 기반 MAC 학습 테이블을 유지하며, 각 엔트리는 MAC 주소와 수신 인터페이스(sw_if_index)의 매핑으로 구성됩니다. 학습된 MAC 엔트리에는 에이징 타이머(aging timer)가 적용되어 기본 300초 동안 트래픽이 없으면 자동으로 삭제됩니다. 목적지 MAC이 학습 테이블에 없는 유니캐스트(Unknown Unicast), 브로드캐스트, 멀티캐스트를 통칭하는 BUM 트래픽은 브릿지 도메인 내 모든 멤버 포트로 플러딩(flooding)됩니다. 이때 스플릿 호라이즌 그룹(Split-Horizon Group)을 설정하면 동일 그룹에 속한 포트 간에는 플러딩이 억제되어 루프 방지 및 불필요한 트래픽 전파를 차단할 수 있습니다. BVI(Bridge Virtual Interface)는 브릿지 도메인에 L3 라우팅 기능을 연결하는 가상 인터페이스로, BVI에 IP 주소를 할당하면 해당 브릿지 도메인의 트래픽이 VPP의 라우팅 테이블로 전달됩니다. 이를 통해 동일 브릿지 도메인 내에서 L2 스위칭과 L3 라우팅을 동시에 수행하는 IRB(Integrated Routing and Bridging) 구성이 가능합니다.

/* 브릿지 도메인 생성 및 인터페이스 추가 */
vpp# create bridge-domain 1 learn 1 forward 1 flood 1
vpp# set interface l2 bridge GigabitEthernet0/8/0 1
vpp# set interface l2 bridge GigabitEthernet0/9/0 1
vpp# set interface l2 bridge tap0 1 bvi
vpp# show bridge-domain 1 detail

l2-learn 노드 내부 구현

VPP의 L2 MAC 학습은 l2-learn 노드에서 수행됩니다. 이 노드는 수신 패킷의 소스 MAC 주소(Source MAC)를 추출하여 L2 FIB 해시 테이블에 등록하거나 갱신합니다. quad-loop 패턴을 통해 파이프라인 효율을 극대화합니다.

• 해시 계산: 소스 MAC 주소와 브릿지 도메인 ID를 결합하여 해시 키를 생성합니다
• 엔트리 조회: 해시 테이블에서 기존 엔트리를 검색합니다
• 신규 등록: 엔트리가 없으면 새로 생성하고 sw_if_index, 타임스탬프를 기록합니다
• 갱신: 기존 엔트리가 있으면 타임스탬프를 갱신하고, 포트가 변경되었으면 sw_if_index를 업데이트합니다
• 에이징(Aging): 주기적으로 타임스탬프를 비교하여 일정 시간 동안 갱신되지 않은 엔트리를 삭제합니다

/* src/vnet/l2/l2_learn.c - l2learn_node_inline() 간소화 의사 코드 */
static_always_inline uword
l2learn_node_inline (vlib_main_t *vm,
                      vlib_node_runtime_t *node,
                      vlib_frame_t *frame,
                      int do_trace)
{
  u32 n_left, *from;
  l2learn_main_t *msm = &l2learn_main;
  f64 timestamp = vlib_time_now (vm);

  from = vlib_frame_vector_args (frame);
  n_left = frame->n_vectors;

  /* quad-loop: 4개 패킷 동시 처리 */
  while (n_left >= 8)
    {
      vlib_prefetch_buffer_header (b[4], LOAD);
      vlib_prefetch_buffer_header (b[5], LOAD);
      vlib_prefetch_buffer_header (b[6], LOAD);
      vlib_prefetch_buffer_header (b[7], LOAD);

      for (int i = 0; i < 4; i++)
        {
          ethernet_header_t *eh = vlib_buffer_get_current (b[i]);
          u32 bd_index = vnet_buffer(b[i])->l2.bd_index;
          u32 sw_if_index = vnet_buffer(b[i])->sw_if_index[VLIB_RX];

          /* 소스 MAC + BD 인덱스로 해시 키 생성 */
          l2fib_entry_key_t key;
          l2fib_make_key (eh->src_address, bd_index, &key);

          /* L2 FIB 해시 테이블에서 조회 */
          l2fib_entry_result_t result;
          u32 bucket = l2fib_lookup (msm->mac_table, &key, &result);

          if (PREDICT_FALSE (result.fields.age_not == 0))
            {
              /* 엔트리 없음 → 신규 MAC 학습 */
              l2fib_add_entry (key.raw, bd_index, sw_if_index,
                               L2FIB_ENTRY_RESULT_FLAG_NONE, timestamp);
            }
          else
            {
              result.fields.timestamp = timestamp;
              /* MAC 이동 감지: 포트가 변경된 경우 업데이트 */
              if (PREDICT_FALSE (
                    result.fields.sw_if_index != sw_if_index))
                {
                  result.fields.sw_if_index = sw_if_index;
                  if (result.fields.static_mac)
                    goto skip_update;
                }
              l2fib_update_entry (bucket, &result);
            }
          skip_update:
          vnet_buffer(b[i])->l2.feature_bitmap &= ~L2INPUT_FEAT_LEARN;
        }
      b += 4;
      n_left -= 4;
    }
  /* single-loop: 나머지 1~3개 패킷 처리 */
  while (n_left > 0) { /* ... 동일 로직 ... */ n_left--; }
  return frame->n_vectors;
}

l2-fwd 노드 내부 구현

MAC 학습이 완료된 패킷은 l2-fwd 노드로 전달됩니다. 이 노드는 목적지 MAC 주소를 L2 FIB에서 조회하여 출력 인터페이스를 결정합니다. BUM(Broadcast, Unknown unicast, Multicast) 트래픽은 브릿지 도메인 내 모든 포트로 플러딩됩니다.

/* src/vnet/l2/l2_fwd.c - l2fwd_node_inline() 간소화 의사 코드 */
static_always_inline uword
l2fwd_node_inline (vlib_main_t *vm,
                    vlib_node_runtime_t *node,
                    vlib_frame_t *frame)
{
  u32 n_left, *from, next_index;
  from = vlib_frame_vector_args (frame);
  n_left = frame->n_vectors;

  while (n_left > 0)
    {
      vlib_buffer_t *b0 = vlib_get_buffer (vm, from[0]);
      ethernet_header_t *eh = vlib_buffer_get_current (b0);
      u32 bd_index = vnet_buffer(b0)->l2.bd_index;

      /* 목적지 MAC + BD 인덱스로 L2 FIB 조회 */
      l2fib_entry_key_t key;
      l2fib_make_key (eh->dst_address, bd_index, &key);
      l2fib_entry_result_t result;
      int hit = l2fib_lookup (msm->mac_table, &key, &result);

      if (PREDICT_TRUE (hit))
        {
          if (result.fields.bvi)
            {
              /* BVI 포트 → L3 라우팅으로 전환 (IRB) */
              next_index = L2FWD_NEXT_L2_INPUT_VTR;
            }
          else
            {
              /* 일반 L2 포워딩 */
              next_index = L2FWD_NEXT_L2_OUTPUT;
            }
          vnet_buffer(b0)->sw_if_index[VLIB_TX] =
              result.fields.sw_if_index;

          /* Split-horizon 검사: 동일 그룹이면 드롭 */
          u32 rx_shg = vnet_buffer(b0)->l2.shg;
          if (PREDICT_FALSE (rx_shg != 0 &&
                rx_shg == result.fields.shg))
            next_index = L2FWD_NEXT_DROP;
        }
      else
        {
          /* FIB 미스: BUM 트래픽 → 플러딩 */
          if (ethernet_address_is_multicast (eh->dst_address)
              || ethernet_address_is_broadcast (eh->dst_address))
            next_index = L2FWD_NEXT_FLOOD;
          else
            {
              /* Unknown unicast: BD 설정에 따라 플러딩 또는 드롭 */
              l2_bridge_domain_t *bd =
                  vec_elt_at_index (l2input_main.bd_configs, bd_index);
              if (bd->feature_bitmap & L2INPUT_FEAT_UU_FLOOD)
                next_index = L2FWD_NEXT_FLOOD;
              else
                next_index = L2FWD_NEXT_DROP;
            }
        }
      vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
          to_next, n_left_to_next, from[0], next_index);
      from++;
      n_left--;
    }
  return frame->n_vectors;
}

L2 FIB 해시 테이블 구현

VPP의 L2 FIB는 clib_bihash_8_8(Bounded-index Extensible Hashing) 자료구조를 기반으로 구현됩니다. lock-free 조회를 지원하며 수백만 개의 MAC 엔트리를 관리할 수 있습니다.

L2 패킷 처리 노드 체인

L2 패킷 처리는 노드 그래프 기반으로 동작합니다. BVI를 통한 라우팅 트래픽은 l2-fwd 노드에서 L3 경로로 분기됩니다.

브릿지 도메인 실전 활용 예제

다음은 L2 브릿지 도메인을 생성하고 IRB(Integrated Routing and Bridging)를 구성하는 전체 워크플로우입니다.

# 1. 브릿지 도메인 생성 (BD-ID 100, MAC 에이징 5분)
vpp# create bridge-domain 100 learn 1 forward 1 flood 1 uu-flood 1 mac-age 5

# 2. 물리 인터페이스 추가 (SHG 0)
vpp# set interface l2 bridge GigabitEthernet0/8/0 100 0
vpp# set interface l2 bridge GigabitEthernet0/9/0 100 0

# 3. VXLAN 터널 추가 (SHG 1 — 동일 SHG 간 플러딩 차단)
vpp# create vxlan tunnel src 10.0.0.1 dst 10.0.0.2 vni 1000
vpp# set interface l2 bridge vxlan_tunnel0 100 1

# 4. BVI 인터페이스 생성 (IRB용 L3 게이트웨이)
vpp# bvi create instance 100
vpp# set interface state bvi100 up
vpp# set interface ip address bvi100 192.168.100.1/24
vpp# set interface l2 bridge bvi100 100 bvi

# 5. 인터페이스 활성화 후 확인
vpp# set interface state GigabitEthernet0/8/0 up
vpp# set interface state GigabitEthernet0/9/0 up
vpp# show bridge-domain 100 detail
vpp# show l2fib all

# 6. 정적 MAC / MAC 필터 설정
vpp# l2fib add 00:aa:bb:cc:dd:ee 100 GigabitEthernet0/8/0 static
vpp# l2fib add 00:de:ad:be:ef:00 100 filter

L3 라우팅 (FIB)

VPP의 FIB(Forwarding Information Base)는 mtrie(multi-way trie) 구조를 사용하여 O(1) 시간에 longest-prefix match를 수행합니다. 8-16-8 stride 구조로 최대 3회의 메모리 접근으로 lookup이 완료됩니다.

/* IP 라우팅 설정 */
vpp# ip route add 10.0.0.0/8 via 192.168.1.1
vpp# ip route add 0.0.0.0/0 via 192.168.1.1

/* ECMP (Equal-Cost Multi-Path) */
vpp# ip route add 10.0.0.0/8 via 192.168.1.1 via 192.168.2.1

/* FIB 테이블 확인 */
vpp# show ip fib
vpp# show ip fib table 0 summary

DPO (Data-Path Object) 체인 구현

VPP의 FIB 엔트리는 직접 패킷 처리 동작을 수행하지 않습니다. 대신 DPO(Data-Path Object) 체인을 통해 패킷의 다음 처리 경로를 결정합니다. FIB 엔트리는 항상 load-balance DPO를 가리키며, ECMP(Equal-Cost Multi-Path) 라우팅의 경우 내부에 여러 버킷(Bucket)이 존재하여 각각 서로 다른 adjacency DPO를 가리킵니다.

Adjacency 타입별 구현

Adjacency는 패킷의 L2 rewrite와 출력 인터페이스를 결정하는 핵심 객체입니다. ARP/ND 해석 상태에 따라 여러 타입으로 분류됩니다.

/* DPO 구조체 (src/vnet/dpo/dpo.h) */
typedef struct dpo_id_t_ {
    dpo_type_t dpoi_type;       /* DPO 타입 (adjacency, drop 등) */
    dpo_proto_t dpoi_proto;     /* 프로토콜 (IPv4, IPv6, MPLS) */
    u32 dpoi_index;              /* 타입별 오브젝트 인덱스 */
    u32 dpoi_next_node;          /* 그래프 노드에서의 next index */
} dpo_id_t;

/* Adjacency 구조체 (src/vnet/adj/adj.h) */
typedef struct ip_adjacency_t_ {
    CLIB_CACHE_LINE_ALIGN_MARK(cacheline0);
    u8 rewrite_header[64];     /* L2 rewrite 헤더 (Ethernet 등) */
    u32 sw_if_index;             /* 출력 인터페이스 sw_if_index */
    adj_type_t lookup_next_index; /* adjacency 타입 */
    ip46_address_t next_hop;     /* next-hop IP 주소 */
    u32 n_adj;                   /* 참조 카운트 */
} ip_adjacency_t;

FIB 경로 해석 실전 예제

# ECMP 경로 추가
vpp# ip route add 10.0.100.0/24 via 192.168.1.254 GigabitEthernet0/0/0 \
                                via 192.168.2.254 GigabitEthernet0/0/1

# FIB 엔트리 확인 — DPO 체인 표시
vpp# show ip fib 10.0.100.0/24
  10.0.100.0/24
    unicast-ip4-chain
    [@0]: dpo-load-balance: [proto:ip4 index:22 buckets:2 uRPF:28]
      [0] [@5]: ipv4 via 192.168.1.254 GigE0/0/0: rewrite-adj-idx:24
      [1] [@5]: ipv4 via 192.168.2.254 GigE0/0/1: rewrite-adj-idx:25

# Adjacency 상세 확인
vpp# show adjacency 24
  [@24] ipv4 via 192.168.1.254 GigE0/0/0:
    rewrite: [dst:00:00:5e:00:01:01 src:de:ad:be:ef:00:01 ethertype:0800]
    flags: rewrite  share-count: 1

# Adjacency incomplete 진단 (ARP 미해석)
vpp# show ip fib 10.0.200.0/24
  10.0.200.0/24
      [0] [@0]: ipv4 via 192.168.3.254 GigE0/0/2: ** INCOMPLETE **

# 수동 ARP 엔트리 추가로 해결
vpp# set ip neighbor GigabitEthernet0/0/2 192.168.3.254 00:11:22:33:44:55

ACL

VPP의 ACL 플러그인(acl_plugin.so)은 커널의 Netfilter/nftables에 대응하는 고성능 패킷 필터링 엔진입니다. 이 플러그인은 두 가지 동작 모드를 제공합니다. Stateless 모드는 각 패킷을 독립적으로 5-tuple(소스 IP, 목적지 IP, 프로토콜, 소스 포트, 목적지 포트) 기반으로 규칙 테이블과 매칭하여 permit 또는 deny 결정을 내립니다. Stateful 모드는 세션 기반 연결 추적(Connection Tracking)을 수행하며, 첫 번째 패킷이 규칙에 매칭되면 해당 연결의 세션 항목을 세션 테이블에 생성합니다. 이후 동일 연결에 속하는 패킷은 규칙 테이블을 다시 순회하지 않고 세션 테이블에서 직접 조회하여 빠르게 처리합니다.

Reflexive ACL은 stateful 모드의 핵심 기능으로, 아웃바운드 트래픽에 대한 허용 규칙이 존재하면 그에 대응하는 인바운드 응답 트래픽을 자동으로 허용합니다. 이를 통해 명시적인 양방향 규칙 없이도 양방향 통신이 가능합니다. 플러그인은 acl-plugin-in-ip4-fa와 acl-plugin-out-ip4-fa 피처 노드를 통해 인터페이스의 입력(input) 및 출력(output) 경로에 각각 삽입되며, 패킷 그래프 내에서 인라인으로 실행됩니다.

/* ACL 규칙 생성 */
vpp# set acl-plugin acl permit src 192.168.1.0/24 dst 10.0.0.0/8 \
     proto 6 sport 1024-65535 dport 80

/* 인터페이스에 적용 */
vpp# set acl-plugin interface GigabitEthernet0/8/0 input acl 0
vpp# show acl-plugin acl

NAT44/NAT64

/* NAT44: 내부 → 외부 주소 변환 */
vpp# nat44 add interface address GigabitEthernet0/8/0
vpp# set interface nat44 in GigabitEthernet0/9/0 out GigabitEthernet0/8/0

/* 정적 매핑 (DNAT) */
vpp# nat44 add static mapping local 192.168.1.100 22 \
     external GigabitEthernet0/8/0 2222 tcp

/* 세션 확인 */
vpp# show nat44 sessions

NAT44 ED 세션 생성 내부 구현

NAT44 Endpoint-Dependent(ED) 모드에서 첫 번째 패킷이 도착하면, VPP는 slow path를 통해 세션을 생성합니다. 이 과정은 5-tuple 해시 계산, 외부 포트 할당, 양방향 세션 엔트리 삽입의 세 단계로 구성됩니다.

ED 모드의 핵심은 목적지 주소와 포트까지 포함한 5-tuple을 세션 키로 사용하는 점입니다. 이를 통해 동일한 내부 호스트가 서로 다른 외부 목적지에 대해 동일한 외부 포트를 재사용할 수 있으므로, 포트 고갈 문제를 크게 완화할 수 있습니다.

/* nat44_ed_in2out_node_fn_inline() 간략화 의사 코드 */
static_always_inline uword
nat44_ed_in2out_node_fn_inline (vlib_main_t *vm,
                                  vlib_node_runtime_t *node,
                                  vlib_frame_t *frame,
                                  int is_slow_path)
{
  snat_main_t *sm = &snat_main;
  snat_session_t *s0 = 0;
  u32 n_left_from, *from;

  from = vlib_frame_vector_args (frame);
  n_left_from = frame->n_vectors;

  while (n_left_from > 0)
  {
    vlib_buffer_t *b0;
    ip4_header_t *ip0;
    clib_bihash_kv_16_8_t kv0, value0;

    /* 1단계: 패킷 버퍼에서 IP 헤더 추출 */
    b0 = vlib_get_buffer (vm, from[0]);
    ip0 = vlib_buffer_get_current (b0);

    /* 2단계: 5-tuple + fib_index로 해시 키 구성 */
    make_ed_kv (&kv0,
                &ip0->src_address,     /* 소스 IP */
                &ip0->dst_address,     /* 목적지 IP */
                ip0->protocol,          /* 프로토콜 */
                rx_fib_index,           /* FIB 인덱스 */
                src_port, dst_port);

    /* 3단계: bihash 조회 — 기존 세션 검색 */
    if (clib_bihash_search_16_8 (
          &sm->flow_hash, &kv0, &value0) == 0)
    {
      /* Fast path: 세션 발견 → 변환 적용 */
      s0 = pool_elt_at_index (
              tsm->sessions, ed_value_get_session_index (&value0));
      nat44_ed_session_reopen_last_heard (s0, now);
    }
    else if (is_slow_path)
    {
      /* Slow path: 세션 미발견 → 새 세션 생성 */

      /* 4단계: 외부 주소/포트 할당 */
      if (nat44_ed_alloc_addr_and_port (
            sm, rx_fib_index, tx_sw_if_index,
            nat_proto, thread_index,
            &outside_addr, &outside_port,
            ip0->dst_address, dst_port))
      {
        /* 포트 할당 실패 → 패킷 드롭 */
        next0 = NAT_NEXT_DROP;
        goto trace0;
      }

      /* 5단계: 세션 구조체 할당 및 초기화 */
      s0 = nat_ed_session_alloc (sm, thread_index, now,
                                  ip0->protocol);

      /* 6단계: in2out, out2in 양방향 해시 엔트리 삽입 */
      s0->in2out.addr = ip0->src_address;
      s0->in2out.port = src_port;
      s0->out2in.addr = outside_addr;
      s0->out2in.port = outside_port;
      s0->ext_host_addr = ip0->dst_address;
      s0->ext_host_port = dst_port;

      nat_ed_session_create (sm, s0, thread_index,
                             rx_fib_index, tx_fib_index);
    }

    /* 7단계: IP 헤더 소스 주소/포트 변환 */
    ip0->src_address = s0->out2in.addr;
    nat44_ed_rewrite_tcp_udp (b0, ip0, s0);
    ip0->checksum = ip4_header_checksum (ip0);

    n_left_from--;
    from++;
  }
  return frame->n_vectors;
}

NAT44 세션 생명주기

NAT44 ED 해시 테이블 구현

VPP의 NAT44 ED 모드는 clib_bihash_16_8(16바이트 키, 8바이트 값) 자료 구조를 사용하여 세션을 관리합니다. 락프리 읽기를 지원하며, 멀티 스레드 환경에서 높은 성능을 제공합니다.

/* ED 모드 해시 키 구성 함수 */
static_always_inline void
make_ed_kv (clib_bihash_kv_16_8_t *kv,
            ip4_address_t *l_addr, ip4_address_t *r_addr,
            u8 proto, u32 fib_index,
            u16 l_port, u16 r_port)
{
  /* 상위 8바이트: 소스 IP(4) + 목적지 IP(4) */
  kv->key[0] = (u64) l_addr->as_u32 << 32 | r_addr->as_u32;

  /* 하위 8바이트: 소스 포트(2) + 목적지 포트(2) + proto(1) + fib(3) */
  kv->key[1] = (u64) l_port << 48 |
               (u64) r_port << 32 |
               (u64) proto  << 24 |
               (u64) fib_index;
}

/* 해시 조회 및 세션 포인터 획득 */
static_always_inline int
nat44_ed_find_session (snat_main_t *sm,
                       clib_bihash_kv_16_8_t *kv,
                       snat_session_t **s)
{
  clib_bihash_kv_16_8_t value;

  /* 락프리 해시 조회 (읽기 경로) */
  if (clib_bihash_search_16_8 (&sm->flow_hash, kv, &value))
    return -1;  /* 세션 미발견 */

  /* 값에서 스레드/세션 인덱스 추출 */
  u32 thread_idx = ed_value_get_thread_index (&value);
  u32 session_idx = ed_value_get_session_index (&value);

  /* per-thread 세션 풀에서 세션 포인터 획득 */
  snat_main_per_thread_data_t *tsm =
      vec_elt_at_index (sm->per_thread_data, thread_idx);
  *s = pool_elt_at_index (tsm->sessions, session_idx);
  return 0;
}

NAT44 포트 할당 전략

VPP는 예측 가능한 포트 할당을 방지하기 위해 무작위 포트 선택 알고리즘을 사용합니다.

/* nat44_ed_alloc_addr_and_port() 간략화 */
static_always_inline int
nat44_ed_alloc_addr_and_port (snat_main_t *sm,
                              u32 rx_fib_index, u32 nat_proto,
                              u32 thread_index,
                              ip4_address_t *outside_addr,
                              u16 *outside_port,
                              ip4_address_t dst_addr, u16 dst_port)
{
  snat_address_t *a;
  u16 port, attempts;
  u32 portrange;

  /* 사용 가능한 외부 주소 풀 순회 */
  vec_foreach (a, sm->addresses)
  {
    portrange = a->port_range_end - a->port_range_start + 1;

    /* 무작위 시작점에서 포트 탐색 */
    port = a->port_range_start +
           (random_u32 (&sm->random_seed) % portrange);

    for (attempts = 0; attempts < portrange; attempts++)
    {
      /* ED 모드: 목적지까지 포함하여 충돌 검사 */
      clib_bihash_kv_16_8_t kv;
      make_ed_kv (&kv, &a->addr, &dst_addr,
                  nat_proto, rx_fib_index,
                  clib_host_to_net_u16 (port), dst_port);

      /* bihash에 동일 키가 없으면 → 포트 사용 가능 */
      if (clib_bihash_search_16_8 (&sm->flow_hash, &kv, &kv))
      {
        *outside_addr = a->addr;
        *outside_port = clib_host_to_net_u16 (port);
        return 0;  /* 성공 */
      }

      /* 충돌: 다음 포트로 이동 (wrap-around) */
      port++;
      if (port > a->port_range_end)
        port = a->port_range_start;
    }
  }
  return 1;  /* 모든 주소/포트 소진 → 할당 실패 */
}

# 포트 사용량 확인
vppctl show nat44 addresses
# 출력 예시:
# 203.0.113.10  TCP in use: 48721, UDP in use: 12043

# 포트 고갈 에러 카운터 확인
vppctl show errors | grep out_of_ports

# 전체 세션 수 확인
vppctl show nat44 sessions count

IPsec

VPP의 IPsec 구현은 크게 ESP 터널 모드(Tunnel Mode)와 전송 모드(Transport Mode) 두 가지를 지원합니다. 터널 모드에서는 원본 IP 패킷 전체를 새로운 IP 헤더로 감싸서 암호화하며, 전송 모드에서는 원본 IP 헤더를 유지한 채 페이로드(Payload)만 암호화합니다. IPsec의 핵심 데이터 구조는 SA(Security Association)와 SPD(Security Policy Database)입니다. SA는 암호화 알고리즘, 키, SPI(Security Parameter Index), 터널 엔드포인트 등 보안 매개변수를 정의하며, SPD는 트래픽 셀렉터(소스/목적지 IP 범위, 포트, 프로토콜)를 기반으로 어떤 SA를 적용할지 또는 패킷을 통과/차단할지 결정하는 정책을 담고 있습니다.

아웃바운드 처리에서는 평문 패킷이 SPD 룩업을 거쳐 매칭되는 정책의 SA를 선택하고, ESP 캡슐화(헤더/트레일러(Trailer) 추가) 후 암호화를 수행한 뒤 ip4-rewrite 노드를 통해 전송합니다. 인바운드 처리에서는 수신된 암호화 패킷의 SPI를 기반으로 SA를 조회하여 복호화하고, ESP 디캡슐화를 수행한 뒤 SPD 정책 검증을 통과하면 내부 네트워크로 포워딩합니다.

VPP는 크립토 엔진 선택 프레임워크를 제공하여, 동일한 IPsec 파이프라인에서 소프트웨어 구현(native, OpenSSL, ipsecmb)과 하드웨어 가속(DPDK Cryptodev, Intel QAT)을 플러그인 방식으로 교체할 수 있습니다. 또한 비동기 크립토 프레임워크(Async Crypto Framework)를 통해 암호화/복호화 작업을 별도의 워커 스레드나 하드웨어 큐에 오프로드하여 메인 패킷 처리 루프의 지연을 최소화합니다. DPDK Cryptodev 통합 시에는 dpdk_cryptodev 플러그인을 로드하고, set crypto handler CLI로 엔진 우선순위를 지정하여 특정 알고리즘에 대해 하드웨어 가속을 활성화할 수 있습니다.

/* IPsec 터널 모드 설정 */
vpp# ipsec sa add 10 spi 1001 esp crypto-alg aes-gcm-256 \
     crypto-key 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef \
     tunnel src 10.0.0.1 dst 10.0.0.2

vpp# ipsec sa add 20 spi 1002 esp crypto-alg aes-gcm-256 \
     crypto-key fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210 \
     tunnel src 10.0.0.2 dst 10.0.0.1

vpp# ipsec policy add spd 1 priority 100 outbound action protect \
     sa 10 local-ip-range 192.168.1.0 - 192.168.1.255 \
     remote-ip-range 192.168.2.0 - 192.168.2.255

IPsec Policy 기반 vs Route 기반

VPP는 IPsec 트래픽 선택 방식으로 Policy 기반(정책 기반)과 Route 기반(라우팅 기반) 두 가지를 모두 지원합니다. 전통적인 IPsec 구현은 Policy 기반이 기본이지만, 대규모 네트워크에서는 Route 기반이 유연성과 확장성 면에서 유리합니다.

Policy-based IPsec (정책 기반)

정책 기반 IPsec은 SPD(Security Policy Database)에 등록된 정책 규칙으로 트래픽을 선택합니다. 각 정책은 5-tuple(출발지 IP, 목적지 IP, 프로토콜, 출발지 포트, 목적지 포트) 매칭 조건을 가지며, 매칭된 패킷에 대해 PROTECT(암호화), BYPASS(통과), DISCARD(폐기) 중 하나의 동작을 수행합니다.

/* SPD(Security Policy Database) 구조체 - src/vnet/ipsec/ipsec_spd.h */
typedef struct {
  u32 id;                          /* SPD 식별자 */
  u32 *policies[IPSEC_SPD_POLICY_N_TYPES]; /* 정책 타입별 인덱스 배열 */
  /* IPSEC_SPD_POLICY_IP4_OUTBOUND, IPSEC_SPD_POLICY_IP4_INBOUND 등 */
} ipsec_spd_t;

/* 개별 정책 항목 - src/vnet/ipsec/ipsec_spd_policy.h */
typedef struct {
  u32 id;                          /* 정책 ID */
  i32 priority;                    /* 우선순위 (높을수록 먼저 매칭) */

  /* 5-tuple 매칭 조건 */
  ip46_address_t laddr_start;      /* 로컬 IP 범위 시작 */
  ip46_address_t laddr_stop;       /* 로컬 IP 범위 끝 */
  ip46_address_t raddr_start;      /* 원격 IP 범위 시작 */
  ip46_address_t raddr_stop;       /* 원격 IP 범위 끝 */
  u16 lport_start, lport_stop;     /* 로컬 포트 범위 */
  u16 rport_start, rport_stop;     /* 원격 포트 범위 */
  u8 protocol;                     /* IP 프로토콜 번호 */

  ipsec_policy_action_t policy;    /* PROTECT | BYPASS | DISCARD */
  u32 sa_id;                       /* PROTECT 시 사용할 SA 식별자 */
} ipsec_policy_t;

Outbound 패킷 처리 시 ipsec-output-ip4 노드가 SPD를 검색하여 매칭되는 정책을 찾습니다. 정책 검색은 우선순위가 높은 항목부터 순차적으로 5-tuple 비교를 수행하며, 첫 번째 매칭 정책의 동작을 적용합니다. Inbound에서는 복호화 후 ipsec-input-ip4 노드가 SPD inbound 정책과 대조하여 허용 여부를 판정합니다.

/* SPD 정책 설정 CLI 예시 */
/* 인터페이스에 SPD 바인딩 */
vpp# ipsec spd add 1
vpp# set interface ipsec spd GigabitEthernet0/8/0 1

/* outbound 정책: 192.168.1.0/24 → 192.168.2.0/24 트래픽 보호 */
vpp# ipsec policy add spd 1 priority 100 outbound action protect \
     sa 10 local-ip-range 192.168.1.0 - 192.168.1.255 \
     remote-ip-range 192.168.2.0 - 192.168.2.255

/* inbound 정책: 반대 방향 트래픽 허용 */
vpp# ipsec policy add spd 1 priority 100 inbound action protect \
     sa 20 local-ip-range 192.168.2.0 - 192.168.2.255 \
     remote-ip-range 192.168.1.0 - 192.168.1.255

Route-based IPsec (라우팅 기반)

라우팅 기반 IPsec은 create ipsec tunnel CLI로 가상 터널 인터페이스(ipsecN)를 생성하고, FIB 라우팅 테이블의 경로 설정을 통해 트래픽을 선택합니다. 이 방식에서는 SPD 정책 대신 일반 IP 라우팅이 트래픽을 IPsec 터널로 전달하므로, BGP나 OSPF 같은 동적 라우팅 프로토콜과 자연스럽게 통합됩니다.

/* IPsec 터널 인터페이스 구조체 - src/vnet/ipsec/ipsec_tun.h */
typedef struct {
  u32 input_sa_id;                 /* inbound SA 식별자 */
  u32 output_sa_id;                /* outbound SA 식별자 */
  u32 hw_if_index;                 /* 하드웨어 인터페이스 인덱스 */
  u32 sw_if_index;                 /* 소프트웨어 인터페이스 인덱스 */
  ip46_address_t tunnel_src;       /* 터널 출발지 IP */
  ip46_address_t tunnel_dst;       /* 터널 목적지 IP */
} ipsec_tunnel_if_t;

/* Route 기반 IPsec 설정 CLI 예시 */
/* IPsec 터널 인터페이스 생성 (SA 자동 연결) */
vpp# create ipsec tunnel local-ip 10.0.0.1 remote-ip 10.0.0.2 \
     local-spi 1001 remote-spi 1002 \
     local-crypto-key 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef \
     remote-crypto-key fedcba9876543210fedcba9876543210fedcba9876543210fedcba9876543210 \
     crypto-alg aes-gcm-256

/* 터널 인터페이스 활성화 */
vpp# set interface state ipsec0 up
vpp# set interface ip address ipsec0 172.16.0.1/30

/* FIB 라우팅으로 트래픽 선택 (SPD 불필요) */
vpp# ip route add 192.168.2.0/24 via 172.16.0.2 ipsec0

/* 동적 라우팅 프로토콜과 통합 가능 */
/* BGP neighbor가 ipsec0 인터페이스를 통해 경로를 교환 */

Policy vs Route 방식 비교

ipsec_sa_t 구조체와 ESP 노드 그래프

VPP의 IPsec 구현에서 가장 핵심적인 데이터 구조는 ipsec_sa_t(Security Association)입니다. 이 구조체는 암호화 알고리즘, 키, 터널 엔드포인트, 시퀀스 번호 등 ESP 처리에 필요한 모든 상태를 담고 있습니다.

ipsec_sa_t 핵심 필드 분석

/* Security Association 핵심 구조체 - src/vnet/ipsec/ipsec_sa.h */
typedef struct {
  u32 id;                          /* SA 식별자 */
  u32 spi;                         /* Security Parameter Index (네트워크 바이트 순서) */
  u32 stat_index;                  /* 통계 카운터 인덱스 */

  /* 암호화 설정 */
  ipsec_crypto_alg_t crypto_alg;   /* AES-CBC-128/256, AES-GCM-128/256 등 */
  ipsec_key_t crypto_key;          /* 암호화 키 (최대 32바이트) */
  u8 crypto_iv_size;               /* 초기화 벡터 크기 */
  u8 crypto_block_size;            /* 블록 암호 크기 */

  /* 무결성 검증 설정 (AES-GCM은 AEAD이므로 별도 불필요) */
  ipsec_integ_alg_t integ_alg;     /* SHA1-96, SHA-256-128 등 */
  ipsec_key_t integ_key;           /* 무결성 키 */
  u8 integ_icv_size;               /* ICV(Integrity Check Value) 크기 */

  /* 터널 모드 엔드포인트 */
  ip46_address_t tunnel_src_addr;  /* 터널 출발지 IP */
  ip46_address_t tunnel_dst_addr;  /* 터널 목적지 IP */

  /* 시퀀스 번호 (ESN: Extended Sequence Number 지원) */
  u32 seq;                         /* 하위 32비트 시퀀스 번호 */
  u32 seq_hi;                      /* 상위 32비트 (ESN 활성 시) */
  u64 last_seq;                    /* 수신 측 마지막 시퀀스 번호 */
  u64 replay_window;               /* anti-replay 윈도우 비트맵 (64비트) */

  /* 플래그 (동작 모드 제어) */
  ipsec_sa_flags_t flags;
#define IPSEC_SA_FLAG_IS_TUNNEL       (1 << 0)  /* 터널 모드 */
#define IPSEC_SA_FLAG_USE_ESN         (1 << 1)  /* 확장 시퀀스 번호 */
#define IPSEC_SA_FLAG_USE_ANTI_REPLAY (1 << 2)  /* anti-replay 검사 */
#define IPSEC_SA_FLAG_UDP_ENCAP       (1 << 4)  /* NAT-T UDP 캡슐화 */
#define IPSEC_SA_FLAG_IS_INBOUND      (1 << 6)  /* inbound SA */

  /* 암호 엔진 연동 */
  vnet_crypto_op_id_t crypto_enc_op_id;  /* 암호화 연산 ID */
  vnet_crypto_op_id_t crypto_dec_op_id;  /* 복호화 연산 ID */
  vnet_crypto_op_id_t integ_op_id;       /* 무결성 연산 ID */
  vnet_crypto_key_index_t crypto_key_index; /* 키 인덱스 */
  vnet_crypto_key_index_t integ_key_index;  /* 무결성 키 인덱스 */
} ipsec_sa_t;

Anti-replay 메커니즘은 재전송 공격을 방어하기 위한 핵심 기능입니다. 수신 측은 64비트 슬라이딩 윈도우 비트맵(Bitmap)(replay_window)을 유지하며, 이미 수신한 시퀀스 번호의 패킷을 탐지하여 폐기합니다. last_seq는 윈도우의 우측 경계(가장 최근 수신된 시퀀스 번호)를 나타내며, 윈도우 범위 밖의 오래된 패킷도 폐기됩니다. ESN(Extended Sequence Number) 사용 시 64비트 시퀀스 공간을 활용하여 고속 링크에서의 시퀀스 번호 고갈 문제를 해결합니다.

ESP 그래프 노드 상세

VPP의 ESP 처리는 그래프 노드 체인을 통해 이루어집니다. Outbound(송신)와 Inbound(수신) 경로는 각각 별도의 노드 체인을 구성하며, 각 노드가 ESP 프로토콜의 특정 단계를 담당합니다.

Outbound 경로에서 패킷은 ip4-output에서 시작하여 ipsec-output-ip4 노드가 SPD 정책 또는 터널 인터페이스를 통해 암호화 대상 여부를 판별합니다. 대상 패킷은 esp4-encrypt 노드로 전달되어 ESP 헤더 생성, IV 삽입, 패딩, 암호화, ICV 계산을 수행한 후 ip4-rewrite를 거쳐 물리 인터페이스로 전송됩니다.

Inbound 경로에서는 ip4-local 노드가 ESP 프로토콜(IP 프로토콜 번호 50)을 감지하면 esp4-decrypt 노드로 전달합니다. Route 기반 IPsec의 경우 ipsec-if-input 노드가 터널 인터페이스별 SA를 먼저 매칭합니다. 복호화 노드에서는 SPI로 SA를 검색하고, anti-replay 검사, ICV 검증, 복호화, 패딩 제거, 디캡슐화를 순차적으로 수행한 후 내부 패킷을 ip4-input으로 재주입합니다.

esp4-encrypt 처리 의사 코드

/* esp4-encrypt 노드 벡터 처리 의사 코드 */
static uword
esp_encrypt_inline (vlib_main_t *vm, vlib_node_runtime_t *node,
                    vlib_frame_t *frame, int is_ip6)
{
  u32 n_left = frame->n_vectors;
  vlib_buffer_t **b = bufs;

  while (n_left > 0)
  {
    ipsec_sa_t *sa = ipsec_sa_get (sa_index);

    /* 1단계: 시퀀스 번호 할당 및 증가 */
    u32 seq = clib_atomic_fetch_add (&sa->seq, 1);
    u32 seq_hi = sa->seq_hi; /* ESN 상위 32비트 */

    /* 2단계: 패딩 크기 계산 (블록 크기 정렬) */
    u8 pad_len = (sa->crypto_block_size -
                  (payload_len + 2) % sa->crypto_block_size)
                 % sa->crypto_block_size;

    /* 3단계: ESP 헤더 삽입 */
    esp_header_t *esp = (esp_header_t *) payload_start;
    esp->spi = sa->spi;       /* 네트워크 바이트 순서 */
    esp->seq = clib_host_to_net_u32 (seq);

    /* 4단계: IV 생성 및 삽입 */
    u8 *iv = (u8 *)(esp + 1);
    if (sa->crypto_alg == IPSEC_CRYPTO_ALG_AES_GCM_256)
      *(u64 *)iv = clib_host_to_net_u64 (sa->gcm_iv_counter++);

    /* 5단계: ESP 트레일러 구성 (패딩 + pad_length + next_header) */
    u8 *padding = payload_end;
    for (int i = 0; i < pad_len; i++)
      padding[i] = i + 1;     /* RFC 4303 패딩 패턴 */
    padding[pad_len] = pad_len;
    padding[pad_len + 1] = next_hdr; /* 원본 프로토콜 번호 */

    /* 6단계: vnet_crypto를 통한 암호화 연산 큐잉 */
    vnet_crypto_op_t *op = crypto_ops + n_ops++;
    op->op = sa->crypto_enc_op_id;
    op->src = op->dst = payload;
    op->len = payload_len + pad_len + 2;
    op->key_index = sa->crypto_key_index;
    op->iv = iv;

    /* AEAD(AES-GCM): AAD = ESP 헤더, 태그 = ICV */
    if (is_aead) {
      op->aad = (u8 *)esp;
      op->aad_len = 8; /* SPI(4) + Seq(4) */
      op->tag = payload_end + pad_len + 2;
      op->tag_len = sa->integ_icv_size;
    }

    /* 7단계: 터널 모드 시 외부 IP 헤더 추가 */
    if (sa->flags & IPSEC_SA_FLAG_IS_TUNNEL) {
      ip4_header_t *oh = vlib_buffer_push_ip4 (vm, b[0],
          &sa->tunnel_src_addr.ip4,
          &sa->tunnel_dst_addr.ip4,
          IP_PROTOCOL_IPSEC_ESP, 1);
    }

    n_left--;
    b++;
  }

  /* 배치 암호화 실행 (DPDK cryptodev 또는 OpenSSL) */
  vnet_crypto_process_ops (vm, crypto_ops, n_ops);
}

위 의사 코드에서 핵심적인 부분은 vnet_crypto_process_ops() 호출입니다. VPP는 개별 패킷마다 암호화를 수행하지 않고, 벡터의 모든 패킷에 대한 암호화 연산을 배치로 모아 한 번에 실행합니다. 이 방식은 CPU 캐시 효율성을 높이고, 하드웨어 가속기(Intel QAT 등)의 배치 처리 성능을 최대로 활용합니다. AES-GCM과 같은 AEAD 알고리즘 사용 시 암호화와 무결성 검증이 단일 연산으로 수행되어 별도의 HMAC 계산이 불필요합니다.

IKEv2 플러그인 내부 구현

VPP의 IKEv2 플러그인(src/plugins/ikev2/)은 IKEv2(RFC 7296) 프로토콜을 사용자 공간에서 직접 구현합니다. 이 플러그인은 IPsec SA를 동적으로 생성·갱신·삭제하는 키 관리 데몬 역할을 수행하며, VPP의 그래프 노드 구조에 통합되어 IKE 패킷을 벡터 처리 파이프라인에서 직접 수신합니다.

IKE SA 상태 머신은 다음과 같은 전이를 따릅니다. 초기 상태에서 IKE_SA_INIT 교환을 통해 Diffie-Hellman 공유 비밀을 수립하고, IKE_AUTH 교환으로 상호 인증을 완료하면 ESTABLISHED 상태에 진입합니다. 이후 SA의 수명이 만료에 가까워지면 REKEYING 상태로 전환하여 새로운 키를 협상하고, SA 삭제 시 DELETED 상태로 전이합니다.

• IKE_SA_INIT: Diffie-Hellman 교환 수행, Ni(Initiator Nonce)와 Nr(Responder Nonce) 교환, 암호 스위트 협상이 이루어집니다.
• IKE_AUTH: 암호화된 채널에서 신원 인증(PSK 또는 인증서) 수행, 첫 번째 Child SA(IPsec SA) 생성이 포함됩니다.
• ESTABLISHED: IKE SA가 활성 상태이며, CREATE_CHILD_SA 교환으로 추가 Child SA 생성 또는 리키잉이 가능합니다.
• REKEYING: 기존 SA의 수명 만료 전에 새로운 키 재료를 협상합니다. 완료 후 기존 SA는 삭제됩니다.
• DELETED: INFORMATIONAL 교환의 Delete 페이로드로 SA가 삭제된 상태입니다.

ikev2_sa_t 구조체는 IKE SA의 전체 상태를 관리합니다. 핵심 필드로는 양측의 식별자(i_id, r_id), DH 교환에 사용된 난스 값(i_nonce, r_nonce), 도출된 키 집합(keys), 그리고 이 IKE SA 하에서 생성된 Child SA 배열(child_sa[])이 포함됩니다.

/* IKEv2 SA 구조체 핵심 필드 (src/plugins/ikev2/ikev2_priv.h 기반) */
typedef struct {
  /* SA 식별 */
  u64 ispi;                        /* Initiator SPI (8바이트) */
  u64 rspi;                        /* Responder SPI (8바이트) */
  ikev2_state_t state;             /* SA 상태 머신 현재 상태 */

  /* 신원 식별자 */
  ikev2_id_t i_id;                 /* Initiator 식별자 (FQDN, IP, 이메일 등) */
  ikev2_id_t r_id;                 /* Responder 식별자 */

  /* 난스(Nonce) — 키 도출의 신선도 보장 */
  u8 *i_nonce;                     /* Initiator Nonce (최소 16, 최대 256바이트) */
  u8 *r_nonce;                     /* Responder Nonce */

  /* Diffie-Hellman 교환 */
  ikev2_dh_group_t dh_group;       /* 협상된 DH 그룹 (14, 19, 20 등) */
  u8 *dh_shared_key;               /* DH 공유 비밀 */
  u8 *dh_private_key;              /* DH 개인 키 (Initiator만 보유) */

  /* 도출된 키 집합 */
  ikev2_sa_keys_t keys;            /* SK_d, SK_ai/ar, SK_ei/er, SK_pi/pr */

  /* 암호 스위트 */
  ikev2_sa_transform_t *transforms; /* 협상된 ENCR, PRF, INTEG, DH */

  /* Child SA (IPsec SA) 배열 */
  ikev2_child_sa_t *childs;        /* vec — 이 IKE SA 하의 모든 Child SA */

  /* 수명 관리 */
  f64 time_to_expiration;          /* SA 만료까지 남은 시간 */
  f64 last_sa_init_req_packet_data; /* 재전송 타이머 */
  u8 initial_contact;              /* INITIAL_CONTACT 알림 수신 여부 */
} ikev2_sa_t;

키 도출 과정은 RFC 7296 Section 2.14에 정의된 절차를 따릅니다. IKE_SA_INIT 교환에서 수립된 DH 공유 비밀과 양측 난스를 사용하여 SKEYSEED를 계산한 뒤, PRF+(Pseudo-Random Function Plus) 확장으로 7개의 세션 키를 도출합니다.

• SKEYSEED = PRF(Ni | Nr, DH_shared_secret): 마스터 시드 키입니다.
• SK_d: Child SA 키 도출에 사용되는 파생 키입니다.
• SK_ai, SK_ar: IKE 메시지 무결성 검증 키(Initiator/Responder)입니다.
• SK_ei, SK_er: IKE 메시지 암호화 키(Initiator/Responder)입니다.
• SK_pi, SK_pr: IKE AUTH 페이로드 생성 키(Initiator/Responder)입니다.

Child SA 생성 시에는 SK_d와 새로운 난스를 사용하여 IPsec SA용 암호화/무결성 키를 별도로 도출합니다. 이 분리 구조 덕분에 IKE SA를 유지한 채 Child SA만 독립적으로 리키잉할 수 있습니다.

/* IKE_SA_INIT 응답 처리 — Responder 측 (간략화된 의사 코드) */
static int
ikev2_process_sa_init_resp (ikev2_sa_t *sa,
                            ike_header_t *ike,
                            u8 *sa_payload,
                            u8 *ke_payload,
                            u8 *nonce_payload)
{
  /* 1단계: 응답 페이로드 파싱 */
  sa->rspi = ike->rspi;
  sa->r_nonce = ikev2_parse_nonce (nonce_payload);
  sa->dh_shared_key = ikev2_calc_dh_shared_key (
      sa->dh_group, ke_payload, sa->dh_private_key);

  /* 2단계: SKEYSEED 도출 */
  u8 *nonce_concat = vec_concat (sa->i_nonce, sa->r_nonce);
  u8 *skeyseed = ikev2_calc_prf (
      nonce_concat, sa->dh_shared_key);  /* PRF(Ni|Nr, g^ir) */

  /* 3단계: PRF+ 확장으로 7개 키 도출 */
  /* S = Ni | Nr | SPIi | SPIr */
  u8 *s_material = format (0, "%v%v%U%U",
      sa->i_nonce, sa->r_nonce,
      format_u64, sa->ispi,
      format_u64, sa->rspi);

  u8 *keymat = ikev2_calc_prfplus (
      skeyseed, s_material,
      /* 필요한 총 키 길이: SK_d + SK_ai + SK_ar
         + SK_ei + SK_er + SK_pi + SK_pr */
      key_len_d + 2 * key_len_a + 2 * key_len_e + 2 * key_len_p);

  /* 4단계: keymat을 순서대로 분할하여 각 키에 할당 */
  int pos = 0;
  sa->keys.sk_d  = vec_slice (keymat, pos, key_len_d); pos += key_len_d;
  sa->keys.sk_ai = vec_slice (keymat, pos, key_len_a); pos += key_len_a;
  sa->keys.sk_ar = vec_slice (keymat, pos, key_len_a); pos += key_len_a;
  sa->keys.sk_ei = vec_slice (keymat, pos, key_len_e); pos += key_len_e;
  sa->keys.sk_er = vec_slice (keymat, pos, key_len_e); pos += key_len_e;
  sa->keys.sk_pi = vec_slice (keymat, pos, key_len_p); pos += key_len_p;
  sa->keys.sk_pr = vec_slice (keymat, pos, key_len_p);

  sa->state = IKEV2_STATE_SA_INIT;
  return 0;
}

IPsec 터널 인터페이스 구현 상세

VPP의 IPsec 터널 인터페이스는 일반적인 네트워크 인터페이스처럼 동작하면서 내부적으로 IPsec 암호화/복호화를 수행합니다. 이 구현은 ipsec_tun_protect_t 구조를 중심으로 인터페이스와 SA를 연결하며, 라우팅 기반 VPN 구성의 핵심 요소입니다.

ipsec_tunnel_if_t 구조체는 터널 인터페이스의 상태를 관리합니다. 각 터널 인터페이스는 VPP의 sw_if_index를 가지며, 이를 통해 일반 인터페이스와 동일하게 IP 주소 할당, 라우팅, ACL 적용이 가능합니다.

/* IPsec 터널 보호 구조체 (src/vnet/ipsec/ipsec_tun.h 기반) */
typedef struct {
  /* 보호 대상 인터페이스 */
  u32 itp_sw_if_index;             /* 연결된 sw_interface 인덱스 */
  index_t itp_out_sa;              /* 송신(outbound) SA 인덱스 */
  index_t *itp_in_sas;             /* 수신(inbound) SA 인덱스 배열 */

  /* 터널 엔드포인트 */
  ip_address_t itp_tun_src;        /* 터널 소스 주소 */
  ip_address_t itp_tun_dst;        /* 터널 목적지 주소 */

  /* adjacency rewrite 데이터 */
  fib_node_t itp_node;             /* FIB 그래프 노드 — adjacency 추적 */
  u32 itp_n_sa_in;                 /* 수신 SA 개수 */
  ipsec_protect_flags_t itp_flags; /* ITF, ENCAPED_ENABLED 등 플래그 */
} ipsec_tun_protect_t;

/* 터널 인터페이스 생성 및 SA 연결 과정 (의사 코드) */
static int
ipsec_tun_protect_update (u32 sw_if_index,
                          const ip_address_t *nh,
                          u32 sa_out, u32 *sas_in)
{
  ipsec_tun_protect_t *itp;

  /* 1단계: 보호 객체 할당 또는 기존 객체 검색 */
  itp = ipsec_tun_protect_find (sw_if_index, nh);
  if (!itp) {
    pool_get (ipsec_tun_protect_pool, itp);
    itp->itp_sw_if_index = sw_if_index;
  }

  /* 2단계: 송신/수신 SA 연결 */
  itp->itp_out_sa = sa_out;
  itp->itp_in_sas = vec_dup (sas_in);
  itp->itp_n_sa_in = vec_len (sas_in);

  /* 3단계: adjacency rewrite 갱신
     — 패킷이 이 인터페이스로 전달될 때 ESP 캡슐화 적용 */
  ipsec_tun_protect_adj_update (itp);

  /* 4단계: 수신 SA의 SPI → 인터페이스 매핑 등록
     — esp4-decrypt 노드가 SPI로 터널 인터페이스를 역방향 검색 */
  for (int i = 0; i < itp->itp_n_sa_in; i++) {
    ipsec_sa_t *sa = ipsec_sa_get (sas_in[i]);
    ipsec_tun_register (sa->spi, itp->itp_sw_if_index);
  }

  return 0;
}

GRE over IPsec 패턴은 GRE 터널 인터페이스를 먼저 생성한 뒤, ipsec tunnel protect로 해당 인터페이스에 IPsec 보호를 연결하는 방식입니다. GRE가 캡슐화를 담당하고, IPsec이 암호화를 담당하는 분리 구조로 동작합니다.

/* GRE over IPsec 구성 CLI 예시 */

/* 1단계: IPsec SA 생성 (송신/수신) */
ipsec sa add 10 spi 1000 esp \
  crypto-alg aes-gcm-256 crypto-key 0123456789abcdef... \
  tunnel-src 10.0.0.1 tunnel-dst 10.0.0.2

ipsec sa add 20 spi 2000 esp \
  crypto-alg aes-gcm-256 crypto-key fedcba9876543210... \
  tunnel-src 10.0.0.2 tunnel-dst 10.0.0.1

/* 2단계: GRE 터널 인터페이스 생성 */
create gre tunnel src 10.0.0.1 dst 10.0.0.2

/* 3단계: GRE 인터페이스에 IPsec 보호 적용 */
ipsec tunnel protect gre0 sa-out 10 sa-in 20

/* 4단계: 터널 인터페이스에 IP 주소 할당 및 라우팅 */
set interface ip address gre0 192.168.100.1/30
set interface state gre0 up
ip route add 172.16.0.0/16 via 192.168.100.2 gre0

VXLAN over IPsec 패턴은 오버레이 네트워크(VXLAN)와 암호화(IPsec)를 결합합니다. VXLAN 터널을 먼저 생성한 뒤, 해당 터널이 사용하는 외부 IP 경로에 IPsec 터널 보호를 적용하면 VXLAN 패킷이 자동으로 ESP로 암호화됩니다.

/* VXLAN over IPsec 구성 CLI 예시 */

/* 1단계: IPsec SA 생성 */
ipsec sa add 30 spi 3000 esp \
  crypto-alg aes-gcm-256 crypto-key aabbccdd... \
  tunnel-src 10.0.0.1 tunnel-dst 10.0.0.2
ipsec sa add 40 spi 4000 esp \
  crypto-alg aes-gcm-256 crypto-key ddccbbaa... \
  tunnel-src 10.0.0.2 tunnel-dst 10.0.0.1

/* 2단계: IPsec 터널 인터페이스 생성 및 보호 설정 */
create ipip tunnel src 10.0.0.1 dst 10.0.0.2
set interface unnumbered ipip0 use loop0
ipsec tunnel protect ipip0 sa-out 30 sa-in 40
set interface state ipip0 up

/* 3단계: VXLAN 터널을 IPsec 터널 위에 생성
   — 외부 경로가 ipip0을 경유하므로 자동 암호화 */
create vxlan tunnel src 10.0.0.1 dst 10.0.0.2 vni 100 \
  encap-vrf-id 0

/* 4단계: VXLAN 인터페이스를 브릿지 도메인에 연결 */
set interface l2 bridge vxlan_tunnel0 100
set interface l2 bridge GigabitEthernet0/0/1 100

Anti-Replay 윈도우 구현 상세

IPsec의 Anti-Replay 메커니즘(RFC 4302/4303)은 공격자가 캡처한 ESP/AH 패킷을 재전송하는 재생 공격(Replay Attack)을 방지합니다. VPP는 64비트 비트맵 기반의 슬라이딩 윈도우 알고리즘으로 이를 구현하며, 수신된 각 패킷의 시퀀스 번호를 검사하여 중복 또는 너무 오래된 패킷을 탐지합니다.

슬라이딩 윈도우 동작 원리는 다음과 같습니다. SA별로 마지막으로 수신한 최대 시퀀스 번호(last_seq)와 64비트 비트맵(replay_window)을 유지합니다. 비트맵의 각 비트는 last_seq 기준으로 최근 64개 시퀀스 번호의 수신 여부를 기록합니다.

• seq > last_seq: 새로운 패킷입니다. 윈도우를 seq - last_seq만큼 오른쪽으로 시프트하고, last_seq를 갱신한 후 해당 비트를 설정합니다.
• last_seq - 63 ≤ seq ≤ last_seq: 윈도우 범위 내의 패킷입니다. 해당 비트가 이미 설정되어 있으면 중복 패킷으로 폐기하고, 미설정이면 비트를 설정하고 통과시킵니다.
• seq < last_seq - 63: 윈도우 범위를 벗어난 오래된 패킷으로, 즉시 폐기합니다.

ESN(Extended Sequence Number, RFC 4304) 환경에서는 시퀀스 번호가 64비트로 확장되지만, ESP 헤더에는 하위 32비트만 전송됩니다. 수신 측은 상위 32비트(seq_hi)를 로컬 카운터를 기반으로 추론해야 합니다. VPP는 수신된 하위 32비트(seq)와 현재 last_seq의 상위 32비트를 비교하여 오버플로우 여부를 판단하고, 필요시 seq_hi를 1 증가시킵니다. 추론된 전체 64비트 시퀀스 번호는 무결성 검증(ICV) 계산에 포함되어 정확성이 암호학적으로 보장됩니다.

/* Anti-Replay 윈도우 검사 (src/vnet/ipsec/ipsec_sa.h 기반 의사 코드) */
static inline int
ipsec_sa_anti_replay_check (ipsec_sa_t *sa, u32 seq)
{
  u64 last_seq = sa->last_seq;
  u64 replay_window = sa->replay_window;
  u32 diff;

  /* ESN 상위 32비트 추론 */
  u32 seq_hi = sa->seq_hi;
  if (PREDICT_TRUE (sa->flags & IPSEC_SA_FLAG_USE_ESN)) {
    /* 하위 32비트 오버플로우 감지:
       수신 seq가 last_seq의 하위 32비트보다 크게 작으면
       아직 이전 epoch의 패킷일 수 있습니다 */
    u32 last_seq_lo = (u32) last_seq;
    if (seq < last_seq_lo &&
        (last_seq_lo - seq) > 0x80000000u) {
      /* 상위 비트 증가 (다음 epoch 패킷) */
      seq_hi = sa->seq_hi + 1;
    }
  }

  u64 full_seq = ((u64) seq_hi << 32) | seq;

  /* Case 1: 윈도우 범위 왼쪽 밖 — 너무 오래된 패킷 */
  if (PREDICT_FALSE (
      full_seq + IPSEC_SA_ANTI_REPLAY_WINDOW_SIZE < last_seq)) {
    return -1;  /* 폐기 */
  }

  /* Case 2: 윈도우 범위 내 — 중복 검사 */
  if (full_seq <= last_seq) {
    diff = last_seq - full_seq;
    if (replay_window & (1ULL << diff)) {
      return -1;  /* 중복 패킷 — 폐기 */
    }
  }

  /* Case 3: seq > last_seq 또는 윈도우 내 미수신 — 통과 */
  return 0;
}

/* Anti-Replay 윈도우 전진 — 무결성 검증 통과 후 호출 */
static inline void
ipsec_sa_anti_replay_advance (ipsec_sa_t *sa, u32 seq, u32 seq_hi)
{
  u64 full_seq = ((u64) seq_hi << 32) | seq;
  u64 last_seq = sa->last_seq;

  if (full_seq > last_seq) {
    /* 윈도우 시프트: 차이만큼 비트맵을 왼쪽으로 밀기 */
    u64 diff = full_seq - last_seq;
    if (diff < IPSEC_SA_ANTI_REPLAY_WINDOW_SIZE)
      sa->replay_window = (sa->replay_window << diff) | 1;
    else
      sa->replay_window = 1;  /* 큰 점프 시 윈도우 초기화 */

    sa->last_seq = full_seq;
    sa->seq_hi = seq_hi;
  } else {
    /* 윈도우 내 이전 시퀀스: 해당 비트만 설정 */
    u64 diff = last_seq - full_seq;
    sa->replay_window |= (1ULL << diff);
  }
}

Anti-Replay 검사는 esp4-decrypt 노드에서 무결성 검증(ICV 확인) 이전에 수행됩니다. 이는 비용이 큰 암호화 연산을 수행하기 전에 명백한 재생 공격 패킷을 조기에 걸러내기 위함입니다. 무결성 검증이 통과한 후에만 ipsec_sa_anti_replay_advance()를 호출하여 윈도우를 실제로 전진시킵니다. 이 2단계 구조는 위조 패킷이 윈도우 상태를 오염시키는 것을 방지합니다.

Segment Routing (SRv6)

VPP는 IPv6 Segment Routing(SRv6)을 데이터 플레인 수준에서 완전히 구현합니다. SRv6는 IPv6 확장 헤더인 Segment Routing Header(SRH)를 사용하여 패킷 경로를 소스에서 명시적으로 지정합니다. SRH에는 128비트 IPv6 주소 형식의 SID(Segment Identifier) 목록이 역순으로 저장되며, Segments Left 카운터가 현재 활성 세그먼트를 가리킵니다. 각 SRv6 노드는 Segments Left 값을 1씩 감소시키고 다음 SID를 IPv6 목적지 주소에 복사하여 패킷을 다음 홉으로 전달합니다.

VPP는 두 가지 SRv6 적용 모드를 지원합니다. 캡슐화(Encapsulation) 모드는 원본 패킷을 새로운 IPv6 + SRH 외부 헤더로 감싸는 방식이며, 삽입(Insertion) 모드는 기존 IPv6 헤더에 SRH를 직접 삽입합니다. 캡슐화 모드가 기본이며, 삽입 모드는 중간 라우터가 SRv6를 인식하지 못하는 환경에서 유용합니다.

로컬 SID 동작(Local SID Behavior)은 각 노드에서 SID가 자신에게 할당된 것일 때 수행하는 처리를 정의합니다. VPP가 지원하는 주요 동작은 다음과 같습니다:

• End: 중간 노드에서 Segments Left를 감소시키고 다음 SID로 전달합니다.
• End.X: End와 동일하되, 지정된 인접 노드(cross-connect)로 L3 전달합니다.
• End.DT4 / End.DT6: SRH를 제거하고 내부 IPv4 또는 IPv6 패킷을 특정 VRF 테이블에서 라우팅합니다. VPN 서비스 구현에 핵심적입니다.
• End.DX4 / End.DX6: SRH를 제거하고 내부 IPv4 또는 IPv6 패킷을 지정된 인접 노드로 직접 전달합니다.

BSID(Binding SID)는 SRv6 정책 전체를 하나의 SID로 추상화하여 트래픽 엔지니어링을 단순화합니다. 입구 노드는 BSID만 참조하면 되므로 정책 내부의 세그먼트 목록 변경이 투명하게 처리됩니다. VPP에서는 sr policy add bsid 명령으로 BSID를 정책에 바인딩하고, sr steer 명령으로 특정 트래픽을 해당 정책으로 유도합니다.

VPP는 SRv6 Mobile 기능도 제공하여 5G 환경에서 UPF(User Plane Function) 역할을 수행합니다. GTP-U 터널 패킷을 SRv6 세그먼트로 변환(T.M.GTP4.D)하거나, SRv6 패킷을 다시 GTP-U로 복원(End.M.GTP4.E)하는 상호 변환을 지원합니다. 이를 통해 모바일 백홀 네트워크에서 GTP-U 터널링 대신 SRv6 기반의 유연한 트래픽 엔지니어링을 적용할 수 있습니다.

/* SRv6 정책 설정 */
vpp# sr localsid address fc00::1 behavior end
vpp# sr policy add bsid fc00::999 next fc00::2 next fc00::3 encap
vpp# sr steer l3 10.0.0.0/8 via bsid fc00::999

QoS (Quality of Service)

VPP는 패킷 마킹, 폴리싱, 스케줄링 기능을 제공합니다:

# 폴리서 생성 (2r3c: 2-rate 3-color marker)
vpp# configure policer name rate-limiter cir 100000 cb 10000 \
     eir 200000 eb 20000 rate kbps color-aware

# 인터페이스에 폴리서 적용
vpp# set policer classify interface GigabitEthernet0/8/0 ip4-table 0
vpp# policer input rate-limiter GigabitEthernet0/8/0

# QoS 마킹 (DSCP 설정)
vpp# set qos record interface GigabitEthernet0/8/0 input ip
vpp# set qos mark interface GigabitEthernet0/9/0 output ip table 0

# 상태 확인
vpp# show policer
vpp# show qos record
vpp# show qos mark

VXLAN / GENEVE 터널(Tunnel)

VXLAN(Virtual Extensible LAN, RFC 7348)은 L2 프레임을 UDP 패킷으로 캡슐화하여 L3 네트워크 위에 가상의 L2 오버레이(Overlay) 네트워크를 구성하는 터널링 프로토콜입니다. 원본 이더넷 프레임 앞에 외부 이더넷 헤더(Outer Ethernet), 외부 IP 헤더(Outer IP), 외부 UDP 헤더(목적지 포트 4789), 그리고 8바이트 VXLAN 헤더가 추가됩니다. VXLAN 헤더에는 24비트 VNI(VXLAN Network Identifier)가 포함되어 최대 약 1,600만 개의 논리적 네트워크 세그먼트를 지원합니다. BUM(Broadcast, Unknown unicast, Multicast) 트래픽 처리에는 멀티캐스트 그룹을 사용한 복제 방식과 헤드엔드 유니캐스트 복제(Head-End Replication) 방식이 있으며, VPP는 두 가지 모두 지원합니다.

GENEVE(Generic Network Virtualization Encapsulation, RFC 8926)는 VXLAN의 후속 프로토콜로, 고정 헤더 뒤에 가변 길이 TLV(Type-Length-Value) 옵션 필드를 추가할 수 있습니다. 이를 통해 OAM(Operations, Administration, Maintenance) 정보, 보안 태그, 텔레메트리 메타데이터 등을 터널 헤더에 직접 포함할 수 있어 확장성이 크게 향상됩니다. UDP 목적지 포트는 6081을 사용하며, VXLAN과 동일하게 24비트 VNI를 지원합니다.

VPP의 패킷 그래프에서 VXLAN 디캡슐화는 ip4-input → ip4-lookup → ip4-local → udp-local → vxlan4-input 경로를 거치며, vxlan4-input 노드에서 VNI를 기반으로 해당 터널 인터페이스를 식별하고 내부 프레임을 추출합니다. 캡슐화 경로는 l2-output → vxlan4-encap → ip4-rewrite → interface-output 순서로 진행됩니다. 최신 NIC(Intel X710, Mellanox ConnectX-5 이상 등)은 VTEP(VXLAN Tunnel End Point) 오프로드를 지원하여 외부 헤더의 추가·제거를 하드웨어에서 처리함으로써 CPU 부담을 줄이고 처리량을 높일 수 있습니다.

# VXLAN 터널 생성
vpp# create vxlan tunnel src 10.0.0.1 dst 10.0.0.2 vni 100
vpp# set interface state vxlan_tunnel0 up

# 브릿지 도메인에 추가 (L2 오버레이)
vpp# set interface l2 bridge vxlan_tunnel0 100
vpp# set interface l2 bridge GigabitEthernet0/9/0 100

# GENEVE 터널 생성
vpp# create geneve tunnel src 10.0.0.1 dst 10.0.0.2 vni 200
vpp# set interface state geneve_tunnel0 up

# 터널 상태 확인
vpp# show vxlan tunnel
vpp# show geneve tunnel

VPP CLI 및 API

VPP CLI (vppctl)

VPP는 유닉스 도메인 소켓(/run/vpp/cli.sock)을 통한 CLI를 제공합니다:

# VPP CLI 접속
$ vppctl
    _______    _        _   _____  ___
 __/ __/ _ \  (_)__    | | / / _ \/ _ \
 _/ _// // / / / _ \   | |/ / ___/ ___/
 /_/ /____(_)_/\___/   |___/_/  /_/

vpp# show version
vpp# show interface
vpp# show hardware-interfaces
vpp# show runtime               /* 노드별 성능 통계 */
vpp# show errors                /* 에러 카운터 */
vpp# show trace                 /* 패킷 트레이스 */

# 패킷 트레이싱 (디버깅)
vpp# trace add dpdk-input 100   /* DPDK 입력 100 패킷 추적 */
vpp# show trace                 /* 추적 결과 확인 */

# 비대화형 실행
$ vppctl show interface

Binary API

VPP Binary API는 공유 메모리를 통한 고성능 프로그래밍 인터페이스입니다. .api 파일에서 메시지를 정의하고, 코드 생성기가 C/Python/Go 바인딩을 자동 생성합니다:

/* my_plugin.api — API 메시지 정의 */
autoreply define my_plugin_enable_disable {
    u32 client_index;
    u32 context;
    bool enable_disable;
    vl_api_interface_index_t sw_if_index;
};

define my_plugin_details {
    u32 context;
    vl_api_interface_index_t sw_if_index;
    u64 packet_count;
};

VAPI (VPP API)

VAPI는 C/C++용 고수준 API 라이브러리로, Binary API 위에서 동기/비동기 호출, 콜백, 자동 직렬화(Serialization)를 제공합니다:

/* VAPI 사용 예제 (C) */
#include <vapi/vapi.h>
#include <vapi/vpe.api.vapi.h>

vapi_ctx_t ctx;
vapi_ctx_alloc(&ctx);
vapi_connect(ctx, "my_app", NULL,
             64,  /* max outstanding requests */
             32,  /* response queue depth */
             VAPI_MODE_BLOCKING, true);

/* 인터페이스 목록 조회 */
vapi_msg_sw_interface_dump *msg = vapi_alloc_sw_interface_dump(ctx);
msg->payload.name_filter_valid = false;
vapi_sw_interface_dump(ctx, msg, callback_fn, NULL);

vapi_disconnect(ctx);
vapi_ctx_free(ctx);

GoVPP / Python bindings

# Python (vpp_papi) 예제
from vpp_papi import VPPApiClient

vpp = VPPApiClient(apifiles=['/usr/share/vpp/api/core/*.api.json'])
vpp.connect('my-python-app')

# 인터페이스 목록
ifaces = vpp.api.sw_interface_dump()
for iface in ifaces:
    print(f"{iface.interface_name}: {iface.sw_if_index}")

# TAP 생성
rv = vpp.api.tap_create_v2(id=0, host_if_name='vpp-tap0',
                            host_ip4_prefix='192.168.1.1/24')

vpp.disconnect()

Python vpp_papi 자동화 예제

운영 환경에서는 CLI를 사람이 수동으로 입력하는 것보다, API 세션 생성 → 설정 적용 → 검증 → 통계 수집을 한 번의 자동화 흐름으로 묶는 편이 훨씬 안전합니다. 특히 VPP는 설정 성공 여부를 즉시 반환하므로, 배포 스크립트에서 실패 지점을 명확히 잡아낼 수 있습니다.

from vpp_papi import VPPApiClient

vpp = VPPApiClient(apifiles=[
    "/usr/share/vpp/api/core/*.api.json",
    "/usr/share/vpp/api/plugins/*.api.json",
])
vpp.connect("vpp-automation")

def run(cmd):
    reply = vpp.api.cli_inband(cmd=cmd)
    if reply.retval != 0:
        raise RuntimeError(reply.reply)
    return reply.reply

# 1. 구성 적용
run("create loopback interface instance 10")
run("set interface state loop10 up")
run("set interface ip address loop10 172.16.10.1/24")
run("ip route add 198.18.0.0/15 via 172.16.10.254 loop10")

# 2. 읽기 경로는 typed dump 사용
interfaces = vpp.api.sw_interface_dump()
for iface in interfaces:
    name = iface.interface_name.rstrip("\\x00")
    if name == "loop10":
        print(f"loop10 index={iface.sw_if_index} mtu={iface.mtu[0]}")

# 3. 최종 검증
print(run("show interface loop10"))
print(run("show ip fib 198.18.0.0/15"))

vpp.disconnect()

Stats Segment

VPP의 Stats Segment는 통계 카운터를 외부 프로세스에 노출하는 공유 메모리 영역입니다. 배리어 없이 읽기 전용으로 접근할 수 있어, 모니터링 시스템이 VPP 성능에 영향을 주지 않습니다.

/* C에서 Stats Segment 접근 */
#include <vpp-api/client/stat_client.h>

stat_client_main_t *sm = stat_client_get();
stat_segment_connect("/run/vpp/stats.sock");

/* 패턴으로 카운터 조회 */
u8 **patterns = 0;
vec_add1(patterns, (u8 *)"/if/rx");
stat_segment_data_t *data = stat_segment_dump(patterns);

/* Python에서 접근 */
# from vpp_papi.vpp_stats import VPPStats
# stats = VPPStats(socketname='/run/vpp/stats.sock')
# print(stats['/if/rx'])

성능 최적화

CPU 핀닝과 워커 스레드

VPP 성능의 핵심은 CPU 코어 격리와 적절한 워커 스레드 배치입니다:

/* startup.conf — CPU 핀닝 */
cpu {
    main-core 0                    /* 메인 스레드 (API, CLI 처리) */
    corelist-workers 2,4,6,8       /* 워커: 물리 코어만 (HT 제외) */
    skip-cores 1                   /* 코어 1 건너뛰기 (OS용) */
}

# 커널 부팅 파라미터: VPP 코어를 OS 스케줄러에서 격리
GRUB_CMDLINE_LINUX="isolcpus=2,4,6,8 nohz_full=2,4,6,8 rcu_nocbs=2,4,6,8"

NUMA 인식

NIC과 VPP 워커 스레드를 동일 NUMA 노드에 배치하여 원격 메모리 접근(remote memory access)을 방지합니다:

# NIC의 NUMA 노드 확인
$ cat /sys/bus/pci/devices/0000:03:00.0/numa_node
0

# NUMA 노드 0의 CPU 확인
$ lscpu | grep "NUMA node0"
NUMA node0 CPU(s): 0-7

/* startup.conf — NUMA 인식 설정 */
buffers {
    buffers-per-numa 16384        /* NUMA 노드당 버퍼 수 */
    default data-size 2048
}

dpdk {
    dev 0000:03:00.0 {            /* NUMA 0에 위치한 NIC */
        num-rx-queues 4
    }
}

cpu {
    main-core 0                   /* NUMA 0 코어 */
    corelist-workers 2,4,6        /* NUMA 0 코어 */
}

인터럽트 모드 vs 폴링 모드

/* startup.conf — 인터럽트 모드 활성화 */
dpdk {
    dev 0000:03:00.0 {
        num-rx-queues 4
    }
}

/* 적응형 모드: 유휴 시 sleep */
unix {
    poll-sleep-usec 100           /* 유휴 시 100μs sleep */
}

성능 벤치마킹

# VPP 내장 패킷 생성기로 벤치마크
vpp# packet-generator new {
    name pg0
    limit 10000000
    size 64-64
    interface pg0
    node ethernet-input
    data { IP4: 1.2.3 -> 4.5.6
           UDP: 192.168.1.1 -> 192.168.2.1
           UDP: 1234 -> 5678
           incrementing 100
    }
}
vpp# packet-generator enable

# 런타임 통계 확인
vpp# show runtime
# 출력:
# Name                 State    Calls   Vectors  Suspends  Clocks   Vectors/Call
# dpdk-input           polling  1000000 10000000 0         24.50    10.00
# ethernet-input       active   1000000 10000000 0         18.30    10.00
# ip4-input            active   1000000 10000000 0         15.20    10.00
# ip4-lookup           active   1000000 10000000 0         12.80    10.00

# TRex 외부 트래픽 생성기 사용
$ ./t-rex-64 -f stl/bench.py -m 10mpps -d 60

버퍼 풀 최적화

# 버퍼 풀 상태 확인
vpp# show buffers
 Thread             Name           Index    Size     Alloc    Free     #Alloc   #Free
      0 default-numa-0                0     2048     32768    31200     1568     31200
      1 default-numa-0                0     2048     32768    30800     1968     30800

# 부족 시 증상: show errors에서 no-buffer 증가
vpp# show errors
   Count  Node           Reason
   15230  dpdk-input      no-buffer         ← 버퍼 부족!
       0  dpdk-input      buffer-alloc-fail

perf/VPP 성능 카운터 분석

# perf stat로 VPP 워커의 CPU 카운터 측정
$ perf stat -e cycles,instructions,cache-misses,cache-references,\
branch-misses,branch-instructions -p $(pidof vpp) -t $(pgrep -P $(pidof vpp)) sleep 10

# VPP 내장 성능 카운터
vpp# show runtime
# Clocks/Call: 노드당 평균 CPU 사이클 (낮을수록 좋음)
# Vectors/Call: 호출당 평균 벡터 크기 (높을수록 좋음)

# 노드별 상세 통계
vpp# show runtime max
vpp# clear runtime

VPP 성능 프로파일링 실전

VPP 성능 문제를 체계적으로 진단하려면, 내장 카운터 분석부터 시작하여 단계적으로 깊이를 늘려가야 합니다. 다음 의사결정 트리는 프로파일링 워크플로의 전체 흐름을 보여줍니다.

show runtime 출력 해석

show runtime은 VPP의 가장 기본적이면서도 강력한 성능 분석 도구입니다. 각 노드의 호출 횟수, 처리 벡터 수, 클럭 소비를 한눈에 보여줍니다.

vpp# show runtime
Time 120.3, 10 sec internal node vector rate 255.00

Thread 1 vpp_wk_0 (lcore 2)
Name                 State    Calls     Vectors   Suspends  Clocks    Vectors/Call
dpdk-input           polling  1523471   389688320  0        28.72     255.80
ethernet-input       active   1523471   389688320  0        11.45     255.80
ip4-input            active   1523468   389687552  0         8.33     255.80
ip4-lookup           active   1523468   389687552  0        18.91     255.80
ip4-rewrite          active   1523468   389687552  0        12.67     255.80
                                                           ↑          ↑
                                            Clocks/Call 낮을수록 좋음   Vectors/Call 높을수록 좋음
GigabitEthernet0/8/0-output active 1523468 389687552 0       6.22     255.80
GigabitEthernet0/8/0-tx     active 1523468 389687552 0       9.81     255.80

Thread 2 vpp_wk_1 (lcore 4)
Name                 State    Calls     Vectors   Suspends  Clocks    Vectors/Call
dpdk-input           polling  1519832   388757248  0        29.01     255.78
ethernet-input       active   1519832   388757248  0        11.52     255.78
ip4-input            active   1519830   388756992  0         8.41     255.78
ip4-lookup           active   1519830   388756992  0        19.05     255.78
ip4-rewrite          active   1519830   388756992  0        12.74     255.78

핵심 지표(Metric)의 의미와 판단 기준은 다음과 같습니다:

perf + FlameGraph 분석

show runtime의 Clocks/Call이 비정상적으로 높은 노드를 발견했다면, perf 도구로 해당 노드 내부의 CPU 핫스팟을 정밀 분석합니다.

# 1. VPP 워커 스레드 PID 확인
$ pgrep -a vpp
12345 /usr/bin/vpp -c /etc/vpp/startup.conf

# 2. 워커 스레드 TID 확인
$ ls /proc/12345/task/
12345  12347  12348  12349
#      ↑ wk_0  ↑ wk_1  ↑ wk_2

# 3. perf top으로 실시간 핫스팟 확인 (특정 워커)
$ sudo perf top -t 12347 -g --no-children

# 4. perf record로 프로파일 기록 (30초)
$ sudo perf record -F 9999 -g --call-graph dwarf \
    -t 12347 -o perf_vpp_wk0.data -- sleep 30

# 5. perf script로 텍스트 변환
$ sudo perf script -i perf_vpp_wk0.data > perf_vpp_wk0.txt

# 6. FlameGraph 생성
$ git clone https://github.com/brendangregg/FlameGraph.git
$ ./FlameGraph/stackcollapse-perf.pl perf_vpp_wk0.txt \
    | ./FlameGraph/flamegraph.pl --title "VPP Worker 0" \
    > vpp_wk0_flamegraph.svg

# 7. 브라우저에서 SVG 열기 (인터랙티브 탐색 가능)
$ xdg-open vpp_wk0_flamegraph.svg

FlameGraph에서 VPP 관련 함수를 읽는 방법은 다음과 같습니다:

• 그래프 노드 함수 (*_node_fn): ip4_lookup_node_fn, ethernet_input_node_fn 등. 이 함수들이 전체 폭의 대부분을 차지하는 것은 정상입니다.
• 프레임워크 오버헤드: vlib_main_loop, dispatch_node, vlib_frame_* 함수들. 전체의 10~15% 이하여야 정상입니다.
• 메모리 접근: __memcpy_avx_unaligned, clib_memcpy 등. 이 함수가 상위에 보이면 패킷 데이터 복사가 병목입니다.
• FIB 조회: ip4_fib_table_lookup_lb, mtrie_* 함수. 이 부분이 넓으면 FIB 크기가 캐시를 초과한 것입니다.

병목 진단 시나리오별 가이드

실무에서 자주 발생하는 VPP 성능 문제와 그 진단·해결 방법을 정리합니다.

디버깅 및 트러블슈팅

패킷 트레이싱

VPP의 패킷 트레이싱은 가장 강력한 디버깅 도구입니다. 패킷이 어떤 노드를 거쳐 어떤 결정을 받았는지 라인별로 확인할 수 있습니다.

# 트레이싱 활성화 (dpdk-input 노드에서 10개 패킷)
vpp# trace add dpdk-input 10

# 트래픽 발생 후 결과 확인
vpp# show trace

Packet 1

00:00:01:123456: dpdk-input
  GigabitEthernet0/8/0 rx queue 0
  buffer 0x9a340: current data 0, length 98, buffer-pool 0
  trace_handle 0x1000001
  l2-hdr-offset 0 ip4-hdr-offset 14

00:00:01:123458: ethernet-input              ← L2 분류
  IP4: fa:16:3e:aa:bb:cc -> fa:16:3e:dd:ee:ff

00:00:01:123459: ip4-input                   ← IPv4 처리 진입
  TCP: 192.168.1.100 -> 10.0.0.1
    tos 0x00, ttl 64, length 84, checksum 0x1234 dscp CS0 ecn NON_ECN
    fragment id 0x0001, flags DONT_FRAGMENT
  TCP: 45000 -> 80
    seq 0x12345678 ack 0x00000000
    flags [SYN] window 65535

00:00:01:123460: ip4-lookup                  ← FIB 룩업
  fib 0 dpo-idx 7 flow hash: 0x00001234
  TCP: 192.168.1.100 -> 10.0.0.1

00:00:01:123461: ip4-rewrite                 ← MAC 재작성
  tx_sw_if_index 2 dpo-idx 7
  adjacency rewrite: GigabitEthernet0/9/0
    dst aa:bb:cc:dd:ee:01 src fa:16:3e:xx:yy:zz

00:00:01:123462: GigabitEthernet0/9/0-output ← 인터페이스 출력
  GigabitEthernet0/9/0
  IP4: fa:16:3e:xx:yy:zz -> aa:bb:cc:dd:ee:01

00:00:01:123463: GigabitEthernet0/9/0-tx     ← TX 큐 전송
  buffer 0x9a340: current data -14, length 112

에러 카운터 분석

vpp# show errors
   Count   Node                  Reason
   15230   dpdk-input            no buffer available
     842   ip4-input             ip4 spoofed local-address packet drops
     156   ip4-lookup            ip4 destination lookup miss
      23   acl-plugin-in-ip4-fa  acl deny
       5   nat44-in2out          no translation
       2   ipsec-input-ip4       SA not found

PCAP 캡처

# 인입 패킷 PCAP 캡처
vpp# pcap trace rx max 1000 file rx-capture.pcap

# 송출 패킷 캡처
vpp# pcap trace tx max 1000 file tx-capture.pcap

# 드롭 패킷 캡처 (문제 진단에 가장 유용)
vpp# pcap trace drop max 1000 file drop-capture.pcap

# 특정 인터페이스만 캡처
vpp# pcap trace rx max 500 intfc GigabitEthernet0/8/0 file intf-rx.pcap

# 캡처 중지 및 저장
vpp# pcap trace off

# 파일 위치: /tmp/*.pcap

이벤트 로거와 코어 덤프(Core Dump)

# 이벤트 로거 활성화
vpp# event-logger resize 1000000
vpp# event-logger restart
vpp# event-logger save /tmp/elog.dat

# GDB로 VPP 디버깅 (디버그 빌드 필요)
$ gdb /usr/bin/vpp_main core.12345
(gdb) bt                          # 백트레이스
(gdb) thread apply all bt         # 모든 스레드 백트레이스
(gdb) frame 3                     # 특정 프레임으로 이동
(gdb) p *b                        # vlib_buffer_t 내용 출력

# startup.conf에서 코어 덤프 활성화
# unix { full-coredump }
# coredump 크기 제한 해제: ulimit -c unlimited

자주 발생하는 문제와 해결

보안 고려사항

API 소켓 보안

/* 보안 API 설정 예제 (startup.conf) */
unix {
    cli-listen /run/vpp/cli.sock   /* 로컬 유닉스 소켓만 (TCP 금지) */
    gid vpp                         /* vpp 그룹만 CLI 접근 */
}

api-segment {
    gid vpp                         /* API 세그먼트 그룹 제한 */
    api-pvt-heap-size 64M
}

api-trace {
    on                              /* API 호출 감사 추적 */
    save-api-table /tmp/api-table   /* API 테이블 저장 */
}

DPDK/VFIO 보안 격리

네트워크 보안 기능

설치 및 설정

패키지 설치

# Ubuntu/Debian — FD.io 공식 저장소
$ curl -s https://packagecloud.io/install/repositories/fdio/release/script.deb.sh | sudo bash
$ sudo apt-get install vpp vpp-plugin-core vpp-plugin-dpdk vpp-dev

# CentOS/RHEL
$ curl -s https://packagecloud.io/install/repositories/fdio/release/script.rpm.sh | sudo bash
$ sudo yum install vpp vpp-plugins vpp-devel

# 서비스 시작
$ sudo systemctl start vpp
$ sudo systemctl enable vpp

소스 빌드

# 소스 클론
$ git clone https://gerrit.fd.io/r/vpp
$ cd vpp

# 의존성 설치 (Ubuntu)
$ make install-dep
$ make install-ext-deps

# 빌드
$ make build             /* 디버그 빌드 */
$ make build-release     /* 릴리스 빌드 */

# 실행
$ make run               /* 빌드 디렉터리에서 직접 실행 */

startup.conf 설정

/* /etc/vpp/startup.conf — 프로덕션 설정 예제 */

unix {
    nodaemon                       /* 포그라운드 실행 (디버깅 시) */
    cli-listen /run/vpp/cli.sock   /* CLI 소켓 경로 */
    log /var/log/vpp/vpp.log       /* 로그 파일 */
    full-coredump                  /* 코어 덤프 활성화 */
    exec /etc/vpp/setup.gate       /* 시작 시 실행할 CLI 스크립트 */
}

api-trace {
    on                             /* API 추적 활성화 */
}

api-segment {
    gid vpp                        /* API 소켓 그룹 */
}

cpu {
    main-core 0
    corelist-workers 2,4,6,8
}

dpdk {
    dev default {
        num-rx-queues 4
        num-tx-queues 4
        num-rx-desc 1024
        num-tx-desc 1024
    }
    dev 0000:03:00.0
    dev 0000:03:00.1
    uio-driver vfio-pci            /* VFIO 사용 */
}

buffers {
    buffers-per-numa 32768
    default data-size 2048
}

plugins {
    plugin default { disable }     /* 기본 비활성화 */
    plugin dpdk_plugin.so { enable }
    plugin acl_plugin.so { enable }
    plugin nat_plugin.so { enable }
    plugin linux_cp_plugin.so { enable }
}

활용 사례

가상 스위치 (vSwitch)

VPP는 데이터센터의 가상 스위치로 활용됩니다. VM 간 트래픽을 vhost-user 인터페이스로 고성능 전달하며, OvS-DPDK 대비 더 높은 pps 성능을 제공합니다. Kubernetes 환경에서는 Calico/VPP CNI 플러그인으로 Pod 네트워킹을 가속합니다.

CPE/VNF

통신사의 고객 구내 장비(CPE)를 소프트웨어로 구현하는 VNF(Virtual Network Function)에 VPP가 사용됩니다. 라우팅, NAT, IPsec, QoS를 단일 VPP 인스턴스에서 처리하여 전용 하드웨어를 대체합니다.

5G UPF

5G 코어 네트워크의 UPF(User Plane Function)에서 GTP-U 터널 종단, PDU 세션 관리, SRv6 기반 모바일 유저플레인을 VPP로 구현합니다.

# GTP-U 터널 설정 (upf 플러그인)
vpp# upf pfcp association setup-params
vpp# upf nwi create name internet
vpp# create upf application name internet

# 또는 travelping/upg-vpp 사용 시
vpp# upf gtpu endpoint ip 10.200.0.1 nwi access teid-range-timeout 30

Kubernetes CNI 통합

# Calico/VPP CNI 설치 (Helm)
$ helm repo add projectcalico https://docs.tigera.io/calico/charts
$ helm install calico projectcalico/tigera-operator \
    --set installation.cni.type=Calico \
    --set installation.calicoNetwork.linuxDataplane=VPP

로드 밸런서

VPP의 lb 플러그인은 Maglev 해시 기반 L3/L4 로드 밸런서를 제공합니다. GRE 또는 VXLAN으로 백엔드 서버에 패킷을 분산합니다:

vpp# lb vip 10.0.0.100/32 protocol tcp port 80 encap gre4
vpp# lb as 10.0.0.100/32 protocol tcp port 80 192.168.1.10
vpp# lb as 10.0.0.100/32 protocol tcp port 80 192.168.1.11

CSIT 테스팅 프레임워크

CSIT 개요

CSIT(Continuous System Integration and Testing)은 FD.io 프로젝트의 공식 테스트 프레임워크입니다. VPP의 기능 검증, 성능 측정, 회귀 테스트를 자동화합니다.

로컬 테스트 실행

# VPP 소스에서 단위 테스트 실행
$ cd vpp
$ make test                        /* 전체 단위 테스트 */
$ make test TEST=test_ip4          /* 특정 테스트만 */
$ make test-debug                  /* 디버그 빌드 테스트 */
$ make test V=2                    /* 상세 출력 */

# CSIT 기능 테스트 실행 (Docker 필요)
$ git clone https://gerrit.fd.io/r/csit
$ cd csit
$ ./bootstrap-verify-perf.sh       /* 성능 테스트 */

흔한 실수와 안티패턴

VPP 운영 시 자주 발생하는 실수와 권장 해결 방법을 정리합니다. 특히 초기 구축 시 환경 설정 오류가 대부분의 장애 원인입니다.

Hugepage 설정 누락/부족

# Hugepage 상태 확인
$ cat /proc/meminfo | grep -i huge
HugePages_Total:    2048
HugePages_Free:     1536
HugePages_Rsvd:        0
Hugepagesize:       2048 kB

# 부팅 시 영구 설정 (GRUB)
GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=2M hugepages=2048 \
    hugepagesz=1G hugepages=4 iommu=pt intel_iommu=on"

# 런타임 할당 (재부팅 없이)
$ echo 2048 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
$ sudo mkdir -p /dev/hugepages
$ sudo mount -t hugetlbfs none /dev/hugepages

DPDK 인터페이스 바인딩 오류

# 잘못된 예: IOMMU 없이 vfio-pci 바인딩 시도
$ sudo dpdk-devbind.py --bind=vfio-pci 0000:00:08.0
# Error: Cannot bind to driver vfio-pci: No IOMMU group

# 올바른 해결 방법 1: IOMMU 활성화
# GRUB에 intel_iommu=on iommu=pt 추가 후 재부팅

# 올바른 해결 방법 2: IOMMU 없는 환경에서 vfio 사용
$ sudo modprobe vfio enable_unsafe_noiommu_mode=1
$ echo 1 | sudo tee /sys/module/vfio/parameters/enable_unsafe_noiommu_mode
$ sudo dpdk-devbind.py --bind=vfio-pci 0000:00:08.0

# NIC 현재 상태 확인
$ dpdk-devbind.py --status
Network devices using DPDK-compatible driver
============================================
0000:00:08.0 'Virtio network device' drv=vfio-pci

Network devices using kernel driver
====================================
0000:00:03.0 'Virtio network device' drv=virtio-pci

startup.conf 워커 스레드 / CPU 핀닝 실수

# CPU 토폴로지 확인
$ lscpu -e
CPU NODE SOCKET CORE L1d L2 L3 ONLINE
  0    0      0    0   0  0  0      yes  ← main-core (관리용)
  1    0      0    1   1  1  0      yes  ← worker 0
  2    0      0    2   2  2  0      yes  ← worker 1
  3    0      0    3   3  3  0      yes  ← worker 2
  4    0      0    0   0  0  0      yes  ← HT sibling of core 0 (사용 금지)

# NIC NUMA 노드 확인
$ cat /sys/bus/pci/devices/0000:00:08.0/numa_node
0

# 올바른 startup.conf
cpu {
    main-core 0                        /* 관리 전용 */
    corelist-workers 1-3               /* NIC와 같은 NUMA, HT 제외 */
    skip-cores 0                       /* 기본값 유지 */
}

# 커널 부트 파라미터 (VPP 코어 격리)
GRUB_CMDLINE_LINUX="isolcpus=1-3 nohz_full=1-3 rcu_nocbs=1-3"

벡터 크기와 배치 처리 오해

VPP의 벡터 처리 모델에서 벡터 크기(VLIB_FRAME_SIZE)는 한 번에 처리되는 패킷 묶음의 크기입니다. 벡터가 클수록 I-cache 효율이 높아지지만, 레이턴시는 증가합니다.

memif 연결 시 소켓 권한 문제

# 흔한 오류: Permission denied
vpp# create interface memif id 0 socket-id 1 slave
# create memif: connect error (Permission denied)

# 원인 진단
$ ls -la /run/vpp/
srwxrwx--- 1 root root 0 memif-chain.sock     ← 그룹 접근 필요

# 해결: 공통 그룹 사용
$ sudo groupadd vpp-memif
$ sudo usermod -aG vpp-memif vpp-user1
$ sudo usermod -aG vpp-memif vpp-user2

# startup.conf에서 그룹 지정
unix {
    gid vpp-memif
}

# 소켓 디렉터리 권한 확인 (실행 권한 필수)
$ sudo chmod 2770 /run/vpp/
$ sudo chgrp vpp-memif /run/vpp/

# 연결 상태 확인
vpp# show memif
interface memif1/0
  socket-id 1 id 0 mode ethernet
  status: connected                     ← 정상
  ring 0: region 0 num-s 2048 ...
  link up

VPP 운영 가이드

프로덕션 환경에서 VPP를 안정적으로 운영하려면 무중단 설정 변경, 재시작 절차, 고가용성 구성, 용량 산정, 로깅 체계를 체계적으로 관리해야 합니다. 이 섹션에서는 실무에서 반드시 알아야 할 운영 지침을 다룹니다.

무중단 설정 변경

VPP는 많은 설정을 런타임에 변경할 수 있지만, 일부 설정은 프로세스 재시작이 필요합니다. 운영 중 서비스 중단 없이 변경 가능한 항목과 그렇지 않은 항목을 명확히 구분해야 합니다.

# 안전한 런타임 설정 변경 예시

# 1) 인터페이스 IP 변경
vpp# set interface state GigabitEthernet0/8/0 up
vpp# set interface ip address GigabitEthernet0/8/0 192.168.1.1/24

# 2) 라우팅 테이블 업데이트
vpp# ip route add 10.0.0.0/8 via 192.168.1.254
vpp# ip route del 172.16.0.0/12 via 192.168.1.254

# 3) NAT44 매핑 추가
vpp# nat44 add static mapping local 10.0.0.100 22 external 203.0.113.50 2222 tcp
vpp# show nat44 static mappings

# 4) ACL 규칙 동적 적용
vpp# set acl-plugin acl permit src 10.0.0.0/24 dst 0.0.0.0/0
vpp# set acl-plugin interface GigabitEthernet0/8/0 input acl 0

exec 명령을 사용하면 여러 CLI 명령을 하나의 스크립트 파일로 묶어 원자적으로 실행할 수 있습니다. 개별 명령을 하나씩 입력하는 것보다 설정 오류를 줄이고, 일관된 상태를 보장합니다.

# /etc/vpp/reconfigure-nat.cli — NAT 재구성 배치 스크립트
nat44 del static mapping local 10.0.0.100 22 external 203.0.113.50 2222 tcp
nat44 add static mapping local 10.0.0.200 22 external 203.0.113.50 2222 tcp
nat44 add static mapping local 10.0.0.201 80 external 203.0.113.51 80 tcp
nat44 add static mapping local 10.0.0.201 443 external 203.0.113.51 443 tcp

# VPP CLI에서 배치 실행
vpp# exec /etc/vpp/reconfigure-nat.cli

# 결과 확인
vpp# show nat44 static mappings

우아한 재시작과 설정 영속성

VPP는 자체적인 설정 영속성 메커니즘을 제공하지 않습니다. startup.conf의 exec 지시문을 통해 부팅 시 CLI 스크립트를 자동 실행하여 원하는 상태를 재구성합니다.

# /etc/vpp/startup.conf — exec 스크립트 지정
unix {
    nodaemon
    log /var/log/vpp/vpp.log
    full-coredump
    cli-listen /run/vpp/cli.sock
    exec /etc/vpp/setup.gate           ← 부팅 시 자동 실행
}

cpu {
    main-core 0
    corelist-workers 1-3
}

buffers {
    buffers-per-numa 16384
    default data-size 2048
}

dpdk {
    dev 0000:00:08.0
}

# /etc/vpp/setup.gate — 부팅 시 자동 실행 스크립트
# 순서가 중요합니다: 인터페이스 → IP → 라우팅 → NAT → ACL

# 1단계: 인터페이스 활성화
set interface state GigabitEthernet0/8/0 up
set interface state GigabitEthernet0/9/0 up

# 2단계: IP 주소 할당
set interface ip address GigabitEthernet0/8/0 192.168.1.1/24
set interface ip address GigabitEthernet0/9/0 10.0.0.1/24

# 3단계: 라우팅 설정
ip route add 0.0.0.0/0 via 192.168.1.254
ip route add 172.16.0.0/12 via 10.0.0.254

# 4단계: NAT44 설정
nat44 plugin enable sessions 131072
set interface nat44 in GigabitEthernet0/9/0 out GigabitEthernet0/8/0
nat44 add static mapping local 10.0.0.100 22 external 192.168.1.1 2222 tcp
nat44 add static mapping local 10.0.0.101 80 external 192.168.1.1 80 tcp

# 5단계: ACL 설정
set acl-plugin acl permit+reflect src 10.0.0.0/24 dst 0.0.0.0/0
set acl-plugin interface GigabitEthernet0/9/0 input acl 0

고가용성(HA)과 장애 조치

프로덕션 환경에서는 단일 VPP 인스턴스의 장애가 서비스 중단으로 이어지지 않도록 고가용성 구성이 필수입니다. VPP는 여러 HA 패턴을 지원합니다.

# NAT44 HA 구성 — 세션 미러링

# Primary 노드 설정
vpp# nat44 ha listener 10.0.0.1:20000 path-mtu 1400
vpp# nat44 ha failover 10.0.0.2:20000

# Standby 노드 설정
vpp# nat44 ha listener 10.0.0.2:20000 path-mtu 1400
vpp# nat44 ha failover 10.0.0.1:20000

# 세션 동기화 확인
vpp# show nat44 ha
  listener 10.0.0.1:20000
  failover 10.0.0.2:20000
  in-sync sessions: 45832
  pending updates: 3                   ← 0에 가까울수록 양호
  last resync: 2.3s ago

# Active-Standby VRRP 연동 (linux-cp 플러그인)

# linux-cp 활성화: startup.conf에 추가
# plugins { plugin linux_cp_plugin.so { enable } }

# 커널에 미러 인터페이스 생성
vpp# lcp create GigabitEthernet0/8/0 host-if eth-vpp0
vpp# set interface state GigabitEthernet0/8/0 up
vpp# set interface ip address GigabitEthernet0/8/0 192.168.1.1/24

# 커널에서 keepalived(VRRP) 구성
# /etc/keepalived/keepalived.conf에서 eth-vpp0 사용
# VIP 192.168.1.254를 VRRP로 관리

VPP 인스턴스의 활성(liveness) 상태를 외부에서 확인하는 방법은 다음과 같습니다.

# 방법 1: CLI 소켓을 통한 헬스 체크
$ vppctl -s /run/vpp/cli.sock show version 2>&1 | grep -q "vpp" && echo "UP" || echo "DOWN"

# 방법 2: API 소켓 존재 여부 확인
$ test -S /run/vpp/api.sock && echo "API socket exists"

# 방법 3: systemd 상태 확인
$ systemctl is-active vpp.service

# 방법 4: 프로세스 체크 + CLI 응답 확인 (모니터링 스크립트)
#!/bin/bash
if pgrep -x vpp_main > /dev/null; then
    RESULT=$(timeout 3 vppctl show runtime 2>&1)
    if [ $? -eq 0 ]; then
        echo "VPP healthy"
    else
        echo "VPP process alive but CLI unresponsive"
    fi
else
    echo "VPP process not running"
fi

용량 산정과 사이징

VPP의 성능은 메모리, CPU 코어 수, Hugepage 설정에 크게 의존합니다. 워크로드에 맞는 리소스를 사전에 산정해야 운영 중 성능 저하나 OOM(Out of Memory) 장애를 방지할 수 있습니다.

# Hugepage 산정 예시: 25GbE NIC, 워커 3개

# 1) 필요 버퍼 수 계산
# NIC 링 크기: rx 2048 + tx 2048 = 4096/NIC
# 파이프라인 버퍼: 워커당 ~8192개 (벡터 처리 + 큐잉)
# 총 버퍼: 4096 + (3 × 8192) = 28672 → 32768 (2의 거듭제곱)

# 2) 메모리 = 32768 × 2.2KB ≈ 72MB (버퍼)
#    + FIB/NAT/세션 등 추가 메모리
#    → 총 1GB (여유 포함) ~ 2GB 권장

# 3) 2MB Hugepage 기준: 1GB / 2MB = 512페이지
#    1GB Hugepage 기준: 1개 (또는 2개 권장)

# 커널 부트 파라미터
GRUB_CMDLINE_LINUX="default_hugepagesz=2M hugepagesz=2M hugepages=1024"

# 또는 런타임 할당 (권장하지 않음 — 단편화 가능)
$ echo 1024 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# 할당 상태 확인
$ cat /proc/meminfo | grep Huge
HugePages_Total:    1024
HugePages_Free:      980
HugePages_Rsvd:       44
Hugepagesize:       2048 kB

로깅과 Syslog 통합

VPP는 모듈별 로그 레벨 제어, 파일 로깅, syslog 전달을 지원합니다. 운영 환경에서는 로그를 중앙 로그 시스템으로 전달하여 장애 추적과 감사(audit)에 활용합니다.

# 파일 로그: startup.conf에서 설정
unix {
    log /var/log/vpp/vpp.log           ← VPP 메인 로그 파일
    full-coredump
}

# 로그 파일 로테이션: logrotate 연동
# /etc/logrotate.d/vpp
# /var/log/vpp/vpp.log {
#     daily
#     rotate 14
#     compress
#     missingok
#     notifempty
#     postrotate
#         vppctl set logging size 0   ← 로그 버퍼 리셋
#     endscript
# }

# 모듈별 로그 레벨 설정 (런타임)

# 현재 로그 설정 확인
vpp# show logging
  default level: warn
  unthrottled:   0

# 특정 모듈의 로그 레벨 변경
vpp# set logging class dpdk level debug
vpp# set logging class nat level info
vpp# set logging class acl-plugin level warn
vpp# set logging class session level notice

# 사용 가능한 로그 클래스 확인
vpp# show logging class
  Name                  Level
  acl-plugin            warn
  dpdk                  debug
  nat                   info
  session               notice
  ...

# Syslog 전달 설정

# 원격 syslog 서버로 전달
vpp# set logging syslog-address 10.0.0.10 port 514

# 실시간 로그 확인 (디버깅 시 유용)
vpp# show logging

# 특정 로그 엔트리 수 제한하여 확인
vpp# show logging count 50

# 로그 버퍼 크기 설정
vpp# set logging size 4096

VPP 플러그인 개발

VPP 플러그인은 그래프 노드(graph node)를 등록하여 패킷 처리 파이프라인에 새로운 기능을 삽입합니다. 커널 모듈과 달리 유저스페이스에서 동작하므로 크래시가 시스템 전체에 영향을 주지 않으며, 핫 리로드가 가능합니다.

VPP 핵심 API 함수 상세 분석

VPP 플러그인 개발에서 가장 빈번하게 사용되는 핵심 API 함수들을 상세히 분석합니다. 이 함수들은 패킷 처리 노드의 fn() 콜백 내에서 호출되며, 각 함수의 동작 원리와 올바른 사용 패턴을 이해하는 것이 고성능 플러그인 작성의 핵심입니다.

vlib_frame_vector_args() — 프레임에서 버퍼 인덱스 배열 획득

vlib_frame_vector_args()는 노드 함수에 전달된 프레임(vlib_frame_t)에서 버퍼 인덱스 배열의 시작 포인터를 반환합니다. 반환 타입은 u32*이며, 각 원소는 vlib_buffer_pool 내의 버퍼 인덱스입니다. 배열의 유효 크기는 frame->n_vectors로 확인할 수 있습니다.

/* vlib_frame_vector_args() 기본 사용 패턴 */
static uword
my_node_fn (vlib_main_t *vm,
            vlib_node_runtime_t *node,
            vlib_frame_t *frame)
{
    u32 n_left_from, *from;

    /* 프레임에서 버퍼 인덱스 배열 포인터 획득 */
    from = vlib_frame_vector_args (frame);

    /* 처리할 패킷 수 (1~VLIB_FRAME_SIZE, 최대 256) */
    n_left_from = frame->n_vectors;

    while (n_left_from > 0)
    {
        u32 bi0 = from[0];
        vlib_buffer_t *b0 = vlib_get_buffer (vm, bi0);

        /* b0->data + b0->current_data 위치부터 패킷 데이터 접근 */
        ip4_header_t *ip0 = vlib_buffer_get_current (b0);

        /* 패킷 처리 로직 ... */

        from += 1;
        n_left_from -= 1;
    }

    return frame->n_vectors;
}

vlib_frame_vector_args()가 반환하는 포인터는 프레임 구조체 바로 뒤에 위치한 인라인 배열을 가리킵니다. 프레임은 노드 런타임에 의해 사전 할당되므로 별도의 메모리 할당이 발생하지 않습니다. 반환 값의 수명은 현재 노드 함수 실행 동안에만 유효합니다.

vlib_get_next_frame() / vlib_put_next_frame() — 다음 노드로의 프레임 관리

vlib_get_next_frame()은 다음 노드로 패킷을 전달하기 위한 출력 프레임의 참조를 획득합니다. vlib_put_next_frame()은 처리 완료 후 프레임을 반환하며, 실제로 전달할 벡터 수를 갱신합니다. 이 두 함수는 반드시 쌍(pair)으로 호출해야 합니다.

/* get_next_frame / put_next_frame 쌍 사용 패턴 */
u32 n_left_from, *from;
u32 n_left_to_next, *to_next;
u32 next_index;

from = vlib_frame_vector_args (frame);
n_left_from = frame->n_vectors;
next_index = node->cached_next_index;

while (n_left_from > 0)
{
    /* 다음 노드의 출력 프레임 참조 획득 */
    vlib_get_next_frame (vm, node, next_index,
                        to_next, n_left_to_next);

    while (n_left_from > 0 && n_left_to_next > 0)
    {
        u32 bi0 = from[0];
        u32 next0 = next_index;

        to_next[0] = bi0;
        from += 1;
        to_next += 1;
        n_left_from -= 1;
        n_left_to_next -= 1;

        /* next0가 변경될 수 있는 경우 validate_buffer_enqueue 사용 */
        vlib_validate_buffer_enqueue_x1 (vm, node, next_index,
                                         to_next, n_left_to_next,
                                         bi0, next0);
    }

    /* 프레임 반환: n_left_to_next 값으로 실제 전달 수 계산 */
    vlib_put_next_frame (vm, node, next_index, n_left_to_next);
}

vlib_get_next_frame()은 내부적으로 next_index에 해당하는 다음 노드의 보류 프레임(pending frame)을 조회합니다. 보류 프레임이 없으면 새로 할당합니다. to_next는 해당 프레임의 버퍼 인덱스 배열 끝 위치를, n_left_to_next는 남은 슬롯 수를 반환합니다.

vlib_put_next_frame()은 n_left_to_next 값을 사용하여 실제로 프레임에 추가된 벡터 수를 계산하고, 프레임을 보류 큐에 등록합니다. 이 함수를 호출하지 않으면 프레임이 다음 노드에 전달되지 않으며, 버퍼가 누수됩니다. 반대로 get 없이 put을 호출하면 초기화되지 않은 상태에서 접근하여 정의되지 않은 동작이 발생합니다.

vlib_validate_buffer_enqueue_x1/x2/x4() — 버퍼 큐잉 최적화

vlib_validate_buffer_enqueue 매크로 계열은 패킷을 다음 노드로 전달할 때 next_index 변경을 효율적으로 처리합니다. 같은 next_index로 연속 전달 시에는 fast-path로 동작하여 추가 복사가 불필요하지만, next_index가 변경되면 slow-path에서 현재 프레임을 반환하고 새 프레임을 획득합니다.

/* vlib_validate_buffer_enqueue_x1 매크로 의사 코드 (pseudo-code) */
/*
 * 매개변수:
 *   vm            — vlib_main_t*
 *   node          — vlib_node_runtime_t*
 *   next_index    — 현재 프레임이 가리키는 다음 노드 인덱스 (변경 가능)
 *   to_next       — 출력 프레임 버퍼 인덱스 배열 포인터
 *   n_left_to_next — 출력 프레임 남은 슬롯 수
 *   bi0           — 현재 패킷 버퍼 인덱스
 *   next0         — 이 패킷이 가야 할 다음 노드 인덱스
 */
if (PREDICT_FALSE (next0 != next_index))
{
    /* slow-path: next_index가 변경됨 */
    /* 1. 현재 프레임에서 방금 기록한 bi0를 제거 (to_next 롤백) */
    /* 2. 현재 프레임을 반환 (put_next_frame) */
    /* 3. next0에 해당하는 새 프레임 획득 (get_next_frame) */
    /* 4. 새 프레임에 bi0 기록 */
    /* 5. 새 프레임 반환 (put_next_frame) */
    /* 6. 원래 next_index의 프레임 재획득 (get_next_frame) */
    vlib_set_next_frame_buffer (vm, node, next0, bi0);
    n_left_to_next += 1;  /* 롤백한 슬롯 복원 */
}
/* fast-path: next0 == next_index → 이미 to_next에 기록되어 있으므로 추가 작업 없음 */

x2와 x4 변형은 각각 2개, 4개의 패킷을 동시에 처리하여 명령어 수준 병렬성(ILP, Instruction-Level Parallelism)을 활용합니다. 현대 CPU의 슈퍼스칼라 파이프라인에서 독립적인 메모리 접근과 분기 예측을 병렬로 수행할 수 있습니다.

/* x2 변형: 2개 패킷 동시 큐잉 */
while (n_left_from >= 4 && n_left_to_next >= 2)
{
    u32 bi0, bi1;
    u32 next0, next1;
    vlib_buffer_t *b0, *b1;

    /* 프리페치: 2개 앞의 패킷을 미리 캐시에 적재 */
    {
        vlib_buffer_t *p2, *p3;
        p2 = vlib_get_buffer (vm, from[2]);
        p3 = vlib_get_buffer (vm, from[3]);
        vlib_prefetch_buffer_header (p2, LOAD);
        vlib_prefetch_buffer_header (p3, LOAD);
    }

    bi0 = from[0]; bi1 = from[1];
    to_next[0] = bi0; to_next[1] = bi1;

    b0 = vlib_get_buffer (vm, bi0);
    b1 = vlib_get_buffer (vm, bi1);

    /* 각 패킷의 next_index 결정 */
    next0 = process_packet (b0);
    next1 = process_packet (b1);

    from += 2; to_next += 2;
    n_left_from -= 2; n_left_to_next -= 2;

    vlib_validate_buffer_enqueue_x2 (vm, node, next_index,
                                     to_next, n_left_to_next,
                                     bi0, bi1, next0, next1);
}

x1은 패킷 단위 처리로 코드가 단순하지만 ILP를 활용하지 못합니다. x2는 2개 패킷을 병렬 처리하여 L1/L2 캐시 미스 대기 시간을 숨길 수 있으며, x4는 4개 패킷을 병렬 처리하여 최대 처리량을 달성합니다. 일반적으로 dual-loop(x2)와 single-loop(x1)를 조합하여 n_left_from이 2 미만일 때 x1으로 나머지를 처리하는 패턴을 사용합니다.

vlib_buffer_advance() — 헤더 파싱을 위한 포인터 이동

vlib_buffer_advance()는 버퍼의 current_data 오프셋과 current_length를 동시에 조정하여 패킷 데이터 내에서 논리적 시작 위치를 이동합니다. 양수 값을 전달하면 헤더를 건너뛰어 디캡슐화(decapsulation) 효과를 내고, 음수 값을 전달하면 헤더 공간을 확보하여 캡슐화(encapsulation)를 수행합니다.

/* vlib_buffer_advance() 내부 동작 */
/*
 * b->current_data += advance;
 * b->current_length -= advance;
 *
 * 양수(+N): current_data를 N바이트 뒤로 이동 → 헤더 스킵
 * 음수(-N): current_data를 N바이트 앞으로 이동 → 헤더 공간 확보
 */

/* 예시 1: 이더넷 헤더 스킵 후 IP 헤더 접근 (디캡슐화) */
ethernet_header_t *eth = vlib_buffer_get_current (b0);
u16 ethertype = clib_net_to_host_u16 (eth->type);

/* current_data += sizeof(ethernet_header_t) */
vlib_buffer_advance (b0, sizeof (ethernet_header_t));

/* 이제 vlib_buffer_get_current()는 IP 헤더를 가리킵니다 */
ip4_header_t *ip0 = vlib_buffer_get_current (b0);

/* 예시 2: 새 헤더 추가 (캡슐화) */
/* current_data -= sizeof(my_header_t) → 앞쪽 headroom 사용 */
vlib_buffer_advance (b0, -(i32) sizeof (my_header_t));
my_header_t *hdr = vlib_buffer_get_current (b0);
hdr->version = 1;
hdr->length = clib_host_to_net_u16 (payload_len);