2026/01/24 2:29
**ISPアプライアンスを「殺す」―eBPF/XDPによる分散型BNGの実装**
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
新しいオープンソースのブロードバンドネットワークゲートウェイ（BNG）が構築され、eBPF/XDPで高速化されたデータプレーンを直接光線終端装置（OLT）ハードウェア上で動作させています。これにより、高価な中央機器の必要性が排除され、分散型BNG展開がより安価で耐障害性が高く、管理が容易になります。
- パフォーマンス：eBPF/XDPデータプレーンは、標準Linux上で10–40 Gbpsのスループットを実現し、tcpdump、bpftool、perfといった従来から馴染み深いデバッグツールが使用できます。
- DHCP & IP割り当て：2層構造のDHCPシステムは、カーネルXDPパスで約45 kリクエスト/秒（遅延≈10 µs）とユーザースペースで約5 kリクエスト/秒（遅延≈10 ms）を処理し、ウォームアップ後に95 %以上のキャッシュヒット率を達成します。デバイス認証はRADIUS時に決定的なハッシュリングIPを割り当て、アドレス競合を防ぎつつDHCP読み取りのみで済ませます。
- アーキテクチャ：エッジOLT‑BNGはデータプレーンだけを実行し、中央Kubernetes「Nexus」制御プレーン（CRDT状態同期、IP割り当て、設定配布、メトリクス）がそれらを調整します。キャッシュされたセッション、DHCP更新、NAT変換、およびQoS施行はエッジサイトがオフラインでも継続し、コア障害がサービスに影響するのを防ぎます。
- 実装：1つのGoバイナリにeBPFプログラム（
、dhcp_fastpath.c
、qos_ratelimit.c
、nat44.c
）が埋め込まれ、Linux 5.10+対応のホワイトボックスOLT（例：Radisys RLT‑1600G、約7,400 USD）上で動作します。これらは1,500–2,000ユーザーをサポートしています。antispoof.c - 現在のギャップ：デバイス認証（TPM）、IPv6対応、完全なRADIUS計上、および管理UIがまだ追加されていません。プロジェクトはGitHubでオープンソース化されています。
運用者は各OLTにローカルでBNG機能を展開できるため、資本支出の削減、耐障害性の向上、レイテンシの低減、および従来の専有機器と比べたオペレーションの簡素化が実現します。これにより、ブロードバンドにおけるオープンソースネットワーキングの広範な採用への道が開かれます。
本文
私は以前、次世代インフラを構築していたISPスタートアップで働いていました。
その会社は成長できませんでしたが、私たちが解決しようとしていた問題は残り続けました。
そこで数週間かけて、実際には手に入らなかったもの――eBPF を活用したオープンソース BNG（Broadband Network Gateway）を OLT（光線終端装置）のハードウェア上で直接動作させる仕組み―を構築しました。
この記事では、そのアーキテクチャと、なぜ私はこれが ISP のエッジインフラの未来だと考えるかを説明します。
問題点：集中型 BNG がボトルネックになる
従来の ISP アーキテクチャは次のようになっています。
顧客 → ONT → OLT → [BNG 機器] → インターネット ↑ 単一障害点 高価な専用ハードウェア すべての加入者トラフィックがここを通る
DHCP、認証、NAT、QoS といった加入者トラフィックはすべて中央 BNG 機器に流れ込みます。
その機器は数十万ドル規模で、ベンダーサポート契約が必要ですし、単一障害点となります。ダウンすると全員がダウンします。
業界の対策としては、冗長性を増やしたより大きなボックスを購入することが主流でした。
しかし、もしモデルを完全に逆転させたらどうでしょう？
アイデア：エッジへ BNG を分散させる
すべてのトラフィックを中央機器へ集約する代わりに、各エッジサイトの OLT ハードウェア上で直接 BNG 機能を動かすとしたら？
顧客 → ONT → OLT(+BNG) → インターネット ↑ 加入者トラフィックはローカルに留まる 中央のボトルネックがない 各サイトは独立して動作する
これは新しいアイデアではありません。ハイパースケーラーがエッジインフラで実践していることと同じです。
しかし ISP が遅れた理由は次の通りです。
- 従来の BNG ソフトウェアは中央配置を前提に設計されている
- 状態管理（IP 割り当て、セッション）は分散が難しい
- パフォーマンス要件が専用ハードウェアを必要とするように見えた
鍵となる洞察は、モダンな Linux と eBPF/XDP が商用ハードウェア上で ISP スケールのパケット処理を実現できるということです。
なぜ eBPF/XDP なのか、VPP ではないのか？
プロジェクト開始時に 2 つの手法を評価しました。
| eBPF/XDP | VPP | |
|---|---|---|
| パフォーマンス | 10–40 Gbps ✓ | 100+ Gbps（オーバーキル） |
| デプロイメント | 標準 Linux カーネル | DPDK、HugePages、専用 NIC |
| 運用 | systemd サービス、簡単セットアップ | 複雑な専用セットアップ |
| デバッグ | tcpdump, bpftool, perf など | 学習曲線が急だが文書化済み |
VPP はコア集約に適しています。
しかしエッジサイトでは eBPF/XDP の方がシンプルで十分です。
アーキテクチャ
構築したものは次のようになります。
┌─────────────────────────────────────────────────────────────┐ │ CENTRAL (Kubernetes) │ │ Nexus: CRDT 状態同期、ハッシュリング IP 割り当て │ │ （制御プレーンのみ – 加入者トラフィックは通らない） │ └──────────────────────────┬──────────────────────────────────┘ │ 設定同期、メトリクス ┌─────────────────┼─────────────────┐ ▼ ▼ ▼ ┌───────────┐ ┌───────────┐ ┌───────────┐ │ OLT‑BNG 1 │ │ OLT‑BNG 2 │ │ OLT‑BNG N │ │ eBPF/XDP │ │ eBPF/XDP │ │ eBPF/XDP │ │ 1500 サブ │ │ 2000 サブ │ │ 1800 サブ │ └─────┬─────┘ └─────┬─────┘ └─────┬─────┘ │ │ │ トラフィック ローカル トラフィック ローカル トラフィック ローカル ↓ ↓ ↓ ISP PE ISP PE ISP PE
核心原則：加入者トラフィックは中央インフラを通らない。
中央の Nexus サーバーは制御プレーンだけ（設定配布、IP 割り当て調整、監視）を担当します。
二段階 DHCP：高速パス + 低速パス
性能上重要なのは、多くの DHCP 操作が既知加入者からの更新である点です。これらをカーネル内だけで処理できます。
DHCP リクエスト到着 │ ▼ ┌───────────────────────────────────────────────────────┐ │ XDP 高速パス (カーネル) │ │ │ │ 1. Ethernet → IP → UDP → DHCP を解析 │ │ 2. クライアント MAC を抽出 │ │ 3. eBPF subscriber_pools マップで MAC を検索 │ │ │ │ CACHE HIT? │ │ ├─ YES: カーネル内で DHCP ACK を生成 │ │ │ XDP_TX (~10 µs の遅延) │ │ └─ NO: XDP_PASS → ユーザースペースへ │ └───────────────────────────────────────────────────────┘ │ XDP_PASS (キャッシュミス) ▼ ┌───────────────────────────────────────────────────────┐ │ Go Slow Path (ユーザースペース) │ │ │ │ 1. Nexus キャッシュで加入者を検索 │ │ 2. 事前割り当てられた IP を取得 │ │ 3. 将来の高速パスヒット用に eBPF キャッシュを更新 │ │ 4. DHCP レスポンス送信 │ └───────────────────────────────────────────────────────┘
結果
| パス | 遅延 | スループット |
|---|---|---|
| 高速 | ~10 µs | 45,000+ req/sec |
| 低速 | ~10 ms | 5,000 req/sec |
ウォームアップ後のキャッシュヒット率は >95%。
IP 割り当て：RADIUS 時点でハッシュリング
設計上の決断として、IP 割り当てを DHCP のタイミングではなく RADIUS 認証時に行いました。
- 加入者が RADIUS で認証される
- 成功 → Nexus がハッシュリング（決定論的）から IP を割り当て
- IP は加入者レコードに保存
- DHCP は単なる READ 操作
これにより：
- 分散 BNG ノード間で IP 衝突が起きない
- DHCP 高速パスは eBPF 内で完結（ユーザースペースの割り当て判断不要）
- 加入者は常に同じ IP を取得できる（ハッシュリングの決定論性）
オフライン優先エッジ運用
エッジサイトが中央 Nexus への接続を失った場合、次のようになります。
| 状況 | 効果 |
|---|---|
| 既存加入者セッション | eBPF マップにキャッシュされているので継続 |
| DHCP リース更新 | ローカルで処理 |
| NAT 翻訳 | 維持 |
| QoS 制御 | 継続 |
低下状態
- 新規加入者認証（RADIUS が無い） → ローカルフォールバックプール
- 新規 IP 割り当てはローカルプールへ戻る
- 設定更新は再接続までキューに入れる
エッジサイトは自律的に動作するよう設計されており、中央の協調は「あると便利」だけです。
実装概要
BNG は Go で書かれた単一バイナリで、埋め込み eBPF プログラムを含みます。
bng/ ├── cmd/bng/ # メインバイナリ ├── pkg/ │ ├── ebpf/ # eBPF ローダーとマップ管理 │ ├── dhcp/ # DHCP スロー パスサーバ │ ├── nexus/ # 中央協調クライアント │ ├── radius/ # RADIUS クライアント │ ├── qos/ # QoS / レートリミット │ ├── nat/ # NAT44 / CGNAT │ ├── pppoe/ # PPPoE サーバ │ ├── routing/ # BGP/FRR 統合 │ └── metrics/ # Prometheus メトリクス ├── bpf/ │ ├── dhcp_fastpath.c # XDP DHCP 高速パス │ ├── qos_ratelimit.c # TC QoS eBPF │ ├── nat44.c # TC NAT eBPF │ └── antispoof.c # TC アンチスポーフィング
実行方法
# 独立モード（ローカル IP プール） sudo ./bng run \ --interface eth1 \ --pool-network 10.0.1.0/24 \ --pool-gateway 10.0.1.1 # 本番モード（Nexus と協調） sudo ./bng run \ --interface eth1 \ --nexus-url http://nexus.internal:9000 \ --radius-enabled \ --radius-servers radius.isp.com:1812
ハードウェア
任意の Linux ボックス（5.10+ カーネル）で動作します。
対象は Radisys RLT‑1600G のようなホワイトボックス OLT：
- 16 ポート GPON / XGS‑PON
- Debian Linux が稼働し、価格は約 $7,400（従来の BNG は数十万ドル）
- 1,500–2,000 サブスクライバーを処理可能
Linux を実行しネットワークインターフェースが OS に露出されている任意の OLT で同じ手法が使えます。
今後やるべきこと
コードは動作しますが、本番向けにはまだ足りません。
不足している機能：
- デバイス認証（TPM アテステーションなど）で不正 OLT‑BNG の防止
- IPv6 サポート（DHCPv6、SLAAC）
- 完全な RADIUS 計上（現状は簡易的）
- 管理 UI（CLI と Prometheus メトリクスだけ）
オープンソース化を検討しています。
BNG 市場は高価な専用ソリューションが支配しており、良いオープンソース代替品は存在しません。もしかしたら、そこに市場のニーズがあるかもしれません。
大局的視点
従来の ISP インフラは、コンピューティングコストが高くネットワーク速度が遅い時代に設計されました。
中央機器はパケット処理に専用ハードウェアを必要としていました。
しかし今はコンピュータが安価で、eBPF により Linux カーネル内でラインレートのパケット処理が可能です。
経済性も変わり、数百個のエッジサイトへ BNG を分散させる方が、数台の巨大中央ボックスを構築するよりも安価になります。
コスト削減だけではありません。 分散アーキテクチャは単一障害点がなく、トラフィックがローカルに留まるためレイテンシが低く、運用も簡潔です（Linux そのものを使うだけ）。
ハイパースケーラーはこのモデルを数年前に実装しました。 ISP は徐々に追随しています。
興味のある方へ
コードは次のリポジトリにあります：
ISP／オルタネットワーク領域で同様の課題に取り組んでいる方、eBPF や分散システム、ベンダー BNG が不合理だと感じる方はぜひご連絡ください。 交流を楽しみにしています。