디버깅 · 성능 측정

VPP 운영 중 실제로 마주치는 문제를 진단·복구하고, 성능을 측정·비교하는 방법을 정리합니다. 패킷 트레이싱·PCAP·이벤트 로거 같은 내부 계측 도구, 증상별 트러블슈팅 매트릭스, 흔한 설정 실수와 안티패턴, HTTP 프로토콜 레벨 트러블슈팅, TRex 기반 외부 벤치마크까지 다룹니다.

성능 측정 및 벤치마크

VPP 구성을 완료한 뒤, 실제 처리량과 지연을 측정하는 체계적인 방법을 소개합니다. 수치 없는 "잘 되는 것 같다"는 운영에서 통하지 않습니다.

TRex를 이용한 트래픽 생성

TRex는 DPDK 기반 고성능 트래픽 생성기로, VPP 벤치마크의 사실상 표준입니다. CSIT(Continuous System Integration Testing)에서도 TRex를 사용합니다.

# TRex STL(Stateless) 프로파일 — NAT44 부하 테스트
from trex_stl_lib.api import *

class STLS1(object):
    def create_stream(self):
        base_pkt = Ether() / IP(
            src="192.168.1.10",
            dst="198.51.100.10"
        ) / UDP(
            sport=1024,
            dport=80
        ) / ("X" * 16)

        # 소스 IP와 포트를 변경하여 다양한 플로우 생성
        vm = STLScVmRaw([
            STLVmFlowVar(name="src_ip",
                         min_value="192.168.1.10",
                         max_value="192.168.1.250",
                         size=4, op="inc"),
            STLVmWrFlowVar(fv_name="src_ip",
                           pkt_offset="IP.src"),
            STLVmFlowVar(name="src_port",
                         min_value=1024,
                         max_value=60000,
                         size=2, op="inc"),
            STLVmWrFlowVar(fv_name="src_port",
                           pkt_offset="UDP.sport"),
            STLVmFixIpv4(offset="IP"),
        ])

        return STLStream(
            packet=STLPktBuilder(pkt=base_pkt, vm=vm),
            mode=STLTXCont(pps=1000000)  # 1Mpps부터 시작
        )

    def get_streams(self, **kwargs):
        return [self.create_stream()]

def register():
    return STLS1()

# TRex 실행 및 결과 확인
$ sudo ./t-rex-64 -i -c 4 --cfg /etc/trex_cfg.yaml

# TRex 콘솔에서:
trex> start -f nat44_test.py -m 5mpps -d 60
trex> stats
# TX: 5.00 Mpps, RX: 4.98 Mpps → 드롭율 0.04%

# VPP 측에서 동시에 확인:
vpp# show runtime
vpp# show interface GigabitEthernet0/8/0
vpp# show nat44 sessions count

VPP 내부 성능 카운터 해석

show runtime 출력의 각 열이 무엇을 뜻하는지 정확히 알아야 병목을 찾을 수 있습니다.

Name                 State    Calls    Vectors  Suspends  Clocks   Vectors/Call
dpdk-input           polling  1234567  9.87e7   0         22.1     79.9
ethernet-input       active   1234567  9.87e7   0         8.3      79.9
ip4-input            active   1234567  9.87e7   0         12.5     79.9
ip4-lookup           active   1234567  9.87e7   0         15.2     79.9
nat44-ed-in2out      active   1200000  9.60e7   0         44.3     80.0
ip4-rewrite          active   1200000  9.60e7   0         9.8      80.0
GigE0/9/0-output     active   1200000  9.60e7   0         5.1      80.0
GigE0/9/0-tx         active   1200000  9.60e7   0         18.7     80.0

디버깅 및 트러블슈팅

패킷 트레이싱

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

자주 발생하는 문제와 해결

트러블슈팅 가이드

VPP 실전 구성에서 자주 만나는 문제와 체계적인 진단 방법을 정리합니다.

패킷이 전달되지 않는 경우

# 1단계: 인터페이스 상태 확인
vpp# show interface
# 모든 인터페이스가 'up'인지 확인
# 'admin-down'이면: set interface state  up

# 2단계: 수신 패킷 확인
vpp# clear interface counters
# 트래픽 생성 후:
vpp# show interface
# rx-pkts가 증가하는지 확인
# 증가하지 않으면: DPDK 바인딩, Hugepage, NIC 드라이버 문제

# 3단계: 패킷 추적
vpp# clear trace
vpp# trace add dpdk-input 20
# 트래픽 생성 후:
vpp# show trace
# 패킷이 어느 노드에서 드롭되는지 확인
# 'error' 또는 'drop' 노드에서 끝나면 해당 에러 메시지 확인

# 4단계: 에러 카운터 확인
vpp# show errors
# 가장 높은 에러 카운터부터 추적

# 5단계: FIB(라우팅 테이블) 확인
vpp# show ip fib                  # 전체 라우팅 테이블
vpp# show ip fib 198.51.100.0/24  # 특정 서브넷 경로

