Page 1 of 1
Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Mon Jun 27, 2011 3:06 pm
by srofin
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.
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Mon Jun 27, 2011 3:53 pm
by mrz
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Mon Jun 27, 2011 5:10 pm
by srofin
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.
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Fri Jul 06, 2012 3:56 am
by traverss
HI Guys,
Just seeing if anyone knows if they have support for this yet. Its affecting a heap of our connections at present.
Thanks
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Tue Aug 07, 2012 4:18 pm
by dominicbatty
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.
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Tue Aug 07, 2012 4:22 pm
by dominicbatty
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.
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Tue Aug 07, 2012 4:24 pm
by dominicbatty
woof .... RFC4638 ...
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Fri Jun 28, 2013 3:27 am
by thermionic
Is there any likelihood that RFC 4638 will be supported ?
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Fri Jan 17, 2014 1:03 am
by traverss
Any updates. This is causing major issues for us (basically we cant use mikrotiks \ routerboards...)
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Fri Jan 17, 2014 12:27 pm
by onnoossendrijver
I would really like RFC4638 support too!
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Wed Dec 17, 2014 11:15 am
by keithy
v7 maybe?
Please!
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payloa
Posted: Wed Dec 17, 2014 12:13 pm
by MrYan
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).
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Thu Feb 12, 2015 1:51 pm
by nickshore
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
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Wed May 20, 2015 2:03 pm
by lenart
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.
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Thu Jun 18, 2015 12:12 pm
by pe1chl
+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
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Thu Jun 18, 2015 12:31 pm
by tomaskir
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
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Thu Jun 18, 2015 9:09 pm
by pe1chl
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?
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Fri Jun 19, 2015 12:17 pm
by tomaskir
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%
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Fri Jun 19, 2015 7:41 pm
by lenart
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.
Re: Support for PPPoE MTU > 1492 (via RFC4638 PPP-Max-Payload)
Posted: Thu Nov 05, 2020 10:20 pm
by lukastribus
For the record: RFC4638 was implemented back in 2015 in 6.33.