nz_monkey on your example above do you actually have a VPLS tunnel terminating on that box?

EDIT: nvm I looked at the pic again, it was right there. I assume it passes a ping test of 1500 bytes.

Yes. It actually passes 1504 byte packets with no vlan tag, or 1500 byte inside vlans.

We are connecting two datacentres with this, running constantly at between 150mbit and 1gbit and as you can see its been pretty reliable

Ok so now Im confused again. BTW the dell r210 is very nice!

But I bench tested all of this in the lab, the onboard broadcom chipsets would set the MTU properly and then MPLS MTU 1526 worked fine, was happy.

But Then I went to put it into production and it didnt work!

I failed to realize that the interface I was running MPLS/LDP over was a VLAN, and it seemed to be where it would stop passing the large packets.
Now how do I get the VLAN to pass the proper traffic? Same way? Adjust its MTU from 1500 to whatever? So Im adjusting the MTU of the physical interface, THEN the vlan interface?

I dont have a PC to check. But im pretty sure the vlan inherits its L2MTU from the parent interface. But yes i do remember adjusting MTU on the couple of installs we have running MPLS inside a vlan.

The 11th/12th gen Dell servers are really nice, i like them a lot more than HP DL/ML G6/7.

The R210 is pretty basic but its nice and short so fits in comms cabinets. It also has great warranty and runs RouterOS really well.

I dont have a PC to check. But im pretty sure the vlan inherits its L2MTU from the parent interface. But yes i do remember adjusting MTU on the couple of installs we have running MPLS inside a vlan.

Im not sure it does on x86. There is no aformentioned L2MTU anywhere on the parent interface, so Im not sure the VLAN knows what to inherit, I cant see it inheriting the IP MTU value?. I think I will have to build a test on the bench again. Lol.

I CAN see that it does indeed inherit the parent interface L2MTU if its on an actual routerboard.

1512

This is a really strange behavior (been searched for errors regarding to this for some hour today).

Thes is somehow a "fix" or hack. to make Things working...

ros code

/ip firewall mangle
add action=change-mss chain=output disabled=no new-mss=1400 passthrough=yes \
    protocol=tcp tcp-flags=syn tcp-mss=1401-65535
add action=change-mss chain=forward disabled=no new-mss=1400 passthrough=yes \
    protocol=tcp tcp-flags=syn tcp-mss=1401-65535

(at both ends of vpls tunnel)

This is a really strange behavior (been searched for errors regarding to this for some hour today).

Thes is somehow a "fix" or hack. to make Things working...

ros code

/ip firewall mangle
add action=change-mss chain=output disabled=no new-mss=1400 passthrough=yes \
    protocol=tcp tcp-flags=syn tcp-mss=1401-65535
add action=change-mss chain=forward disabled=no new-mss=1400 passthrough=yes \
    protocol=tcp tcp-flags=syn tcp-mss=1401-65535

(at both ends of vpls tunnel)

That is definitely covering up an issue with the underlying network.

Ive since determined that it _was_ my underlying network that was really broken, and why it worked in the first place was a bug (without proof) in Mikrotik that allowed it to work that I believe was fixed in very recent versions (MPLS MTU config problem). After careful analysis of my networks L2MTU, some hardware replacements, and proper MTU config across the board I have yet to see this problem happen again.

This is a really strange behavior (been searched for errors regarding to this for some hour today).

Thes is somehow a "fix" or hack. to make Things working...

ros code

/ip firewall mangle
add action=change-mss chain=output disabled=no new-mss=1400 passthrough=yes \
    protocol=tcp tcp-flags=syn tcp-mss=1401-65535
add action=change-mss chain=forward disabled=no new-mss=1400 passthrough=yes \
    protocol=tcp tcp-flags=syn tcp-mss=1401-65535

(at both ends of vpls tunnel)

i got same issue on vpls over bonding , this mangle actually solved it. but just curious , is there any possible issue if we apply this mangle ? like limited throughput or something else ?

Depends on what type of throughput testing your doing. Any TCP traffic will be chopped into a maximum 1400 byte packet, which increases the bandwidth needed due to TCP's congestion mechanisms and such.

UDP however, no.

Its possible to trim it more, and use 1480 etc. Then it would be less impact to performance.

PS, don't use it to smaller than 1280, then ipv6 will stop working.

@Inssomniak

Glad you finally got your MTUs sorted out. It's one of the trickest things to manage when you are building an MPLS based network. It took me several years to understand the role MTUs played across L2, MPLS and L3 when dealing with advanced transport mediums like Metro Ethernet, Wireless backhaul, Sonet, xDSL, etc. Everything has to be just right

Coming from the service provider world and Cisco based MPLS, i've been extremely impressed with the MPLS capabilities of MikroTik and continue to be an advocate for the use of MikroTik.