Data-Plane Objects · Adjacency · Tunnel Infra

VPP Data-Plane Objects(DPO), Adjacency, Tunnel Infra의 참조 구조와 포워딩 체인 구성 방식을 정리합니다.

선행 문서: 이 페이지는 기초와 아키텍처의 벡터 패킷 처리·그래프 노드 개념을 전제로 합니다. 내부 구현 카테고리의 다른 페이지와 함께 읽어 주세요.

VPP의 FIB·터널·로드 밸런싱은 모두 Data-Plane Object (DPO)라는 공통 추상화를 공유합니다. 이 페이지는 FIB 상세를 이해하려는 독자를 위해 DPO 모델과 Adjacency·Tunnel Infra의 관계를 정리합니다.

DPO — 데이터 평면 객체 모델

DPO는 "패킷이 이 객체에 도달했을 때 다음에 무엇을 할지"를 캡슐화한 객체입니다. 모든 DPO는 공통 헤더 dpo_id_t (type + index)를 가지며, 데이터 평면에서는 이 id만 보고 다음 노드를 결정합니다.

FIB 엔트리는 결국 DPO를 가리킵니다. 10.0.0.0/24 → 192.168.1.1 via eth0 같은 흔한 경로는 내부적으로 DPO_LOAD_BALANCEDPO_ADJACENCY 체인으로 표현됩니다.

vpp# show ip fib summary
vpp# show fib paths
vpp# show adj
vpp# show adj detail

Adjacency 종류

Adjacency는 "L2 다음 홉이 준비되었다"를 나타내는 객체입니다. 세 가지 상태가 있습니다.

Tunnel Infra — 공통 터널 추상화

VPP의 터널(IPsec·VXLAN·GRE·GTP-U·IP-in-IP·WireGuard)은 서로 다른 프로토콜이지만 내부적으로 같은 tunnel_t 인프라를 공유합니다. 터널 인터페이스는 midchain adjacency를 만들고, 송신 패킷은 먼저 midchain을 거쳐 캡슐화된 뒤 실제 output 인터페이스로 나갑니다.

/* src/vnet/tunnel/tunnel.h — 공통 구조 */
typedef struct {
  ip_address_t t_src;
  ip_address_t t_dst;
  tunnel_mode_t t_mode;     /* P2P · MP */
  tunnel_encap_decap_flags_t t_encap_decap_flags;
  ip_dscp_t t_dscp;
  u8 t_hop_limit;
  u32 t_table_id;            /* underlay VRF */
  u32 t_flags;
} tunnel_t;

이 공통 인프라 덕분에 새 터널 프로토콜을 추가할 때 인접성·FIB 재수렴·MTU 계산·DSCP 복사 등 공통 로직을 재사용할 수 있습니다. IPsec과 VXLAN이 완전히 다른 프로토콜인데도 MTU 조정과 fragmentation 처리가 일관되게 동작하는 이유입니다.

FIB Recursive Resolution

BGP 학습 경로는 종종 재귀적 next-hop을 가집니다. 예를 들어 10.0.0.0/24 → 203.0.113.1인데 203.0.113.1은 또 다른 프리픽스로 해석되어야 합니다. VPP의 FIB는 이런 재귀를 DPO 체인으로 표현해, 하위 경로가 바뀌면 상위 경로 수만 개도 자동으로 갱신됩니다.

vpp# ip route add 10.0.0.0/24 via 203.0.113.1
vpp# show ip fib 10.0.0.0/24
# 출력에 "recursive-resolution-via" 체인이 보임
운영 관점: FIB의 재귀 해석 깊이가 너무 깊어지면 패킷당 DPO 조회 횟수가 늘어 성능이 떨어집니다. show ip fib summary의 "recursive-depth" 통계를 주시하고, 평균 깊이가 3을 넘으면 경로 설계를 재검토해야 합니다.