eBPF + P4 프로그래머블 NGFW 파이프라인

eBPF 기반 차세대 NGFW 파이프라인과 P4 프로그래머블 NGFW 오프로드: BPF netfilter(커널 6.4+), Cilium eBPF 방화벽, tc-bpf vs XDP 비교, P4 match-action 테이블, Tofino/FPGA P4 NGFW 구현, P4 vs TC flower vs eBPF 비교

eBPF 기반 차세대 NGFW

eBPF(extended Berkeley Packet Filter)는 커널 내에서 안전하게 실행되는 프로그램을 통해 네트워크 패킷 처리를 프로그래밍할 수 있는 기술입니다. 전통적인 nftables/iptables 기반 방화벽을 넘어, eBPF는 더 유연하고 고성능인 NGFW 파이프라인을 구현할 수 있게 합니다.

eBPF NGFW의 장점과 한계

BPF netfilter 프로그램 (커널 6.4+)

Linux 커널 6.4에서 도입된 BPF_PROG_TYPE_NETFILTER는 Netfilter 훅 포인트에 BPF 프로그램을 직접 연결할 수 있게 합니다. 이를 통해 nftables 규칙 대신 BPF 프로그램으로 방화벽 로직을 구현할 수 있습니다.

/* BPF netfilter 프로그램 예시 — 세션 추적 + 오프로드 결정 */
/* 커널 6.4+ 필요, libbpf 사용 */

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <linux/netfilter.h>

/* conntrack kfunc 선언 (커널 6.4+) */
extern struct nf_conn *
bpf_xdp_ct_lookup(struct xdp_md *ctx,
                  struct bpf_sock_tuple *tuple, u32 len,
                  struct bpf_ct_opts *opts, u32 opts_len) __ksym;
extern void
bpf_ct_release(struct nf_conn *ct) __ksym;

/* 세션별 DPI 결과를 저장하는 BPF 맵 */
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 1000000);
    __type(key, struct flow_key);    /* 5-tuple */
    __type(value, struct flow_info);  /* DPI 결과 + 상태 */
} flow_map SEC(".maps");

/* DPI 완료 + ALLOW된 세션을 기록하는 맵 */
struct {
    __uint(type, BPF_MAP_TYPE_LRU_HASH);
    __uint(max_entries, 500000);
    __type(key, struct flow_key);
    __type(value, __u64);  /* 오프로드 타임스탬프 */
} offload_map SEC(".maps");

/* 통계 카운터 */
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 4);  /* 0:pass, 1:drop, 2:offload, 3:dpi */
    __type(key, __u32);
    __type(value, __u64);
} stats SEC(".maps");

struct flow_key {
    __be32 saddr;
    __be32 daddr;
    __be16 sport;
    __be16 dport;
    __u8   proto;
};

struct flow_info {
    __u32 app_id;        /* DPI 분류 결과 */
    __u32 verdict;       /* 0=pending, 1=allow, 2=deny */
    __u64 pkt_count;     /* 패킷 수 */
    __u64 byte_count;    /* 바이트 수 */
    __u64 last_seen;     /* 마지막 패킷 타임스탬프 */
};

SEC("netfilter")
int ngfw_filter(struct bpf_nf_ctx *ctx)
{
    struct sk_buff *skb = ctx->skb;
    struct flow_key key = {};
    struct flow_info *info;
    __u32 stat_key;

    /* 5-tuple 추출 */
    if (extract_flow_key(skb, &key) < 0)
        return NF_ACCEPT;

    /* flow_map에서 기존 세션 조회 */
    info = bpf_map_lookup_elem(&flow_map, &key);

    if (!info) {
        /* 새 세션: flow_map에 등록하고 DPI로 전달 */
        struct flow_info new_info = {
            .verdict = 0,  /* pending */
            .pkt_count = 1,
        };
        bpf_map_update_elem(&flow_map, &key, &new_info, BPF_ANY);
        stat_key = 3;  /* DPI로 전달 */
        update_stats(&stats, stat_key);
        return NF_ACCEPT;  /* Slow Path로 진행 */
    }

    /* DPI 결과에 따른 처리 */
    switch (info->verdict) {
    case 1:  /* ALLOW */
        info->pkt_count++;
        info->byte_count += skb->len;
        info->last_seen = bpf_ktime_get_ns();

        /* 10패킷 이상이면 오프로드 대상으로 마킹 */
        if (info->pkt_count > 10 &&
            !bpf_map_lookup_elem(&offload_map, &key)) {
            __u64 ts = bpf_ktime_get_ns();
            bpf_map_update_elem(&offload_map, &key, &ts, BPF_ANY);
            stat_key = 2;
            update_stats(&stats, stat_key);
        }

        stat_key = 0;
        update_stats(&stats, stat_key);
        return NF_ACCEPT;

    case 2:  /* DENY */
        stat_key = 1;
        update_stats(&stats, stat_key);
        return NF_DROP;

    default:  /* PENDING — 아직 DPI 진행 중 */
        info->pkt_count++;
        return NF_ACCEPT;
    }
}

char _license[] SEC("license") = "GPL";

BPF kfunc conntrack API 상세

Linux 커널 6.4부터 BPF 프로그램에서 커널의 nf_conntrack 서브시스템에 직접 접근할 수 있는 kfunc(Kernel Function) 인터페이스가 도입되었습니다. 기존에는 Cilium처럼 BPF 맵으로 자체 conntrack을 구현해야 했지만, kfunc를 사용하면 커널 conntrack과 완전히 일관된 세션 상태를 BPF 프로그램에서 활용할 수 있습니다.

kfunc conntrack 함수 목록 (커널 6.4~6.10)

주요 kfunc 시그니처

/* bpf_xdp_ct_lookup — XDP 프로그램에서 conntrack 조회 */
struct nf_conn *
bpf_xdp_ct_lookup(struct xdp_md *xdp_ctx,
                  struct bpf_sock_tuple *tuple,
                  u32 tuple_size,
                  struct bpf_ct_opts *opts,
                  u32 opts_size) __ksym;

/* bpf_skb_ct_lookup — TC/Netfilter 프로그램에서 conntrack 조회 */
struct nf_conn *
bpf_skb_ct_lookup(struct __sk_buff *skb_ctx,
                  struct bpf_sock_tuple *tuple,
                  u32 tuple_size,
                  struct bpf_ct_opts *opts,
                  u32 opts_size) __ksym;

/* bpf_ct_insert_entry — 새 conntrack 엔트리 삽입 */
struct nf_conn *
bpf_ct_insert_entry(struct nf_conn___init *nfct_i,
                    struct bpf_sock_tuple *tuple,
                    u32 tuple_size,
                    struct bpf_ct_opts *opts,
                    u32 opts_size) __ksym;

/* bpf_ct_release — conntrack 엔트리 참조 해제 (반드시 호출 필수) */
void bpf_ct_release(struct nf_conn *nfct) __ksym;

/* bpf_ct_set_timeout / bpf_ct_change_timeout */
int bpf_ct_set_timeout(struct nf_conn___init *nfct_i, u32 timeout) __ksym;
int bpf_ct_change_timeout(struct nf_conn *nfct, u32 timeout) __ksym;

/* bpf_ct_set_status / bpf_ct_change_status */
int bpf_ct_set_status(struct nf_conn___init *nfct_i, u32 status) __ksym;
int bpf_ct_change_status(struct nf_conn *nfct, u32 status) __ksym;

/* bpf_ct_opts 구조체 */
struct bpf_ct_opts {
    s32 netns_id;    /* 네트워크 네임스페이스 ID (-1 = 현재) */
    s32 error;       /* 반환 시 에러 코드 */
    u8  l4proto;     /* IPPROTO_TCP, IPPROTO_UDP 등 */
    u8  dir;         /* IP_CT_DIR_ORIGINAL 또는 IP_CT_DIR_REPLY */
    u8  reserved[2]; /* 패딩 */
};

kfunc CT 활용 BPF 프로그램 예시

/* kfunc conntrack API를 활용한 스테이트풀 방화벽 */
/* 커널 6.4+, libbpf 1.2+ 필요 */

#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>
#include <bpf/bpf_endian.h>
#include <linux/if_ether.h>
#include <linux/ip.h>
#include <linux/tcp.h>

/* kfunc 선언 */
extern struct nf_conn *bpf_skb_ct_lookup(
    struct __sk_buff *, struct bpf_sock_tuple *,
    u32, struct bpf_ct_opts *, u32) __ksym;
extern struct nf_conn *bpf_ct_insert_entry(
    struct nf_conn___init *, struct bpf_sock_tuple *,
    u32, struct bpf_ct_opts *, u32) __ksym;
