Starting with linux PPP deamon version 2.4.6, RFC 4638 is supported.
http://tools.ietf.org/html/rfc4638
This ppp option do allow MTU larger than 1492 over PPPoE links.
This is supported for example at British Telecom.
It would be nice if this could be supported on Router OS so that we don’t have anymore to use MLPPP over single link tunnels (and the associated overhead) for desired MTU larger than 1492.
Have you tried max-mtu=1500 and max-mru=1500?
PPPoE links are limited to 1492. Some CPE can even refuse to connect if the provider permit a 1500 PPPoE MTU. So most providers are following the standard and force the PPPoE MTU to 1492.
In France, all big providers have an ADSL transport network MTU of 1500, so there is absolutly no possibility to go behind 1492 for the PPPoE MTU , and MLPPP over single link is not supported neither.
This is a terrible situation compared to England, where British Telecom propose VDSL2 links supporting RFC 4638 with 1500 PPPoE MTU.
If RFC 4638 is supported by the provider and the CPE, then an option is negociated during the PPP handshaking to determine the extended MTU.
This PPPoE over ATM is still old technology compared to newer IPoA or EFM links, but RFC 4638 PPPoE links with 1500 MTU are still better than the terrible 1492 value we have since many years on ADSL PPPoE links…
In France we can use PPPoA with 1500 MTU, but this is possible only if you terminate the PPP session on the modem. If you want to terminate it on the router this does not work except if you could connect the modem and the router through an ATM link. Some older modems did had an ATM25 interface, but Mikrotik routers anyway do not support ATM25 interfaces and this is too much complex and expensive things for most peoples.
Another possibility is to have a modem with PPPoA to PPPoE internal bridging, but this is not common.
RFC 4638 is a simple and low cost alternative, waiting for EFM and fiber technologies to slowly replace ADSL.
Actually it is possible to be compatible with RFC 4638 using a linux or OpenWRT box. I hope that Mikrotik will follow. This will encourage providers to support this and will be a good option even for private use.
This is printouts from my pppoe-client and server.
Client:
> int pppoe-client monitor pppoe-rt-bfs-2
status: connected
uptime: 16m16s
idle-time: 55s
active-links: 1
encoding: MPPE128 stateless
service-name: rt-bfs-2
ac-name: rt-bfs-2
ac-mac: 00:0C:42:A4:7A:51
mtu: 1500
mru: 1500
local-address: 172.32.1.2
remote-address: 172.32.1.1
Server:
> int pppoe-server monitor pppoe-rt-bfs-3
status: connected
uptime: 21m1s
idle-time: 0s
user: rt-bfs-3
caller-id: 00:0C:42:33:35:1F
encoding: MPPE128 stateless
service: rt-bfs-2
interface: br-int
mtu: 1500
mru: 1500
And some tests:
> ping 172.32.1.1 size=1500 do-not-fragment
HOST SIZE TTL TIME STATUS
172.32.1.1 1500 64 2ms
172.32.1.1 1500 64 2ms
172.32.1.1 1500 64 2ms
sent=3 received=3 packet-loss=0% min-rtt=2ms avg-rtt=2ms max-rtt=2ms
> ping 172.32.1.1 size=1502 do-not-fragment
HOST SIZE TTL TIME STATUS
172.32.1.2 576 64 1ms fragmentation needed and DF set
172.32.1.2 576 64 1ms fragmentation needed and DF set
172.32.1.2 576 64 1ms fragmentation needed and DF set
sent=3 received=0 packet-loss=100%
Yes this is working because your private L2 transport support a 1508 MTU, but it is out of standard. PPPoE links should be limited to 1492 MTU to follow the standard and avoid compatibility problems.
According to RFC 2516 (PPP over Ethernet) :
The Maximum-Receive-Unit (MRU) option MUST NOT be negotiated to a
larger size than 1492. Since Ethernet has a maximum payload size of
1500 octets, the PPPoE header is 6 octets and the PPP Protocol ID is
2 octets, the PPP MTU MUST NOT be greater than 1492.
As a provider if you do not limit the PPPoE MTU to 1942, then you will be assured to have a small pourcentage of clients refusing PPP connections because of out of standard feature.
To go higher the PPP-Max-Payload Tag must be used in the PADI and PADR packets. Then full compatibility is kept.
From RFC 4638 (Accommodating an MTU/MRU greater than 1492 in PPPoE) :
If a PPPoE client wants to use a higher MTU/MRU than 1492 octets,
then it MUST include an optional PPP-Max-Payload Tag in the PADI
and PADR packets.
If the PPPoE server can support a higher MTU/MRU than 1492 octets, it
MUST respond with an echo of the clients tag in the PADO and PADS
packets when the PPP-Max-Payload tag is received from the client.Tag-name: PPP-Max-Payload
Tag-value: 0x0120
Tag-length: 2 octets
Tag-value: binary encoded value (max PPP payload in octets)Tag-description:
This TAG indicates that the client and server are capable of
supporting a given maximum PPP payload greater than 1492 octets for
both the sending and receiving directions.
Note that this value represents the PPP payload, so it is directly
comparable with the value used in the PPP MRU negotiation.
I assume that you done some sniffing of the negotiation and seen that the PPP-Max-Payload aren’t in PADI and PADR.
Then ok, I agree that MT should include RFC 4638 in ROS code.
Add a feature request at:
http://wiki.mikrotik.com/wiki/MikroTik_RouterOS/Feature_Requests
I will not add anything to this difficult to edit list. It is now mostly unefficient because of its lenght and unorganized style. Something more modern is needed to manage feature requests.
I prefer to discuss here those requests to that each one can participate and Mikrotik can have a better understanding of the involved modifications and benefits.
I have gone through this thread and only read keeping the MTU standard at 1492 bytes.
Whats wrong with setting it to 1500 on a network that you fully control from CPE to
the transport network?
Unfortunately mikrotik is very lazy to add core features to PPPoE maybe it is not written by themself . http://forum.mikrotik.com/t/feature-request-pppoe-option-82/38611/1