Show HN: UniFiのPPPoEパフォーマンス低下をPPPoE Half-Bridgeで解決

序文 ArcBox Labsでは、オフィスでUniFiゲートウェイの後ろに5 GbpsのPPPoE接続を使用していますが、その速度には全く近づけず、UDM Pro Maxの動作が不安定になり、運用にも影響が出ていました。これは、多くの他のUniFiユーザーが観測している現象と一致します。 https://community.ui.com/questions/a6f24f8c-6b83-4617-ad33-b5af0b32d8dc?replyId=2808b654-e4be-4ac2-b199-09c1b1a0fbac https://community.ui.com/questions/What-is-the-max-performance-for-PPPOE-on-UDM-Pro-With-Solution/67057f47-509e-4f8b-8edd-5dc29f380759 https://www.reddit.com/r/Ubiquiti/comments/1dto912/story_time_investigating_slow_pppoe_speeds_on/ https://forum.level1techs.com/t/unifi-and-bad-pppoe-speeds-any-solutions/224548 https://community.ui.com/questions/ETA-on-bugfix-for-UDM-Pro-bad-PPPoE-performance/9119aa98-412f-41c7-9188-a30036c2e4c2 https://www.reddit.com/r/Ubiquiti/comments/1buqkx1/max_speed_pppoe_on_udm_pro_with_10gbit_wan/ https://www.reddit.com/r/Ubiquiti/comments/1hctxjk/efg_with_pppoe_uk_testing/ UDM Pro/SE、UXG Pro、EFGといったほとんどのUniFiゲートウェイは、PPPoEやNATのハードウェアアクセラレーションをサポートしないCPUを搭載して出荷されています。その結果、これらのゲートウェイの後ろにPPPoEベースのISP接続を配置すると、スループットが大幅に低下し、定格回線速度に全く近づけなくなります。これはUniFiコミュニティで広く文書化されています。 要するに、UniFiゲートウェイのPPPoEパフォーマンスはかなり悲惨なものです。 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 PPPoE (Point-to-Point Protocol over Ethernet) は、Ethernetフレーム内にPPP (Point-to-Point Protocol) フレームをカプセル化するネットワークプロトコルです。ISPは、ブロードバンドユーザーの認証と請求に使用します。PPPoEは、EthernetフレームとIPパケットの間に6バイトのPPPoEヘッダーと2バイトのPPPプロトコルヘッダーを追加しますが、これらの8バイトのオーバーヘッドは無視できる程度です。 PPPoEがパフォーマンスを低下させる本当の理由は、プロトコル自体にあります。PPPoEベースの接続下では、ルーターは送信するすべてのパケットにPPPoEヘッダーを追加し、受信するすべてのパケットからPPPoEヘッダーを剥がす必要があります。ルーターが見るパケットレートでは、これには大量のCPUパワーまたは専用のハードウェアアクセラレーション回路（ASIC）が必要です。 PPPoEハードウェアアクセラレーションを持たないルーターでは、さらに悪化します。事実上すべてのPPPoE実装はシングルスレッドです。マルチコアCPUであっても、PPPoEのエンキャップ/デキャップは通常1つのコアで実行されます。現在の（2026年4月）ところ、UCG FiberのようなPPPoEハードウェアアクセラレーションをSoCに組み込んでいるUniFiゲートウェイはごく少数です。皮肉なことに、UniFiゲートウェイが高性能であるほど、OEMプラットフォームにPPPoEアクセラレーションが含まれていない可能性が高くなります。例えば、EFGはMarvellのOCTEON TX2 Infrastructureシリーズを使用していますが、そのようなサポートはありません。 ほとんどのUniFiゲートウェイはPPPoEハードウェアアクセラレーションを持たないOEMプラットフォームを使用しているため、ファームウェアの作業をいくら行っても、PPPoEパフォーマンスの問題の根本を解決することはできません。また、UniFiのよく知られたエンジニアリング品質を考えると、可能なソフトウェア側のPPPoE最適化さえも、まだ行われていません。 外部PPPoE Half-Bridgeアクセラレーション 2026年になっても、Bell Canada、AT&T Fiber、米国のXfinity、そしてヨーロッパ、アジア、中国のほとんどのISPを含む、非常に多くのISPがPPPoEに依存しています。UniFiゲートウェイが単独で十分なPPPoEパフォーマンスを提供できない場合、PPPoEダイヤルを専用デバイスに任せることができます。そのデバイスはPPPoEをダイヤルし、IPアドレス（例: 公開IPv4）を取得し、そのIPをPPPoE仮想インターフェース（例: ppp0）から剥がし、DHCP経由でUniFiゲートウェイに渡します。UniFiゲートウェイは、PPPoEのCPU負荷を一切負わずにDHCP経由で公開IPv4を取得し、ルーティング、IDS/IPS、NATに集中できます。 PPPoEセッション ISP <===============> [PPPoE Offloading via OpenWrt] ========================> [UniFi Gateway] 公開IPv4を所有しない DHCPから公開IPv4を所有 WAN この技術はPPPoE Half-Bridge（Zero IP Bridgeとも呼ばれる）として知られています。PPPoEオフロードデバイスはPPPoEダイヤルを行い、ダイヤルされたIPv4をPPPoE仮想インターフェース（例: ppp0）から剥がし、物理インターフェース上でDHCPサーバーを起動し、ダイヤルされたIPv4アドレスを下流のルーター（UniFiゲートウェイ）にDHCP経由で渡します。これにより、PPPoEオフロードデバイスはPPPoEダイヤルに集中し、下流のUniFiゲートウェイはPPPoEのCPU負荷を一切負わずにDHCP経由で公開IPv4を取得できます。 実際、一部のISP提供のONU/ONTデバイスはすでにこの機能を実装しています。特定のモデルは、「Advanced DMZ」、「IP Passthrough」、「DMZplus」などの機能を提供します。これらを有効にすると、ONU/ONT（PPPoEハードウェアアクセラレーションを含む）がPPPoEダイヤル自体を行い、結果として得られた公開IPv4を下流ルーターにDHCP経由で渡します。しかし、多くのISPのONU/ONTデバイスはこれを提供しておらず、その場合は自分でソリューションを構築する必要があります。 OpenWrtによるPPPoE Half-Bridgeの実装 ここでは、OpenWrtのhotplug.dメカニズムを使用して、前述のPPPoE half-bridgeアクセラレーションを実装します。完全なコードと設定例は、arcboxlabs/pppoe-half-bridge GitHubリポジトリで入手できます。 arcboxlabs/pppoe-half-bridgeのコアは、99-half-bridgeとstart-half-bridge.shの2つのファイルで構成されています。99-half-bridgeは/etc/hotplug.d/iface/に配置され、PPPoEダイヤルが成功してOpenWrtがppp0スタイルの仮想インターフェースを作成したときに起動し、start-half-bridge.shを呼び出してhalf-bridgeの設定を完了します。 start-half-bridge.shには実際のhalf-bridgeロジックが含まれており、PPPoEダイヤルが完了すると、以下の手順を順番に実行します。 1. OpenWrtファイアウォールのWAN側でのNAT/MASQUERADEを無効にします。 2. ダイヤルされたIPv4アドレスをPPPoE仮想インターフェース（例: ppp0）から読み取ります。 3. ダイヤルされた公開IPv4が属する/24サブネットを計算し、そのサブネットの最初のIPアドレス（例: x.x.x.1）をOpenWrtのDHCPサーバーのゲートウェイとして使用し、OpenWrtのDHCPサーバーがダイヤルされた公開IPv4（例: x.x.x.114）を下流のUniFiゲートウェイに渡すように正しいオフセットを設定します。 4. デフォルトルートを置き換え、ソースIP（つまり、OpenWrtのDHCPサーバーが下流ルーター/UniFiゲートウェイに渡した公開IPv4）に一致するPPPoE仮想インターフェースからパケットが送信されるように、「ソースベースルーティング」を実装するためにポリシーベースルーティングを追加します。これにより、複数のPPPoEブロードバンド接続を同時にアクセラレートすることが可能になります。 5. 前の手順で計算されたDHCPサーバーゲートウェイとオフセット値をOpenWrtのDHCPサーバー設定に適用し、DHCPサーバーを再起動して有効にします。 6. OpenWrtの物理インターフェースを再起動（ifdown && ifup）してリンクステータスの変更をトリガーし、下流のUniFiゲートウェイにOpenWrtのDHCPサーバーから新しい公開IPv4を要求させます。 ほとんどのルーターでは、上記のステップでDHCP経由で公開IPを取得し、オンラインになるのに十分です。しかし、UniFiゲートウェイでは、バグのあるARP実装のおかげで、OpenWrtとUniFiゲートウェイ間の信頼性の高い通信を確保するために、OpenWrtに静的ARPエントリ（ip neigh replace）を追加する必要があります。 完全な設定と使用例は、arcboxlabs/pppoe-half-bridge GitHubリポジトリのEXAMPLE.mdファイルでも確認できます。ここでは、OpenWrtを実行するBanana Pi BPI-R4 ProをPPPoEオフロードデバイスとして使用していますが、OpenWrtをサポートする任意のデバイスを使用できます。