PPPoE and MTU > 1488

Upgraded to 6.37 this morning and noticed that even with max-mtu=1500 on the pppoe-client interface that the MTU changes to 1480 after between 3-5 seconds (seen using monitor command on interface).

Thought it was a problem with 6.37 so downgraded back to 6.36.3 but that exhibited the same problem. This has worked in the past so I’m not sure what has changed to break it.

One thing I did notice is that if I set max-mtu to 1488 or lower it doesn’t change MTU after 3-5 seconds, but if set to 1489 it changes.
A packet trace shows that if the max-mtu is set to > 1488 then a large LCP echo request is sent 3 times. The BRAS I’m connected to seems to return a malformed packet and I guess this is what caused the Mikrotik to fallback to a 1480 byte MTU. If max-mtu is set to 1488 bytes or less this large LCP echo request is not sent by the Mikrotik device.

I see on the forums that others have had problems in the past with 1488 byte MTUs but this seems to have been fixed in subsequent versions of ROS.

A Google search turns up instances where people say that the MTU should be setup to 1488 if you are doing PPPoE over DSL to fit completely within a round number of ATM cells. Not sure if this is why the Mikrotik PPPoE client does this or not.

Anyone have any other insight?

The Mtu seems auto-adjusted by the discovery mechanism.
If interfaces or tunnels You use does not allow 1500, You must set MRRU.
Mikrotik say to leave unchanged mtu and mru to defaults
See also http://forum.mikrotik.com/t/eoip-tunnel-mtu-and-pppoe-serverr/87493/1

This large LCP request is RFC4638 compliant. It is sent to validate that your link is indeed capable of
transferring the large (larger than ethernet standard) packet. Make sure your BRAS supports RFC4638
and that your ethernet MTU is large enough along the path between router and BRAS.
(so on your ethernet interface on the MikroTik, on your DSL modem, etc)

The interface MTU on the Mikrotik and DSL modem (Vigor 130) is set to 1508 bytes so the path to the BRAS should be capable of sending > 1492 byte packets.

I see in the PPPoE discovery that the Mikrotik advertises PPP-Max-Payload for RFC 4638 negotiation (05dc == 1500):

Frame 1: 38 bytes on wire (304 bits), 38 bytes captured (304 bits)
Ethernet II, Src: Routerbo_8d:70:a6 (d4:ca:6d:8d:70:a6), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
PPP-over-Ethernet Discovery
    0001 .... = Version: 1
    .... 0001 = Type: 1
    Code: Active Discovery Initiation (PADI) (0x09)
    Session ID: 0x0000
    Payload Length: 18
    PPPoE Tags
        Host-Uniq: 016a0001
        PPP-Max-Payload: 05dc

And the BRAS (BT Alcatel) negotiates a 1500 byte MRU (the Mikrotik ACKs this):

Frame 5: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: Alcatel-_c0:36:b4 (0c:a4:02:c0:36:b4), Dst: Routerbo_8d:70:a6 (d4:ca:6d:8d:70:a6)
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
    Code: Configuration Request (1)
    Identifier: 124 (0x7c)
    Length: 19
    Options: (15 bytes), Maximum Receive Unit, Authentication Protocol, Magic Number
        Maximum Receive Unit: 1500
        Authentication Protocol: Challenge Handshake Authentication Protocol (0xc223)
        Magic Number: 0x09051c66

But the Mikrotik doesn’t do the same (not sure if it needs to) - it only negotiates the magic number:

Frame 6: 32 bytes on wire (256 bits), 32 bytes captured (256 bits)
Ethernet II, Src: Routerbo_8d:70:a6 (d4:ca:6d:8d:70:a6), Dst: Alcatel-_c0:36:b4 (0c:a4:02:c0:36:b4)
PPP-over-Ethernet Session
Point-to-Point Protocol
PPP Link Control Protocol
    Code: Configuration Request (1)
    Identifier: 3 (0x03)
    Length: 10
    Options: (6 bytes), Magic Number
        Magic Number: 0x0fbf18cd

I see in section 5.2 of RFC 4638:

If the MRU is negotiated to a value larger than 1492 octets, the
sending side SHOULD have the option of sending one or more MRU-sized
Echo-Request packets once the session is opened.

Not sure why Mikrotik decided to use 1488 instead of 1492 here.


Matt.

I have a similar setup, MikroTik router, Draytek Vigor 130 VDSL2 modem, but my provider uses a Juniper BRAS.
It works OK here:

/interface pppoe-client print detail
Flags: X - disabled, R - running
0 R ;;; PPPoE-link XS4ALL-internet
name=“pppoe-xs4all-inet” max-mtu=1500 max-mru=1500 mrru=1500
interface=eth1-vdsl user=“x” password=“x” profile=default
keepalive-timeout=60 service-name=“” ac-name=“” add-default-route=yes
default-route-distance=1 dial-on-demand=no use-peer-dns=no
allow=pap,mschap2

Apparently there is still some “bottleneck” for you that clamps the ethernet frame size.
BTW, I have MTU 1598 on the ethernet port of the MikroTik and I do the VLAN tag insertion
on the Draytek modem. (provider requires a VLAN tag on the PPPoE frames)
When you do the VLAN tag insertion on the MikroTik you need more headroom on the ethernet MTU.

The VLAN insertion is done on the Vigor (not on the Mikrotik). I’ve tried with larger MTU (1520 which is the maximum the Vigor supports) with no change to behaviour.

I’m sure you are correct - the path between me and the exchange is probably short 4 bytes (most likely a VLAN tag) but getting BT to do anything about it is unlikely.

Still no closer to finding out why the Mikrotik choses 1488 bytes for the large LCP echo request though.


Matt.

Are you sure that BT support the 1500 byte MTU? You can try with the Vigor making the PPPoE connection
and see if that works at 1500 byte MTU. When you do not want IPv6 that may even be the entire solution.
(set the Vigor to have the MikroTik as DMZ host with “Active True IP”)

Yeah, BT do support 1500 byte MTU. It’s worked in the past - not sure when it stopped - I only noticed when I upgraded to 6.37 but was the same on downgrade. Most likely, BT have changed something in their network.

Today its 27 feb 2025 and still this problem persists with mikrotik what a joke!!!

1500 Byte MTU with PPPoE and RFC4638 works just fine.

The problems described 10 years ago in this thread where probably not even related to ROS itself.

lol… the reason it drops to 1480 is because MikroTik sends a message out at the requested MTU and if it does not receive a response it will lower the MTU as that packet got silently discarded and therefore that MTU is not supported. It doesn’t keep on sending 1 byte at a time to lower it. So often you can manually set it to 1492 to get more, it just reverts down to 1480 if anything larger is not working

1500 works fine, but you need a minimum of 1508 L2MTU (actually 1522 including ethernet) in the entire path between client and server. Many switches use 1518 by default, just enough room for a single VLAN + ethernet, and need to manually be increased. Once that is done hey presto 1500 byte MTU on PPPoE works fine

Please see my post my isp supports RFC 4638 also l2mtu doesnt work on chr/x86 version but vyos/opnsense/ipfire all work on same setup with 1492 mtu except mikrotik why???

http://forum.mikrotik.com/t/pppoe-mtu-always-defaults-to-1480-instead-of-1492/181991/1

No idea why it does not work for you. It works perfectly fine for me.
In the meantime I have changed from a Vigor modem to a ZyXEL modem, do the VLAN tagging in the MikroTik, and it still works fine.
Must be an error on your config or in the network.

RFC 4638 and PPPoE with MTU 1500 work on all of my MikroTik devices. But I’ve seen multiple people (MikroTik forum in my country) using x86 having the same issue as himurae, where the MTU drops to 1480 because large LCP EchoReq packets cannot be sent. But threre are also people with x86 RouterOS where PPPoE MTU 1500 works perfectly. It may be compatibility issues with the NIC drivers shipped with RouterOS.

It can also be a limitation of the used network card. I remember that my previous PC motherboard, which had 2 network devices on-motherboard, allowed >1500 byte MTU on one port but not on the other.
This was with native Linux installed on the PC. I used one port for my LAN (including VLAN tags, it would accept tagged VLAN with 1500 byte MTU) and the other port connected to a port on the MikroTik configured as monitor port of my internet link. I could not trace the VLAN-tagged 1500 byte PPPoE traffic (minimal required MTU 1512) on that port, but swapping the purpose of the ports it worked fine.
Some network cards simply do not allow >1500 byte MTU to be set, or not >1504. Hardware limitation.
But I am not aware of any MikroTik-branded hardware with this problem, they normally allow up to ~1600 at least.