So if I have calculated that the smallest l2MTU in all of my network is 1522, that’s what I set my MPLS MTU to?
I can’t seem to get it to work if that is the case.. The only way mpls works properly is if mpls MTU is set to 1500.
1522 is to low to run MPLS.
That depends on your application and That’s not what I asked though.
MPLS mtu have to be the lowest l2MTU that allow a full frame MPLS packet trough. So it depends on your need. a full frame standard Ethernet packet, would be just simply dropped, if L2MTU is to small for a full frame MPLS packet. Its not possible to fragment in MPLS. VPLS add more.
Why run on the edge? And why use the “minimum” possible MTU?. I have a setup and have l2mtu at minimum 1600. I run MPLS mtu at 1560, and vpls l2mtu at 1525 and mtu at 1510. Then you are sure things is working.
In your setup, a packet included ip header will just be 1498, instead of 1500. If you use vlan, vpls etc, it’s even lower. at 1522 need 2 more bytes to get it working.
But, to just “play around” with MPLS, set the MPLS mtu to the same as your interface l2mtu. if mopre devices connected, set it to the lowest interface l2mtu in the “string”
http://wiki.mikrotik.com/wiki/Manual:Maximum_Transmission_Unit_on_RouterBoards
Ok. Thanks.
I’d love to run an MTU that allows a full frame, but much of my equipment does not have an l2mtu higher than 1522.
I have VPLS tunnels carrying pppoe traffic back to my concentrator
No vlans
So. Math trick of the night ?
What’s the PPPoE MTU I should run ? I came up with 1484.
Actually you should not run like this 
Run in full frame mode. I canged all my net, to support l2mtu minimum 1600. If you don’t have mtu enough, you will run into troble. Let a Ethernet be 1500, and pppoe 1492.
If you start fragment, you will have about 1/2 the possible maximum speed. A package is a pakage, even if big or small. If you start to fragment. you will use 2 package, and all wireless stuff required to transfer doble, to send actually one frame (pakage).
Yes Im aware of it, but I have 47 devices on the top of towers and silos that would need to be changed, and over time it will happen.
But for now, Im trying to determine the optimum MPLS MTU, which is 1522 like you said. Then account for the VPLS headers, etc, then I can come up with a PPPoE MTU to run that wont get fragmented in a VPLS tunnel.
I already have all this working, it works fine, its just not optimal, I just want to make it optimal given the hardware I have to work with. Thats all.
As far as MPLS mtu goes, here are the numbers you need for 1500 bytes frames.
1526 - To run untagged VPLS
1530 - To run tagged VPLS
If you cannot run any higher than 1522 then you will need to write a mangle rule to do a TCP MSS adjust. It will solve most of the performance issues. Ultimately you need to plan to upgrade your equipment.
As far as PPPoE, it requires 8 bytes of overhead for the PPP portion, so given that you have a 1496 byte frame to work with, I would start at 1488 and decrement if needed for any other overhead you have.
/ip firewall mangle
add action=change-mss chain=forward new-mss=1280 protocol=tcp tcp-flags=syn tcp-mss=1281-65535Is a good way to do the mangle. Then ipv6 would go work.
Its really a “hack” but make things working. (Yo don’t have to go as low as 1280, but you don’t need to be exactly at maximum either) If solution is to fragment, just fragment as “low” as possible. More small packet will go trough yor system. Latency may actualy be better, if you don’t run at maximum speed. (Speed will be reduced, due to double the amount of packets, but response time could be better) Its also possible to actually have a better wireless network, if its in a noisy environment (a small packet is more likely to get trough the wireless link without breaking, and the need for a restransmition (in bad ccq links) is reduced
1526 I assumed I needed to run, as mentioned on the mikrotik wiki to be full frame.
1522 Is what I have to work with.
PPPoE=1488+PPPoE header 8 bytes=1496+ETH14+MPLS4+MPLS4+VPLS4=1522
So I set my PPPoE server that is bridged with many VPLS tunnels to MTU 1488.
have an MSS rule of 1448.??
This should allow no fragmentation in the VPLS tunnels for customers?
You will make fragmentation, when you change your pppoe mtu. Mostly all webserver will send you a 1500 byte frame, and it will be fragmented, in your NAS (incoming). Outgomming, you could fragment in pppoe (client), but its better to fragment using the change mss rule before reaching the pppoe. Then you will have a already fragmented packet, when pppoe handle the “connection”
Its better to make the change mss a bit smaller, like the 1280. Then ipv6 will get full framed. (and work) Then you will send 1280 bytes, then 220, then 1280,then 220, i (+ ETH14+MPLS4+MPLS4+VPLS4) and you have “something left” for your MPLS setup, and can play with vlan, qinq etc.
Just to clarify what MSS Adjust does…
When a TCP SYN packet comes through the router, it will rewrite the header and adjust the MSS if the MSS is larger than the MSS adjust setting. It does not fragment the packet. Although I don’t recommend running with MSS adjust if you can help it, I’ve seen some fairly large networks (10,000+ nodes) use it successfully with MPLS and PPPoE to overcome low MTU transport issues.
Right now I think I have bigger problems.
I cant make MPLS work with the MPLS MTU setting even at 1501 despite knowing the L2MTU is 1522 at least.
Why are you setting MPLS MTU at 1501? Set it at 1522 if that’s the highest L2 MTU you have.
I have, it doesnt work 
only 1500 works.
1501 and higher does not.
Ive been working on this issue for months.
If My MPLS MTU is 1522, what should the VPLS MTU/advertised L2MTU be set to?
Hi inssomniak.
It sounds like you have a mismatch somewhere.
Set the vpls mtu to 1500.
Allow CW for vpls.
Set the physical interface to the max l2mtu it supports that is also supported by the remote end.
Set the mpls mtu per ldp carrying interface and set it the same as the l2mtu for that interface.
If you want to pass vlan tagged frames set the vpls mtu to 1504 and type to tagged ethernet.
Oh and leave the mtu set to 1500 on the physical interfaces that have an ip configured on them
Thus should get you up and running.
If not paste your configs up and we can tell you what is wrong.
For my test environment I have this setup I set up this morning which changes the rules a but bit created the same problem.
Router A - physical interface has max l2mtu of 9014, and its set to 9014, and on this router a VLAN is connecting to this interface giving me a 9010 l2mtu.
This then passes through a switch with jumbo frames enabled on the interfaces and gives me 9216.
This vlan passes through Router B via bridge and 2 ethernet interfaces which has a l2mtu of 2024 (RB750)
It again passes through router C via bridge and 2 ethernet interfaces which is my bottleneck Router, has max l2mtu of 1518 (RB493AH)
Then it continues to Router D which then exits an ethernet interface and gives me an L2MTU of 9500 (RB600).
Routers B and C have no MPLS configuration relating to the vlan interfaces.
All layer 3 MTU settings are left at 1500 on all interfaces.
The routers are all connected together via ubiquiti WDS bridges and all MTUs have been set to the max (some 1524, some 2024)
Now this test environment subtracts me again 4 bytes because of the vlan passing thru router C, so I calculated my MPLS MTU in this scenario to be 1518 (for testing)
VPLS all set to 1500 MTU for both l2mtu and IP MTU.
no vlans in VPLS tunnels.
With MPLS MTU set to 1500 everything seems OK: I can ping thru the VPLS tunnel.
1480(1500) packet goes thru with I assume a VPLS fragmentation.
Daves-Mac:~ dave$ ping -Ds 1472 192.168.201.1
PING 192.168.201.1 (192.168.201.1): 1472 data bytes
1480 bytes from 192.168.201.1: icmp_seq=0 ttl=63 time=55.815 ms
1480 bytes from 192.168.201.1: icmp_seq=1 ttl=63 time=14.475 ms
1480 bytes from 192.168.201.1: icmp_seq=2 ttl=63 time=26.153 ms
I set it to 1518:
Daves-Mac:~ dave$ ping -Ds 1472 192.168.201.1
PING 192.168.201.1 (192.168.201.1): 1472 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
I set to packet size 1450(1470), its the largest I can get thru.
Daves-Mac:~ dave$ ping -Ds 1450 192.168.201.1
PING 192.168.201.1 (192.168.201.1): 1450 data bytes
1458 bytes from 192.168.201.1: icmp_seq=0 ttl=63 time=19.633 ms
1458 bytes from 192.168.201.1: icmp_seq=1 ttl=63 time=14.377 ms
1458 bytes from 192.168.201.1: icmp_seq=2 ttl=63 time=11.376 ms
To add to this thread and possibly mark as solved?
The issue after hours of testing and troubleshooting is the network adapter or its drivers in mikrotik 5.24 and probably other versions?
The card reports an L2MTU of 9014 (not changeable) Its an Intel 82572EI Gigabit Ethernet Controller (Copper) (rev: 6)
The large or jumbo frames would transmit out the card through the switch and to another mikrotik router, but does not receive any packets larger than an IP MTU size of 1507.
So Did I solve anything ? No, But I have determined where my issue is. Network adapter that happily transmits large packets but won’t receive them.
I replaced the card in a 2am maintenance window last night
With the RB44Ge pci-express card.
And it worked.
So goes to show not even the good cards are perfect? or the drivers aren’t.
The card I removed was a PCI-express 1x pro/1000 PT server adapter.
Again the card would send out the large frames, but not receive them back.