Hi guys i have a little question about MTU .. I need to run to PPPoE Server over to single VLAN in our CCR1036 to our clients and i have a question about set MTU on interfaces to avoid fragmentation problems.

The basic diagram is this: CCR1036 ---------- (eth cable) ---------- SWITCH ------- (eth cable's) ------- | Clients over Vlan

I know this:
- L2 MTU is 1580 Bytes (Max is 10222)
- L3 MTU is 1500 Bytes
- Payload: 1480 Bytes
- PPPoE Overhead is 8 Bytes
- Vlan Overhead is 4 Bytes
- IP Header: 20 Bytes

If we put all this together we got this:
1480 + 20 +8 +4 = 1512 Bytes > This is bigger than L3 MTU

And my question is ... Where do I need to change MTU value? On Ethernet interface where Vlan runs, VLAN Interface or i need to set it on PPPoE Server (MTU & MRU) ??

Thanks!

VLANS ( tags) are included in L2MTU so this part is OK. Regarding PPPoE, from 1500 you take out 8 Bytes because all traffic is "wraped" in PPPoE. This leaves you with 1492 MTU for rest overhead + data. Only thing you should consider is MSS change to 1452 ( MTU - 40Bytes ( 20Bytes of IP and 20Bytes of TCP header)). Also, if you are not blocking ICMP, PMTUD should kick in. Someone will correct me if i missunderstood scenario,
Additional info needed - Is PPPoE between routers tagged ot not? How ports on switch are configured?

Thanks for your reply blajah.

In this case the only thing that i need is create 2 mangle rules to change tcp mss to 1452 or 1440 right? In my case:

Ether2 MTU: 1500
Vlan100 (over Ether2) MTU: 1500
PPPoE Server:
- Max MTU: 1480
- Max MRU: 1480

And then, create this 2 rules on firewall: This is correct?

Thanks!

Mangle rules are depending on your rOS version

rOS 6.39
!) ppp - implemented internal algorithm for "change-mss", no mangle rules necessary;

rOS 6.39.2
*) ppp - fixed "change-mss" functionality (introduced in 6.39);

You should be OK without any additional settings

Mangle rules are depending on your rOS version

rOS 6.39
!) ppp - implemented internal algorithm for "change-mss", no mangle rules necessary;

rOS 6.39.2
*) ppp - fixed "change-mss" functionality (introduced in 6.39);

You should be OK without any additional settings

Change MSS only applies to TCP, ultimately you want to pay attention to all MTU and related messaging from ICMPv4 and ICMPv6 (too big, fragmentation needed, etc ...) that makes up path MTU discovery. If that's respected there actually isn't a need for a protocol fix-up for MSS.

Hi guys i have a little question about MTU .. I need to run to PPPoE Server over to single VLAN in our CCR1036 to our clients and i have a question about set MTU on interfaces to avoid fragmentation problems.