extern void bpf_ct_release(struct nf_conn *) __ksym;
extern int bpf_ct_set_timeout(
    struct nf_conn___init *, u32) __ksym;
extern int bpf_ct_change_timeout(
    struct nf_conn *, u32) __ksym;

/* 허용 포트 맵 */
struct {
    __uint(type, BPF_MAP_TYPE_HASH);
    __uint(max_entries, 1024);
    __type(key, __u16);      /* 목적지 포트 */
    __type(value, __u8);     /* 1=허용 */
} allowed_ports SEC(".maps");

/* Per-CPU 통계 */
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 3);  /* 0:허용, 1:차단, 2:CT히트 */
    __type(key, __u32);
    __type(value, __u64);
} fw_stats SEC(".maps");

static __always_inline void inc_stat(__u32 idx)
{
    __u64 *val = bpf_map_lookup_elem(&fw_stats, &idx);
    if (val) (*val)++;
}

SEC("tc")
int stateful_fw(struct __sk_buff *skb)
{
    void *data     = (void *)(long)skb->data;
    void *data_end = (void *)(long)skb->data_end;

    struct ethhdr *eth = data;
    if ((void *)(eth + 1) > data_end)
        return TC_ACT_OK;
    if (eth->h_proto != bpf_htons(ETH_P_IP))
        return TC_ACT_OK;

    struct iphdr *ip = (void *)(eth + 1);
    if ((void *)(ip + 1) > data_end)
        return TC_ACT_OK;
    if (ip->protocol != IPPROTO_TCP)
        return TC_ACT_OK;

    struct tcphdr *tcp = (void *)ip + (ip->ihl * 4);
    if ((void *)(tcp + 1) > data_end)
        return TC_ACT_OK;

    /* 5-tuple 구성 */
    struct bpf_sock_tuple tuple = {};
    tuple.ipv4.saddr = ip->saddr;
    tuple.ipv4.daddr = ip->daddr;
    tuple.ipv4.sport = tcp->source;
    tuple.ipv4.dport = tcp->dest;

    struct bpf_ct_opts opts = {
        .netns_id = -1,
        .l4proto  = IPPROTO_TCP,
    };

    /* 1단계: 커널 conntrack 조회 */
    struct nf_conn *ct = bpf_skb_ct_lookup(
        skb, &tuple, sizeof(tuple.ipv4),
        &opts, sizeof(opts));

    if (ct) {
        /* 기존 세션 — 타임아웃 갱신 후 허용 */
        bpf_ct_change_timeout(ct, 300); /* 5분 */
        bpf_ct_release(ct);
        inc_stat(2);  /* CT 히트 */
        return TC_ACT_OK;
    }

    /* 2단계: 새 세션 — 허용 포트인지 확인 */
    __u16 dport = bpf_ntohs(tcp->dest);
    __u8 *allowed = bpf_map_lookup_elem(&allowed_ports, &dport);
    if (!allowed) {
        inc_stat(1);  /* 차단 */
        return TC_ACT_SHOT;
    }

    /* 3단계: 새 conntrack 엔트리 삽입 */
    opts.error = 0;
    struct nf_conn *new_ct = bpf_ct_insert_entry(
        (struct nf_conn___init *)ct,
        &tuple, sizeof(tuple.ipv4),
        &opts, sizeof(opts));
    if (new_ct)
        bpf_ct_release(new_ct);

    inc_stat(0);  /* 허용 */
    return TC_ACT_OK;
}

char _license[] SEC("license") = "GPL";

kfunc CT vs BPF 맵 기반 CT 비교

Cilium의 eBPF 방화벽 아키텍처

Cilium은 Kubernetes 환경에서 가장 널리 사용되는 eBPF 기반 CNI + 방화벽 솔루션입니다. 커널의 nf_conntrack과 nftables를 사용하지 않고, eBPF 맵으로 자체 conntrack과 정책 엔진(Policy Engine)을 구현합니다.

Cilium의 데이터 플레인 파이프라인은 다음과 같은 순서로 실행됩니다:

• 1단계 — XDP pre-filter: 인입 트래픽에서 명백한 공격(SYN flood, 잘못된 패킷)을 드라이버 수준에서 차단
• 2단계 — tc-bpf ingress: 목적지 Pod의 identity를 lookup하고, CT map에서 기존 세션을 조회
• 3단계 — Policy 평가: source identity + destination identity 조합으로 policy map에서 ALLOW/DENY 판정
• 4단계 — CT update: 새 세션이면 CT map에 엔트리 생성, 기존 세션이면 카운터와 타임스탬프 갱신
• 5단계 — NAT/LB: ClusterIP → Pod IP 변환, NodePort → Pod IP 변환
• 6단계 — redirect: bpf_redirect_peer()로 veth 피어를 통해 목적지 Pod에 직접 전달 (네트워크 스택 우회)

/* Cilium CT map 구조 (간소화) */
/* bpf/lib/conntrack.h 참고 */

struct ct_entry {
    __u64 rx_packets;        /* 수신 패킷 수 */
    __u64 rx_bytes;          /* 수신 바이트 */
    __u64 tx_packets;        /* 송신 패킷 수 */
    __u64 tx_bytes;          /* 송신 바이트 */
    __u32 lifetime;          /* 남은 수명 (초) */
    __u16 rx_closing:1;      /* FIN 수신 */
    __u16 tx_closing:1;      /* FIN 송신 */
    __u16 nat46:1;           /* NAT46 변환 */
    __u16 lb_loopback:1;     /* LB 루프백 */
    __u16 seen_non_syn:1;    /* SYN 이후 패킷 확인 */
    __u16 node_port:1;       /* NodePort 플래그 */
    __u8  rev_nat_index;     /* 역NAT 인덱스 */
    __u8  slave;             /* LB backend 슬롯 */
    __u16 ifindex;           /* 출력 인터페이스 */
    __u32 src_sec_id;        /* 소스 보안 identity */
};

/* CT GC (Garbage Collection) — 유저스페이스 에이전트 */
/* cilium-agent가 주기적으로 CT map을 순회하며 만료 엔트리 삭제 */
/* GC 주기: 기본 12초, conntrack-gc-interval 옵션으로 조절 */
/* GC 전략: */
/*   1. lifetime이 0인 엔트리 삭제 */
/*   2. TCP FIN/RST 후 grace period 만료 엔트리 삭제 */
/*   3. NAT map의 orphan 엔트리 정리 */

Calico eBPF 데이터 플레인

Calico는 Tigera가 개발한 Kubernetes 네트워킹 + 보안 솔루션으로, v3.13부터 eBPF 데이터 플레인을 지원합니다. Cilium과 달리 Calico는 기존 iptables 모드와 eBPF 모드를 선택적으로 전환할 수 있으며, BGP 기반 라우팅과 VXLAN 오버레이를 모두 지원합니다.

Calico iptables vs eBPF 모드 비교

Calico eBPF 아키텍처

Calico eBPF 모드는 tc-bpf 프로그램을 각 인터페이스의 ingress와 egress에 부착하여 패킷을 처리합니다. Cilium과 유사하지만, 호스트 엔드포인트(Host Endpoint) 보호와 VXLAN + BPF 조합에서 차별화됩니다.

• Workload Endpoint(WEP): Pod의 veth 인터페이스에 tc-bpf 프로그램을 부착합니다. ingress에서 정책 평가, egress에서 conntrack 업데이트를 수행합니다.
• Host Endpoint(HEP): 호스트의 물리/가상 인터페이스에도 tc-bpf를 부착하여 호스트 레벨 방화벽을 구현합니다. Cilium은 기본적으로 Pod 간 트래픽에 집중하지만, Calico는 호스트 자체의 보안까지 커버합니다.
• VXLAN + BPF: VXLAN 터널 인터페이스에도 BPF 프로그램을 부착하여 터널링 전후로 정책을 적용합니다. 터널 내부 패킷에도 정책이 일관되게 적용됩니다.

Calico 핵심 BPF 맵

Calico eBPF 모드 설정

# 1. Calico 설치 (Operator 기반, v3.26+)
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.0/manifests/tigera-operator.yaml

# 2. eBPF 데이터 플레인 활성화
cat <<EOF | kubectl apply -f -
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec:
  calicoNetwork:
    linuxDataplane: BPFDataplane
    bgp: Enabled
    ipPools:
    - cidr: 10.244.0.0/16
      encapsulation: VXLAN
EOF

# 3. kube-proxy 비활성화 (eBPF 모드에서 불필요)
kubectl patch ds -n kube-system kube-proxy \
  -p '{"spec":{"template":{"spec":{"nodeSelector":{"non-calico": "true"}}}}}'

# 4. eBPF 모드 동작 확인
kubectl get felixconfiguration default -o yaml | grep bpfEnabled
# bpfEnabled: true

