Hi, I have a doubt about L2MTU.
In a bridged network like the following graph in which the RB1 is a PPPoE server with MTU and MRU set at 1500 and RB that act only as switch and RB3 that is a PPPoE client I would know if the correct value for MTU is 1500 on all interfaces of the devices and L2MTU have to be set to 1508. And if it's all ok, have the flag Change TCP MSS on PPPoE server to be set to NO?
Finally, what is the difference between L2MTU and Max L2MTU?


| RB1 | <-----> | RB2 | <-----> | RB3 |

Bump

No, MTU would have to be 1508 across the board, and L2MTU would also have to be at minimum 1508 as well (unless you wanted to also stack VLANs on top of that).

max-l2mtu is just the maximum value that you can set L2MTU to on a given interface. You can change L2MTU, but not max-l2mtu. max-l2mtu is just for informational purposes.

See: http://wiki.mikrotik.com/wiki/Manual:Ma ... uterBoards

Alternatively, you can use MRRU to achieve PPP tunnels with 1500-byte MTU. Leave MTU at 1500 on the ethernet interfaces, set mtu and mru to 1492 on the PPP server, and set mrru to 1500. The PPP packets will be fragmented, but not by using IP fragmentation, so the IP stacks will not be aware that any fragmentation is going on.

-- Nathan

No, MTU would have to be 1508 across the board, and L2MTU would also have to be at minimum 1508 as well (unless you wanted to also stack VLANs on top of that).

max-l2mtu is just the maximum value that you can set L2MTU to on a given interface. You can change L2MTU, but not max-l2mtu. max-l2mtu is just for informational purposes.

See: http://wiki.mikrotik.com/wiki/Manual:Ma ... uterBoards

Alternatively, you can use MRRU to achieve PPP tunnels with 1500-byte MTU. Leave MTU at 1500 on the ethernet interfaces, set mtu and mru to 1492 on the PPP server, and set mrru to 1500. The PPP packets will be fragmented, but not by using IP fragmentation, so the IP stacks will not be aware that any fragmentation is going on.

-- Nathan

Thanks for the reply Nathan, I wouldn't use mrru, but I don't know why mtu should be at 1508. The PPPoE 8 byte header is not a L2 header? So why do I have to increase mtu?

Thanks for the reply Nathan, I wouldn't use mrru, but I don't know why mtu should be at 1508.

Because PPPoE uses an 8-byte header, and so if you want 1500 MTU inside the PPP tunnel, then you need to budget for those 8 bytes.

The PPPoE 8 byte header is not a L2 header?

No, it is more like L2.5. Switch chips know nothing about "PPPoE" and don't track anything related to PPPoE sessions.

So why do I have to increase mtu?

I just explained that. The 8-byte PPPoE header goes INSIDE the ethernet frame, and is counted as part of the ethernet payload. It is not given "special treatment" like 802.1Q is.

In any case, why don't you test it and see for yourself? Don't take my word for it. If you try to do a 1500-byte PPPoE tunnel over an ethernet interface with a 1500-byte MTU, regardless of L2MTU, and you try to send 1500-byte-sized IP packets through the PPPoE tunnel with the do-not-fragment bit set, you will find that they get dropped. Try it and see.

-- Nathan

Thanks.
Last question, all the other further header like mpls, vpls etc. should cause an increment of mtu as well as l2mtu?

The documentation that I linked to earlier answers this question; please read it.

http://wiki.mikrotik.com/wiki/Manual:Ma ... uterBoards

It actually looks like for MPLS, RouterOS only pays attention to L2MTU, so no, you do not need to raise MTU. MPLS is also treated as a "special case". I believe that the concept of L2MTU in RouterOS was introduced around the same time that MPLS was added, so this makes sense.

-- Nathan

Thanks. I will read the entire document soon

I set up the devices.
Please can you check if the interface are correctly configured?
I also Unchecked "Change TCP MSS", is it correct?
And last, is there a method to see if fragmentation appen in the way and not only in the test router in which I ping google.it size=1500 do-not-fragment ?

This is the PPPoE Server


This is the AP attached at Ether 4 of PPPoE Server


This is the PPPoE Client connected via wireless to AP

I would give karma to Nathan but with the new skin it seems not possible.

You can set back old forum look in your preferences.

