New PPPoE backend, some feedback
-
That should work. There's nothing newer I'm aware of. Because it's now a regular interface (mostly) you should be able to do regular interface things with it. If you want/need to.
-
Is there a definitive list of PPPoE performance tweaks that should be removed before using if_pppoe?
If so, it may be worth adding it to Jim's article too.
Apologies if it exists somewhere but I did look... and clearly I have forgotten all the tweaks I did apply to try and get the best PPPoE performance on the current backend.
️ -
Does anyone have packet loss on a new backend? The connection is not interrupted just loss of packets, about 5%, once a day or so.
MONITOR: WAN_PPPOE has packet lossThis could be something on isp or on my side also, because I haven't seen this before. IDK...
-
Not seen any significant loss here. Been solid since I switched both my edge PPPoE links to it:
And I'd been running it for months before that on one WAN in 25.03.
-
@RobbieTT said in New PPPoE backend, some feedback:
Is there a definitive list of PPPoE performance tweaks that should be removed before using if_pppoe?
There isn't. The testing we did though was without any of the previous pppoe tweaks AFAIK. So the default sysctls only.
-
@stephenw10 said in New PPPoE backend, some feedback:
@RobbieTT said in New PPPoE backend, some feedback:
Is there a definitive list of PPPoE performance tweaks that should be removed before using if_pppoe?
There isn't. The testing we did though was without any of the previous pppoe tweaks AFAIK. So the default sysctls only.
I know, I just need a nudge on what I now need to remove (eg deleting the top entry for a start):
️ -
I think only the net.isr.dispatch value there is non-default.
Default values I see here are:
Tunable Name Description Value net.inet.ip.portrange.first 1024 net.inet.tcp.blackhole Do not send RST on segments to closed ports 2 net.inet.udp.blackhole Do not send port unreachables for refused connects 1 net.inet.ip.random_id Assign random ip_id values 1 net.inet.tcp.drop_synfin Drop TCP packets with SYN+FIN set 1 net.inet.ip.redirect Enable sending IP redirects 1 net.inet6.ip6.redirect Send ICMPv6 redirects for unforwardable IPv6 packets 1 net.inet6.ip6.use_tempaddr Create RFC3041 temporary addresses for autoconfigured addresses 0 net.inet6.ip6.prefer_tempaddr Prefer RFC3041 temporary addresses in source address selection 0 net.inet.tcp.syncookies Use TCP SYN cookies if the syncache overflows 1 net.inet.tcp.recvspace Initial receive socket buffer size 65228 net.inet.tcp.sendspace Initial send socket buffer size 65228 net.inet.tcp.delayed_ack Delay ACK to try and piggyback it onto a data packet 0 net.inet.udp.maxdgram Maximum outgoing UDP datagram size 57344 net.link.bridge.pfil_onlyip Only pass IP packets when pfil is enabled 0 net.link.bridge.pfil_member Packet filter on the member interface 1 net.link.bridge.pfil_bridge Packet filter on the bridge interface 0 net.link.tap.user_open Enable legacy devfs interface creation for all users 1 net.link.vlan.mtag_pcp Retain VLAN PCP information as packets are passed up the stack 1 kern.randompid Random PID modulus. Special values: 0: disable, 1: choose random value 347 net.inet.ip.intr_queue_maxlen Maximum size of the IP input queue 1000 hw.syscons.kbd_reboot enable keyboard reboot 0 net.inet.tcp.log_debug Log errors caused by incoming TCP segments 0 net.inet.tcp.tso Enable TCP Segmentation Offload 1 net.inet.icmp.icmplim Maximum number of ICMP responses per second 0 vfs.read_max Cluster read-ahead max block count 32 kern.ipc.maxsockbuf Maximum socket buffer size 4262144 net.inet.ip.process_options Enable IP options processing ([LS]SRR, RR, TS) 0 kern.random.harvest.mask Entropy harvesting mask 351 net.route.netisr_maxqlen maximum routing socket dispatch queue length 1024 net.inet.udp.checksum compute udp checksum 1 net.inet.icmp.reply_from_interface ICMP reply from incoming interface for non-local packets 1 net.inet6.ip6.rfc6204w3 Accept the default router list from ICMPv6 RA messages even when packet forwarding is enabled 1 net.key.preferred_oldsa 0 net.inet.carp.senderr_demotion_factor Send error demotion factor adjustment 0 net.pfsync.carp_demotion_factor pfsync's CARP demotion factor adjustment 0 net.raw.recvspace 65536 net.raw.sendspace 65536 net.inet.raw.recvspace Maximum space for incoming raw IP datagrams 131072 net.inet.raw.maxdgram Maximum outgoing raw IP datagram size 131072 kern.corefile Process corefile name format string /root/%N.core kern.crypto.iimb.enable_aescbc 1 kern.crypto.iimb.enable_multiq 1 kern.crypto.iimb.use_task 0 kern.crypto.iimb.arch auto kern.crypto.iimb.prefetch 1 kern.crypto.iimb.max_jobs 256Urgh, formatting fail!
-
Well I'm up and running on if_pppoe and I can see the pppoe load being spread across multiple cores. It works!
UK / Openreach FTTP / 1500MTU (baby-jumbos) / Xeon D-1736NT CPU @ 2.70GHz / HyperThreading Off / IPV4 & IPV6 / bidirectional fq_codel / 10 GbE LANs & VLANs
I think I will need to get the Netgate 6100 out and try this. Running pfSense+ on my Xeon provided no issues for single-core PPPoE anyway but it does seem to run at a slightly lower CPU load with the latest config.
No PPP logs or entries in the System logs, which I think has been mentioned already.
️ -
Ooo you got full size packets over pppoe working. For some reason I can't seem to set that. I'm wondering if I'm hitting some hardware restriction.
Did you have to do anything special?
-
@stephenw10 said in New PPPoE backend, some feedback:
Ooo you got full size packets over pppoe working. For some reason I can't seem to set that. I'm wondering if I'm hitting some hardware restriction.
Did you have to do anything special?
Didn't change anything as I did an in-place update so my config was unchanged from before:
@Smaug ~ % ping -D -s 1472 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 1472 data bytes 1480 bytes from 8.8.8.8: icmp_seq=0 ttl=119 time=8.628 ms 1480 bytes from 8.8.8.8: icmp_seq=1 ttl=119 time=8.637 ms 1480 bytes from 8.8.8.8: icmp_seq=2 ttl=119 time=8.457 ms 1480 bytes from 8.8.8.8: icmp_seq=3 ttl=119 time=8.303 ms 1480 bytes from 8.8.8.8: icmp_seq=4 ttl=119 time=8.383 ms 1480 bytes from 8.8.8.8: icmp_seq=5 ttl=119 time=8.600 ms 1480 bytes from 8.8.8.8: icmp_seq=6 ttl=119 time=8.442 ms 1480 bytes from 8.8.8.8: icmp_seq=7 ttl=119 time=8.582 ms 1480 bytes from 8.8.8.8: icmp_seq=8 ttl=119 time=8.845 ms 1480 bytes from 8.8.8.8: icmp_seq=9 ttl=119 time=8.423 msSo everything worked for me out of the gate; I only checked it 'just to be sure' as it is a bit of a UK oddity.
I can compare a few things for you tomorrow if you like.
️ -
Yup, something odd Openreach are doing. I'll recheck....
-
Hmm, I have that set but the actual interface MTU is 1492 still:
pppoe1: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492 description: BT options=0 inet 86.191.X.X --> 172.16.13.252 netmask 0xffffffff inet6 fe80::201:21ff:fe01:6775%pppoe1 prefixlen 64 scopeid 0x10 groups: pppoec nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD>Do you have the parent set to 1508?
-
Ah forgot I'd added it to a bridge.
That worked once I set the parent to 1508.
[2.8.0-BETA][admin@pfsense.fire.box]/root: ifconfig igb1 igb1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1508 description: BT_MODEM options=48100b8<VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,VLAN_HWFILTER,HWSTATS,MEXTPG> ether 00:01:21:01:67:76 inet 192.168.102.10 netmask 0xffffff00 broadcast 192.168.102.255 inet6 fe80::201:21ff:fe01:6776%igb1 prefixlen 64 scopeid 0x2 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> [2.8.0-BETA][admin@pfsense.fire.box]/root: pppcfg pppoe1 dev: igb1 svc: BTInfinity state: session sid: 0x1a99 PADI retries: 5 PADR retries: 0 time: 00:01:24 sppp: phase network authproto auto authname "bthomehub@btbroadband.com" peerproto auto dns: 81.139.56.100 81.139.57.100 [2.8.0-BETA][admin@pfsense.fire.box]/root: ifconfig pppoe1 pppoe1: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500 description: BT options=0 inet 86.191.X.X --> 172.16.13.252 netmask 0xffffffff inet6 fe80::201:21ff:fe01:6775%pppoe1 prefixlen 64 scopeid 0xf groups: pppoec nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD> -
@stephenw10 said in New PPPoE backend, some feedback:
Hmm, I have that set but the actual interface MTU is 1492 still:
pppoe1: flags=1008851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492 description: BT options=0 inet 86.191.X.X --> 172.16.13.252 netmask 0xffffffff inet6 fe80::201:21ff:fe01:6775%pppoe1 prefixlen 64 scopeid 0x10 groups: pppoec nd6 options=123<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL,NO_DAD>Do you have the parent set to 1508?
The link to the ONT? It is set to 1508 as you would expect - the final pipe needs to be a bit bigger to carry the PPPoE overhead and I am sure you used to have it set that way:
️ -
Yeah, that would do it for sure!
Mine:
igc0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1508 description: ONT options=4e020bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,WOL_MAGIC,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTPG> ether 02:76:xx:xx:xx:81 inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255 inet6 fe80::76:xxxx:fe00:xxxx%igc0 prefixlen 64 scopeid 0x5 media: Ethernet autoselect (1000baseT <full-duplex>) status: active nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>️ -
Yup and in fact you don't have to set the parent to 1508. If you set the pppoe interface to 1500 the parent will inherit that and be set to 1508.
I had the parent interface as part of an unassigned bridge and forgot. In that situation the bridge interface controls the MTU of all the members and was forcing it to 1500.
All good now though.
-
@stephenw10 said in New PPPoE backend, some feedback:
Yup and in fact you don't have to set the parent to 1508. If you set the pppoe interface to 1500 the parent will inherit that and be set to 1508.
All good now though.
More things I didn't know!
I'll probably leave it set as 1508 just to help remind me what I am doing when I am tired and forgetting what I am supposed to be doing...
️ -
@RobbieTT I've posted my issues over in the reddit forum but I'm not sure its been picked up.
If you go to Status-> Interfaces - then Disconnect the WAN interface to drop the PPPoE, then refresh the page to get the button to change to Connect, then Connect, does it reconnect? I only get every other connection attempt work, every other one stalls saying its "UP" but no Gateways or connectivity is established, I need to drop and then reconnect again. It's fine switching back to the original PPPoE.
Also the IPv6 Gateway doesn't always start monitoring correctly, and shows status Unknown, but there is IPv6 connectivity okay. Going into Gateways and into the IPv6 gateway and disabling monitoring, then saving that, then re-enabling monitoring and it starts monitoring and switches back to online.
With regards to the MTU, I find a great way to check is to use Speedguide.net and from the left hand menu select their TCP/IP Analzyer, snapshot of mine below. I would think you are only seeing 1492 MTU and losing the 8 bytes due to PPPoE. Your MTU can be set to 1508 (1508 being what they call a Baby Jumbo Frame) which is supported via Openreach and most others, so that holds the extra overhead for PPPoE, and when that's stripped of you are left then with the full 1500 bytes.
-
@Phil2025 said in New PPPoE backend, some feedback:
Speedguide.net
Hi Phil, perhaps lost in the noise but I didn't say I had an issue with the PPPoE MTU, only that I checked it to be sure it was still ok, demonstrated my settings and displayed the test results to prove it. @stephenw10 did have a hiccup with his settings due to his role in testing multiple configurations - all now resolved.
I did try the speedguide.net link and I note that it does not run on Safari and seems to require a Chromium-based browser. Using Brave browser my results are:
« SpeedGuide.net TCP Analyzer Results » Tested on: 2025.04.25 04:13 IP address: 93.8x.xxx.xx Client OS/browser: Mac OS (Chrome 135.0.0.0) TCP options string: 020405b4010303060101080a26e64ea30000000004020000 MSS: 1460 MTU: 1500 TCP Window: 131776 (not multiple of MSS) RWIN Scaling: 6 bits (2^6=64) Unscaled RWIN : 2059 Recommended RWINs: 64240, 128480, 256960, 513920, 1027840 BDP limit (200ms): 527 Mbps (53 Megabytes/s) BDP limit (500ms): 211 Mbps (21 Megabytes/s) MTU Discovery: ON TTL: 50 Timestamps: ON SACKs: ON IP ToS: 00000000 (0)
Nothing leaps out at me but I am unfamiliar with this tool so feel free to run your eyes over it for me.
Regarding the Status / Interfaces / PPPoE interface 'Disconnect' I do experience the exact same issue you describe and pfSense seems to hang after the first state change command (eg Disconnect WAN) and if left alone it fails to recover IPv6 properly. If you repeat the command it seems to all work fine again, including IPv6.
So that looks like a bug that needs resolving. It may even be linked to the PPP status logs not working, as noted by others.
️ -
@RobbieTT Many thanks for trying the connect and disconnect, good to know its not just me, I hope they pick it up and fix it as I think it could mean if the Internet goes down for some reason, it may not come back up again by itself.
Yes your MTU looks spot on, usually with 1500 set under the WAN it would mean you would only see 1492 as MTU, so I expect your ISP is negotiating 1508 when you connect and overriding the 1500 MTU you have set.
With other overheads you end up with 1448 bytes of useable data in each packet. You can tweak things to get rid of those overheads and get a bit more throughput, but things like timestamps are useful for retransmission and recovering from errors, so what you lose in maximum throughput you gain in another way, so its all good as it is I would say.
