A lot of people dunk on PPPoE, but it does have one redeeming feature: failover is a lot easier and faster compared to IPoE. With IPoE you often rely on vendor-proprietary mechanisms. The closest thing to a common standard is packet-triggered sessions. Normally, BNG's set up sessions using DHCP but you can rig it to do a RADIUS request for a non-DHCP packet without a known session. In this case, it will send the source IP as the radius username, rather than the configured value (this usually comes from dhcp option 82 which includes the customer-id and circuit-id). In an access network, the source address is usually untrusted so instead you would want to have your BNG attach the NAS-Port-Id to the request (which usually contains the SVLAN and CVLAN).
What's wrong with using BFD for IP over Ethernet? You can put whatever control plane you want on top from simple static route priorities to full blown eBGP and everything inbetween.
Nothing, except that it's expensive to do on the carrier side and completely unsupported on any cheap CPE I know of. Aside from that is not a terrible idea, aside from being over engineered when you could just be using DHCP.
> 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.
An approximate, if imperfect, predictor of PPPoE usage is "did this organization previously deliver packets over twisted pair, especially DSL?". Xfinity/Comcast historically (and currently) delivered packets over coaxial cable -> no PPPoE. All the telcos delivered over DSL -> mostly PPPoE.
PPPoE is pretty much only used for DSL in the US. I'm not sure about elsewhere.
Xfinity and AT&T Fiber do /not/ use PPPoE. Xfinity is built on DOCSIS, and AT&T Fiber is built on XGSPON. This means neither one relies on PPPoE at the data link layer. XGSPON uses XGEM/XGTC at data link layer, DOCSIS uses MAC (same data link protocol as Ethernet).
This article is making a bunch of assertions which are just patently false. PPPoE is basically old hat at this point. It's extremely high overhead anyway, so is only used for DSL because DSL is an old approach.
It's extremely high overhead anyway, so is only used for DSL because DSL is an old approach.
I have 4Gbit symmetric fiber over PPPoE (+ a VLAN) in NL. It's quite common here in Europe. The Unifi Cloud Gateway Fiber, handles it well though (as mentioned in the article).
Quantum Fiber doesn't use PPPoE, it uses IPoE w/ VLAN tagging using VLAN 201, which is a common approach for legacy GPON networks. CenturyLink Fiber does use PPPoE, but I believe only the authentication portion of PPPoE, but I have never had CenturyLink Fiber so I can't say for certain.
I have Quantum and a UCG fiber. IIRC you only have to turn off vlan tagging on the ONT, and then set DHCP and the vlan tag on the UCG. If you try to keep the vlan tag on ONT you will get horrendous latency. The ISP still shows as CenturyLink.
I'm mostly replying to this line "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."
As I noted in my other comment, AT&T Fiber doesn't actually using PPPoE, but anyway, glad to see you linked pon.wiki here. I am running XGSPON ONU stick (ONU on SFP) with the community firmware for my AT&T Fiber connection, getting native 5gbit throughput without the AT&T device in the path. pon.wiki is an amazing resource.
I always suspected this was possible but having it demonstrated is excellent. I would assume this would be of most benefit on an OpenWRT box which _does_ support hardware offload!
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.
AT&T offers only a /25 here. But it's just a shell script, adjust to whatever your flavor is. You can hardcode in your own netmask, bits, and gateway without any issue.
I mean at this point just ditch the Unifi? You have a much more capable gateway in play now that needs to have equal to greater throughput than the one you are bridging for.
No, the half-bridge is less capable for various functions, but happens to have hardware PPPoE offload which makes it faster for this specific function but not for others
Could you go into more detail - how is the half-bridge less capable? (I'm not familiar with ether device, but the ultimate solution seems like a sub-optimal solution to me?)
Essentially, it's a case of smaller device with less powerful CPU and less powerful routing offloads, but which happens to have a hardware offload for the specific use case that they needed offloading - PPPoE.
As the article itself mentions, hardware PPPoE is often present on lower shelf chips, but missing from higher end chips that in turn have more switching/routing capabilities.
There is really so much failure in this post: crappy vendor, misunderstanding how PPP actually works (it requires no addressing at all), using "half bridge" (idiot term) instead of just using it properly. I swear people are even less informed than 20 years ago, it's very sad.
Idiot majority does not make it correct. But that page makes it absolutely clear that apparently nobody understands how PPP actually works (hint: addressing is not PPP)
A lot of people dunk on PPPoE, but it does have one redeeming feature: failover is a lot easier and faster compared to IPoE. With IPoE you often rely on vendor-proprietary mechanisms. The closest thing to a common standard is packet-triggered sessions. Normally, BNG's set up sessions using DHCP but you can rig it to do a RADIUS request for a non-DHCP packet without a known session. In this case, it will send the source IP as the radius username, rather than the configured value (this usually comes from dhcp option 82 which includes the customer-id and circuit-id). In an access network, the source address is usually untrusted so instead you would want to have your BNG attach the NAS-Port-Id to the request (which usually contains the SVLAN and CVLAN).
What's wrong with using BFD for IP over Ethernet? You can put whatever control plane you want on top from simple static route priorities to full blown eBGP and everything inbetween.
Nothing, except that it's expensive to do on the carrier side and completely unsupported on any cheap CPE I know of. Aside from that is not a terrible idea, aside from being over engineered when you could just be using DHCP.
> 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.
Comcast (Xfinity) does not use PPPoE.
An approximate, if imperfect, predictor of PPPoE usage is "did this organization previously deliver packets over twisted pair, especially DSL?". Xfinity/Comcast historically (and currently) delivered packets over coaxial cable -> no PPPoE. All the telcos delivered over DSL -> mostly PPPoE.
It doesn't apply to Verizon (FIOS) either, despite their history of DSL.
Oh thanks. My local ISP insists on pppoe even for business lines.
I like the unifi APs but then using their gateways is a no-no.
PPPoE is pretty much only used for DSL in the US. I'm not sure about elsewhere.
Xfinity and AT&T Fiber do /not/ use PPPoE. Xfinity is built on DOCSIS, and AT&T Fiber is built on XGSPON. This means neither one relies on PPPoE at the data link layer. XGSPON uses XGEM/XGTC at data link layer, DOCSIS uses MAC (same data link protocol as Ethernet).
This article is making a bunch of assertions which are just patently false. PPPoE is basically old hat at this point. It's extremely high overhead anyway, so is only used for DSL because DSL is an old approach.
It's extremely high overhead anyway, so is only used for DSL because DSL is an old approach.
I have 4Gbit symmetric fiber over PPPoE (+ a VLAN) in NL. It's quite common here in Europe. The Unifi Cloud Gateway Fiber, handles it well though (as mentioned in the article).
Some of AT&T's fiber acquisitions still use PPPoE including CenturyLink and Quantum's fiber offerings (acquired from Lumen).
Quantum Fiber doesn't use PPPoE, it uses IPoE w/ VLAN tagging using VLAN 201, which is a common approach for legacy GPON networks. CenturyLink Fiber does use PPPoE, but I believe only the authentication portion of PPPoE, but I have never had CenturyLink Fiber so I can't say for certain.
You're right about Quantum. I just went and checked my router config. (I switched from CL to Q about 6 months ago).
CenturyLink did use a full PPPoE stack though.
I have Quantum and a UCG fiber. IIRC you only have to turn off vlan tagging on the ONT, and then set DHCP and the vlan tag on the UCG. If you try to keep the vlan tag on ONT you will get horrendous latency. The ISP still shows as CenturyLink.
I don't know how 'only authentication' from PPPoE would work... If you do PPPoE auth, then you can DHCP? That would be a pretty weird config to setup.
I know some CenturyLink fiber defaults to PPPoE, but you can ask for IPoE instead.
Mind telling us which assertions are false? They make no claims about pppoe adoption other than that’s what their connection uses.
My fibre connection in the uk uses pppoe (2gbps)
I'm mostly replying to this line "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."
VDSL2 is using PPPoE here in europe often. Havent seen it used on PON based internet connections though
We have PPPoE on XGS-PON (4Gbit) on one of the largest providers in NL.
In my specific situation I was able to use this WAS-110 to get full speed PPPoE from my fiber provider (Bell).
https://pon.wiki/guides/masquerade-as-the-bce-inc-giga-hub-2...
Sure, it bypasses the supplied hardware but does not solve PPPoE limitations on UniFi.
I use the same WAS-110 on Bell.
As I noted in my other comment, AT&T Fiber doesn't actually using PPPoE, but anyway, glad to see you linked pon.wiki here. I am running XGSPON ONU stick (ONU on SFP) with the community firmware for my AT&T Fiber connection, getting native 5gbit throughput without the AT&T device in the path. pon.wiki is an amazing resource.
I always suspected this was possible but having it demonstrated is excellent. I would assume this would be of most benefit on an OpenWRT box which _does_ support hardware offload!
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.
I miss when this kind of content would've just been two paragraphs and a config snippet.
(also, this isn't a "Show HN")
I guess what they did works but it makes some of valid ip addresses unavailable.
Was thinking along the same lines; why do we hardcode a /24? Is that reality in ISP last mile networks?!
AT&T offers only a /25 here. But it's just a shell script, adjust to whatever your flavor is. You can hardcode in your own netmask, bits, and gateway without any issue.
I mean at this point just ditch the Unifi? You have a much more capable gateway in play now that needs to have equal to greater throughput than the one you are bridging for.
No, the half-bridge is less capable for various functions, but happens to have hardware PPPoE offload which makes it faster for this specific function but not for others
Could you go into more detail - how is the half-bridge less capable? (I'm not familiar with ether device, but the ultimate solution seems like a sub-optimal solution to me?)
Essentially, it's a case of smaller device with less powerful CPU and less powerful routing offloads, but which happens to have a hardware offload for the specific use case that they needed offloading - PPPoE.
As the article itself mentions, hardware PPPoE is often present on lower shelf chips, but missing from higher end chips that in turn have more switching/routing capabilities.
There is really so much failure in this post: crappy vendor, misunderstanding how PPP actually works (it requires no addressing at all), using "half bridge" (idiot term) instead of just using it properly. I swear people are even less informed than 20 years ago, it's very sad.
Seems to be a commonly accepted term for this purpose:
https://openwrt.org/docs/guide-user/network/wan/bridge-mode#...
Idiot majority does not make it correct. But that page makes it absolutely clear that apparently nobody understands how PPP actually works (hint: addressing is not PPP)