MTU for PPPoE over VLAN

[Virsacer]

Hi,
I would like to have MTU 1500 for PPPoE over VLAN.
So to accommodate the pppoe header I set the MTU of the VLAN interface to 1508.

This results in the PPPoE status showing MRU 1500 but MTU increased only to 1496.
I tried setting higher values, also on the physical interface and the max-mtu on pppoe1, but MTU does not go higher.

Is there something else I am missing?
Or has my ISP just configured 4 bytes to low?

/interface bridge
add name=bridge1 pvid=10 vlan-filtering=yes
/interface vlan
add interface=bridge1 mtu=1508 name=vlan7 vlan-id=7
add interface=bridge1 name=vlan10 vlan-id=10
/ppp profile
add change-tcp-mss=yes name=profile1 use-compression=yes use-encryption=yes
/interface pppoe-client
add add-default-route=yes allow=pap,chap,mschap2 disabled=no interface=vlan7 name=pppoe1 profile=profile1 user=xxxxxxxxxxxx
/interface bridge port
add bridge=bridge1 interface=sfp-sfpplus1
add bridge=bridge1 interface=sfp-sfpplus2
add bridge=bridge1 interface=sfp-sfpplus3
add bridge=bridge1 interface=sfp-sfpplus4
add bridge=bridge1 interface=sfp-sfpplus5 pvid=10
add bridge=bridge1 interface=sfp-sfpplus6 pvid=10
add bridge=bridge1 interface=sfp-sfpplus7 pvid=10
add bridge=bridge1 interface=sfp-sfpplus8 pvid=10
/interface bridge vlan
add bridge=bridge1 comment=WAN tagged=bridge1,sfp-sfpplus7 vlan-ids=7
add bridge=bridge1 comment=LAN tagged=bridge1,sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 untagged=sfp-sfpplus5,sfp-sfpplus6,sfp-sfpplus7,sfp-sfpplus8 vlan-ids=10

Thanks
Virsacer

[Znevna]

Any particular reason why you didn't create VLAN 7 directly over sfp-sfpplus7 ?
I don't know how the "auto" MTU/MRU works in this scenario.
But you could try setting 1500 on both MTU/MRU manually on the PPPoE client.

[Virsacer]

I thought vlan-filtering is the prefered way.
Also when I set it up, the modem wasnt directly connected to the router.

But moving the vlan to the interface doesnt seem to have an effect.
Nether does setting max-mtu and max-mru to 1500.

[tdw]

The interface MTU setting is irrelevant for PPPoE traffic as Mikrotiks have separate MTU (for layer 3 / IP) and L2MTU (for layer 2 / ethernet).

Setting max-mru and max-mtu is just a request which would point to the ISP having misconfigured something at their end. You could add logging for pppoe,debug,!packet to observe the link negotiation.

If the WAN port is only for internet access the most common setup is to have that port not in a bridge, add an /interface vlan to the port, then a DHCP client (for IPoE) or an /interface pppoe-client (for PPPoE) to the VLAN. Having the WAN port as a bridge member and using VLAN filtering is only required if multiple services are being delivered over the WAN, some of which have to be bridged directly to LAN ports, e.g. IPTV to a box provided by the ISP.

[Znevna]

@tdw

interface MTU setting is irrelevant for PPPoE traffic

YUP

While you are right that the value is irrelevant for the PPPoE traffic itself, it is not irrelevant for auto MRU/MTU negotiation (the client looks at the parent interface before initiating the session to see how high can it go) and it is also not ignored by the client if the value decreases, as seen in the recording above it causes a client reconnect and renegotiation of MTU/MRU.

[horizn]

What you want is to increase the mtu on ether interface tied to your pppoe

[Virsacer]

Just setting max-mtu and max-mru (all interfaces MTU reset to default) and VLAN on physical interface:

The log does not show anything regarding MTU...

