Hi!

When I change the PPPoE MTU on the server side to let's say 1492, it only changes the MRU to 1492 on the server side and the MTU keeps set to 1480. In this case, a SXT Lite 5 is the CPE and even though the pppoe client is se to default in the CPE it only changes the MRU. We now have 155 SXTs deployed with the MTU at default, 1480, but now we want to set everything to 1492 and don't want to have the work to set it manually on each CPE. Is there a way I can change it only on the PPPoE server side and the CPE responds to it?

This is what it happens when I change the MTU on the server side only:

Anyone??

I still can't make my SXT clients follow the server MTU automatically. All my Ubiquiti ONUs automatically change the MRU and MTU following the PPPOE server settings. Why can't routerOS do the same on the routerboards clients, SXTs...?

Hey. I believe not. It's just default PPP mtu.
https://wiki.mikrotik.com/wiki/Manual%3 ... operties_2

MT PPPoE server only sends out MRU as option during discover / session stage

Anumrak,

If I set the pppoe server side to 1492 (MRU and MTU) and set the clients to 1492 as well, there is no packet fragmentation.

CZfan,

Then why the Ubiquiti ONUs follow the Mikrotik pppoe server side for MTU and MRU without having to set anything on them? I assume the default mtu of the ubquiti onu cpes is 1492, right? or more likely, they set this automatically because you can't change it anywhere on Ubiquiti ONUs. If on the server side I set it to 1480 or any other number, the ONUs follows suit for both MTU and MRU and that does not happen with an SXT being a pppoe client.

Anumrak,

If I set the pppoe server side to 1492 (MRU and MTU) and set the clients to 1492 as well, there is no packet fragmentation.

CZfan,

Then why the Ubiquiti ONUs follow the Mikrotik pppoe server side for MTU and MRU without having to set anything on them? I assume the default mtu of the ubquiti onu cpes is 1492, right? or more likely, they set this automatically because you can't change it anywhere on Ubiquiti ONUs. If on the server side I set it to 1480 or any other number, the ONUs follows suit for both MTU and MRU and that does not happen with an SXT being a pppoe client.

Yeah, but if next link after your router will be 1480 or 1440, there will be fragmentation. Anyway, 1480 MTU is a good way to encapsulate your frames into switched network with QinQ and/or MPLS as many ISP do. For example PPP mtu is 1480, then you will need only 1524 mtu link for QinQ with VPLS. But with PPP mtu 1492 you will need 1536.

It is a bit unfortunate that the default PPPoE MTU/MRU in RouterOS is 1480 because in practice PPPoE is used without any options and the max MTU/MRU is 1492 on a 1500-byte MTU link.
It is common practice for other routers to negotiate 1492 in this case.

Of course in PPPoE there can be extra options that would require a longer header, and 1480 is the worst case MTU/MRU that would still work over 1500-byte link.
However, it would have been better if the admins in those special situations would set a lower MTU on the servers rather than the users would have to set it everywhere on the client routers.

But, it is how it is and there is nothing that can be done about it.
You should think about some scripting to change it everywhere, when you want to do that.

Hi!

Guys, I understand all your points, but I think no one got my point! I as a network administrator know what my network is capable of or at least I should know that, right? I know what all my equipment can handle and I I know they can handle 1492 for the MTU and MRU, why should I set it manually in every piece of equipment at the client side?? Why not program routerOS pppoe client to respond to what is set on the pppoe server side?? Is that so difficult to do? Why all my Ubiquiti ONUs do that and no SXT unit can do this??? If I set 1492 MTU / 1492 MRU on my PPPOE Mikrotik Server, all UBNT ONUs respond to that beautifully! They automatically set the PPPOE client to 1492 MTU / 1492 MRU! Why can't my SXT clients do that as well?? Why don't implement it in RouterOS? Is it impossible to do? Clients should respond automatically to what settings are made on the server side, not the opposite!

The MTU negotiation is not blindly following the server side, it is taking the lowest value of what the server proposes and what the client (thinks it can) accept.
So when the client has MTU 1480 and the server has MTU 1492, the value 1480 will be chosen.

Now, as I already wrote, what is unfortunate is that the client in MikroTik equipment by default has an MTU of 1480. When you set that to 1492 (or to 1500, for that matter), it will work OK.
MikroTik read the spec too closely and decided that because the PPPoE header can be 20 bytes at worst, 1480 is the required MTU. But when no optional tags are used, 1492 works fine. And as far as I know, RouterOS does not support any optional tags in the data phase.

So, you could make a feature request saying that the default MTU/MRU for PPPoE should be changed to 1492 in RouterOS. But MikroTik proably fear widespread unclear problems when that would now suddenly be changed after it has been at 1480 for so long. So your practical solution is to set it yourself when configuring a client, or to live with 1480.

The fact is, my Ubiquiti ONUs internal pppoe client set its MTU automatically to what is set on the PPPOE server side both for MTU and MRU and this doesn't happen with the Mikrotik RouterOS pppoe client! I myself think the client should obey what is set on the server side, simple as that! Or there should be options to set the pppoe client to "auto" (to get whichever value definied on the server side) or use fixed values.

I have already explained the situation above. Protocol implementations should do what is written in the standard (RFC/STD), not what is more convenient in a particular situation.
(at least not without amendment of the standard)
Note that to support 1500 byte MTU a specific standard was written (which RouterOS conforms to): RFC4638.
In your way of arguing, that standard is not required because the server can just say "max MTU/MRU is 1500". But no, the PPPoE RFC says that MTU/MRU must not be more than 1492.
So, an amendment was written to override that (and do some other checks to protect those that do not fully understand the matter).
Similarly, an amendment would be required to force the MTU/MRU from the server side, as the standard is to use the lowest value specified by server and client. Which unfortunately is 1480 in RouterOS.

So, you are saying my Ubiquiti ONUs is not respecting an RFC? Because if my pppoe server is set to 1492/1492 (MTU and MRU) all my ONUs automatically sets everything to 1492, MTU and MRU withou the need to set it manually in each CPE! The UBNT OLT L2 MTU is set to 1518 bytes which corresponds to the maximum pppoe payload 1492 plus the ppp header, 8 bytes, plus ethernet header, 14 bytes plus optional vlan header, 4 bytes, and since most if not all current router OS box can cope with an L2 MTU bigger then 1518, all is fine with the 1492 setting at the server side as well at the client side.

Not necessarily, it may just as well be that the Ubiquiti has client MTU/MRU values of 1492. It is not "following the server side", it still gets the min of server and client and it works out OK in this case.
As I explained before, in RouterOS the client default is 1480 and the server cannot override this without violating the standard.
The proper way to change it is to change the value 1480 in the client to 1492. Which has to be done by config change.