# 5. BPF 프로그램 부착 확인
tc filter show dev eth0 ingress
# filter protocol all pref 1 bpf chain 0
#   handle 0x1 calico_from_host_ep ...

# 6. conntrack 맵 엔트리 확인
calico-bpf conntrack dump | head -20

Calico eBPF vs Cilium 성능 비교

tc-bpf vs XDP vs BPF netfilter 비교

eBPF 기반 NGFW를 구현할 때 사용할 수 있는 3가지 BPF 프로그램 타입의 특성을 비교합니다:

각 BPF 타입의 NGFW에서의 역할을 종합하면:

• XDP: 최전방에서 볼륨 공격(SYN flood, UDP flood, amplification)을 드라이버 수준에서 차단합니다. skb 할당 전에 처리하므로 CPU 오버헤드가 최소입니다.
• tc-bpf: 메인 방화벽 엔진으로 작동합니다. conntrack 조회, 정책 평가, NAT, 라우팅/redirect를 모두 처리합니다. Cilium/Calico의 핵심 데이터 플레인입니다.
• BPF netfilter: 기존 nftables 인프라를 유지하면서 특정 훅에 BPF 로직을 삽입합니다. 커스텀 DPI 로직이나 복잡한 verdict 결정에 적합합니다.

eBPF NGFW 성능 최적화

eBPF 기반 NGFW는 높은 유연성을 제공하지만, 최대 성능을 달성하려면 BPF 프로그램 구조, 맵 선택, 커널 기능 활용에 대한 세밀한 최적화가 필요합니다.

Per-CPU 맵 vs 공유 맵

Tail Call / BPF-to-BPF Call로 파이프라인 분할

복잡한 NGFW 로직을 단일 BPF 프로그램에 구현하면 verifier 복잡도 한계(100만 명령)에 도달할 수 있습니다. Tail call과 BPF-to-BPF call을 사용하여 파이프라인을 스테이지로 분할합니다.

/* Tail call 기반 NGFW 파이프라인 분할 */

/* 파이프라인 스테이지 인덱스 */
#define STAGE_PREFILTER  0
#define STAGE_CT_LOOKUP  1
#define STAGE_POLICY     2
#define STAGE_NAT        3
#define STAGE_REDIRECT   4

/* Tail call 맵 */
struct {
    __uint(type, BPF_MAP_TYPE_PROG_ARRAY);
    __uint(max_entries, 8);
    __uint(key_size, sizeof(__u32));
    __uint(value_size, sizeof(__u32));
} pipeline_stages SEC(".maps");

/* 스테이지 간 공유 메타데이터 */
struct {
    __uint(type, BPF_MAP_TYPE_PERCPU_ARRAY);
    __uint(max_entries, 1);
    __type(key, __u32);
    __type(value, struct pkt_meta);
} meta_map SEC(".maps");

struct pkt_meta {
    __u32 src_ip;
    __u32 dst_ip;
    __u16 src_port;
    __u16 dst_port;
    __u8  proto;
    __u8  ct_state;    /* 0=NEW, 1=EST, 2=REL */
    __u8  verdict;    /* 0=PENDING, 1=ALLOW, 2=DENY */
    __u32 nat_dst_ip;
    __u16 nat_dst_port;
};

SEC("tc")
int stage_prefilter(struct __sk_buff *skb)
{
    /* 헤더 파싱 + 메타데이터 저장 */
    struct pkt_meta meta = {};
    if (parse_headers(skb, &meta) < 0)
        return TC_ACT_SHOT;

    __u32 key = 0;
    bpf_map_update_elem(&meta_map, &key, &meta, BPF_ANY);

    /* 다음 스테이지로 tail call */
    bpf_tail_call(skb, &pipeline_stages, STAGE_CT_LOOKUP);
    return TC_ACT_OK; /* tail call 실패 시 fallback */
}

SEC("tc")
int stage_ct_lookup(struct __sk_buff *skb)
{
    __u32 key = 0;
    struct pkt_meta *meta = bpf_map_lookup_elem(&meta_map, &key);
    if (!meta)
        return TC_ACT_OK;

    /* conntrack 조회 + 상태 업데이트 */
    ct_lookup_and_update(skb, meta);

    /* ESTABLISHED면 정책 건너뛰기 */
    if (meta->ct_state == 1) {
        bpf_tail_call(skb, &pipeline_stages, STAGE_NAT);
    } else {
        bpf_tail_call(skb, &pipeline_stages, STAGE_POLICY);
    }
    return TC_ACT_OK;
}

bpf_redirect 함수군 비교

XDP Multi-Buffer (커널 6.0+)

커널 6.0부터 XDP에서 멀티 버퍼(Multi-Buffer) 패킷을 처리할 수 있게 되었습니다. 기존 XDP는 단일 페이지(4KB) 이내의 패킷만 처리할 수 있어 점보 프레임(Jumbo Frame, 9000 바이트)이나 GRO(Generic Receive Offload) 병합 패킷을 다룰 수 없었습니다. 멀티 버퍼 XDP는 xdp_buff에 mb 플래그를 추가하고 bpf_xdp_get_buff_len() 헬퍼로 전체 패킷 길이를 조회할 수 있게 합니다.

BPF Arena (커널 6.9+)

커널 6.9에서 도입된 BPF arena는 BPF 프로그램에서 대용량 메모리를 동적으로 할당할 수 있는 메커니즘입니다. 기존 BPF 맵은 고정 크기 엔트리만 지원하여 가변 길이 DPI 시그니처나 대형 룩업 테이블 구현이 어려웠습니다. Arena는 mmap 기반으로 최대 수 GB의 연속 메모리를 BPF 프로그램과 유저스페이스가 공유할 수 있게 합니다.

IRQ 어피니티 + NAPI 최적화

eBPF NGFW의 성능은 하드웨어 인터럽트와 NAPI 폴링(Polling) 설정에 크게 영향받습니다.

• IRQ 어피니티: NIC의 각 RX 큐 인터럽트를 특정 CPU에 고정하여 캐시 효율을 극대화합니다. /proc/irq/<N>/smp_affinity 또는 irqbalance로 설정합니다.
• RPS/RFS: Receive Packet Steering / Receive Flow Steering으로 소프트웨어 수준의 패킷 분산을 수행합니다. XDP에서는 CPUMAP을 활용하여 BPF 내에서 직접 CPU를 지정할 수 있습니다.
• NAPI busy-poll: net.core.busy_poll과 net.core.busy_read sysctl을 설정하여 폴링 모드를 활성화하면, 인터럽트 오버헤드 없이 패킷을 수신합니다.
• GRO: XDP 멀티 버퍼 지원 시, GRO 병합된 대형 패킷을 XDP에서 직접 처리하여 패킷당 BPF 호출 횟수를 줄입니다.

Verifier 복잡도 최소화 팁

• Tail call 분할: 단일 프로그램의 명령 수를 줄여 verifier 부하를 분산합니다. Tail call 체인은 최대 33단계까지 가능합니다.
• BPF-to-BPF 서브함수: static __noinline 함수로 공통 로직을 분리하면 verifier가 함수 단위로 검증하여 효율적입니다.
• bounded loop: 커널 5.3+에서 bpf_loop() 또는 bounded for 루프를 사용합니다. 루프 상한을 명시적으로 지정해야 verifier가 승인합니다.
• 불필요한 분기 제거: 컴파일러 힌트(__builtin_expect, likely()/unlikely())를 활용하여 분기 예측을 돕고, verifier 탐색 경로를 줄입니다.
• 맵 타입 선택: ARRAY 맵은 verifier가 범위 검사를 자동으로 수행하므로 HASH보다 검증이 빠릅니다. 가능한 경우 ARRAY를 우선 사용합니다.

eBPF 작업별 성능 수치

P4 프로그래머블 파이프라인 NGFW 오프로드

TC flower와 eSwitch 오프로드는 고정 함수(Fixed-Function) 파이프라인에서 미리 정의된 매치/액션을 수행합니다. 반면 P4(Programming Protocol-independent Packet Processors)는 NIC/스위치의 패킷 처리 파이프라인 자체를 프로그래밍할 수 있게 하여, 커스텀 프로토콜 파싱, 임의의 매치-액션 테이블, 스테이트풀 레지스터를 라인 레이트에서 실행합니다. 이 절에서는 P4 언어의 기본 개념부터 NGFW 구현까지 단계적으로 살펴봅니다.

P4 언어 개요

P4(Programming Protocol-independent Packet Processors)는 2014년 스탠퍼드 대학과 프린스턴 대학의 연구자들이 발표한 도메인 특화 언어(Domain-Specific Language, DSL)입니다. 네트워크 장비의 데이터 플레인(Data Plane) 동작을 소프트웨어처럼 정의할 수 있도록 설계되었으며, 컴파일 결과가 ASIC, FPGA, 소프트웨어 스위치 등 다양한 타깃에 직접 매핑됩니다.

P4의 핵심 설계 목표

• 프로토콜 독립성(Protocol Independence): 특정 프로토콜(IPv4, TCP 등)에 종속되지 않고, 사용자가 임의의 프로토콜 헤더 형식을 정의할 수 있습니다. 새로운 프로토콜이 등장해도 하드웨어 변경 없이 P4 프로그램만 수정하면 됩니다.
• 타깃 독립성(Target Independence): 동일한 P4 프로그램이 다양한 하드웨어/소프트웨어 타깃(Tofino ASIC, FPGA, BMv2 소프트웨어 스위치 등)에서 실행될 수 있습니다. 타깃별 차이는 아키텍처 모델(Architecture Model)이 추상화합니다.
• 재구성 가능성(Reconfigurability): 패킷 처리 파이프라인을 런타임에 재프로그래밍할 수 있습니다. 고정 함수(Fixed-Function) ASIC과 달리 새로운 기능 추가에 하드웨어 교체가 필요하지 않습니다.

P4₁₄ vs P4₁₆

P4는 두 가지 주요 버전이 존재합니다. 현재 표준은 P4₁₆이며, 대부분의 새 프로젝트에서 사용됩니다.

P4₁₆ 핵심 문법 구조

P4₁₆ 프로그램은 헤더(Header) 정의 → 파서(Parser) → 제어 블록(Control) → 디파서(Deparser)의 4단계로 구성됩니다. 각 요소는 타깃 아키텍처 모델이 정의한 파이프라인 구조에 매핑됩니다.

/* P4_16 프로그램의 기본 구조 (V1Model 아키텍처 기준) */

/* 1단계: 타입 및 헤더 정의 */
typedef bit<48> mac_addr_t;        /* 고정 폭 비트 타입 */
typedef bit<32> ipv4_addr_t;

header ethernet_t {                 /* 헤더: 패킷에서 추출할 필드 묶음 */
    mac_addr_t  dst_addr;
    mac_addr_t  src_addr;
    bit<16>     ether_type;
}

struct headers_t {                   /* 구조체: 파서가 추출한 헤더 모음 */
    ethernet_t  ethernet;
}

struct metadata_t {                  /* 메타데이터: 패킷 간 전달되는 사용자 정의 상태 */
    bit<1>      is_valid;
}

/* 2단계: 파서 — 상태 머신 기반 헤더 추출 */
parser MyParser(packet_in pkt,
               out headers_t hdr,
               inout metadata_t meta,
               inout standard_metadata_t std_meta) {
    state start {
        pkt.extract(hdr.ethernet);   /* extract(): 패킷에서 헤더 필드 추출 */
        transition accept;            /* transition: 다음 상태로 이동 */
    }
}

/* 3단계: 제어 블록 — 매치-액션 파이프라인 로직 */
control MyIngress(inout headers_t hdr,
                  inout metadata_t meta,
                  inout standard_metadata_t std_meta) {

    action drop() {                 /* action: 테이블 매치 시 실행할 동작 */
        mark_to_drop(std_meta);
    }

    action forward(bit<9> port) {
        std_meta.egress_spec = port;
    }

    table dmac_table {               /* table: 매치-액션 테이블 */
        key = {
            hdr.ethernet.dst_addr : exact;  /* 매치 타입: exact, ternary, lpm, range */
        }
        actions = { forward; drop; }
        size = 1024;                 /* 최대 엔트리 수 */
        default_action = drop();
    }

    apply {                          /* apply: 제어 블록 실행 진입점 */
        dmac_table.apply();
    }
}

/* 4단계: 디파서 — 수정된 헤더를 패킷에 다시 조합 */
control MyDeparser(packet_out pkt, in headers_t hdr) {
    apply {
        pkt.emit(hdr.ethernet);      /* emit(): 헤더를 출력 패킷에 직렬화 */
    }
}

/* 파이프라인 인스턴스화 (V1Model 아키텍처) */
V1Switch(MyParser(), MyVerifyChecksum(), MyIngress(),
         MyEgress(), MyComputeChecksum(), MyDeparser()) main;

P4₁₆ 타입 시스템

P4₁₆ 프로그램 컴파일 및 배포 흐름

P4 프로그램은 소스 코드 작성부터 디바이스 배포까지 아래 흐름을 따릅니다. 컴파일러(p4c)는 P4 소스와 아키텍처 모델을 입력받아 타깃별 바이너리와 P4Info(테이블/액션 메타데이터)를 생성합니다.

P4 아키텍처 모델

P4₁₆은 언어와 타깃 하드웨어 사이에 아키텍처 모델(Architecture Model) 계층을 도입하여 이식성을 확보합니다. 아키텍처 모델은 파이프라인 구조(파서, 제어 블록의 수와 순서), 사용 가능한 extern 객체, 표준 메타데이터 등을 정의합니다.

P4 개발 환경 및 도구

p4c — P4 레퍼런스 컴파일러

p4c는 P4.org에서 관리하는 오픈 소스 P4 컴파일러입니다. 프론트엔드(구문 분석, 타입 검사), 미드엔드(중간 표현 최적화), 백엔드(타깃별 코드 생성) 3단계로 구성됩니다.

# p4c 설치 (Ubuntu 22.04+)
sudo apt-get install p4lang-p4c

# BMv2 백엔드로 컴파일 (V1Model 아키텍처)
p4c --target bmv2 --arch v1model -o ngfw.json ngfw.p4

# Tofino 백엔드로 컴파일 (Intel P4 Studio 필요)
# p4c-tofino --target tofino --arch tna -o ngfw.bin ngfw.p4

# P4Info 파일도 함께 생성 (P4Runtime 컨트롤 플레인용)
p4c --target bmv2 --arch v1model \
    --p4runtime-files ngfw_p4info.pb.txt \
    -o ngfw.json ngfw.p4

BMv2 (Behavioral Model v2) — 소프트웨어 레퍼런스 스위치

BMv2는 P4 프로그램을 소프트웨어에서 실행하는 레퍼런스 구현체입니다. 실제 ASIC의 라인 레이트 성능은 제공하지 않지만, P4 프로그램의 기능 검증과 디버깅에 필수적인 도구입니다.

# BMv2 simple_switch 실행
sudo simple_switch --interface 0@veth0 --interface 1@veth2 \
    --log-console --log-level trace \
    ngfw.json

# BMv2 simple_switch_grpc (P4Runtime 지원)
sudo simple_switch_grpc --interface 0@veth0 --interface 1@veth2 \
    --log-console \
    -- --grpc-server-addr 0.0.0.0:9559 \
    ngfw.json

# simple_switch_CLI로 테이블 엔트리 수동 추가
simple_switch_CLI --thrift-port 9090 <
table_add dmac_table forward 00:00:00:00:00:01 => 1
table_dump acl_table
EOF

P4 개발 도구 종합

P4 파이프라인 개요와 NGFW 적용

P4₁₆은 패킷 처리 파이프라인을 정의하는 도메인 특화 언어(DSL)입니다. 네트워크 하드웨어의 데이터 플레인 동작을 소프트웨어처럼 프로그래밍하되, 컴파일 결과가 ASIC/FPGA에 직접 매핑되어 라인 레이트 처리를 보장합니다.

P4 파이프라인 핵심 구성 요소

P4가 NGFW에 중요한 이유

• 커스텀 프로토콜 라인 레이트 파싱: TC flower는 미리 정의된 L2-L4 필드만 매치할 수 있지만, P4는 임의의 프로토콜 헤더를 파싱할 수 있습니다. GTP-U 내부 5-tuple, SRv6 SID, VXLAN-GPE 메타데이터 등을 하드웨어에서 직접 검사합니다.
• 하드웨어 스테이트풀 처리: 레지스터 어레이를 사용하여 커넥션 상태 머신을 ASIC 내부에서 실행합니다. 소프트웨어 conntrack 없이도 SYN flood 탐지, 상태 기반 필터링이 가능합니다.
• 라인 레이트 보장: P4 프로그램은 ASIC의 매치-액션 유닛(MAU) 스테이지에 직접 매핑되므로, 패킷당 처리 시간이 고정됩니다. TC flower 오프로드와 달리 복잡한 규칙에서도 성능 저하가 없습니다.
• 동적 정책 업데이트: 테이블 엔트리는 런타임에 컨트롤 플레인(P4Runtime, gRPC)에서 추가/삭제할 수 있어, 방화벽 규칙을 재컴파일 없이 업데이트합니다.

P4 NGFW 5-tuple ACL + Stateful 방화벽 구현

