Hello,
Are there any plans to support RFC4638 to allow a PPPoE MTU of 1500?
Or is it already implemented and I’m misconfiguring? The highest MTU I’ve been able to get using 5.5 is 1492.
Thanks.
you can get 1500 by adjusting mrru values
http://wiki.mikrotik.com/wiki/Manual:MLPPP_over_single_and_multiple_links#MLPPP_over_single_link
The other end doesn’t support it.
The case I have in mind is where there is a [AV]DSL modem in bridge mode and the upstream support RFC4638. This is the case for BT in the UK’s VDSL offering, for instance, and is becoming more common for other providers too I understand.
I take from you answer that at RFC 4638 isn’t support at present. Are there any plans to?
Thanks.
HI Guys,
Just seeing if anyone knows if they have support for this yet. Its affecting a heap of our connections at present.
Thanks
There appear to be lots of replies on the net simply stating that you just have to up the ethernet interface to 1508 and the PPPoE interface to 1500 and this should solve the problem.
However, the BT supplied VDSL modem requires the inclusion of the RFC4638 PPP-Max-Payload Tag in the PADI and PADR packets otherwise it just drops straight back to a 1492 MTU.
I would love to be proved wrong but so far this does appear to be the case with my Router OS installation and BT FTTC lines.
Regards, Dominic.
Also, from the Mikrotik support option above, I think the MRRU option is only related to MLPPP link isn’t it?
This is going to become a massive issue shortly as the BT FTTC roll out goes through in the UK and every man and his dog with Router OS is going to start asking about RFC4638.
woof … RFC4638 … 
Is there any likelihood that RFC 4638 will be supported ?
Any updates. This is causing major issues for us (basically we cant use mikrotiks \ routerboards…)
I would really like RFC4638 support too!
v7 maybe?
Please!
In the UK, if your provider uses BT Wholesale you don’t need RFC4638 (although it would be better if it were supported). You can negotiate an asymmetric MTU where its 1500 bytes into your router (from the Internet) and 1492 bytes out. This means that sites which filter ICMP Fragmentation Needed messages (and have DF set) will work as the inbound MTU is 1500 bytes (so no fragmentation is required). In the other direction, unless you are filtering ICMP messages back to your client machines, they will adjust their pMTU accordingly (to 1492) where required.
This is better than just using TCP MSS clamping as it also works for UDP (and other non-TCP protocols).
Any news on including RFC 4683 support ?
This is already available in the linux pppoe code, so it shouldn’t be difficult to add ?
Nick
Any news on support for RFC 4638 in the PPPoE client? I realize that it’s an informal standard but it’s finding significant adoption with broadband providers. I would be very happy to see this feature included in RouterOS.
+1
Now the Draytek 130 modem finally supports it, I have just installed a MikroTik RB2011 that terminates the PPPoE
connection only to find that the software does not support RFC4638 yet…
So still stuck at MTU 1492 
PPPoE client supports 1500 MTU in v6.x
Support for MTU >1500 is not there, but 1500 is supported.
/interface pppoe-client add interface=ether1 max-mtu=1500 max-mru=1500
Ok but that is not the same thing!
I see that I can get MTU 1500 negotiated with the peer, but then it still fails to send 1500 byte packets.
I think it will need the special options defined in RFC4638 for that.
Are those present in the PPPoE client?
You have something configured wrong then. 1500 works without a problem.
Client config:
/ppp profile
add change-tcp-mss=no name=pppoe use-compression=no use-encryption=no use-ipv6=no use-mpls=no \
use-vj-compression=no
/interface pppoe-client
add disabled=no interface=ether1 keepalive-timeout=10 max-mru=1500 max-mtu=1500 name=pppoe-out1 password=\
123456 profile=pppoe user=pppoe-test
PPPoE AC config:
/ppp profile
add change-tcp-mss=no local-address=10.0.0.1 name=pppoe remote-address=10.0.0.2 use-compression=no \
use-encryption=no use-ipv6=no use-mpls=no use-vj-compression=no
/interface pppoe-server server
add default-profile=pppoe disabled=no interface=ether1 max-mru=1500 max-mtu=1500
/ppp secret
add name=pppoe-test password=123456 profile=pppoe
Ping from client to AC:
[admin@MikroTik] > ping 10.0.0.1 do-not-fragment size=1500
SEQ HOST SIZE TTL TIME STATUS
0 10.0.0.1 1500 64 2ms
1 10.0.0.1 1500 64 3ms
2 10.0.0.1 1500 64 2ms
sent=3 received=3 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=3ms
[admin@MikroTik] > ping 10.0.0.1 do-not-fragment size=1501
SEQ HOST SIZE TTL TIME STATUS
0 packet too large and cannot be fragmented
0 10.0.0.2 576 64 1ms fragmentation needed and DF set
1 packet too large and cannot be fragmented
1 10.0.0.2 576 64 9ms fragmentation needed and DF set
sent=2 received=0 packet-loss=100%
I’m pretty sure that people who are interested in an implementation of RFC 4638 are fully aware that you can set the MTU to 1500 but honestly, that is not what we are asking for.
RFC 4638 requires an additional attribute in two packets (the PADI and PADR) sent by the client to enable both sides to settle on an MTU of 1500. At the moment, RouterOS is not adding that attribute to the appropriate packets when the MTU is set to 1500. As such, they do not adhere to RFC 4638 and anyone who does not control both sides of the PPPoE connection is unable to get their MTU to 1500.
For the record: RFC4638 was implemented back in 2015 in 6.33.