I have a wireless network whit some ptp and ptmp links routed via ospf. On top of that I recently implemented mpls/vpls to the end customers.
The wireless network is based on 411AH, 433AH, 912UAG,SXT and Sextant links running NV2.
Everything works, the vpls tunnels are up and running but I cant achieve any bandwidth higher then 20-30mbit in each direction, but in a singel ptp link I can push about 60mbit tcp in bandwidth test whit the rb cpus so probably more, as each ptp link is in 300/300 connection and ptmp is in 150/150 connection whit good ccq.
So, Iam now wounder if I might have an mtu problem? How can i determine that?
Maybe I have an switch that dont support jumbo frames?
What mtu/l2mtu do I must have in every interface to get this to work?
For exampel the RB411AH has only 1500 mtu and 1526 l2mtu, is that enough?
The vpls tunnels are set to 1500 mtu, 1500 l2mtu and advertised l2mtu 1500.
MPLS Interface is set by default 1508 mtu *all interfaces.
From what I can understand from this presentation I need 1522 l2mtu at least; RB411 and RB433 got 1526 l2mtu so it should be fine. the rest of the routerboard hw got more l2mtu. http://mum.mikrotik.com/presentations/US13/kirnak.pdf
Eth header 14, MPLS 4, VPLS 4, IP header 20, data 1480 = 1522 bytes.
But how can I test my wireless network to work whit that size of mtu?
I have seen other post where they are talking about tagged and untagged vpls interfaces? My vpls interfaces looks like this;
Yes, your calculations are correct, and it will work.
Just remember to set the L2MTU correctly on all interfaces on all devices.
As for how to test it:
Simply create a VPLS tunnel between 2 routers, and try to ping within that tunnel with 1472 packet size with do-not-fragment set.
(1472 because ICMP has a 8byte header as well)
So assign an IP address to both devices inside the VPLS tunnel, and do the ping using those IPs.
Well, that works, but I have read somewhere that the vpls interface will fragment the package anyway, due that I can ping whit 1500 packetsize as well.
Eth header 14, MPLS 4, VPLS ID 4, VPLS 4, IP header 20 + data 1500 + ping header 8 = 1554
How does this work ? ? ?
Untitled.jpg
Yes, VPLS interface will fragment frames automatically.
BUT it fragments based on its L2MTU and MTU values. So if you have L2MTU and MTU set on the VPLS interface correctly, and full size frames pass through, it means the rest of your topology does not have MTU issues.
Usually MTU issues are L2MTU issues on actual ethernet (or wireless) interfaces that carry the traffic.
Regarding the ping, it indeed should NOT work (should return fragmentation needed error).
Well then I guess that it would work because the vpls interface are set to 1500 ? It should be set to 1480 to fit the l2mtu on the interfaces that are 1526,
Eth header 14, MPLS 4, VPLS ID 4, VPLS 4, IP header 20 + data 1480 = 1526?
1500 is the correct L3 and L2 MTU on the VPLS interface in your test scenario.
Remember that MTU (L3 MTU) in MKT is with the data, L4 and L3 headers counted in.
Calculation of MTU from the point of view of the VPLS interface:
1472 data + 8 icmp header + 20 ip header = 1500 L3 MTU for the VPLS interface. (but that realistically is 1472 packet size for ping)
Why ping is working for you with 1500 size and do-not-fragment flag, I do not know.
It might be that the VPLS interface is not respecting the DF flag, which would of course be a bug.
Or it might be some other particularity in your setup, where the ICMP packet is getting routed somehow over the “naked” path, which supports such high L3 MTU.
In the weekend I am also going to replace an old central switch that I am unsure if its capable to handle jumbo packages.
If it only handles 1514 mtu, it will be an bottleneck.
RouterOS calculates the packet size differently from a PC so it may well show 1500 byte packets unfragmented whereas a PC pinging on the same path would max out at 1472 due to the ICMP and IP headers.
1522 is too small because VPLS requires two MPLS labels instead of one. One label is for the MPLS endpoint, and the other is for the VPLS tunnel identification. hence the 1526 minimum.
Standard MTUs for MPLS to hand off a 1500 bytes frame are:
minimum of:
1526 - if planning to use untagged frames with VPLS 1530 - with tagged VPLS frames
In reality, most MPLS networks are designed using jumbo frames whenever possible on the transport side. It simplifies adding more advanced services like QinQ at a later date.
Tagged VPLS is when you hand off the Layer 2 segment to the customer or endpoint with an 802.1q VLAN tag. The extra 4 bytes for that tag is what causes the MTU requirement to change from 1526 to 1530.
No, we dont use any vlans in the vpls tunnels, just plain vpls tunnel to the customer whit either static or dhcp addresses to the customers/our router.
So our l2mtu on 1526 should then be enough?
Eth header 14, MPLS 4, VPLS ID 4, VPLS 4, IP header 20 + data 1480 = 1526
1526 is the absolute minimum to hand off a 1500 byte frame to the customer. Your MTUs should look like this
L2 MTU - 1526 or higher (L2 MTUs should match on each side of a link and can be higher than 1526)
L3 MTU - 1500 bytes (This must match on every IP in that subnet to be RFC compliant)
MPLS MTU - 1526 or higher (This must be the same on every MPLS router to avoid issues and cannot exceed the max supported L2 MTU)
MTU mismatch is the single biggest issue we see on MPLS networks. Sometimes it takes a while to rear it’s ugly head and often times, it is misdiagnosed as a RouterOS bug.
Here is a very easy test you can do to see if a segment will support over 1500 bytes