자주 발생하는 문제와 해결법

패킷 캡처 (pcap)

패킷 내용을 직접 확인해야 할 때는 VPP의 내장 pcap 기능을 사용합니다. tcpdump와 달리 커널을 거치지 않으므로 DPDK 인터페이스의 패킷도 캡처할 수 있습니다.

# 특정 인터페이스의 수신 패킷 캡처
vpp# pcap trace rx tx max 1000 intfc GigabitEthernet0/8/0 \
     file /tmp/vpp-capture.pcap

# 트래픽 발생 후 캡처 중지
vpp# pcap trace off

# 호스트에서 Wireshark로 분석
$ wireshark /tmp/vpp-capture.pcap

# 또는 tcpdump로 빠르게 확인
$ tcpdump -r /tmp/vpp-capture.pcap -nn | head -20

# 그래프 노드 단위 캡처 (더 세밀한 분석)
vpp# pcap trace rx tx max 500 \
     classify-table-index 0 \
     file /tmp/vpp-classified.pcap

흔한 실수와 안티패턴

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

L7 트러블슈팅 — HTTP 파싱 오류부터 워커 편중까지

L4 트러블슈팅이 패킷 드롭·재전송·MTU 같은 전송 계층 문제에 집중한다면, L7 트러블슈팅은 한 단계 더 위에서 시작합니다. 이 절은 운영에서 자주 마주치는 6가지 L7 증상을 골라, 증상 → 가설 → 진단 명령 → 해결 패턴 순으로 정리합니다.

증상별 진단 매트릭스

L7 pcap — vppctl trace + 외부 분석

VPP는 자체 패킷 트레이스(trace add)와 pcap 캡처(pcap trace)를 모두 제공합니다. L7 문제 해결에는 두 도구를 조합해야 합니다.

# 1) HTTP 게이트웨이 인터페이스에서 캡처
vppctl pcap trace rx tx max 5000 \
    intfc TenGigabitEthernet0/0/0 \
    file /tmp/http-debug.pcap \
    filter classify table 0 match l3 ip4 dst 192.0.2.10 \
                            l4 tcp dst-port 443

# 2) 캡처 시작 후 재현
curl -k -v https://192.0.2.10/api/v1/version

# 3) 캡처 종료
vppctl pcap trace off

# 4) Wireshark에서 분석
wireshark /tmp/http-debug.pcap
# - TLS pre-master secret 있으면 복호화 후 HTTP 메시지 확인
# - HTTP/2는 Wireshark가 자동 해석 (SETTINGS·HEADERS·DATA 프레임)

# 5) 그래프 노드 트레이스 (헤더 파싱 단계까지 추적)
vppctl trace add dpdk-input 100
vppctl show trace | grep -A 20 'http-static'

show 명령 카드

# 세션 레이어 상태
vppctl show session verbose 2          # 모든 활성 세션
vppctl show session thread 0 verbose   # 워커 0만

# HTTP/2 스트림 상세
vppctl show http2 conn
vppctl show http2 stream <conn-id> <stream-id>
# - state: open / half-closed / closed
# - recv_window / send_window
# - bytes_sent / bytes_recv

# TLS 세션
vppctl show tls
vppctl show tls openssl ctx 0
# - cipher / version / sni / alpn
# - resumption: full / psk / 0-rtt

# 게이트웨이 라우팅·캐시
vppctl show http gateway routes
vppctl show http gateway upstream
vppctl show http gateway cache top 20

# 워커 편중 진단
for i in 0 1 2 3; do
  echo "Worker $i:"
  vppctl show session thread $i | grep -c 'state ESTABLISHED'
done

자주 마주치는 증상 — 해결 레시피 4가지

레시피 1: 특정 vhost만 5xx

1. rate(http_requests_total{status=~"5..", vhost="api.example.com"}[5m]) 추세 확인
2. 같은 시간대 http_upstream_failures_total{upstream="api-backend-1"} 동반 상승 여부
3. 업스트림 헬스체크 결과(show http gateway upstream)에서 응답 시간 분포 확인
4. 해결: 업스트림 health check interval 단축, 회로 차단 임계 강화, 트래픽 일부를 백업 업스트림으로 이동

레시피 2: HTTP/2 스트림이 멈춤

1. show http2 stream에서 send_window=0 확인
2. 같은 연결의 다른 스트림도 같은 상태면 연결 윈도 고갈, 한 스트림만이면 스트림 윈도 고갈
3. 대형 응답 BDP 계산: BDP = bandwidth × RTT. 100Mbps × 100ms = 1.25MB
4. 해결: SETTINGS_INITIAL_WINDOW_SIZE를 BDP × 2 이상으로 설정. VPP CLI 또는 startup.conf의 http2 절

레시피 3: 워커 편중으로 한 워커만 100%

