Given the previous posts in the dedicated topic about PPPoE, I think there are other issues with RouterOS 7.20.
Anyway, regarding the MTU, my clients that work via VLAN & PPPoE all have an MTU of 1500.
Simply ensure that the L2MTU is at least 1512 on the devices used; everything else is automatic.
Virtually everything is set as it is by default, except for the MTU and MRU in the PPPoE server/client, which are set to 1500.
(and keepalive-timeout=10)... @CGGXANNX
As I've replied in the 7.20 thread, try to set keepalive-timeout=10 (the default value) on your PPPoE client instance. Starting from 7.20, disabling keepalive-timeout will also disable sending the LCP echo request messages that try to probe the possible MTU.
If you want to have MTU = 1500 on PPPoE client instances, and if your ISP support RFC4638 (they seem to do), do as @rextended wrote and keep the MTU of all the underlying ethernet (including SFP) and VLAN interfaces at the default 1500 value. There is no need to increase them to 1508. Only the L2MTU must be at least 1512 because you'll also use VLAN, but for most of MikroTik devices the default L2MTU value is already above that. What you need is to set max-mru=1500 and max-mtu=1500 on the pppoe-out1 settings.
However currently doing that is still not enough. The PPPoE client connection will get Actual MTU = 1500, and you'll be able to send unfragmented IP packet with the full 1500 size. BUT with the default PPP profile, RouterOS will also perform the automatic adjustment of MSS for IPv4 TCP connection going through the PPPoE connection. Unfortunately, this MSS adjustment just look at the MTU of the VLAN interface, see the value set to 1500, and will adjust the MSS of the IPv4 TCP connections as though the PPPoE MTU was only 1492. Instead of MSS = 1460 (matching MTU 1500), the MSS will unnecessarily be adjusted to 1452! You lose the advantage of MTU 1500.
To workaround this, make a copy of the default PPP Profile. In this copy disable Change TCP MSS:
Out of curiousity I just ran the test on the current default profile and it registers an MSS of 1460. Does that mean that the behaviour is different from what you described or am I misreading the results?
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2025.10.02 15:14
IP address: 45.137.xx.xxx
Client OS/browser: Mac OS (Firefox 143.0)
TCP options string: 020405b4010303060101080a07af74d00000000004020000
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)
It will show MSS 1460 with the default profile if you keep the MTU of the underlying interfaces at 1508. Here are screenshots from the tests I just made on the spare RB750Gr3:
With default PPP profile and MTU of ether1 set to 1500:
MSS is now not changed and has the right expected value.
Don't forget that while doing the tests, you should either close/restart the web browser, or go to the IP -> Firewall -> Connections table and clear the connections before reloading the page (for the case where the old TCP connections from the previous test is still kept opened and is reused by the browser).
The tests show that when RouterOS adjusts the TCP MSS values of the PPPoE connections, it ignores the MTU value of the PPPoE client interface, and calculates the value from the MTU of the ethernet interface .
It's in the text below the MSS value, but if you scroll down a bit on the speedguide.net result page, you'll see that it's due to Timestamps (RFC1323) = ON which adds 12 bytes to the TCP header of each packet.
The Timestamps option itself is only 10 bytes long, but the options part of the TCP header must be padded to be a multiple of 4 bytes. That's why it takes 12 bytes if it's the only option used. You can read about the TCP header options here:
For the tests with the screenshots above, I was using Windows. Windows by default does not enable the Timestamps option, and normal packets with data payload have no additional options, so the TCP header only takes 20 bytes, plus 20 bytes for the IPv4 header and there are 1460 bytes left for the payload (hence it can use all the amount specified by the MSS value).
You can use Set-NetTCPSetting (docs), or you can look for Tcp1323Optson this page to find the registry key that can be used to enabled TCP Timestamps on Windows.
Most Linux distros normally enable TCP Timestamps by default. You can check with (and turn off if you want):
sysctl net.ipv4.tcp_timestamps
My Android devices also have Timestamps enabled by default. So, tests on those devices show the same as your result.
I don't have Apple devices, but apparently the TCP Timestamps option is enabled by default on iOS and macOS and on newer versions that cannot be turned off.
Couple posts ago I had a “discussion” with @rextended about L2/L3 for PPPoE and the fact that I was able to obtain 1500 PPPoE MTU only by increasing L3 MTU of ethernet and VLAN to 1508.
Now I managed to connect remotely to a network and restored interfaces MTU to 1500 + PPPoE profile with TCP MSS = Off, now PPPoE MTU remains at 1500!
I'll do more tests, in the meantime great discover and thanks for the tip!
Now, it's a buggy MikroTik implementation or an hack that can cause other issues? Let's see…
The MTU setting on the ethernet / VLAN / bridge interfaces are only layer 3 settings and the limit that PPPoE can transfer doesn't depend on that setting, only the L2MTU value is important. The current L2MTU value of the interface that is the parent of the PPPoE client interface must be at least 1508 if you want the PPPoE interface to have a MTU value of 1500.
As an example from the screenshot above, the RB5009 has the default L2MTU value of the ethernet interfaces set to 1514 (the sfp-sfpplus1 interface). And in this case sfp-sfpplus1 is even part of the main bridge interface, that has all member ports with Actual MTU = 1500 and L2MTU = 1514. The bridge uses the minimum values of its ports as MTU and L2MTU, thus the L2MTU of the bridge is also 1514. Adding a VLAN interface above the bridge reduces the L2MTU to 1510. Fortunately, this is still ≥ 1508, so the PPPoE client interface that has vlan1000 as parent can still easily have Actual MTU = 1500.
The problem is that RouterOS with the default PPP profile tries to be clever and wrongly clamps the MSS of TCP connections. But even if we didn't create the modified PPP profile and still use the default one, as long as the PPPoE client interface still displays Actual MTU = 1500, we'll have no problem sending 1500-byte IP packets through it. You can do tests and send ping or UDP full-size packets with the DF flag turned on, and they all go through without issues. The MTU is really 1500, but the speedguide.net tool derives the MTU value that it displays from the MSS value in the SYN packet and shows 1492 if you let RouterOS clamps the MSS as a result.
As for any potential problems caused by setting parent interface MTU = 1500, PPPoE client Max MRU / Max MTU = 1500, and using the PPP profile that turns off MSS clamping: This is the setup that I've been using at multiple locations with different ISPs for several years, and it works fine, with both IPv4 and IPv6. The change-tcp-mss setting in the PPP profile only acts on IPv4 connections anyway. And we know that IPv6 is much more sensitive to MTU misconfigurations, because the router is not allowed to automatically fragment oversized IPv6 packets.
Reactiving this thread as I’m still having problems with v7.20.2 so perhaps the problem lies elsewhere. There’s no PPPoE server visible with the scan so I’m looking at the lower layers. The SFP (Leox) link is up and so is the VLAN. I created and shared a supout and shared with support, anything else I can do to debug this?
Update: The problem was auto negotiation on the SFP. This is confirmed not to work reliably on Hex S (2025) models, “fix” in this thread.
.