So i upgraded to 6.39 because i saw a feature was a new implementation of fragmentation etc etc. Just wanna say after upgrading, my l2tp/ipsec connection broke again, and it deleted my mangle rules (when i tried to add them in again i could not get clamping to work). I’m not 100% on EXACTLY the issue, just that when I first set up the PPP i had a fragmentation issue i could diagnose with a ping with the DF flag set, but now for some reason even though the symptoms are similar to what i had experienced pre clamping rules, my pings, of any size, with DF set, seem to go through. either way i had to downgrade, i just thought i would let you know that at least for me, 6.39 makes my PPP connection barely usable.
from changelog:
!) l2tp - added fastpath support when MRRU is enabled;
!) ppp - completely rewritten internal fragmentation algorithm (when MRRU is used), optimized for multicore;
!) > ppp - implemented internal algorithm for “change-mss”, no mangle rules necessary;
Posting an export will help…
i rolled back to 6.38.5, so i dont know if an export now will help, cause everything works fine in 6.38.5. Question is /ppp export and /firewall mangle export is enough? or also /ip ipsec export
Just write to support@mikrotik.com
In order for mikrotik to be able to help, upgrade to 6.39 again, and generate a supout file while reproducing the problem if possible.
Attach the file to the email, it will already contain an export of the config and the details they need to analyze the problem.
ok i will do that. thanks.
Did you hear back on this? Had a customer router the other day, using change-mss on PPPoE that I had to roll back to 6.38 as the clamping wasn’t working.
Even if we assume the new ‘internal algorithm’ for this doesn’t work, surely a manual change-mss mangle rule should still force the matter?
I was just working on this with another forum member after 6.39 dropped. We found that MSS clamping does in fact work. You may want to verify the MTU and MRU settings within the PPP connection. This can be found in various places depending on what is using the PPP encapsulation. In the post I will like below you’ll see it in the L2TP server settings. You will also need change-tcp-mss set to yes in the appropriate PPP profile.
We’ll want to make sure your MTU and MRU values are set appropriately despite any behavior of TCP MSS. Without a proper base MTU by clamping the MSS you likely aren’t helping in anyway and if you are it is only helping TCP connections not ICMP or UDP.
This post we discussed the change and why the new method reserves an additional 6 bytes more than what would normally be expected under default settings: http://forum.mikrotik.com/t/mtu-and-mss-with-new-internal-algorithm/108564/1
This post you will see in the last section I dove deeper into MTU and MSS and how those settings affect the connections that traverse a link: http://forum.mikrotik.com/t/gre-tunnel-setup-help/108436/1
As a bonus take a look at the post linked at the bottom of this one. It includes some screenshots of demonstrating how encapsulation affects MTU.
You may ignore most of this post with the exception of my confirmation that 6.39 will adjust MTU and MSS of connections appropriately with default settings if you know all there is to know about MTU and MSS.
Potential fix for this problem is included in 6.40rc13 version. Please test and reply if this has fixed your MSS issues introduced in 6.39 version.
Is this about the extra 6 bytes that were previously reserved?