XDPパケットフィルタ本番導入｜スループット測定とnftables共存・障害時切り戻し

XDP本番導入の前提条件と事前確認

XDP（eXpress Data Path）をパケットフィルタとして本番環境に投入するには、いくつかの前提条件を整理しておく必要があります。XDPのコア機能は Linux 4.8 で実装されましたが、NICネイティブオフロード（XDP_FLAGS_DRV_MODE）を活かすには各ドライバの対応が必須です。2026年時点の主要ディストリビューション（RHEL 9 系・Ubuntu 22.04 以降）ではカーネル 5.14 以降が標準となっており、mlx5・ixgbe・i40e といった主要NICドライバはXDPネイティブモードへの対応を完了しています。汎用モード（XDP_FLAGS_SKB_MODE）はほぼすべてのNICで動作しますが、スループット面での優位性が薄れるため、本番採用では可能な限りネイティブモードを選択するのが現場の標準です。

権限面では、eBPFプログラムのロードに CAP_BPF または CAP_SYS_ADMIN が必要です。コンテナや制限付きサービスアカウントから実行する場合は、seccomp・AppArmor のプロファイルも事前に確認してください。NICのXDP対応可否は次のコマンドで素早く確認できます。

# ドライバ名とバージョンの確認
ethtool -i eth0 | grep -E 'driver|version'

# XDP対応モードの確認（xdp-loader を使う場合）
xdp-loader status eth0

XDPプログラムのロード手段としては、従来の ip link set dev eth0 xdp obj filter.o に加え、2024年以降は libxdp 付属の xdp-loader を使う流儀が主流になっています。複数プログラムのチェーン管理や BPF ピンのライフサイクル管理が容易になるため、本番環境では xdp-loader ベースの構成を選択するのが得策です。

スループット測定：本番前ベンチマークの進め方

XDPを本番適用する前に、対象サーバとNICの組み合わせで実際に何 pps（packets per second）が捌けるかを計測しておく必要があります。「XDPは速い」という定性評価だけでは、設計段階の見積もりが現実のトラフィックと乖離した際に対処できません。

測定ツールとしては xdp-bench（xdp-tools 同梱）が適しています。XDP_PASS・XDP_DROP・XDP_TX それぞれのアクションを単体で計測でき、ベースライン把握に役立ちます。

# XDP_DROP のみを行うシンプルなベンチマーク
xdp-bench drop eth0 --mode native

# 別端末からトラフィックを注入（pktgen や trex を使う例）
# pktgen は /proc/net/pktgen 経由で制御
echo "add_device eth1" > /proc/net/pktgen/kpktgend_0
echo "pkt_size 64" > /proc/net/pktgen/eth1
echo "count 10000000" > /proc/net/pktgen/eth1
echo "start" > /proc/net/pktgen/pgctrl

測定時に注意すべき点が2つあります。まず CPU ピンニングです。IRQ affinity と XDP プログラムが動作する CPU を一致させないと、クロスCPUのキャッシュミスによってスループットが大幅に低下します。irqbalance を停止し、set_irq_affinity スクリプトで手動設定してから計測してください。次に NUMA トポロジです。NICが接続されているNUMAノードと異なるノードのメモリを使うと、メモリ帯域がボトルネックになります。numactl --membind で計測プロセスをNICと同じノードに束縛することで、再現性の高い数値が得られます。

実際のフィルタロジックを組み込んだ状態でのベンチマークも欠かせません。単純な DROP より、5タプルマッチや LPM（Longest Prefix Match）テーブルの参照を含む処理は pps が下がります。BPF マップへのアクセスが増えるほどキャッシュ効率が変化するため、本番相当のルール数でベンチマークを取ることが重要です。

nftablesとの共存設定

多くの本番サーバでは、すでに nftables によるステートフルフィルタやNAT設定が稼働しています。XDPを追加する際に「nftables をすべて置き換える」アプローチは現実的でなく、両者を層として使い分けるのが標準的な設計です。

処理の流れを整理すると次のようになります。

• XDP層（NICドライバ直後）：大量のスキャントラフィックや既知の攻撃パターンを XDP_DROP で即時廃棄。BPFマップで管理するブロックリストに一致するパケットをここで処理します。
• TC/eBPF層（tc ingress）：より複雑な処理や conntrack との連携が必要な場合はここで対応します。
• nftables層（netfilter）：ステートフルな追跡・NAT・ポリシー管理はそのまま nftables に委ねます。

この設計の肝は、XDP が XDP_PASS を返したパケットは通常の netfilter パスに流れる点です。XDP でドロップすべきでないパケットは確実に XDP_PASS を返すよう実装すれば、nftables 側のロジックは改変不要です。逆に言えば、XDP の実装ミスで本来許可すべきパケットを DROP した場合も、nftables のログには何も残りません。これが後述する切り戻し設計が重要になる理由のひとつです。

nftables と XDP を共存させる際の設定上の注意点として、flowtable オフロードとの競合があります。nftables の flowtable を有効にしているセットアップで XDP も有効にすると、NICの HW オフロード機能の取り合いが発生することがあります。特に mlx5 ドライバでは flowtable と XDP のネイティブモードが同時に有効になれない場合があるため、事前にドライバのドキュメントと ethtool --show-offload の出力を突き合わせて確認してください。

