How to squeeze 5 Gbps out of PPPoE on UniFi: a look at a fix using a half-bridge

Networks and networking equipment
, , ,
1

In Short: UniFi gateways throttle PPPoE speed due to single-thread processing without hardware acceleration. We dissect a fix via half-bridge on a separate OpenWrt router that pushes throughput up to 5 Gbps — and who really needs it.

cover
cover1280×670 21.4 KB

If you have a gigabit Internet (and especially 2.5- or 5-gigabit) over PPPoE and a UniFi router, there’s a good chance you’re paying for speed you don’t actually get. A fresh analysis from ArcBox Labs with a clear solution to the problem in a single day sparked a discussion on Hacker News — and the topic is so common in our region (PPPoE from Russian and not only providers is standard) that it’s worth unpacking in Russian. We’re also opening a new forum category: “Networking and Network Equipment.”

What’s the problem

PPPoE is a protocol that attaches an extra 8-byte header to every packet (it must be added on the egress and stripped on ingress). It seems trivial. But there are two nuances that kill speed:

  • UniFi gateways (UDM Pro/SE/Pro Max, EFG) lack hardware acceleration for PPPoE in their SoCs — processing falls on the CPU;
  • almost all PPPoE implementations are single-threaded — that is, one PPPoE session is processed by exactly one CPU core, regardless of how many cores the device has.

Result — a ceiling that fast-rate subscribers hit. According to ArcBox measurements:

  • UDM Pro / SE: ~1200–1500 Mbps;
  • UDM Pro Max: ~1400–1800 Mbps;
  • EFG: ~1400–2400 Mbps.

That means on a 5 Gbps channel the UDM Pro Max tops out around ~1800 Mbps and begins to stutter due to a busy core. By comparison: the IPQ9574 chip on UCG Fiber with hardware PPPoE acceleration calmly delivers over 5000 Mbps — but that’s a different hardware.

Solution: PPPoE half-bridge

The idea is to remove PPPoE handling from UniFi itself and leave it only to routing and firewall. A separate box handles PPPoE (in this write-up — Banana Pi BPI-R4 Pro with OpenWrt), while the public IP is handed down to UniFi.

Traffic diagram:

ISP ── [OpenWrt: up PPPoE, ppp0] ── [UniFi: gets a white IP via DHCP, routes/firewalls]

Key trick — a “half-bridge”: OpenWrt establishes the session, obtains a white IPv4 on interface ppp0, but does not keep it for itself, and via its DHCP server issues the same address to the UniFi gateway. For UniFi it looks as if the white IP is directly on its WAN.

From practical setup details mentioned by the author:

  • on WAN OpenWrt — disable NAT/MASQUERADE (address transparently goes down);
  • the public IP is pulled from ppp0 and handed to the gateway via DHCP;
  • for multiple sessions — source-based and policy-based routing;
  • add static ARP entries to bypass UniFi’s “quirky ARP” implementation;
  • everything is automated with hotplug scripts (99-half-bridge, start-half-bridge.sh) so the address rebinds automatically on reconnect.

Result: the setup pierces the ceiling and yields more than 5000 Mbps where a bare UDM Pro Max used to choke at ~1800.

A sober look: do you need this

Honestly: there’s a big majority for whom — no. This solution is for a narrow but real niche.

  • If your plan is up to ~1 Gbps, UniFi will likely push it over PPPoE anyway — there’s no need to build a half-bridge.
  • The problem appears at 2.5–10 Gbps over PPPoE, and this is still the realm of a few people.
  • The solution adds another box (OpenWrt router), a point of failure, and noticeable complexity (ARP quirks, policy routing). It’s a conscious trade-off of simplicity for speed.

There are, however, simpler alternatives worth trying first:

  • many providers offer IPoE/DHCP or IP Passthrough on ONT/ONU — if so, PPPoE can be removed from UniFi altogether;
  • sometimes moving PPPoE to any router with hardware offload (MikroTik, OpenWrt on a suitable SoC) helps — the principle is the same as in the write-up;
  • as a last resort — switch to a gateway model with hardware PPPoE acceleration (the same UCG Fiber).

What to do

  1. Measure whether you’re hitting a limit at all: speed test to the provider server and top CPU usage on the gateway under load. If the kernel isn’t pegged — issue isn’t there.
  2. Ask the provider about IPoE/IP Passthrough — the cheapest way to bypass the PPPoE ceiling.
  3. If the channel is 2.5 Gbps+ and the limit is real — half-bridge on a separate OpenWrt router is a working solution; budget time for ARP quirks and policy routing.
  4. Don’t break a working network for the sake of fantasy speeds — chasing 5 Gbps only makes sense if you actually use those 5 Gbps.

Sources

Who has PPPoE and at what speed does your router start to stall? And how did you solve it — IPoE, a separate router with offload, or simply accept the ceiling?