PPPoE Half-BridgeによるUniFi GatewayのPPPoEパフォーマンス・ボトルネックの解決方法

UniFi gatewayは、CPUがPPPoEおよびNATのハードウェアアクセラレーションをサポートしていないため、PPPoE接続において深刻なスループット低下が発生することがよくあります。PPPoEダイアリングプロセスを、別のOpenWrtベースのデバイスにオフロードする「PPPoE Half-Bridge」と呼ばれる手法を用いることで、ユーザーはゲートウェイにPPPoEセッション自体を処理させるのではなく、DHCP経由でパブリックIPv4アドレスを渡すことにより、UniFi gatewayのフルラインスピードを回復させることができます。

UniFi PPPoEパフォーマンス問題の根本原因

UDM Pro、UDM SE、UDM Pro Max、UXG Pro、およびEFGを含むほとんどのUniFi gatewayは、PPPoEハードウェアアクセラレーションをサポートしていないOEMプラットフォームを利用しています。これにより、PPPoEプロトコルがルーターに対してすべてのパケットのカプセル化および非カプセル化を要求するため、重大なパフォーマンス・ボトルネックが生じます。これは通常、LinuxおよびpfSenseの実装においてシングルスレッドで処理されます。

処理が単一のCPUコアに固定されるため、デバイス上で利用可能な総コア数に関係なく、スループットは制限されます。観察されたパフォーマンス・ベンチマークは、この差を浮き彫りにしています：

  • UDM Pro/SE: PPPoEにおいて通常 1200 Mbps から 1500 Mbps。
  • UDM Pro Max: PPPoEにおいて通常 1400 Mbps から 1800 Mbps。
  • EFG: PPPoEにおいて通常 1400 Mbps から 2400 Mbps。
  • UCG Fiber: MediaTek Filogic 880 SoCを使用しており、ネイティブなPPPoEハードウェアアクセラレーションが含まれているため、5000 Mbpsを超えることができます。

PPPoE Half-Bridgeアクセラレーションの仕組み

PPPoE Half-Bridge（Zero IP Bridgeとも呼ばれます）は、計算負荷の高いPPPoEダイアリングおよびセッション管理のタスクを、専用のオフロードデバイスに移動させます。UniFi gatewayがISPにダイアリングする代わりに、オフロードデバイスがPPPoEセッションを処理し、パブリックIPv4アドレスを取得し、その後、ローカルDHCPサーバーを介してそのアドレスをUniFi gatewayに「渡す」仕組みです。

このアーキテクチャでは、オフロードデバイスはパブリックIPを自身で保持せず、単にIPアドレスの透過的なパススルーとして機能します。UniFi gatewayはDHCP経由でパブリックIPv4を受信し、これによりPPPoEカプセル化のオーバーヘッドなしに、ルーティング、NAT、およびIDS/IPSにCPUリソースを集中させることができます。

一部のISP提供のONT/ONUデバイスは、「Advanced DMZ」や「IP Passthrough」といった機能を通じて同様の機能を提供していますが、多くの場合は提供されていないため、カスタム実装が必要となります。

OpenWrtによる解決策の実装

ArcBox Labsは、OpenWrtとBanana Pi BPI-R4 Proを使用してこの解決策を実装しました。この実装は、PPPoEセッションが確立されるたびにブリッジ構成を自動化するために、hotplug.dメカニズムに依存しています。

技術的なワークフロー

プロセスは、主に2つのファイル：99-half-bridge（トリガー）とstart-half-bridge.sh（ロジック）によって管理されます。実行フローは以下の通りです：

  1. Firewall Adjustment: OpenWrtファイアウォールのWAN側でNAT/MASQUERADEが解除されます。
  2. IP Extraction: スクリプトは、PPPoE仮想インターフェース（例：ppp0）からダイアリングされたパブリックIPv4アドレスを読み取ります。
  3. DHCP Configuration: スクリプトはパブリックIPの/24サブネットを計算し、OpenWrt DHCPサーバーを構成して、その特定のパブリックIPv4をダウンストリームのUniFi gatewayに渡すように設定します。
  4. Source-Based Routing: ポリシーベースルーティングが実装され、パケットがダウンストリームのルーターに割り当てられたソースIPと一致する場合にのみ、PPPoE仮想インターフェース経由で送信されるようにします。これにより、システムは複数のPPPoE接続を同時にサポートできます。
  5. Interface Reset: 物理インターフェースを再起動して、UniFi gatewayがDHCP経由で新しいIPをリクエストするように促します。
  6. ARP Fix: UniFiのARP実装の問題により、静的なARPエントリ（ip neigh replace）をOpenWrtに追加して、通信を安定させます。

この方法を使用することで、ArcBox Labsは5000 Mbpsを超えるPPPoEスループットを達成したと報告しています。

コミュニティの洞察と反論

この実装に関する技術的な議論では、いくつかの論争点や代替的な視覚が浮き彫りにされています：

Hardware vs. Protocol Overhead

一部のユーザーは、パフォーマンスの低下はPPPoE固有の欠陥ではなく、厳密にはハードウェアの差であると主張しています。あるユーザーが次のように述べています：

The UCG Fiber numbers make the case: this is a SoC acceleration gap, not a PPPoE overhead problem. Half-bridge is a workaround for hardware Ubiquiti shipped.

ISP Prevalence and Accuracy

PPPoEの現在の普及率については、大きな議論があります。米国の主要なプロバイダーであるAT&T FiberやXfinity（DOCSIS）は、PPPoEをデータリンク層で使用していないため、コミュニティメンバーは著者の者の主張を訂正し、Xfinity (DOCSIS) と AT&T Fiber (XGSPON) はデータリンク層でPPPoEを使用していないと述べています。

Alternative Solutions

一部のユーザーは、PPPoEセッションを処理するために高性能なOpenWrtデバイスを既に導入している場合、UniFi gatewayをブリッジするのではなく、UniFi gatewayを完全に置き換える方が効率的である可能性を提案しています。また、特定のプロバイダー（例：Bell Canada）において、フルスピードのPPPoEを実現するために、WAS-110のような特定のハードウェアを使用することを挙げるユーザーもいました。

Sources