HN Debrief

Show HN: We Fixed UniFi's Slow PPPoE Performance with PPPoE Half-Bridge

  • Infrastructure
  • Hardware
  • Networking
  • Open Source

The post walks through a workaround for UniFi gateways that lose a lot of throughput on PPPoE connections. The setup puts a second device in front of the UniFi box to terminate PPPoE and then passes traffic onward in a “half-bridge” arrangement, preserving most of the existing UniFi setup while recovering line speed. The key point that landed is that this is mostly a silicon and driver story, not proof that PPPoE itself cannot handle multi-gigabit links. People pointed to the UniFi Cloud Gateway Fiber as evidence. It performs well on PPPoE, which suggests the bad results come from missing hardware acceleration on specific UniFi platforms.

If you run UniFi on a PPPoE-based ISP, treat throughput limits as a hardware offload problem before you redesign your network or blame the protocol. Also verify your ISP details carefully, because the post’s broad claims about which providers use PPPoE were challenged hard.

Discussion mood

Mostly positive about the hack itself, but skeptical of the framing. People liked the concrete workaround and the proof that PPPoE bottlenecks on UniFi are really hardware acceleration gaps, while criticizing the post for sloppy claims about PPPoE adoption and some imprecise networking terminology.

Key insights

  1. 01

    UniFi is the bottleneck, not PPPoE

    The useful takeaway from the benchmark numbers is that PPPoE is not inherently too expensive for modern links. The limiting factor is whether the system-on-chip has PPPoE offload. That reframes the post from a protocol story into a product-selection story. If one UniFi model handles PPPoE fine and another falls over, the protocol is not the main variable.

    When you see bad PPPoE throughput, compare chip capabilities and offload support across models before changing ISPs or abandoning your topology. Vendor lineups can hide major performance differences behind similar branding.

      Attribution:
    • sage981 #1
    • cr3ative #1
  2. 02

    PPPoE persists because operations still favor it

    PPPoE is still hanging around for reasons that are more operational than technical. People called out faster failover, mature session handling, and broad support on cheap customer-premises equipment as reasons carriers keep it, especially in footprints that grew out of DSL. Suggested alternatives like Bidirectional Forwarding Detection can work, but commenters argued they are costlier on the carrier side and poorly supported on low-end gear.

    If you are dealing with last-mile networks, do not assume newer physical media automatically means a cleaner control plane. Migration away from PPPoE can be blocked by provisioning systems, failover behavior, and installed device support.

      Attribution:
    • Arubis #1
    • icedchai #1
    • microtonal #1
    • chaz6 #1
  3. 03

    The front box only wins at one job

    The half-bridge device is not a generally better gateway. It is a smaller box with weaker overall routing and switching features that just happens to accelerate PPPoE in hardware. That makes the architecture less silly than it first appears. You are not replacing UniFi with a superior router. You are inserting a specialist that does one expensive function faster.

    Use this pattern only when PPPoE termination is your choke point. For broader routing, firewalling, and management needs, the extra box may still be a net downgrade if you let its role expand.

      Attribution:
    • p_l #1 #2
  4. 04

    The subnet trick is configurable but awkward

    The workaround burns part of an address block to make the handoff work, which immediately raised concerns about wasting valid IP space. The reply was that the script’s hardcoded /24 is not fundamental. It can be adjusted to whatever subnet or gateway layout your ISP provides, including smaller allocations. That makes it fixable, not clean.

    Read this setup as a template, not a drop-in recipe. Before copying it, map your ISP’s actual addressing and confirm the script does not collide with usable addresses or assumptions in your environment.

      Attribution:
    • mono442 #1
    • ksk23 #1
    • hayleyest #1
  5. 05

    Bypassing ISP gear is a separate problem

    Several comments pointed to pon.wiki and ONU-on-SFP setups like the WAS-110 as a way to remove the ISP-supplied gateway on fiber. That is valuable, but it solves a different problem from the one in the post. You can successfully impersonate or replace the provider device and still hit UniFi PPPoE limits afterward. The access-device hack and the PPPoE acceleration hack sit on different layers.

    Split your troubleshooting into two questions. First, can you get rid of the ISP box. Second, can your own gateway terminate the service at full speed. Solving one does not imply the other is fixed.

      Attribution:
    • davidhariri #1
    • asniper #1
    • tristor #1

Against the grain

  1. 01

    Just replacing UniFi may be cleaner

    The strongest pushback was that inserting a second box to paper over a gateway defect is architectural self-harm. Even with the clarification that the front device is only better at PPPoE, the criticism stands. If you already need another router-class device in the path to hit advertised speed, buying gear that handles PPPoE natively may be simpler than maintaining a specialized split design.

    If this workaround would become a long-term production setup, price the operational cost against a gateway replacement. The clever fix can easily be the more expensive one once troubleshooting and future upgrades are included.

      Attribution:
    • simonjgreen #1
    • p_l #1 #2
  2. 02

    The ISP examples undermine trust

    A lot of the technical idea survived, but the post lost credibility by overstating where PPPoE is used. Comcast/Xfinity was called outright incorrect, and AT&T Fiber was disputed as well. That matters because deployment claims are doing persuasive work in the article. Once they wobble, readers have to separate the measured UniFi behavior from the author’s broader industry framing.

    When you evaluate workaround posts like this, trust the direct measurements more than the market-level claims around them. Verify provider-specific assumptions before you design around them.

      Attribution:
    • tristor #1 #2
    • sarabveer #1

In plain english

half-bridge ↩
A networking setup where one device handles part of the connection, such as Point-to-Point Protocol over Ethernet termination, and passes traffic through so another device can still do routing or firewalling.
ONU ↩
Optical Network Unit, a device in a passive optical network that terminates the optical service for a customer or local distribution point.
PON ↩
Passive Optical Network, a fiber access network where multiple customers share optical infrastructure without powered equipment in the field.
PPPoE ↩
Point-to-Point Protocol over Ethernet, a way of running a session-based broadband connection over Ethernet links, often used by internet providers for authentication and connection management.
SFP ↩
Small Form-factor Pluggable, a modular transceiver format used to connect network devices to fiber or copper links.

Reference links

Fiber bypass and ONU guides

Networking documentation