MTU is the largest amount of data that fits in one packet. On Ethernet that is 1500 bytes, the same the world over because everything is built on it. Change something, or have your ISP change it for you, and you get a fault that is hard to recognise: small things work, large things do not. Ping succeeds, a web page loads halfway, a file transfer stalls.
Alongside it there is L2 MTU: the same frame, measured without the MAC headers. A four byte VLAN tag has to fit on top of it. A port with l2mtu=9000 and mtu=9000 therefore drops every full-size tagged packet. That distinction is why this chapter exists.
MTU on all ports
In advanced, under Bridge and ports, sits the field MTU on all ports (jumbo frames). Leaving it empty means the default 1500, and for almost everyone that is the right answer. Enter 9000 and you get jumbo frames on every wired port. That pays off in a storage network or between virtualisation hosts, where large blocks cross the wire. For ordinary office traffic or internet it gains you nothing and only costs you trouble as soon as one device in the path does not play along.
How the script sets it on the ports
How far a port's L2 MTU goes differs per model and even per port: 2026 on a hEX, 9578 on an RB4011. The catalogue in the configurator does not know that, and the browser cannot see your hardware. So the script asks the router itself. For each wired port it writes a line that:
- reads
max-l2mtuof that port; - sets the L2 MTU to that maximum;
- sets the MTU to what you entered, unless that plus four bytes for a VLAN tag no longer fits inside the maximum. The MTU is then lowered to the maximum minus four, and the script writes a warning into the router's log:
genconf: ether3 carries MTU 2022 at most (max-l2mtu 2026).
A port that cannot change its L2 MTU keeps it and only gets the MTU. Every line sits inside error handling, so one stubborn port does not break the rest of the script. After pasting, look in /log print for lines mentioning genconf, and check with /interface ethernet print detail what actually ended up on the ports.
The bridge MTU
Below that sits a separate field for the bridge MTU. Leaving it empty is best: the bridge then follows its ports. Set it higher than the ports can handle and the tool warns you, rightly so: the bridge hands packets to its ports, and the ports drop everything larger than their own MTU. So raise the ports first and the bridge after, or leave the bridge empty.
A cable between two devices in a site
If you work with several devices and have drawn cables on the network board, the configurator checks the MTU at both ends of every cable. When they differ you get a warning naming the two devices, the two ports and the two values: packets larger than the smaller of the two do not get through and disappear without an error. That last part is the nasty bit: no ICMP comes back for you to see, the traffic is simply gone.
The tool also looks at groups of devices joined by cables. If those use different MTUs on their bridge it says so too, listing the devices per value. Within one network the MTU has to be the same everywhere.
An uplink with its own MTU counts: if a WAN port was given an MTU in the WAN section, the check uses that value for that port instead of the general port MTU.
PPPoE and 1492
PPPoE puts your packets in an extra envelope of eight bytes. On a 1500 byte line that leaves 1492, which is the value that goes with nearly every DSL or fibre connection using PPPoE. Leave the MTU field on your uplink empty and RouterOS handles it itself.
Some providers support RFC 4638, also called baby jumbo frames: the line then carries 1508 bytes so that a full 1500 is left after the PPPoE envelope. If you enter an MTU above 1492 on a PPPoE uplink, the script raises the MTU on the WAN port, and on the VLAN if there is one, by eight bytes. You get a note explaining what happens. If your provider does not support it, this will not work and you leave the field empty or set 1492. See also Provider presets, because for the well known providers this is already filled in.
MSS clamping
When the MTU towards the internet is below 1500, through PPPoE or through a lower WAN MTU you entered yourself, the switch clamp TCP MSS on PPPoE/tunnels appears. It is on, and you should leave it on.
In theory two computers work out the right packet size by themselves, through path MTU discovery. In practice many servers and firewalls block the ICMP messages that relies on, and then a web page hangs halfway through loading. MSS clamping solves it by lowering the agreed packet size while each TCP connection is being set up, down to what really fits. The script writes one rule for it in /ip firewall mangle: chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu out-interface-list=WAN. Switch it off while it is needed and the tool warns you.
That rule acts on the WAN list. Traffic that only crosses a tunnel and never passes WAN falls outside it. If you have a tunnel with a small MTU between two locations, add a mangle rule of your own on that tunnel after pasting.
Tunnels
Every tunnel sticks headers on your packets, so less is left inside. The configurator points out the cases where that goes wrong:
- WireGuard uses MTU 1420 by default. That fits over a PPPoE line of 1492, but not when a peer connects over IPv6; then 1412 is needed, on the interface and in the client configuration. See WireGuard.
- EoIP in a bridge is given MTU 1500 by the tool. The tunnel packets are fragmented along the way, but full Ethernet frames do get through. Without it the bridge would drop its MTU to 1458 and lose every full-size packet.
- VXLAN carries 1500 byte frames with 50 bytes on top, so the path to the other end has to carry 1550. Over plain internet that is 1500, and with the DF flag set those packets are dropped. The tool warns about this as long as your port MTU is below 1550.
See Site to site tunnels for the whole picture.
When it goes wrong
- Small things work, large things do not. That is the signature pattern. Test with
/ping 1.1.1.1 size=1472 do-not-fragment: if that fails and a smaller size succeeds, your MTU limit lies in between. Subtract 28 bytes to get to the IP MTU. - One device stops working after enabling jumbo frames. Not every device can do 9000. Put the MTU back to 1500 on all ports and work up from there.
- Tagged traffic disappears, untagged does not. The VLAN tag no longer fits. Look in the router's log for the
genconflines about max-l2mtu. - Web pages load halfway. Check that MSS clamping is on and that the rule is in
/ip firewall mangle.
Read on: Bridge and ports for the ports themselves, WAN and internet for the uplink, and Multiple devices for the checks across a whole site.