I added karma to Nathan with the old interface.
Could you help me at least with the 2 last questions?

I set up the devices.
Please can you check if the interface are correctly configured?
I also Unchecked "Change TCP MSS", is it correct?
And last, is there a method to see if fragmentation appen in the way and not only in the test router in which I ping google.it size=1500 do-not-fragment ?

Please can you check if the interface are correctly configured?

They look fine to me. But the real question is, does it work? If you can answer that question, then you can answer your own question yourself ("teach a man to fish...")! You don't need validation from me. If it works, it is correctly configured. If it doesn't work, then it is not. Elementary logic. If it doesn't work, then we can start to examine the "why".

I also Unchecked "Change TCP MSS", is it correct?

Yes, that's fine, although I suspect it would work fine even with it checked. "Change TCP MSS" takes into account the MTU (subtracting 40 from it, which is the total size of the IP + TCP headers together). It doesn't just blindly make a rule that forces the MSS to some predefined constant value. So if you have "Change TCP MSS" checked on a PPP server which is set for 1500 MTU/MRU, then that checkbox would craft a set of mangle rules to lower the MSS to 1460 if the TCP traffic it is forwarding is advertising an MSS higher than that. But it will never be higher than that for computers with 1500 MTUs that are behind the router, because those computer will be negotiating/advertising a 1460 MSS anyway! So no harm done.

And last, is there a method to see if fragmentation appen in the way and not only in the test router in which I ping google.it size=1500 do-not-fragment ?

Not sure what you want. If you can ping down the tunnel with 1500-byte sized IP packets and DF bit set, and you get responses back, then no IP fragmentation is occurring. If you want further proof above and beyond that, then hook a computer up to the PPPoE client router, install Wireshark to it, and do a packet capture while you try to do something on the internet (e.g., visit www.mikrotik.com in a web browser).

-- Nathan

They look fine to me. But the real question is, does it work? If you can answer that question, then you can answer your own question yourself ("teach a man to fish...")! You don't need validation from me. If it works, it is correctly configured. If it doesn't work, then it is not. Elementary logic. If it doesn't work, then we can start to examine the "why".

It works, but I asked you for confirmation because setting the ether4 MTU to 1500 and not 1508 the ping test with 1500byte packet from PPPoE client with no fragmentation flag works and I don't know why.

Any idea about the strange behavior?

why not leave the L2 MTU on default and increase the MTU to max? the max MTU is 65535 but the L2 max is about 12000 depending on your network. I usually leave L2 MTU to 1500 and leave the MTU to 65535. This reduces CPU load for large transfers. When doing speed test across bridges and routes/VPN, having the very large MTU significantly increases throughput even if the L2 MTU is at 1500.

why not leave the L2 MTU on default and increase the MTU to max? the max MTU is 65535 but the L2 max is about 12000 depending on your network. I usually leave L2 MTU to 1500 and leave the MTU to 65535. This reduces CPU load for large transfers. When doing speed test across bridges and routes/VPN, having the very large MTU significantly increases throughput even if the L2 MTU is at 1500.

Because I want to follow the standard. 1508 mtu is a good choice because is the standard of all computers is 1500 and 8 bytes is used for PPPoE.
The most important question is why Mikrotik ping tool with a 1500 mtu test over a PPPoE interface that passes through a only 1500 mtu interface says that there is no fragmentation?

I usually leave L2 MTU to 1500 and leave the MTU to 65535. This reduces CPU load for large transfers.

Uh, no. L2MTU can never be less than MTU. If that configuration "works", then RouterOS is doing something strange/non-standard/buggy, or it is simply ignoring you and treating it as if MTU = L2MTU.

MTU only "defaults" to 65535 for bridges with no members. (65K is the absolute maximum frame size that Linux -- and thus RouterOS -- supports.) Once you add a member to the bridge, the bridge's MTU and L2MTU both get matched to the interface with the smallest MTU and L2MTU in the bridge. You can try overriding it, but clearly that's not recommended (I imagine the behavior in that case would be undefined, or possibly the bridge would simply not forward packets down any interface that were too large to fit that particular interface).

The most important question is why Mikrotik ping tool with a 1500 mtu test over a PPPoE interface that passes through a only 1500 mtu interface says that there is no fragmentation?

I don't know the answer to this. I would have to run some tests and packet captures to see what is actually going on.

-- Nathan