Article URL: https://arcbox.dev/blog/unifi-pppoe-half-bridge-acceleration Comments URL: https://news.ycombinator.com/item?id=49152871 Points: 12 # Comments: 4

At ArcBox Labs, our office has a 5 Gbps PPPoE connection behind a UniFi gateway, and we could never get anywhere close to that speed, and our UDM Pro Max is beginning to struggle and even affecting operation stability: The overwhelming majority of UniFi gateways, from the UDM Pro/SE/Pro Max and UXG Pro to the EFG, ship with CPUs that support neither PPPoE nor NAT hardware acceleration. As a result, whenever you put a PPPoE-based ISP connection behind one of these gateways, throughput takes a serious hit and never comes close to the rated line speed. This has been well-documented in the UniFi community: PPPoE (Point-to-Point Protocol over Ethernet) is a network protocol that encapsulates PPP (Point-to-Point Protocol) frames inside Ethernet frames; ISPs use it to authenticate and bill broadband users. While PPPoE does add an extra 6-byte PPPoE header and 2-byte PPP protocol header between the Ethernet frame and the IP packet, those 8 bytes of overhead are negligible. The real reason PPPoE kills performance is the protocol itself. Under a PPPoE-based connection, the router has to add a PPPoE header to every outgoing packet and strip a PPPoE header off every incoming packet. At the packet rates a router sees, this requires either a lot of CPU power or a purpose-built hardware acceleration circuit (ASIC). For routers without PPPoE hardware acceleration, it gets worse: virtually all PPPoE implementations are single-threaded. Even with a multi-core CPU, PPPoE encap/decap typically runs on a single core. While pfSense's if_pppoe implements its own NIC-independent RSS (Receive Side Scaling) and the Linux kernel's pppoe module supports RPS/XPS, these only help when there are multiple PPPoE sessions. For a single PPPoE session (i.e. a single broadband connection dialed once) — which is the common case — processing is still pinned to one CPU core. As of this writing (April 2026), only a handful of UniFi gateways, like the UCG Fiber with its MediaTek Filogic 880, have PPPoE hardware acceleration baked into their SoC. And ironically, the higher-end the UniFi gateway, the less likely its OEM platform is to include PPPoE acceleration: the EFG, for example, uses Marvell's OCTEON TX2 Infrastructure series, which has no such support. Since most UniFi gateways use OEM platforms that lack PPPoE hardware acceleration, no amount of firmware work can fix the PPPoE performance problem at its root. And given UniFi's well-known engineering quality, even the software-side PPPoE optimizations that are possible have been left on the table. Even in 2026, a huge number of ISPs still rely on PPPoE, including Bell Canada, AT&T Fiber, and Xfinity in the US, along with the vast majority of ISPs in Europe, Asia, and China. If the UniFi gateway can't deliver enough PPPoE performance on its own, we can hand the PPPoE dialing to a dedicated device instead. That device dials PPPoE, obtains an IP address (e.g. a public IPv4), strips that IP from the PPPoE virtual interface (e.g. ppp0), and hands it down to the UniFi gateway via DHCP. The UniFi gateway gets a public IPv4 via DHCP without carrying any of the PPPoE CPU load, and is free to focus on routing, IDS/IPS, and NAT: