I am using hAp Ac (OS version 6.47.1) which receives internet from a FTTH PPPoE connection. On the FTTH modem the MTU is set as 1492. I have also set the MTU in hAP Ac as 1492. Apart from the option “MTU” I also see an option like “ L2 MTU”. Do I need to set that too? Or just leave it as it is? And Do I need to set the MTU on every interface as seen in first image? (I have found that the MTU size which doesn’t cause packet loss is 1464 by using the ping command “ping www.google.com -f -l 1492 and the results are as given below.)
L2 MTU should, IMHO, be a read-only attribute and should thus be always set to maximum supported by underlying hardware (e.g. switch chip). That is: if switch in LAN doesn’t support frames large enough, it might drop many frames. And LAN devices usually don’t have any mechanism to detect correct value and adapt.
MTU (the one without L2) is L3 (IP, IPv6) setting and makes sure that IP stack (either end device or router) knows maximum packet size to transmit. It naturally has to be lower (or equal) to L2 MTU. And additionally, it has to be the same on all devices in the same subnet. E.g. if one device would have enabled large MTU and another one standard (1500 bytes), then packets from device 1 to device 2 would be dropped by device 2 while packets from device 2 to device 1 would get through just fine.
Router is somehow special … it has multiple L3 interfaces (at least LAN and WAN) and MTUs can be different. In your case LAN interface would normally have MTU 1500 while PPPoE interface has 1492. When router receives 1500 byte packet from LAN and determines it has to push it out through PPPoE interface, it will normally perform packet fragmentation: it will send out two packets, one with size equal to MTU and the other one with the rest of payload (which is not economical due to considerable IP overhead). It will (optionally) send certain ICMP message back to original sender informing that sender about fragmentation needed which allows sender to perform “path MTU discovery” (PMTUD) … next time it will transmit smaller packet and if it doesn’t receive complaint, it will keep sending packets with that size.
So what you did is fine as long as all of your LAN devices have MTU set to 1492 (which I kindof doubt). But usually its just fine to leave MTU on LAN set to 1500 bytes and let PMTUD do its job.
And a comment on your ping tests: the packet size set on command line is payload size … IP stack then adds IP headers … and packet with headers has to fit MTU. The non-working test says that packets had DF set. DF stands for “Don’t Fragment” and if that’s set on IP packet, routers won’t fragment it, they will rather drop it and send ICMP message about it. So your command is great to see what’s realistic PMTU (but you have to add IP overhead and with ICMP messages that’s 28 bytes - 20 bytes for IP and 8 bytes for ICMP).
It is always advisable to try to get the PPPoE MTU to 1500 because that solves so many problems.
When the ISP supports RFC4638 (ask them, and if they don’t submit a request for them to to so) you can set the MTU of the PPPoE interface to 1500 and it will work.
(when they do not support it, it will fall back to 1480 and your setting of 1492 is better)
Aside from the MTU 1492 setting on the internet-facing interface, which indeed is a good idea, you can also do some other things to make it work better:
- do TCP MSS clamping using a rule like this:
/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes \
protocol=tcp tcp-flags=syn
Same for IPv6 when you have it.
- Also in IPv6 ND (default entry) set the MTU to 1492, that is the MTU advertised to users of IPv6 SLAAC.
But really, solving the problem at its source (the PPPoE with MTU 1492) is the best.
The ISP guys are just dumb heads. I had to run around them just to get a port open for me. there is no way I can convince them to set MTU @1500. It’s a lost case. Thank you very much for the “TCP MSS clamping” rule. It really solved my issues with certain websites.