P4₁₆으로 5-tuple ACL과 스테이트풀 커넥션 트래킹을 구현하는 코드를 살펴봅니다. 이 코드는 P4₁₆ 표준 아키텍처(V1Model)를 기준으로 하며, 실제 ASIC에 배포할 때는 플랫폼별 아키텍처(TNA, PNA 등)로 포팅(Porting)합니다.

헤더 정의

/* P4_16 NGFW 헤더 정의 */
header ethernet_t {
    bit<48> dst_addr;
    bit<48> src_addr;
    bit<16> ether_type;
}

header ipv4_t {
    bit<4>  version;
    bit<4>  ihl;
    bit<8>  dscp_ecn;
    bit<16> total_len;
    bit<16> identification;
    bit<3>  flags;
    bit<13> frag_offset;
    bit<8>  ttl;
    bit<8>  protocol;
    bit<16> hdr_checksum;
    bit<32> src_addr;
    bit<32> dst_addr;
}

header tcp_t {
    bit<16> src_port;
    bit<16> dst_port;
    bit<32> seq_no;
    bit<32> ack_no;
    bit<4>  data_offset;
    bit<3>  res;
    bit<9>  flags;       /* NS,CWR,ECE,URG,ACK,PSH,RST,SYN,FIN */
    bit<16> window;
    bit<16> checksum;
    bit<16> urgent_ptr;
}

header udp_t {
    bit<16> src_port;
    bit<16> dst_port;
    bit<16> length;
    bit<16> checksum;
}

struct headers_t {
    ethernet_t ethernet;
    ipv4_t     ipv4;
    tcp_t      tcp;
    udp_t      udp;
}

struct metadata_t {
    bit<2>  ct_state;    /* 0=NEW, 1=ESTABLISHED, 2=RELATED, 3=INVALID */
    bit<1>  acl_permit;
    bit<32> flow_hash;
    bit<8>  meter_color; /* 0=GREEN, 1=YELLOW, 2=RED */
}

프로그래머블 파서

P4 파서는 유한 상태 머신(Finite State Machine)으로 구현됩니다. 아래 다이어그램은 NGFW 파서의 상태 전이를 보여줍니다.

/* P4_16 프로그래머블 파서 */
parser NgfwParser(packet_in pkt,
                  out headers_t hdr,
                  inout metadata_t meta,
                  inout standard_metadata_t std_meta) {

    state start {
        pkt.extract(hdr.ethernet);
        transition select(hdr.ethernet.ether_type) {
            0x0800: parse_ipv4;
            default: accept;
        }
    }

    state parse_ipv4 {
        pkt.extract(hdr.ipv4);
        transition select(hdr.ipv4.protocol) {
            6:  parse_tcp;
            17: parse_udp;
            default: accept;
        }
    }

    state parse_tcp {
        pkt.extract(hdr.tcp);
        transition accept;
    }

    state parse_udp {
        pkt.extract(hdr.udp);
        transition accept;
    }
}

5-tuple ACL 테이블 + 스테이트풀 방화벽

P4 레지스터(Register)를 사용하여 하드웨어에서 직접 커넥션 트래킹 상태 머신을 구현합니다. 아래 다이어그램은 TCP 커넥션 상태 전이를 보여줍니다.

/* 커넥션 트래킹 상태 상수 */
const bit<2> CT_NEW         = 0;
const bit<2> CT_ESTABLISHED = 1;
const bit<2> CT_RELATED     = 2;
const bit<2> CT_INVALID     = 3;

/* TCP 플래그 비트 위치 */
const bit<9> TCP_SYN = 0x002;
const bit<9> TCP_ACK = 0x010;
const bit<9> TCP_FIN = 0x001;
const bit<9> TCP_RST = 0x004;

control NgfwIngress(inout headers_t hdr,
                    inout metadata_t meta,
                    inout standard_metadata_t std_meta) {

    /* --- 레지스터: 커넥션 상태 테이블 (해시 기반) --- */
    register<bit<2>>(65536)  ct_state_reg;    /* 상태: NEW/EST/REL/INV */
    register<bit<32>>(65536) ct_timeout_reg;   /* 타임스탬프 기반 만료 */

    /* --- 카운터 --- */
    direct_counter(CounterType.packets_and_bytes) acl_counter;

    /* --- 미터: 플로우별 속도 제한 --- */
    meter(1024, MeterType.bytes) flow_meter;

    /* --- 5-tuple ACL 테이블 (ternary 매치) --- */
    action permit() {
        meta.acl_permit = 1;
    }

    action deny() {
        meta.acl_permit = 0;
        mark_to_drop(std_meta);
    }

    action permit_and_meter(bit<32> meter_idx) {
        meta.acl_permit = 1;
        flow_meter.execute_meter(meter_idx, meta.meter_color);
    }

    table acl_table {
        key = {
            hdr.ipv4.src_addr  : ternary;
            hdr.ipv4.dst_addr  : ternary;
            hdr.ipv4.protocol  : ternary;
            hdr.tcp.src_port   : ternary;  /* TCP/UDP 공용 */
            hdr.tcp.dst_port   : ternary;
        }
        actions = {
            permit;
            deny;
            permit_and_meter;
        }
        size = 16384;
        default_action = deny();
        counters = acl_counter;
    }

    /* --- 커넥션 트래킹 로직 --- */
    action compute_flow_hash() {
        hash(meta.flow_hash, HashAlgorithm.crc32,
             (bit<32>)0,
             { hdr.ipv4.src_addr, hdr.ipv4.dst_addr,
               hdr.ipv4.protocol, hdr.tcp.src_port, hdr.tcp.dst_port },
             (bit<32>)65535);
    }

    action ct_lookup() {
        bit<2> state;
        ct_state_reg.read(state, meta.flow_hash);
        meta.ct_state = state;
    }

    action ct_update_established() {
        ct_state_reg.write(meta.flow_hash, CT_ESTABLISHED);
        ct_timeout_reg.write(meta.flow_hash,
            (bit<32>)std_meta.ingress_global_timestamp);
    }

    action ct_create_new() {
        ct_state_reg.write(meta.flow_hash, CT_NEW);
        ct_timeout_reg.write(meta.flow_hash,
            (bit<32>)std_meta.ingress_global_timestamp);
    }

    /* --- 새 플로우 CPU 알림 (Digest) --- */
    action send_digest_to_cpu() {
        digest<headers_t>(1, { hdr.ethernet, hdr.ipv4, hdr.tcp, hdr.udp });
    }

    apply {
        if (!hdr.ipv4.isValid()) {
            return;
        }

        /* 1단계: 플로우 해시 계산 */
        compute_flow_hash();

        /* 2단계: CT 상태 조회 */
        ct_lookup();

        /* 3단계: TCP 상태 머신 */
        if (hdr.tcp.isValid()) {
            if (meta.ct_state == CT_NEW &&
                (hdr.tcp.flags & TCP_ACK) != 0) {
                /* SYN-ACK 응답 → ESTABLISHED */
                ct_update_established();
                meta.ct_state = CT_ESTABLISHED;
            } else if (meta.ct_state == CT_NEW &&
                       (hdr.tcp.flags & TCP_SYN) != 0) {
                /* SYN 패킷 → 새 플로우 등록, CPU 알림 */
                ct_create_new();
                send_digest_to_cpu();
            } else if ((hdr.tcp.flags & TCP_RST) != 0 ||
                       (hdr.tcp.flags & TCP_FIN) != 0) {
                /* RST/FIN → 상태 초기화 */
                ct_state_reg.write(meta.flow_hash, CT_NEW);
            }
        }

        /* 4단계: ESTABLISHED 세션은 ACL 건너뛰기 (Fast Path) */
        if (meta.ct_state == CT_ESTABLISHED) {
            meta.acl_permit = 1;
        } else {
            /* 5단계: 5-tuple ACL 테이블 조회 */
            acl_table.apply();
        }

        /* 6단계: 속도 제한 확인 */
        if (meta.meter_color == 2) { /* RED → 드롭 */
            mark_to_drop(std_meta);
            return;
        }

        /* 7단계: 허용/차단 */
        if (meta.acl_permit == 0) {
            mark_to_drop(std_meta);
        }
    }
}

NAT 리라이트 테이블

/* NAT 변환 테이블 */
action do_dnat(bit<32> new_dst_addr, bit<16> new_dst_port) {
    hdr.ipv4.dst_addr = new_dst_addr;
    hdr.tcp.dst_port  = new_dst_port;
    /* 체크섬은 디파서에서 재계산 */
}

action do_snat(bit<32> new_src_addr, bit<16> new_src_port) {
    hdr.ipv4.src_addr = new_src_addr;
    hdr.tcp.src_port  = new_src_port;
}

