Different MRU values on either side of pppoe connection

RouterOS General
1

I have a client router initiating a pppoe session to my core router, I have set max mtu and max mru on both ends like this:

Core Router:

/interface l2tp-server server
set allow-fast-path=yes authentication=chap default-profile=PPP enabled=yes keepalive-timeout=60 max-mru=1462 max-mtu=1462

Client CPE Router:

[admin@client20-CPE-Router] > /interface pppoe-client print 
Flags: X - disabled, I - invalid, R - running 
 0  R ;;; PPPOE-OUT
      name="PPPOE-OUT" max-mtu=1462 max-mru=1462 mrru=disabled interface=ether1 user="client20@fibernet" password="hashed" profile=pppoe keepalive-timeout=10 service-name="" ac-name="" add-default-route=yes default-route-distance=1 
      dial-on-demand=no use-peer-dns=no allow=pap,chap,mschap1,mschap2

I am fixing MTU like this:

/ip firewall mangle print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 0    ;;; Fix PATH MTU
      chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface=ether1 log=no log-prefix=""

On the client side, it shows MRU as 1462, but on the Core router (the other end of the same connection) it shows MRU as 1492

Core router:

[admin@CCR-CoreClientAccessRouter] >
/interface l2tp-server print detail 
116  DR name="<l2tp-client20@fibernet>" user="client20@fibernet" mtu=1462 [flash=]mru=1492[/flash] client-address="191.11.22.33" uptime=1h11m35s encoding=""

On client router it shows fine like:

      name="PPPOE-OUT" max-mtu=1462 max-mru=1462 mrru=disabled interface=ether1 user="client20@fibernet" password="hashed" profile=pppoe keepalive-timeout=10 service-name="" ac-name="" add-default-route=yes default-route-distance=1

Please see diagram below:

pppoe mru issue.png
The question is: How can I force MRU value to be 1462 always, on both ends of the connection?

2

The setup is very unusual. If the client is a PPPoE one whilst the server is an L2TP one, and the fibre provider has no knowledge of usernames and passwords, it means they forward the PPP traffic between the PPPoE session terminated at their RAS and the L2TP session they open as clients towards your L2TP server. Since this is some proprietary implementation, anything may happen during this process, and some information may be lost. On the other hand, since the MTU at client side is 1462, you should never receive a larger payload packet than that from the client, even though the server shows a MRU of 1492.

Plus it may as well be a RouterOS bug. I’d have to see a sniff of the actual LCP exchange.

Other than that, the mangle rule you use to “fix MTU” doesn’t actually fix MTU but adjusts TCP MSS to be in accord with the available MTU.

3

I have in one of my places a provider that uses MikroTik gear, auto mtu/mru for PPPoE never worked right on that one.
I thought it’s something on my end, but I’ve tried replicating the setup, (configuring a pppoe server on another Tik) but I never got the two devices to auto negotiate the proper mtu/mru.
For example, with that MikroTik gear ISP (me as a client) if I increase the ethernet interface MTU with 12 bytes over the 8 required by RFC4638, so having Ethernet MTU set to 1520 for all of it to auto magically work (yes, MikroTik requires 12 magic padding bytes), MRU on my end negotiated to 1500, while MTU was stuck on 1480 (hardcoded on the ISPs end) but MRU of 1500 on my end is broken, as in, it doesn’t work, it’s also limited to 1480 (tested) => somehow the auto negotiation is broken.
On other providers the MTU/MRU negotiation runs ok, as in even with Ethernet MTU set to 1520, the MikroTik client auto sets MTU and MRU to 1492, which the ISP supports (when rfc4638 is not enabled).
So this must be some sort of bug on MikroTik PPPoE server, or some config I’ve missed (and that ISP).
I’ve tried reporting the 12 bytes padding issue, no dice, they don’t care. “set the proper value manually”.
I doubt they will take a look on this issue too.
LE: edited 1420 → 1520, donno how I wrote it badly, TWICE.