Optimal MTU and SQM settings for VDSL2 35B/VLAN/PPPoE


I'm an absolute OpenWrt newbie that has decided to repurpose a mini PC I got from AliExpress a couple years ago by using openwrt-23.05.0-rc3-x86-64-generic-ext4-combined-efi.img. Only basic setup is done at this point, i.e. all my LAN hosts can connect to WAN without issue.

Now I'm mainly looking forward to using OpenWrt for
a) connecting to multiple WireGuard peers and using the pbr package to route traffic through tunnels from/to certain hosts,
b) running a caching DNS resolver myself and blocking requests (to ad servers) based on blacklists, and
c) using SQM to combat bufferbloat, especially while playing fast paced online games.

Despite reading up on these topics in the OpenWrt wiki, I feel overwhelmed by all the information.

My questions:

  1. What MTU do I need to set for each of my WAN interfaces?
    I need three interfaces for the router to be able to connect to WAN: eth0, eth0.7 and pppoe-wan.
    Previously I had only set the MTU of eth0 to 1492, but because I was unsure if this is the correct value or even the correct interface, I reverted this to the default value of 1500 and it didn't seem to make any difference.
  2. Which of the WAN interfaces (eth0, eth0.7, pppoe-wan) should I select for SQM?
    The documentation says to select the "WAN link". This is why I think it should be pppoe-wan. But wouldn't this mean that traffic that gets routed through the WireGuard tunnels would bypass SQM entirely and could cause spikes in latency for non-VPN traffic still? I want no traffic to be exempt from SQM, so shouldn't I rather select eth0?
  3. What should I set Per Packet Overhead, Minimum Packet Size and Maximum Packet Size to?
    If I understand the documentation correctly, in my case Per Packet Overhead should be set to 34 and Minimum Packet Size to 68, but I think this might be incorrect because of the VLAN tagging that my ISP mandates. I'm also confused by the fact that the default value of Maximum Packet Size is so much bigger than MTU (because I think of MTU as the "hard limit" for packet size). Also optimal values for these settings probably change if I select, for example, eth0 instead of pppoe-wan.
  4. How do I boot into OpenWrt without a keyboard connected to the router?
    This is probably a very odd question, but I couldn't figure out how to get past the grub menu, that asks me if I want to boot into failsafe mode or not, without pressing the Return/Enter key.

I don't know if this is needed to answer any of the questions, but here are some speedtest results (without SQM and default MTU):

Thanks in advance!

  1. MTU: change was not needed, I found.
  2. sqm pppoe-wan 49152/10800 , pocake, ppo34, mpu64
    https://www.speedtest.net/result/15167658537 46.65/8.55Mbps, Ping ms 19i/19d/19u
  3. OpenWrt 22.03.5 LeMaker Banana Pi, wan on eth0.35, sqm pppoe-wan, cake/pieceofcake.qos, ppo34, mpu64
    On 5port managed switch, ports 1-5 left untagged on vlan1, ports 4 and 5 tagged on vlan35 for Bell internet with pppoe.
    Bananapi connected to port 4 and dsl modem on port 5. (router-on-a-stick)
  4. Putty for Windows, Teraterm for serial debugging, or ssh into the router.
1 Like

Thanks, I'll try these :+1:

But all these only work after the grub menu. Without a keyboard connected to press return/enter on, I don't get past the grub menu.

Okay, this is IMHO more subtle than it looks. The issue here is the 8 byte PPPoE header. This header lives inside the ethernet payload area on the path between your router and your ISPs PPPoE server/access conentrator, but is not transmitted further upstream. The consequence of this is that on the ethernet path to the ISP (so eth0 and eth0.7) you should keep the maximal MTU your ISP allows, which typically is either plain 1500 bytes (likely in your case, if I am correct to deduce from your VLAN that this is a DSL link in Germany) or occasiobakly 1508 bytes if your ISP supports baby jumbo frames.
But assuming MTU 1500 to your ISP's PPPoE server, packets to/from the rest of the internet look like the path MTU was only 1492.
So at best you set the mtu for the pppoe-wan interface to 1492, or you simply rely on OpenWrt's default MSS clamping on the wan interface, which solves this issue for TCP and UDP should figure this out as part of its own path MTU discovery (which it needs to do anyway). So in alk likelihood OpenWrt defaults should just be fine.

IMHO pppoe-wan, or if you want to include the encrypted traffic into the fairness isolation, you should look at @Lynx's elegant ifb based solution (I think over here. But for starters pick pppoe-wan....

The 34 bytes on top of pppoe-wan already include the 4 byte VLAN tag. Don't worry about Maximum Packet Size in the GUI this is only needed if using tc-stab for overhead accounting, if you use cake this is ignored anyway. However, if you follow @Lynx's aporoach you will need to also account for the wireguard overhead, but let's start with the easy way.

I guess you can configure a default timeout into grub to select one entry unless the user overrides the default choice within X seconds?

1 Like

I put together two simple solutions that facilitate the application of cake despite mixture of encrypted and unencrypted traffic:

The former is simpler and works where there is a single outgoing wan interface but does not support DSCPs.

The latter is more complicated and can probably work with any setup and supports DSCPs - here is a diagram of how it works:

The idea is that you create dual IFBs - one for upload and one for download and mirror the packets as appropriate to both, and apply cake on those.

But these are not plug and play and rather more like templates - you need to work out how they work and tailor for your use case.


Many, many thanks for these great replies! :+1: :+1: :+1:

Only this doesn't work on my machine for whatever weird reason. It's been a while since I used GRUB on my desktop, so I have limited understanding about that, too. Apparently

set default="0"
set timeout="5"

in /boot/grub/grub.cfg should make it so that it automatically boots into whatever is the first option after 5 seconds. Unfortunately this is exactly what the file says by default and I haven't changed it. I also thought it might be, because I had my keyboard connected anyway, but even when having no USB devices connected to the machine (I dd'ed the OpenWrt image onto the internal NVMe drive in the meantime, whereas I booted it from a USB flash drive before) this odd behavior hasn't changed. Oh well, it's kind of bothersome, but not a deal breaker. Thanks again!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.