I recently encountered an issue with IPv6 affecting my ability to play HellDivers 2.
It's my first connection issue that I've experienced and I'm trying to understand exactly why it's an issue and why I may or may not need MSS Clamping enabled. I've seen some conflicting information on how the change-mss mangle rules could disable fasttracking so I don't really want to have to enable it if I don't have to. I'm very confused about the whole thing.
I have a VDSL FTTC PPPoE connection with an MTU/MRU of 1492 (negotiated as I don't explicitly set). My ether ports etc. are set to the default of 1500.
If I access http://icmpcheckv6.popcount.org/ from the same PC that I have issues with the game it shows "✓ All good! ICMP path MTU message was successfully delivered to you." and "✓ All good! IP fragments were successfully delivered to your host."
My main questions are:
1. If I haven't to my knowledge experienced any other MSS related issues, for what reason could this game be giving me connection issues unless I change the MSS manually or clamp to pmtu? Note. disabling IPv6 on my network adapter would let me in without issues.
2. If I enable MSS clamping to pmtu, does this affect ALL packets (i.e. less fasttracking). I am aware that I can specify a range instead of clamping to the pmtu but I have also seen there are benefits of clamping to the pmtu instead?
3. Is fasttracking even a thing for IPv6?! I can't see fasttrack related IPv6 firewall rules
4. Typically, should absolutely need to have MSS clamping enabled on a home network?
Re: Trying to understand the need for MSS Clamping
MTU/MSS/MRU was an issue from beginning of internet. In IPv4, packet fragmentation was allowed and until certain point in time, all routers did it if needed. However, it's burden for routers and fragmentation slowly ceased to happen, instead routers started to drop packets which exceeded MTU of next hop link. Instead, they emitted ICMP packet too big message, prompting sender to reduce packet size (this is effectively the function we all know as "Path MTU discovery").
The problem, though, is that some paranoid network administrators block all ICMP traffic (not only ICMP echo request/reply, which may be used to increase attack surface), breaking PMTUD.
In IPv6 packet fragmentation is not even allowed any more, so working PMTUD is even more important. Hence importance of working ICMP is increased. However, some network admins keep blocking ICMP traffic.
Here comes MSS clamping: it's a feature which allows router to set TCP headers of return packets with MSS value low enough to be able to pass packets upstream. Typically it's set to MTU of next hop (e.g. PPPoE interface has MTU lower than 1500, which is de facto industry standard), but setting has to be configured carefully not to increase same setting if it was set to even lower value by upstream servers.
MSS clamping is done per-connection, hence need to (partially) bypass fasttrack. The good news (kinda) is that ROS currently doesn't support fasttracking IPv6, so currently this option doesn't degrade router performance for IPv6. And, as follows from explanation above, PMTUD may work for some connections and not for other connections (ICMP may be blocked by routers close to particular servers).
MSS clamping is not needed where all links and devices' MTU is equal (i.e. 1500 bytes), so typically for LAN connections it's not needed. In general MSS clamping is not needed if PMTUD works ... it seems to work for your own router and ISP's network as you're getting all those green checks from site you linked.
The problem, though, is that some paranoid network administrators block all ICMP traffic (not only ICMP echo request/reply, which may be used to increase attack surface), breaking PMTUD.
In IPv6 packet fragmentation is not even allowed any more, so working PMTUD is even more important. Hence importance of working ICMP is increased. However, some network admins keep blocking ICMP traffic.
Here comes MSS clamping: it's a feature which allows router to set TCP headers of return packets with MSS value low enough to be able to pass packets upstream. Typically it's set to MTU of next hop (e.g. PPPoE interface has MTU lower than 1500, which is de facto industry standard), but setting has to be configured carefully not to increase same setting if it was set to even lower value by upstream servers.
MSS clamping is done per-connection, hence need to (partially) bypass fasttrack. The good news (kinda) is that ROS currently doesn't support fasttracking IPv6, so currently this option doesn't degrade router performance for IPv6. And, as follows from explanation above, PMTUD may work for some connections and not for other connections (ICMP may be blocked by routers close to particular servers).
MSS clamping is not needed where all links and devices' MTU is equal (i.e. 1500 bytes), so typically for LAN connections it's not needed. In general MSS clamping is not needed if PMTUD works ... it seems to work for your own router and ISP's network as you're getting all those green checks from site you linked.
Re: Trying to understand the need for MSS Clamping [SOLVED]
In addition to @mkx post:
* MSS is only relevant for TCP. Most multiplayer games use UDP, and most of them also only send small packets (because smaller == better latency) and probably won't send anything approaching the MTU limit.
* Many ISP nowadays (all ISPs in my country) support RFC 4638. Which means you can have MTU 1500 with your PPPoE connection. You can try to increase the MTU of the underlying interface of the PPPoE interface (the etherX port or vlan) to 1508. Then on the property page of the pppoe-out interface, set both Max MTU and Max MRU to 1500. If you redial and see Actual MTU listed as 1500, then congratualtion RFC 4638 is supported by your ISP and you don't have to worry about MTU hacks anymore.
Now why the need for setting MTU 1508 for the ethernet/vlan interface underneath? It's actually not needed to have MTU=1500 on the pppoe-out interface, but due to a bug in the following point on RouterOS, it's needed:
* If you use PPPoE in RouterOS, and use the default PPP profile, then there are no needs to add the mangle rule to change MSS for IPv4, because it's already done for you. If you haven't changed the setting, then normally on the PPP profile that the pppoe-out connection uses (look at what currently listed here
then go to PPP -> Profiles and look at the corresponding profile). There is this setting which should already be on for the default profile:
But because of this setting, even if pppoe-outX already successfully has an MTU of 1500, RouterOS will still set MSS of the IPv4 TCP connections to only 1452 instead of 1460, unless you increase the MTU of the underlying ethernet interface to 1508. Then it will correcly set MSS to 1460. You can test both values at this page https://www.speedguide.net/analyzer.php. If everything works, you should see this:
* MSS is only relevant for TCP. Most multiplayer games use UDP, and most of them also only send small packets (because smaller == better latency) and probably won't send anything approaching the MTU limit.
* Many ISP nowadays (all ISPs in my country) support RFC 4638. Which means you can have MTU 1500 with your PPPoE connection. You can try to increase the MTU of the underlying interface of the PPPoE interface (the etherX port or vlan) to 1508. Then on the property page of the pppoe-out interface, set both Max MTU and Max MRU to 1500. If you redial and see Actual MTU listed as 1500, then congratualtion RFC 4638 is supported by your ISP and you don't have to worry about MTU hacks anymore.
Now why the need for setting MTU 1508 for the ethernet/vlan interface underneath? It's actually not needed to have MTU=1500 on the pppoe-out interface, but due to a bug in the following point on RouterOS, it's needed:
* If you use PPPoE in RouterOS, and use the default PPP profile, then there are no needs to add the mangle rule to change MSS for IPv4, because it's already done for you. If you haven't changed the setting, then normally on the PPP profile that the pppoe-out connection uses (look at what currently listed here
then go to PPP -> Profiles and look at the corresponding profile). There is this setting which should already be on for the default profile:
But because of this setting, even if pppoe-outX already successfully has an MTU of 1500, RouterOS will still set MSS of the IPv4 TCP connections to only 1452 instead of 1460, unless you increase the MTU of the underlying ethernet interface to 1508. Then it will correcly set MSS to 1460. You can test both values at this page https://www.speedguide.net/analyzer.php. If everything works, you should see this:
You do not have the required permissions to view the files attached to this post.
Re: Trying to understand the need for MSS Clamping
Thank-you both for taking the time to write such in-depth responses! I have a much better understanding now.
I just wanted to check the following:
1. If I need to set my vlan101 MTU to 1508, does that mean that I need to set my ether1 MTU to 1512? (1508+4 for VLAN) or keep it at 1508?
2. Do I need to adjust my L2 MTU values for ether1 (1514 -> 1526) and vlan101 (1522) to account for these MTU changes? It concerns me that these values are different to every other port on the bridge etc.
3. Should the MTU on my VDSL modem be set to 1500 or 1508?
I logged into my modem today and realised that on there too I specified an MTU of 1492 and it was automatically tagging VLAN 101 to "service" (vs "customer"). I have disabled tagging on my modem and created VLAN 101 (assigned to ether1) on my Mikrotik and set PPPoE to use vlan101 as the interface. Curiously even though the modem suggested it was a "service" VLAN, it woudn't work at all if I selected the "use service tag" box. I have also set the MTU on the modem to 1508.In addition to @mkx post:
* Many ISP nowadays (all ISPs in my country) support RFC 4638. Which means you can have MTU 1500 with your PPPoE connection. You can try to increase the MTU of the underlying interface of the PPPoE interface (the etherX port or vlan) to 1508. Then on the property page of the pppoe-out interface, set both Max MTU and Max MRU to 1500. If you redial and see Actual MTU listed as 1500, then congratualtion RFC 4638 is supported by your ISP and you don't have to worry about MTU hacks anymore.
I just wanted to check the following:
1. If I need to set my vlan101 MTU to 1508, does that mean that I need to set my ether1 MTU to 1512? (1508+4 for VLAN) or keep it at 1508?
2. Do I need to adjust my L2 MTU values for ether1 (1514 -> 1526) and vlan101 (1522) to account for these MTU changes? It concerns me that these values are different to every other port on the bridge etc.
3. Should the MTU on my VDSL modem be set to 1500 or 1508?
You do not have the required permissions to view the files attached to this post.
Re: Trying to understand the need for MSS Clamping
I just wanted to check the following:
1. If I need to set my vlan101 MTU to 1508, does that mean that I need to set my ether1 MTU to 1512? (1508+4 for VLAN) or keep it at 1508?
2. Do I need to adjust my L2 MTU values for ether1 (1514 -> 1526) and vlan101 (1522) to account for these MTU changes? It concerns me that these values are different to every other port on the bridge etc.
3. Should the MTU on my VDSL modem be set to 1500 or 1508?
You don't need to change the MTU of ether1 from the default of 1500. A few weeks ago, there were a bug with VLAN and MTU where back then you would need to set the MTU of ether1 to 1508 too, otherwise the MTU of vlan101 might be reset back to 1500 after a reboot, mentioned here:
viewtopic.php?p=1059444#p1058995
That bug seems to have been fixed now if you use the latest stable version 7.14.3. Now the MTU of ether1 can stay at 1500. You just need to make sure that the MTU value of 1508 for vlan101 is less than or equal to the L2MTU value on the column next to it (which should be the case). You also don't need to make the change on your modem. Like I wrote above the change needed on the ethernet interface directly underneath pppoe-outX (in this case vlan101 and MTU 1508) is only needed due to the bug(?) with the automatic MSS handling of the PPP profile. For the MTU value of the pppoe interface, the only requirement is that your ISP support RFC 4638.
You don't need to change L2MTU if its value is already above 1508. You can watch this video for explanations https://www.youtube.com/watch?reload=9&v=7a_z1jAdIME. And here is an illustration with the interfaces on my router. pppoe-out1 (MTU 1500) uses vlan1000 (MTU 1508). vlan1000 sits over the main bridge (MTU 1500) and sfp-sfpplus1 is the access port for it (also MTU 1500). L2MTU of the VLAN interfaces are 1510, which is 4 bytes less than 1514 of the ethernet interfaces (see video for explanations) but is still greater than 1508, so no adjustments are needed.
If the screenshot with the green text above is from your machine, then I think MTU 1500 is supported by your ISP and working
. To test if you use Windows run:Code: Select all
ping -f -l 1472 google.com
ping -6 -l 1452 google.com
if both commands succeed (no timeout or error message) then MTU 1500 works for both IPv4 (first command) as well as IPv6 (2nd command). For Linux, use
Code: Select all
ping -4 -M do -s 1472 -c 4 google.com
ping -6 -M do -s 1452 -c 4 google.com
You do not have the required permissions to view the files attached to this post.
Re: Trying to understand the need for MSS Clamping
Got it! Thank you. I've just updated my to 7.14.3 and have double checked with a few reboots and the vlan101 MTU stays at 1508 as expected.
You don't need to change the MTU of ether1 from the default of 1500. A few weeks ago, there were a bug with VLAN and MTU where back then you would need to set the MTU of ether1 to 1508 too, otherwise the MTU of vlan101 might be reset back to 1500 after a reboot, mentioned here:
viewtopic.php?p=1059444#p1058995
That bug seems to have been fixed now if you use the latest stable version 7.14.3. Now the MTU of ether1 can stay at 1500. You just need to make sure that the MTU value of 1508 for vlan101 is less than or equal to the L2MTU value on the column next to it (which should be the case). You also don't need to make the change on your modem. Like I wrote above the change needed on the ethernet interface directly underneath pppoe-outX (in this case vlan101 and MTU 1508) is only needed due to the bug(?) with the automatic MSS handling of the PPP profile. For the MTU value of the pppoe interface, the only requirement is that your ISP support RFC 4638.
This pretty much lines up with my config. Many thanks for confirmingYou don't need to change L2MTU if its value is already above 1508. You can watch this video for explanations https://www.youtube.com/watch?reload=9&v=7a_z1jAdIME. And here is an illustration with the interfaces on my router. pppoe-out1 (MTU 1500) uses vlan1000 (MTU 1508). vlan1000 sits over the main bridge (MTU 1500) and sfp-sfpplus1 is the access port for it (also MTU 1500). L2MTU of the VLAN interfaces are 1510, which is 4 bytes less than 1514 of the ethernet interfaces (see video for explanations) but is still greater than 1508, so no adjustments are needed.
It is indeed from my machine and working! It has also solved the issue I had with Helldivers 2 so I no longer need MSS Clamping rules applied which is fantastic.
Thanks so much for taking the time to walk me through it
Re: Trying to understand the need for MSS Clamping
here is script for proper and faster CCR internet. but YMMV.
Code: Select all
/ip firewall mangle
add action=change-mss chain=postrouting comment="536 (syn)" new-mss=536 protocol=tcp tcp-flags=syn tcp-mss=!537-1460
add action=change-mss chain=postrouting comment="536 (ack)" new-mss=536 protocol=tcp tcp-flags=syn,ack tcp-mss=!537-1460
add action=change-mss chain=forward comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn
add action=change-mss chain=forward comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn,ack
add action=change-mss chain=output comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn
add action=change-mss chain=output comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn,ack
add action=change-mss chain=postrouting comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn
add action=change-mss chain=postrouting comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn,ack
Code: Select all
/ipv6 firewall mangle
add action=change-mss chain=postrouting comment="1220 (syn)" new-mss=1220 protocol=tcp tcp-flags=syn tcp-mss=!1221-1440
add action=change-mss chain=postrouting comment="1220 (ack)" new-mss=1220 protocol=tcp tcp-flags=syn,ack tcp-mss=!1221-1440
add action=change-mss chain=forward comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn
add action=change-mss chain=forward comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn,ack
add action=change-mss chain=output comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn
add action=change-mss chain=output comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn,ack
add action=change-mss chain=postrouting comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn
add action=change-mss chain=postrouting comment="clamp action" new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn,ack
Last edited by volkirik on Wed Feb 12, 2025 10:35 am, edited 3 times in total.
-
-
ColinM9991
newbie
- Posts: 33
- Joined:
Re: Trying to understand the need for MSS Clamping
Massive thank you to mmotti and CGGXANNX for documenting the problem and the solution. I too was having issues with Helldivers and couldn't figure it out until I decided to search for Mikrotik specific threads.
I did previously try to increase the MTU of my PPPoE interface but was missing some steps, so I thought my ISP didn't support RFC 4638 but they do.
All is working well now with an MTU of 1500 on the PPPoE-out interface. Hopefully this thread can also help others.
I did previously try to increase the MTU of my PPPoE interface but was missing some steps, so I thought my ISP didn't support RFC 4638 but they do.
All is working well now with an MTU of 1500 on the PPPoE-out interface. Hopefully this thread can also help others.
Re: Trying to understand the need for MSS Clamping
SHARING THESE FOR FOLLOWERS;
how to set IPV6 MTU properly (example=1420 bytes MTU);
How to set IPv4 MTU properly;
firstly convert decimal to hex; (example=1492 bytes MTU);
(source= https://www.rapidtables.com/convert/num ... tml?x=1492)
You will see that under Linux/BSD/Android MTU is working properly now.
For windows they say that DHCP client doesnt ask for MTU.
how to set IPV6 MTU properly (example=1420 bytes MTU);
Code: Select all
/ipv6 nd
set [ find default=yes ] dns=<PUT_YOUR_ROUTER_IPV6_HERE> hop-limit=64 managed-address-configuration=yes mtu=1420 other-configuration=yes ra-delay=0s ra-interval=20m50s-30m
/ipv6 nd prefix default
set preferred-lifetime=4w3d valid-lifetime=4w3dfirstly convert decimal to hex; (example=1492 bytes MTU);
(source= https://www.rapidtables.com/convert/num ... tml?x=1492)
Code: Select all
/ip dhcp-server option
add code=26 name=mtu value=0x05D4
/ip dhcp-server option sets
add name=mtu options=mtu
/ip dhcp-server
add address-pool=dhcp always-broadcast=yes dhcp-option-set=mtu interface=bridge-LAN lease-time=4w3d name=dhcp1
/ip dhcp-server network
add address=192.168.88.0/24 dns-server=192.168.88.1 gateway=192.168.88.1 netmask=24For windows they say that DHCP client doesnt ask for MTU.