table nat_table {
    key = {
        hdr.ipv4.dst_addr : exact;
        hdr.tcp.dst_port  : exact;
    }
    actions = {
        do_dnat;
        do_snat;
        NoAction;
    }
    size = 8192;
    default_action = NoAction();
}

/* 디파서: 수정된 헤더 재조합 */
control NgfwDeparser(packet_out pkt, in headers_t hdr) {
    apply {
        pkt.emit(hdr.ethernet);
        pkt.emit(hdr.ipv4);
        pkt.emit(hdr.tcp);
        pkt.emit(hdr.udp);
    }
}

플랫폼별 P4 NGFW 구현

P4 프로그램은 타깃 플랫폼의 아키텍처 모델에 맞게 컴파일됩니다. 각 플랫폼은 고유한 하드웨어 구조를 가지며, P4 NGFW 구현 시 플랫폼별 특성을 활용해야 최적 성능을 달성합니다.

(a) Intel Tofino

Tofino는 Intel(구 Barefoot Networks)의 P4 네이티브 ASIC으로, 데이터센터 스위치용으로 설계되었습니다.

/* Tofino TNA 아키텍처용 NGFW 파이프라인 (개요) */
Pipeline(
    NgfwIngressParser(),   /* 프로그래머블 파서 */
    NgfwIngress(),         /* 인그레스: ACL + CT + NAT */
    NgfwIngressDeparser(), /* 인그레스 디파서 */
    NgfwEgressParser(),    /* 이그레스 파서 */
    NgfwEgress(),          /* 이그레스: QoS 미터 + 미러링 */
    NgfwEgressDeparser()   /* 최종 디파서 */
) pipe;

Switch(pipe) main;

/* Tofino 특화: Resubmit으로 다단계 CT 조회 구현 */
/* 1차 패스: 정방향 해시로 CT 조회 */
/* miss → resubmit → 2차 패스: 역방향 해시로 CT 조회 */

(b) AMD Pensando DSC

AMD Pensando DSC(Distributed Services Card)는 Elba ASIC 기반의 SmartNIC/DPU로, P4 프로그래머블 파이프라인과 내장 ARM 코어를 결합합니다.

• 인라인 P4 파이프라인: 최대 200 Gbps 라인 레이트 처리
• 내장 ARM 코어: 예외 패킷 처리, 컨트롤 플레인, DPI 엔진 실행
• 통합 메모리: P4 테이블과 ARM 코어가 공유 메모리를 통해 빠르게 통신
• PNA(Portable NIC Architecture): P4 표준 NIC 아키텍처 지원

# Pensando DSC P4 프로그램 배포
# penctl: Pensando 관리 CLI
penctl system tech-support   # 시스템 상태 확인
penctl p4 program load --name ngfw_pipeline --file ngfw.p4bin
penctl p4 table entry add --table acl_table \
    --key "10.0.0.0/8, *, 6, *, 443" \
    --action permit
penctl p4 table entry add --table acl_table \
    --key "*, *, *, *, *" \
    --action deny

(c) Intel IPU (Infrastructure Processing Unit)

Intel IPU(구 Mount Evans)는 IDPF(Infrastructure Data Path Function) 드라이버와 통합되는 인프라 오프로드 전용 프로세서입니다.

• P4 파이프라인 + 내장 Xeon 코어: 패킷 처리와 인프라 서비스를 동시에 오프로드
• IDPF 드라이버: 호스트 커널과 IPU 간 표준화된 인터페이스
• 인프라 오프로드: NGFW뿐 아니라 스토리지, 가상 네트워크, 텔레메트리를 통합 처리
• P4-SDE: Intel P4 Software Development Environment를 통해 프로그래밍

플랫폼 비교 종합

P4Runtime 컨트롤 플레인 연동

P4Runtime은 P4 프로그래머블 디바이스의 데이터 플레인을 원격으로 제어하기 위한 gRPC 기반 API입니다. P4Runtime v1.3 사양을 기준으로, 테이블 엔트리 CRUD, ActionProfile/Selector, PacketIn/Out, Digest 등의 기능을 제공합니다.

P4Runtime API 주요 서비스

테이블 엔트리 CRUD 연산

P4Runtime의 WriteRequest는 하나 이상의 Update 메시지를 포함하며, 각 Update는 INSERT, MODIFY, DELETE 타입을 가집니다. 이를 통해 ACL 규칙을 런타임에 추가하거나 삭제할 수 있습니다.

ActionProfile / ActionSelector (ECMP)

ActionProfile은 테이블 액션을 간접 참조하여 여러 테이블이 동일한 액션 세트를 공유할 수 있게 합니다. ActionSelector는 ActionProfile에 해시 기반 선택 로직을 추가하여 ECMP(Equal-Cost Multi-Path) 로드 밸런싱을 구현합니다. NGFW에서는 다중 백엔드 서버로의 트래픽 분산에 활용됩니다.

PacketIn/PacketOut (CPU Punt)

PacketIn은 데이터 플레인에서 컨트롤 플레인(CPU)으로 패킷을 전달하는 메커니즘입니다. NGFW에서는 새 플로우의 첫 패킷, DPI가 필요한 패킷, 예외 패킷을 CPU로 punt합니다. PacketOut은 반대로 CPU에서 데이터 플레인으로 패킷을 주입합니다. ARP 응답, ICMP 에러, 컨트롤 패킷 전송에 사용됩니다.

DigestList (새 플로우 알림)

Digest는 PacketIn보다 가벼운 CPU 알림 메커니즘입니다. 전체 패킷을 전송하는 대신, P4 프로그램에서 지정한 필드(5-tuple, 타임스탬프 등)만 추출하여 컨트롤 플레인으로 전달합니다. 대역폭 소모가 적어 새 플로우 알림에 적합합니다.

Python P4Runtime 클라이언트 예시

# P4Runtime Python 클라이언트 — ACL 규칙 추가/삭제
# p4runtime-shell 또는 google.protobuf 기반

import grpc
from p4.v1 import p4runtime_pb2, p4runtime_pb2_grpc
from p4.config.v1 import p4info_pb2
import google.protobuf.text_format as tf

class NgfwP4RuntimeClient:
    def __init__(self, address, device_id, election_id):
        self.channel = grpc.insecure_channel(address)
        self.stub = p4runtime_pb2_grpc.P4RuntimeStub(self.channel)
        self.device_id = device_id
        self.election_id = election_id

    def master_arbitration(self):
        """마스터 선출 — 컨트롤 플레인 주도권 획득"""
        req = p4runtime_pb2.StreamMessageRequest()
        req.arbitration.device_id = self.device_id
        req.arbitration.election_id.high = 0
        req.arbitration.election_id.low = self.election_id
        return req

    def add_acl_entry(self, src_ip, dst_ip, dst_port,
                      protocol, action="permit"):
        """5-tuple ACL 엔트리 추가"""
        entry = p4runtime_pb2.TableEntry()
        entry.table_id = 33618978  # acl_table ID (P4Info 참조)

        # 소스 IP 매치 (ternary)
        m1 = entry.match.add()
        m1.field_id = 1  # hdr.ipv4.src_addr
        m1.ternary.value = src_ip.encode_to_bytes()
        m1.ternary.mask = b'\xff\xff\xff\x00'  # /24

        # 목적지 IP 매치 (ternary)
        m2 = entry.match.add()
        m2.field_id = 2  # hdr.ipv4.dst_addr
        m2.ternary.value = dst_ip.encode_to_bytes()
        m2.ternary.mask = b'\xff\xff\xff\xff'  # /32

        # 목적지 포트 매치 (ternary)
        m3 = entry.match.add()
        m3.field_id = 5  # hdr.tcp.dst_port
        m3.ternary.value = dst_port.to_bytes(2, 'big')
        m3.ternary.mask = b'\xff\xff'

        # 액션 설정
        if action == "permit":
            entry.action.action.action_id = 16829080  # permit()
        else:
            entry.action.action.action_id = 16805856  # deny()

        # WriteRequest 전송
        req = p4runtime_pb2.WriteRequest()
        req.device_id = self.device_id
        update = req.updates.add()
        update.type = p4runtime_pb2.Update.INSERT
        update.entity.table_entry.CopyFrom(entry)

        self.stub.Write(req)
        return entry

    def delete_acl_entry(self, entry):
        """ACL 엔트리 삭제"""
        req = p4runtime_pb2.WriteRequest()
        req.device_id = self.device_id
        update = req.updates.add()
        update.type = p4runtime_pb2.Update.DELETE
        update.entity.table_entry.CopyFrom(entry)
        self.stub.Write(req)

    def read_counters(self, counter_id):
        """카운터 값 읽기"""
        req = p4runtime_pb2.ReadRequest()
        req.device_id = self.device_id
        entity = req.entities.add()
        entity.counter_entry.counter_id = counter_id

        responses = self.stub.Read(req)
        for resp in responses:
            for entity in resp.entities:
                ce = entity.counter_entry
                print(f"Counter {ce.counter_id}: "
                      f"packets={ce.data.packet_count}, "
                      f"bytes={ce.data.byte_count}")

    def listen_digests(self):
        """Digest 수신 — 새 플로우 알림 처리"""
        def stream_req():
            yield self.master_arbitration()

        responses = self.stub.StreamChannel(stream_req())
        for resp in responses:
            if resp.HasField("digest"):
                digest = resp.digest
                for data in digest.data:
                    # 새 플로우의 5-tuple 추출
                    src_ip = data.struct.members[0].bitstring
                    dst_ip = data.struct.members[1].bitstring
                    print(f"New flow: {src_ip} -> {dst_ip}")
                # Digest ACK 전송
                ack = p4runtime_pb2.StreamMessageRequest()
                ack.digest_ack.digest_id = digest.digest_id
                ack.digest_ack.list_id = digest.list_id

