So, I realized that when change-mss is enable in PPP profile, there is a bit of a problem…
If MAX MTU and MAX MRU is set = 1492
Two mangle rules are dynamically created (of course, this is with a version < 6.39)
One match traffic going to all-ppp interfaces and change MSS to 1452 when MSS is between 1453-65535
And another is to maatch traffic coming from all-ppp interfaces and change the same thing as the rule above.
But… If one PPP is connected and the other side (normally a router from a customer) is configure as MTU 1400, for example… the rule for traffic coming from all-ppp is automaticaly changed with this new MTU as parameter. For this example, as 1400, the new action is to change mss to 1360
So, all PPP connections will suffer with lower MTU ?
Sometimes is the customer that configured the router, and is making a mess…
How about this new concept in 6.39 ? !) ppp - implemented internal algorithm for “change-mss”, no mangle rules necessary;
How will this actually work?
You should not need any rules like that, when you use “new-mss=clamp-to-pmtu” instead of those explicit
numbers. I have no idea why MikroTik is not doing that, I always disable all that automatic rule creation and
put a single rule in the mangle table:
When you have concerns that it limits performance when you have a lot of ethernet-to-ethernet forwarding you
could always try to limit it to some interface types. But I do not see why it should have fixed values.
If we put this, all packets, even those with MSS lower will have MSS increased.
I don’t know much about the concept, but, if a packet want to have a lower MSS, should we let it pass?
Mikrotik default (dynamic) rules have another match, only packets that would try to deal the MSS above the ideal MSS would get changed, like this for 1480 in MAX MTU:
tcp-mss=1441-65535
or this for 1492 in MAX MTU:
tcp-mss=1453-65535
If we ignore this, would we have some collateral effect ??
So, I did some testing and, even with PPPoE with MTU as 1500 and change-mss=yes in PPP profile, MSS for SYN packets are still changed by 4 bytes I guess. Don’t really know why.
Is that a guess, or did you actually observe that?
It should only lower the MSS when too high, never increase it. When you observe increasing MSS by that rule,
please file a bug report to MikroTik (probably with pcap files with evidence).
But that’s what I’m saying. If the rule has no match with MSS, it should ignore the original MSS and it will change MSS as the action is change MSS for the max possible, even if it is already under that limit.
This is not a bug, but a rule created for that purpose.
That’s what I’m saying. Why do mikrotik is using MSS as a match and you are not…
No that is not correct, “clamp to pmtu” means “lower the mss when too high, leave it alone when already lower”.
When you see “clamp to pmtu” increase the mss, please submit a bug report.
I will try to test when I have possibility to make a test setup for this.
Before this change there was dynamic mange change-mss rules created, this enables connection tracking, disables fastpath making everything slow.
Now this functionality is build-in into ppp interfaces themselves, this way no mangle rules are necessary, no connection tracking, fastpath possible - everything much better.
Initial implementation had bugs, it was not taking into account MRRU, now it is fixed in latest RC. As far as i can tell everything is working fine now.
So, imagine my scenario, when those mangle rules were for all-ppp and limited by the minimal MTU… (before 6.39)
So now, it will consider the MTU from each tunnel ? Which means that I don’t have to worry about limiting all-ppp just because some customer messed it up ?
Thanks!
For us this is irrelevant, since we need to do some NATing for some customers… which breaks fastpath.
The choice is always “do I want to bother with fasttrack and get some additional performance” or “do I want a system where all features work”.
For me, until now the choice has always been to disable fastpath and fasttrack, as fortunately everywhere where I need performance I have a CCR.
For others, it may be different and those tweaks may be welcome. Anyway, you can install the latest RC and test it.
I have used the “clamp to pmtu” rule and I think it has worked for me, I want to test if there really is the above mentioned bug in it but I doubt it.
I want to see this as well. Since you said “clamp to pmtu” means “lower the mss when too high, leave it alone when already lower”. i’m seeking this information… searching every post that would say that, but I could not find anything.
If you could test it, that would be awesome.
Those dynamic rules are not good at all when you have multiple MTU on your costumers, because as I said, they are not respecting the MAX mtu, instead, is making the worse MTU as default parameter.
Just updated whole my pppoe site to 6.39.2, you can forget about change-mss rules, it all is now nicely build-in into ppp interfaces, even with MRU now it works fine.
Could you see, please, if all PPPoE interfaces has same MTU?
I want to test it when MTU is not the same for all interfaces, just to see if will work in that case, or if is considering the minimal mtu to run this “new” algorithm.
It looks like packet get adjustment MSS when it travels through particular interface so if one interface have MSS 1400, other 1350, third 1300, packet will get only that mss that is on interface it is going through.
this is out of topic but I would like to ask in interface pppoe-server server side, how should i set service. should i set max-mtu=1480 max-mru=1480 mrru=1600 or should i set them auto ?
That depends on how much data could a packet carry and flow inside your network.
The default size of an ethernet frame is 1500.
This means: The closer to this number, the better.
MTU is the key to acheive this, but, you need to consider all the protocols that would populate the header of the packet.
For example, if you use only PPPoE and nothing else (like VLAN, MPLS, VPLS, etc) you will need to lower the MSS or increase the L2 MTU from all devices in your path by 8 bytes.
PPPoE uses 8 bytes for the tunnel to be possible.
So, the math is:
1500 - 8 = 1492
This should be the new MTU without needing to increase the L2 MTU in your path.
If you could increase L2 MTU, enabling “jumbo frames” on your switches as well, than you could carry the 1508 byte packet and from this point you would not need tho change MSS at all.
If not, MSS should be decreased to be possible for the packet to flow.
Another example:
If you use MPLS and VLANs, you will need to do the math:
How much does MPLS increase in header?
4 bytes
How much does VLANs increase in header?
802.1q = 4 bytes
QinQ (which means you check the box Service Tag) = 8 bytes
So, do the math:
1500 - 8 (PPPoE) - 4 (MPLS) - 4 (VLAN 802.1q) = 1484 (Max MTU)
You will need to chose what to do. Or you increase your L2 MTU Path (in this example above by 16 bytes) or you need to shrink the MSS (to be able to use the left space on header)
In this scenario, without jumbo frames you will get dropped packets if you don’t change MSS (normally by 40 Bytes), causing connections failures for your costumer.
So, the math for MSS is
MAX MTU - 20 (IP Header) - 20 (TCP Header) = MSS