2026-05-31T21:18:23.632536+02:00 router1 pppoe,ppp,info pppoe1: initializing...
2026-05-31T21:18:23.632536+02:00 router1 pppoe,ppp,info pppoe1: connecting...
2026-05-31T21:18:23.691337+02:00 router1 pppoe,debug vlan7: received PADO with unknown host-uniq, dropping
2026-05-31T21:18:23.694568+02:00 router1 pppoe,ppp,debug pppoe1: LCP lowerup
2026-05-31T21:18:23.694568+02:00 router1 pppoe,ppp,debug pppoe1: LCP open
2026-05-31T21:18:23.740120+02:00 router1 pppoe,ppp,debug pppoe1: LCP opened
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,info pppoe1: authenticated
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: IPCP lowerup
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: IPCP open
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: IPV6CP lowerup
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: IPV6CP open
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: MPLSCP lowerup
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: MPLSCP open
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: BCP open
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: CCP lowerup
2026-05-31T21:18:24.001599+02:00 router1 pppoe,ppp,debug pppoe1: CCP open
2026-05-31T21:18:24.175598+02:00 router1 pppoe,ppp,debug pppoe1: IPCP opened
2026-05-31T21:18:24.175598+02:00 router1 pppoe,ppp,info pppoe1: connected
2026-05-31T21:18:24.175598+02:00 router1 pppoe,ppp,debug pppoe1: IPV6CP opened

So, ISP might have a misconfiguration?

[Faceplate5158]

Here is my configuration, Vodafone PPPoE over vlan 911 on sfp-sfpplus1:

sfp-sfpplus1 & vlan911 both manually set to MTU 1508, PPPoE client then automatically connects at 1500.

Sounds like if this doesn't work for you there's something not quite right at the ISP end. The standard is RFC 4638: "baby jumbo frames". Maybe there's anything online from your ISP about this?

[horizn]

ISP may not support full 1500 MTU on PPPoE. Either on purpose or by misconfiguration.

[rextended]

@Virsacer

MTU increased only to 1496

1500 - 4 VLAN = 1496

Ask the ISP.

The "MTU" must not be changed anywhere, only on PPPoE for supprot 1500 MTU/MRU, but only if your ISP allow you to do so.

How to force "Actual MTU" on PPPoE client

Let’s not mix apples with oranges. Layer 3 MTU is one thing, Layer 2 (L2MTU) is another. Ethernet MTU refers to how much the IP (and others) data is. VLAN MTU means how much big can be the data that internal ethertype can carry. If you have one ethernet with MTU of 1500, you notice that a VLAN with MTU 1500 still work and is not limited by 1496??? Is because VLAN “use” L2MTU of the ethernet… PPPoE MTU means how big the IP payload can be carried. If PPPoE add 8 bytes, and the PPPoE client …

[Znevna]

@rextended

The "MTU" must not be changed anywhere

Explain this then MTU for PPPoE over VLAN - #5 by Znevna
You are not the first to make this claim anyway.
I did complain to support about the behaviour that MikroTik had until RouterOS 7.2 regarding the PPPoE client always trying to negotiate MTU based on L3 MTU of the parent interface -20 MikroTikish bytes in total (8 PPPoE + 12 ???), for standard 1500 L3 MTU the PPPoE client ended up negotiating 1480 MTU.
RouterOS 7.2 Changelog:
*) pppoe - use default MTU of 1492;
this is obviously valid only if parent interface L3 MTU is standard 1500;

[CGGXANNX]

If the hardware is made by MikroTik, and the interface has a value for the L2MTU field, then there is no need to increase or modify the MTU value of any underlaying interface. They can all keep the default value of 1500. What you did not do in your screencap, was to do recommended thing and set Max MRU and Max MTU to 1500.

If you do not set those values, they will be inferred from the MTU setting, which makes the MTU of the PPPoE interface depended of the MTU of the layer 2 interface below it. If you've explicitly set the Max MRU and Max MTU value, then the MTU value of the ethernet interface is unimportant. You only have to make sure that L2MTU shows a big enough value (at least 1508 if you want the PPPoE interface to have a MTU/MRU of 1500).

BUT: on CHR/x86 installation where RouterOS is unable to show the L2MTU value of the ethernet interface (value is blank), then you'll need to explicitly increase the MTU value of that ethernet interface (probably so that RouterOS can tell the adapter's driver to increase the frame limit). But on MikroTik hardware, with L2MTU value available, you don't need to make any modification to the MTU of the ethernet interfaces.