The basic diagram is this: CCR1036 ---------- (eth cable) ---------- SWITCH ------- (eth cable's) ------- | Clients over Vlan

I know this:
- L2 MTU is 1580 Bytes (Max is 10222)
- L3 MTU is 1500 Bytes
- Payload: 1480 Bytes
- PPPoE Overhead is 8 Bytes
- Vlan Overhead is 4 Bytes
- IP Header: 20 Bytes

If we put all this together we got this:
1480 + 20 +8 +4 = 1512 Bytes > This is bigger than L3 MTU

And my question is ... Where do I need to change MTU value? On Ethernet interface where Vlan runs, VLAN Interface or i need to set it on PPPoE Server (MTU & MRU) ??

Thanks!

Great question, MTU is always a tricky beast. You're on the right path, thinking about the layers and their header size. The VLAN layer is almost certainly going to stay with your layer 2 MTU, this means you need 1504 + 18 for Ethernet (max) or 1522. You then apply PPPoE which drops your usable MTU to 1492, a base layer 3 MTU of 1500 - 8 for PPPoE. If you are encapsulating IP within PPPoE then you need to subtract 20 additional bytes leaving you at 1472 bytes of layer 3 MTU on the PPP interfaces.

If you do this and allow ICMP messaging for Path MTU discovery you won't need to use firewall rules or the change MSS feature within the PPPoE interfaces.

(I'm assuming you're not trying to tunnel the VLAN within PPP BCP)

Reading this I am looking at I am able to ping directly from the Mikrotik to the outside at with 1500 without defragmenting.

When I am on a device connected to the Mikrotik I can ping with 1472. Looking at the PPPoE connecting to the server I notice that the datalen is 1492.

The displayed MTU on the PPPoE connection is 1500 (1492+8).

Now am I am asking myself why can ping with MTU 1500 (+8 PPPoE) from the Mikrotik and get 8 deducted when I am not on the Mikrotik?

Reading this I am looking at I am able to ping directly from the Mikrotik to the outside at with 1500 without defragmenting.

When I am on a device connected to the Mikrotik I can ping with 1472. Looking at the PPPoE connecting to the server I notice that the datalen is 1492.

The displayed MTU on the PPPoE connection is 1500 (1492+8).

Now am I am asking myself why can ping with MTU 1500 (+8 PPPoE) from the Mikrotik and get 8 deducted when I am not on the Mikrotik?

Ping has to be toggled to force DF bit, by default it will fragment and you'll only see that in IPv4 between the two routers. IPv6 would show an ICMPv6 too big message to the client.

Reading this I am looking at I am able to ping directly from the Mikrotik to the outside at with 1500 without defragmenting.

When I am on a device connected to the Mikrotik I can ping with 1472. Looking at the PPPoE connecting to the server I notice that the datalen is 1492.

The displayed MTU on the PPPoE connection is 1500 (1492+8).

Now am I am asking myself why can ping with MTU 1500 (+8 PPPoE) from the Mikrotik and get 8 deducted when I am not on the Mikrotik?

True. This is because RouterOS made this way. If you point the size, RouterOS is automagically count data size plus all service headers. So, if you type 1500, it means this size must contain service headers of interface,through which packets goes and size of a data in total.

@idlemind, I know this, and this way is the simplest way if a packet is fragmenting.

Thanks, this is clear but I remember seing on older versions of RouterOS an MTU of 1508 on PPPoE and going to dig this up and test if the displayed 1508 was only cosmetical or a real value.

@idlemind, I know this, and this way is the simplest way if a packet is fragmenting.

Thanks, this is clear but I remember seing on older versions of RouterOS an MTU of 1508 on PPPoE and going to dig this up and test if the displayed 1508 was only cosmetical or a real value.

Make a dump and you'll see If you'll ping wihty 1500 size, a playload of icmp data will be 1452 bytes, if mtu is 1480. 1452(data)+8(icmp)+20(ip).

@idlemind, I know this, and this way is the simplest way if a packet is fragmenting.

Thanks, this is clear but I remember seing on older versions of RouterOS an MTU of 1508 on PPPoE and going to dig this up and test if the displayed 1508 was only cosmetical or a real value.

Check this out https://wiki.mikrotik.com/wiki/Manual:M ... 2.2FL2_MTU there is table with L2MTU sizes per device. Your devices mtu doesn't mean that size will pass all way to destination without fragmentation or pmtud kicking in.

I have run some tests on my current setup and connected Wireshark up to see the content of packets. My PPPoE connection is to my ISP with a vlan.

The PPPoE it is max 1500-8=1492, ping max size 1472 not fragmenting. It makes no difference if I ping from the router self or an external device so the ping size display is indeed cosmetic.
On the vlan and fiber to the ISP the max mtu is 1502 (payload) and I assume that is the vlan but then I expected it to be 4.

Nice to see how fragmenting works and it is not all bad. As I interpreted is a train of packets that only needs one PPPoE packet on front. These coming free 8 bytes are added to the 1472 and the fragmented size becomes 1480. The last carriage in the packet train can be really badly loaded and destroy the earlier gain archived by bigger packets and my max packet size is 1998+28=2026 so not that much advantage.

update:
I have now spent a lot of time looking at how to make the path MTU larger and I can't get beyond 1492. A nice program to test is mturoute.exe from Eli Fulkerson.

I have now disabled jumbo packets on my Windows network device and the packets can be max 1476 (fragmented). This seems to be strange but I think these extra 4 bytes are there for vlan. Not fragmented it is still the standard 1472 (1492 path MTU). I only wished that RFC4638 could put those 8 bytes for PPPoE above the 1500 (1492) MTU so that 1500 would be interneal network wide.