1. vppctl show runtime에서 워커별 vector rate 비교 — 한 워커만 0.9 이상이면 편중
2. show session thread N에서 활성 세션 수 비교
3. 가설 1: NIC RSS 키가 비대칭 → show hardware-interfaces에서 RSS 큐 분포 확인
4. 가설 2: 한 클라이언트가 단일 연결로 거대한 HTTP/2 스트림 폭주 → SETTINGS_MAX_CONCURRENT_STREAMS 하향
5. 해결: RSS 대칭 해시(Toeplitz 키 0x6d5a) 적용, 또는 HAProxy 같은 L7 LB로 사전 분산

레시피 4: 캐시 적중률 급락

1. show http gateway cache의 entries / bytes / evictions 추세 확인
2. evictions 폭증 + 적중률 감소 → 캐시 크기 부족 또는 키 폭증
3. 키 폭증 가설: 새 배포 후 Vary 헤더에 변동성 큰 헤더(예: User-Agent) 추가됨
4. 해결: Vary 정규화, 캐시 크기 상향, 또는 stale-while-revalidate 도입으로 백그라운드 갱신

Common Pitfalls

• 총량 메트릭만 봄 — 전체 5xx가 0.5%여도 특정 vhost나 path는 50%일 수 있습니다. 라벨로 분해해야 합니다.
• p99 대신 평균만 봄 — 평균은 long-tail을 숨깁니다. 사용자 체감은 p95~p99에서 결정됩니다.
• 워커 단위 미관찰 — 노드 전체 CPU가 50%여도 한 워커는 100%일 수 있습니다. per-worker 게이지가 필수입니다.
• pcap 대용량 — 100Gbps 트래픽을 그대로 캡처하면 디스크가 즉시 가득 찹니다. 반드시 classify table로 5튜플 필터를 좁히고, max를 작게 잡아야 합니다.
• 메트릭 카디널리티 폭발 — 라벨에 path를 그대로 넣으면 카디널리티가 폭발합니다. /api/v1/users/12345 → /api/v1/users/:id로 정규화해야 합니다.

디버깅 보조 도구 — PG · nsim · BPF Trace Filter

VPP에는 장애 재현과 조건부 트레이스를 돕는 소규모 도구 세 개가 있습니다. 일상 운영에서 자주 언급되지 않지만 어려운 버그를 잡을 때 결정적인 역할을 합니다. 상시 관측 도구(perfmon/sFlow/IPFIX 등)는 관측성 · 원격 측정에서 다룹니다.

Packet Generator (PG) — 재현 주입

문제를 겪은 패킷 패턴을 외부 장비 없이 VPP 안에서 직접 재현하고 싶을 때 PG가 최적입니다. 헤더 조합을 스크립트로 정의하고, 원하는 비율로 특정 노드에 주입할 수 있어 엣지 케이스 회귀 테스트에도 적합합니다.

vpp# packet-generator new {
  name bug-repro
  limit 100
  node ip4-input
  size 64-1500
  data { IP4: 10.0.0.1 -> 10.0.0.2
         UDP: 1234 -> 5678
         incrementing 100 }
}
vpp# trace add pg-input 100
vpp# packet-generator enable-stream bug-repro
vpp# show trace

장점은 외부 트래픽 생성기(TRex 등) 없이도 패킷 레벨 정확도로 동일 시나리오를 재현할 수 있다는 점입니다. 단점은 pps가 제한적이라 성능 재현 테스트에는 부적합합니다.

nsim — 네트워크 지연 시뮬레이션

nsim은 인터페이스 송신 경로에 지연·대역폭 한계·손실을 주입해 WAN 환경을 재현합니다. 리눅스 netem의 VPP 버전으로, TCP 혼잡 제어가 특정 조건에서 어떻게 동작하는지 검증할 때 결정적입니다.

vpp# nsim output-feature enable-disable <if>
vpp# set nsim delay 100.0 ms bandwidth 10.0 mbit packets-per-drop 1000
vpp# show nsim

실전 시나리오 예:

• 클라이언트가 고속 백본을 거쳐 접속할 때만 발생하는 TLS 재전송 버그 재현
• HTTP/3 QUIC connection migration의 handoff 지연 측정
• TCP BBR vs CUBIC 혼잡 제어 차이 검증

BPF Trace Filter — 조건부 트레이스

일반 trace add는 지정 노드에 들어오는 모든 패킷을 캡처합니다. 트래픽이 많으면 금세 버퍼가 가득 차고, 정작 문제 패킷은 놓치기 쉽습니다. BPF Trace Filter는 tcpdump 문법으로 트레이스 대상을 정밀 필터링합니다.

vpp# set trace filter function-name vlib_trace_filter_bpf      expr "host 192.0.2.100 and tcp port 443"
vpp# trace add dpdk-input 1000
# 문제 재현 후
vpp# show trace

BPF 식은 libpcap 문법을 그대로 사용하므로, tcpdump -d로 익숙한 사람은 바로 쓸 수 있습니다. 고PPS 운영 환경에서 특정 플로우만 정밀 관찰할 수 있어 진단 시간이 크게 단축됩니다.

도구 선택 요약