Another BUT: If your PPPoE client uses the default PPP profile, then unfortunately, the TCP MSS of the IPv4 TCP connection will be clamped based on the MTU of the ethernet interface, even if the PPPoE client interface has no problem letting ICMP or UDP packet will the full size (1500 bytes) through, it will clamp MSS of IPv4 TCP connections to only 1452 if you keep the MTU of the Layer 2 interface at 1500.

To not be affected by that, make a separate PPP profile with Change TCP MSS set to No and use that profile for the PPPoE Client connection:

[Znevna]

So, to summarize: there is no RFC or standard that recommends blindly hardcoding Max MTU/MRU over the documented auto-negotiation process.
Furthermore, your method of doing so while intentionally ignoring the parent interface MTU actually breaks RouterOS's Change TCP MSS behaviour, forcing users to manually set custom PPP profiles just to prevent incorrect TCP MSS that this approach caused in the first place?

[rextended]

I've had a headache dozens of times, for wrong labels (L3MTU / L2MTU)...
but my entire customers network has an L3-MTU of 1500,
with the exception of some non-MikroTik point-to-points which also mean L2MTU by MTU and need to be increased to allow PPPoE+VLAN to pass...

VLAN can not consider (L3)MTU because is valid for any ethertype, not only IP...

[CGGXANNX]

Change TCP MSS = Yes in the default Profile is a hack made for all the PPP protocols that need to reduce the MSS because their MTU is most of the time smaller than the default 1500. It actually increases processing resource usage (same as when you add a FW mangle rule that inspects the TCP SYN packets and modifies the MSS field). Setting it to No when there is no needs for it (because the PPPoE client can use the default MTU of 1500) is the right thing to do and improves performance.

Setting value for Max MRU / Max MTU is according to the standard. If you enable the pppoe logging topic in RouterOS, you'll see that the Max MRU value is used for the ppp-max-payload fields when the router sends out the PADI packets. The Max MTU setting will be combined with what the other side send as their Max MRU, and limits the size of the packets the router send (the limit can be observed when the router send LCP EchoReq messages right after authentication, the payload will be limited by the Max MTU setting minus 8).

If you don't set the two values, then RouterOS uses the MTU of ethernet interface minus 8 for them. You can test by setting the MTU of the ethernet interface to 9000, and keep Max MRU and Max MTU empty. If you enable logging, you'll see the attempt to set ppp-max-payload to 8992. Which will soon be reduced by the value of the other side, because the other side will send a limit much smaller than 8992.

But if you keep the ethernet MTU at 9000, and set Max MRU and Max MTU to 1500 or smaller, you'll see that these setting values are properly used during the negotiation and after the successful authentication.

That is what RFC 4638 dictates: set PPP-Max-Payload during Discovery stage (this depends on Max MRU):

RFC 4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) | RFC Editor

And then send EchoReq with the max size to test that the other side can receive the big packet (this depends on Max MTU):

RFC 4638: Accommodating a Maximum Transit Unit/Maximum Receive Unit (MTU/MRU) Greater Than 1492 in the Point-to-Point Protocol over Ethernet (PPPoE) | RFC Editor

=> Those are the relevant and important setting parameters for PPPoE with RFC 4638 support, NOT the ethernet layer MTU! Setting them explicitly to 1500 is according to the standard.

[Znevna]

@CGGXANNX

NOT the ethernet layer MTU

I did not mention in any of my posts ethernet layer MTU, I don't know why you brought that up. Thought you meant the L2 MTU, I think you were just reffering to the parent interface L3 MTU here which in RouterOS is MTU.

Right, so in case that the ISP supports rfc4638, if bumping the parent interface MTU to 1508 produces the same end results as:

1. setting pppoe client max mtu to 1500;
2. setting pppoe client max mru to 1500;
3. messing with the ppp profiles change tcp mss thingamajig;

Why should I not just bump the interface MTU, again? Since it comes with less headaches?

[CGGXANNX]