# 사용 예시
client = NgfwP4RuntimeClient("192.168.1.1:9559", device_id=0,
                              election_id=1)
# HTTPS(443) 허용 규칙 추가
client.add_acl_entry(
    src_ip="10.0.1.0", dst_ip="10.0.2.100",
    dst_port=443, protocol=6, action="permit"
)
# ACL 카운터 조회
client.read_counters(counter_id=302055013)

SDN 컨트롤러 통합

모니터링: 카운터/미터 읽기

P4Runtime의 Read RPC로 데이터 플레인 카운터와 미터를 주기적으로 폴링하여 NGFW 모니터링 대시보드를 구성할 수 있습니다.

• Direct Counter: 테이블 엔트리별 패킷/바이트 카운트. ACL 규칙별 히트 수 모니터링에 사용합니다.
• Indirect Counter: 인덱스 기반 독립 카운터. 포트별, VLAN별 트래픽 통계에 사용합니다.
• Direct Meter: 테이블 엔트리별 토큰 버킷 속도 제한. 플로우별 QoS에 사용합니다.
• Meter 색상 읽기: 현재 미터 상태(GREEN/YELLOW/RED)를 조회하여 속도 제한 정책의 효과를 모니터링합니다.

P4 vs TC flower vs eBPF 비교

NGFW 오프로드에 사용할 수 있는 세 가지 주요 기술(P4, TC flower, eBPF)의 특성을 비교합니다. 각 기술은 서로 다른 설계 철학과 트레이드오프를 가지며, 환경에 따라 적합한 선택이 달라집니다.

P4 매치-액션 파이프라인 다이어그램

아래 다이어그램은 P4 프로그래머블 파이프라인에서 NGFW 패킷 처리 흐름을 보여줍니다. 각 매치-액션 테이블은 ASIC의 MAU 스테이지에 매핑되며, 라인 레이트로 실행됩니다.

커널 소스 분석

BPF netfilter와 kfunc conntrack 구현의 핵심 커널 소스 코드를 분석합니다. 이 분석은 커널 6.6 기준입니다.

nf_bpf_link.c — BPF netfilter 링크 등록

/* net/netfilter/nf_bpf_link.c */
/* BPF 프로그램을 Netfilter 훅에 연결하는 링크 구현 */

struct bpf_nf_link {
    struct bpf_link link;
    struct nf_hook_ops hook_ops;
    struct net *net;
    u32 dead;
};

static unsigned int
nf_hook_run_bpf(void *bpf_prog, struct sk_buff *skb,
                const struct nf_hook_state *state)
{
    struct bpf_nf_ctx ctx = {
        .state = state,
        .skb   = skb,
    };

    return bpf_prog_run(bpf_prog, &ctx);
}

static int bpf_nf_link_attach(const union bpf_attr *attr,
                              struct bpf_prog *prog)
{
    struct bpf_nf_link *link;
    struct net *net;

    /* 프로그램 타입 검증 */
    if (prog->type != BPF_PROG_TYPE_NETFILTER)
        return -EINVAL;

    link = kzalloc(sizeof(*link), GFP_USER);
    if (!link)
        return -ENOMEM;

    bpf_link_init(&link->link, BPF_LINK_TYPE_NETFILTER,
                  &bpf_nf_link_lops, prog);

    /* Netfilter 훅 등록 */
    link->hook_ops.hook     = nf_hook_run_bpf;
    link->hook_ops.hook_ops_type = NF_HOOK_OP_BPF;
    link->hook_ops.hooknum  = attr->link_create.netfilter.hooknum;
    link->hook_ops.pf       = attr->link_create.netfilter.pf;
    link->hook_ops.priority = attr->link_create.netfilter.priority;
    link->hook_ops.priv     = prog;

    net = current->nsproxy->net_ns;
    link->net = net;

    return nf_register_net_hook(net, &link->hook_ops);
}

bpf.h — BPF_PROG_TYPE_NETFILTER 정의

/* include/linux/bpf.h (일부) */
/* include/uapi/linux/bpf.h */

enum bpf_prog_type {
    BPF_PROG_TYPE_UNSPEC         = 0,
    BPF_PROG_TYPE_SOCKET_FILTER  = 1,
    BPF_PROG_TYPE_KPROBE         = 2,
    /* ... 생략 ... */
    BPF_PROG_TYPE_XDP            = 6,
    /* ... 생략 ... */
    BPF_PROG_TYPE_SCHED_CLS      = 3,  /* tc-bpf */
    /* ... 생략 ... */
    BPF_PROG_TYPE_NETFILTER      = 31, /* 커널 6.4에서 추가 */
};

/* BPF netfilter 프로그램의 컨텍스트 구조체 */
struct bpf_nf_ctx {
    const struct nf_hook_state *state;
    struct sk_buff *skb;
};

nf_conntrack_bpf.c — kfunc CT 구현

/* net/netfilter/nf_conntrack_bpf.c */
/* BPF kfunc으로 nf_conntrack을 노출하는 구현 */

/* bpf_skb_ct_lookup 구현 */
__bpf_kfunc struct nf_conn *
bpf_skb_ct_lookup(struct __sk_buff *skb_ctx,
                  struct bpf_sock_tuple *bpf_tuple,
                  u32 tuple__sz,
                  struct bpf_ct_opts *opts,
                  u32 opts__sz)
{
    struct sk_buff *skb = (struct sk_buff *)skb_ctx;
    struct net *caller_net;
    struct nf_conn *nfct;

    /* 옵션 크기 검증 */
    if (opts__sz < sizeof(struct bpf_ct_opts))
        return NULL;

    /* 네트워크 네임스페이스 해석 */
    caller_net = skb->dev ? dev_net(skb->dev)
                         : sock_net(skb->sk);

    /* 커널 conntrack 조회 */
    nfct = __bpf_nf_ct_lookup(caller_net, bpf_tuple,
                               tuple__sz, opts, opts__sz);
    return nfct;
}

/* 내부 조회 함수 */
static struct nf_conn *
__bpf_nf_ct_lookup(struct net *net,
                   struct bpf_sock_tuple *bpf_tuple,
                   u32 tuple_len,
                   struct bpf_ct_opts *opts,
                   u32 opts_len)
{
    struct nf_conntrack_tuple_hash *hash;
    struct nf_conntrack_tuple tuple = {};
    struct nf_conn *ct;

    /* bpf_sock_tuple → nf_conntrack_tuple 변환 */
    if (tuple_len == sizeof(bpf_tuple->ipv4)) {
        tuple.src.l3num = NFPROTO_IPV4;
        tuple.src.u3.ip = bpf_tuple->ipv4.saddr;
        tuple.dst.u3.ip = bpf_tuple->ipv4.daddr;
        tuple.src.u.tcp.port = bpf_tuple->ipv4.sport;
        tuple.dst.u.tcp.port = bpf_tuple->ipv4.dport;
    }
    tuple.dst.protonum = opts->l4proto;
    tuple.dst.dir = opts->dir;

    /* nf_conntrack_find_get() — RCU 보호 하에 해시 테이블 조회 */
    hash = nf_conntrack_find_get(net, &nf_ct_zone_dflt,
                                  &tuple);
    if (!hash) {
        opts->error = -ENOENT;
        return NULL;
    }

    ct = nf_ct_tuplehash_to_ctrack(hash);
    opts->dir = NF_CT_DIRECTION(hash);
    return ct;
}

verifier.c — netfilter 프로그램 검증

/* kernel/bpf/verifier.c (netfilter 관련 부분) */

/* BPF_PROG_TYPE_NETFILTER 검증 규칙 */
static const struct bpf_verifier_ops netfilter_verifier_ops = {
    .get_func_proto  = bpf_nf_get_func_proto,
    .is_valid_access = bpf_nf_is_valid_access,
};