障害時の切り戻し手順

XDPを本番適用する上で、切り戻し手順の整備は非常に重要です。XDP プログラムに不具合があった場合、ネットワークが完全に不通になるリスクがあるため、SSH セッションが切れる前に素早くアンロードできる手順をチームで共有しておく必要があります。

XDP プログラムのアンロードは次のコマンドで行います。

# ip link 経由でロードした場合のアンロード
ip link set dev eth0 xdp off

# xdp-loader 経由でロードした場合のアンロード
xdp-loader unload eth0 --all

# 特定プログラムだけ外す場合（IDを指定）
xdp-loader unload eth0 --id 42

切り戻しの確実性を高めるために、現場では次のような手順が取られています。

• デプロイスクリプトにアンロードコマンドを組み込む：適用スクリプトの冒頭で既存プログラムをアンロードし、新しいプログラムをロード後に疎通確認を行い、失敗時は自動でアンロードに戻る構成にします。
• watchdog プロセスを用意する：XDP ロード後に別プロセスで監視を行い、特定のプローブパケットへの応答が途絶えたら自動でアンロードするスクリプトを仕込む方法は実効性が高いです。
• BMC/iDRAC 経由の帯域外アクセスを確保する：最悪の場合に備え、管理インタフェース（IPMI・iDRAC・iLO）経由でコンソールにアクセスできる環境を整えておきます。

また、BPF マップのリークにも注意が必要です。xdp-loader unload でプログラムを外しても、bpffs にピンしたマップは残ります。不要なピンは rm /sys/fs/bpf/<map_name> で明示的に削除してください。bpftool map list で残存マップを確認する習慣をつけると安心です。

2026年現行環境での差分と注意点

2026年時点の Linux エコシステムにおいて、XDP 周辺はここ2〜3年で大きく整備が進みました。いくつか現行環境特有のポイントを整理します。

libxdp と xdp-tools の成熟：xdp-tools プロジェクト（xdp-loader・xdp-bench・libxdp 等を含む）が 1.4 系に到達し、複数XDPプログラムのディスパッチャ（libxdp の multi-prog 機構）が安定稼働しています。以前は1つのNICに1つの XDP プログラムしかアタッチできませんでしたが、この機構によって複数の独立したフィルタを連結できるようになり、運用上の柔軟性が大きく向上しました。

カーネル 6.x での BTF・CO-RE 対応強化：BPF CO-RE（Compile Once – Run Everywhere）の普及により、異なるカーネルバージョン間での eBPF バイナリの可搬性が向上しました。以前は RHEL と Ubuntu でカーネルの構造体レイアウトの差異に悩まされることがありましたが、BTF ベースのリロケーションが整備されたことで、単一のコンパイル済みバイナリを複数のディストリビューションで使い回せる場面が増えています。

AF_XDP と DPDK との棲み分け：パフォーマンスが最優先の場合に DPDK が選択肢に上がりますが、2026年現在では AF_XDP（XDP ソケット）を使ったユーザ空間処理が DPDK に近いスループットをカーネルバイパスなしで達成できるケースが増えています。既存の nftables・iptables 資産を捨てずに高スループットを得たいシナリオでは、まず AF_XDP ベースの構成を評価することが現場のトレンドになっています。

セキュリティポリシーとの摩擦：CAP_BPF の分離（Linux 5.8 で導入）により、CAP_SYS_ADMIN を付与せずとも eBPF プログラムをロードできるようになりました。ただし、RHEL 9 のデフォルト設定では kernel.unprivileged_bpf_disabled=1 が有効なため、非 root ユーザからの eBPF 利用には追加設定が必要です。本番環境でのデプロイ自動化を設計する際には、この sysctl 値を確認してから CAP_BPF の付与可否を判断してください。

本番適用チェックリストの考え方

XDP パケットフィルタの本番導入は、適用してしまえば終わりではありません。長期的な運用安定性を確保するために、以下の観点を継続的に管理することが求められます。

• カーネルアップデート時の検証：カーネルを更新すると BTF の構造が変わり、CO-RE 対応していないプログラムはロードに失敗する場合があります。メジャーアップデートの前後で必ず xdp-loader status とスループット測定を実施してください。
• BPFマップのモニタリング：ブロックリストを管理する BPF マップは、エントリ数が増え続けると検索性能が劣化します。定期的に bpftool map dump でエントリ数を確認し、古くなったエントリを自動削除する仕組みを組み込んでおくことが推奨されます。
• nftables ルールとの整合性確認：XDP 側とnftables 側でポリシーが矛盾しないよう、変更時には両者を同時にレビューする手順を組織のルールとして定めてください。
• メトリクスの継続収集：/sys/class/net/eth0/statistics/ や bpftool prog show の実行回数カウンタを Prometheus 等に取り込み、XDP が正常に動作しているかを常時可視化しておくと、障害の予兆を早期に検知しやすくなります。

XDP はカーネルのネットワークスタックに踏み込む強力な技術である分、設定ミスや想定外のドライバ挙動によるインシデントリスクも伴います。スループット測定・nftables 共存設計・切り戻し手順の3点をセットで整備することが、安定した本番運用の基盤になります。