It might be the lazy way, but it's the wrong way:

• As other have mentioned above, for MikroTik devices, what important is the L2MTU value. That changing MTU produces the effect is only due to the way RouterOS automatically calculates Max MRU and Max MTU when not set.

• But changing the MTU value of the underlaying interface affects L3 communication on that interface too. Very often you would have access to the management interface of the optical converter / SFP module / ISP bridge modem on that interface (by configuring an IP address and subnet). For my ISP, even IPTV traffic is on that same interface (not a separate VLAN). Now the router will attempt to send oversized 1508-byte IP packets on it when talking to the modem / converter / SFP module management.

• If you have a configuration like mine where all ports are in a bridge and the WAN is just a VLAN on that bridge, then you'll have to raise the MTU of all the ports. That what I did on the early days of my RB5009, and I still have an old screenshot here:

  

  That was from the time where I still believed that the MTU setting of the interface was important for RFC 4638. Now I've known better:

  

• Changing the PPP profile is still recommended if you can use MTU 1500 for PPPoE. Simply because it avoids having to analyze every packet looking for TCP SYN and to write a value in the packet's header (the same value that is already there).

[Virsacer]

Thanks guys!

@Faceplate5158

Sounds like if this doesn't work for you there's something not quite right at the ISP end. The standard is RFC 4638: "baby jumbo frames". Maybe there's anything online from your ISP about this?

Its a smaller regional ISP - not much to find online...
But RFC4638 seems to be supported, since it increased from 1492 to 1496

@rextended

1500 - 4 VLAN = 1496
Ask the ISP.

Yes, it increased by 4 byte and is still missing 4 byte - could be the vlan tag

@CGGXANNX

To not be affected by that, make a separate PPP profile with Change TCP MSS set to No and use that profile for the PPPoE Client connection

I had to set it to yes (at least while not having 1500), or for example fast.com would not be able to measure

@CGGXANNX

If you have a configuration like mine where all ports are in a bridge and the WAN is just a VLAN on that bridge, then you'll have to raise the MTU of all the ports.

Yes thats what I tried first, but the other way makes more sense

[Znevna]

Is it wrong though?
More often than your very often, the ISP-provided equipment is just a dumb bridge.
The user has absolutely nothing to set on it while in that state, which is the standard for essentially all residential fiber clients from the major ISP in this country.
But even IF you needed to access a management IP on that thing, you would be accessing it from your LAN. Your LAN devices have an MTU of 1500. The router is not going to magically pad a 1500-byte IP packet to 1508 bytes just because the outgoing interface supports it. The routed packet leaving the router towards the modem will remain <= 1500 bytes and the modem will process it perfectly fine.
Regarding that last bit * Changing the PPP profile is still recommended if you can use MTU 1500 for PPPoE. Simply because it avoids having to analyze every packet looking for TCP SYN and to write a value in the packet's header (the same value that is already there). I don't know how that setting is implemented to put my money on it, the performance penalty either way is negligible even if RouterOS decides to spawn the internal clamp rule if the interface already allows 1500 bytes.
Everyone is free to pick their poison.

[CGGXANNX]

Do not put !packet in the logging topic filter. You should keep the packet logging in the log, and you'll see what the other side (the PPPoE server) responds.

Normally, your router (as PPPoE client) will send PADI packet with max-ppp-payload set to 1500 (because you set Max MRU to 1500), but that's you announcing what you can RECEIVE. Your MTU, the largest you can SEND depends on your Max MTU, but also depends on what the other side announces as their MRU. If they say they only have an MRU of 1496, then your router will cap its MTU at 1496, while still saying it's capable of receiving 1500-byte packet (its MRU).

Look for what the other side announces in their PADO message (what ppp-max-payload listed in PADO), also what set as <mru> in the LCP ConfAck packets that you receive.

Also pay attention to the LCP EchoReq that your router sends. There can be a situation where the negotiated MRU (MTU for you) is 1500 but when your router attempts to send LCP EchoReq with 1492 payload (1500 packet), that message doesn't arrive. In that case the next attempt might reduce the size and the effective MTU.