/* 컨텍스트 필드 접근 검증 */
static bool
bpf_nf_is_valid_access(int off, int size,
                       enum bpf_access_type type,
                       const struct bpf_prog *prog,
                       struct bpf_insn_access_aux *info)
{
    /* bpf_nf_ctx의 state와 skb 필드만 읽기 허용 */
    if (type != BPF_READ)
        return false;

    switch (off) {
    case offsetof(struct bpf_nf_ctx, state):
        info->reg_type = PTR_TO_BTF_ID;
        info->btf_id = btf_nf_hook_state_id;
        return true;
    case offsetof(struct bpf_nf_ctx, skb):
        info->reg_type = PTR_TO_BTF_ID;
        info->btf_id = btf_sk_buff_id;
        return true;
    }
    return false;
}

/* kfunc 등록 — CT 관련 kfunc를 BPF 서브시스템에 노출 */
BTF_SET8_START(nf_ct_kfunc_set)
BTF_ID_FLAGS(func, bpf_xdp_ct_lookup,   KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_skb_ct_lookup,   KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_ct_insert_entry, KF_ACQUIRE | KF_RET_NULL)
BTF_ID_FLAGS(func, bpf_ct_release,      KF_RELEASE)
BTF_ID_FLAGS(func, bpf_ct_set_timeout)
BTF_ID_FLAGS(func, bpf_ct_change_timeout)
BTF_ID_FLAGS(func, bpf_ct_set_status)
BTF_ID_FLAGS(func, bpf_ct_change_status)
BTF_SET8_END(nf_ct_kfunc_set)

실습 가이드

아래 실습을 통해 eBPF 방화벽, Cilium 네트워크 정책, P4 파이프라인을 직접 구현하고 테스트할 수 있습니다.

Lab 1: BPF netfilter 프로그램으로 간단한 방화벽 구현

목표: libbpf + clang으로 BPF netfilter 프로그램을 컴파일하고, Netfilter 훅에 부착하여 특정 포트의 트래픽을 차단합니다.

사전 요구사항:

• 커널 6.4 이상 (uname -r로 확인)
• clang/llvm 15+, libbpf-dev, linux-headers 패키지
• root 권한 (BPF 프로그램 로딩)

# 1. 개발 환경 설정
sudo apt install clang llvm libbpf-dev linux-headers-$(uname -r) bpftool

# 2. BPF 프로그램 컴파일
clang -O2 -g -target bpf \
  -D__TARGET_ARCH_x86 \
  -I/usr/include/$(uname -m)-linux-gnu \
  -c ngfw_filter.bpf.c -o ngfw_filter.bpf.o

# 3. BPF skeleton 생성 (로더용)
bpftool gen skeleton ngfw_filter.bpf.o > ngfw_filter.skel.h

# 4. 로더 프로그램 컴파일 및 실행
gcc -O2 -o ngfw_loader ngfw_loader.c -lbpf -lelf -lz
sudo ./ngfw_loader

# 5. BPF 프로그램 부착 확인
sudo bpftool link list
# 출력 예시:
# 42: netfilter  prog 128
#     hooknum PREROUTING  pf INET  priority -100

# 6. 차단 테스트
# 터미널 1: 서버 시작
nc -l -p 8080

# 터미널 2: 차단 확인 (타임아웃 예상)
nc -w 3 localhost 8080

# 7. 통계 확인
sudo bpftool map dump name fw_stats

# 8. 정리
sudo bpftool link detach id 42

Lab 2: Cilium으로 Kubernetes Pod 네트워크 정책 적용

목표: kind 클러스터에 Cilium을 배포하고, CiliumNetworkPolicy로 Pod 간 트래픽을 제어합니다.

사전 요구사항:

• Docker, kind (Kubernetes IN Docker), kubectl, helm
• cilium CLI (curl -L --remote-name-all https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz)

# 1. kind 클러스터 생성 (eBPF 지원 설정)
cat <<EOF | kind create cluster --config=-
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  disableDefaultCNI: true    # 기본 CNI 비활성화
  kubeProxyMode: "none"      # kube-proxy 비활성화
nodes:
- role: control-plane
  extraMounts:
  - hostPath: /opt/images
    containerPath: /opt/images
- role: worker
- role: worker
EOF

# 2. Cilium 설치
cilium install --version 1.14.5 \
  --set kubeProxyReplacement=true \
  --set bpf.masquerade=true

# 3. Cilium 상태 확인
cilium status --wait

# 4. 테스트 Pod 배포
kubectl create deployment web --image=nginx --replicas=2
kubectl expose deployment web --port=80
kubectl create deployment client --image=busybox \
  -- sleep 3600

# 5. 정책 적용 전 — 접근 가능 확인
kubectl exec -it deploy/client -- wget -qO- web

# 6. CiliumNetworkPolicy 적용 — web Pod는 label app=allowed만 허용
cat <<EOF | kubectl apply -f -
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: web-allow
spec:
  endpointSelector:
    matchLabels:
      app: web
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: allowed
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
EOF

# 7. 정책 적용 후 — 접근 차단 확인
kubectl exec -it deploy/client -- wget -qO- --timeout=3 web
# wget: download timed out

# 8. 허용 레이블 추가 후 — 접근 가능 확인
kubectl label pod -l app=client app=allowed --overwrite
kubectl exec -it deploy/client -- wget -qO- web
# 정상 응답

# 9. Hubble로 플로우 모니터링
cilium hubble port-forward &
hubble observe --type drop

# 10. 정리
kind delete cluster

Lab 3: P4 BMv2에서 NGFW 파이프라인 테스트

목표: P4 Behavioral Model(BMv2)에서 5-tuple ACL + 스테이트풀 방화벽을 컴파일하고 실행합니다.

사전 요구사항:

• p4c (P4 컴파일러), BMv2 (behavioral-model), simple_switch_grpc
• Python 3 + p4runtime-shell

# 1. P4 개발 환경 설치 (Ubuntu 22.04)
sudo apt install p4lang-p4c p4lang-bmv2

# 2. P4 프로그램 컴파일
p4c --target bmv2 --arch v1model \
    --p4runtime-files ngfw.p4info.txt \
    -o ngfw.json \
    ngfw.p4

# 3. BMv2 (simple_switch_grpc) 시작
sudo simple_switch_grpc \
    --device-id 0 \
    -i 0@veth0 -i 1@veth2 \
    --log-console --log-level info \
    --no-p4 \
    -- --grpc-server-addr 0.0.0.0:9559 &

# 4. P4Runtime으로 파이프라인 로딩
p4runtime-shell --grpc-addr localhost:9559 \
  --device-id 0 \
  --config ngfw.p4info.txt,ngfw.json \
  --election-id 0,1

# 5. ACL 규칙 추가 (p4runtime-shell 내에서)
# te = table_entry["NgfwIngress.acl_table"]
# te.match["hdr.ipv4.src_addr"] = "10.0.0.0&&&0xffffff00"
# te.match["hdr.ipv4.dst_addr"] = "10.0.1.1&&&0xffffffff"
# te.match["hdr.tcp.dst_port"] = "80&&&0xffff"
# te.action["permit"] = {}
# te.insert()

# 6. 테스트 패킷 전송
sudo python3 send_test_pkt.py --src 10.0.0.1 --dst 10.0.1.1 \
    --dport 80 --iface veth0

# 7. 카운터 확인
# ce = counter_entry["NgfwIngress.acl_counter"]
# ce.read()

# 8. 패킷 캡처로 결과 확인
sudo tcpdump -i veth2 -c 5

# 9. 정리
sudo killall simple_switch_grpc

흔한 실수와 안티패턴

eBPF/P4 기반 NGFW 구현에서 자주 발생하는 실수와 그 해결 방법을 정리합니다.

1. BPF 맵 크기 부족으로 CT 엔트리 소실

2. XDP + tc-bpf 프로그램 순서 착각

3. Per-CPU 맵에서 Cross-CPU 상태 불일치

4. Verifier 복잡도 초과

5. P4 레지스터 해시 충돌 미처리

6. Cilium/Calico 호스트 레벨 보안 미활성화

7. BPF Tail Call 체인 깊이 초과

참고자료

• Linux Kernel: BPF Documentation
• Linux Kernel: XDP (eXpress Data Path)
• Cilium Documentation — eBPF 기반 CNI + 방화벽
• P4 Language Specification (P4.org)
• P4 Behavioral Model (BMv2) — P4 소프트웨어 시뮬레이터
• P4Runtime — 프로그래머블 데이터 플레인 제어 인터페이스
• Intel Tofino Programmable Ethernet Switch
• Linux Kernel: Netfilter Documentation