MTU · Topic 3 of 3
Potential MTU Issues
Find and fix common MTU problems on RouterOS: silent drops, path MTU discovery failures, MSS clamping, tunnel overhead and OSPF MTU mismatch.
- 4 min
- MTU faults show as small packets working and large packets failing.
- Bridges and switches drop oversized frames without telling the sender.
- Path MTU discovery needs ICMP messages to reach the sender.
What it is
MTU problems are faults where small packets work and large packets vanish.
They appear when two points use different size limits and nothing along the path reports it clearly. The symptoms look like application faults, not network faults.
Typical signs are a website that loads its text but hangs on images, a login that stalls after the handshake, or an SSH session that freezes when a long output appears.
How it works
You find the problem by testing sizes, then fix the mismatch or reduce the packet size.
Why it fails quietly
Three behaviours hide the cause.
- A bridge or switch cannot fragment, and it sends no error.
- A router that cannot fragment a packet with the do not fragment bit set should send an ICMP message back, but firewalls often block it.
- Some hosts then keep sending large packets that never arrive.
The mechanism that lets a host discover the right size is path MTU discovery. It depends on the ICMP message reaching the sender. If a firewall drops that message, the discovery fails, and the connection stalls.
Finding the limit
Use ping with the do-not-fragment option and walk the size up and down.
/ping 203.0.113.10 size=1500 do-not-fragment count=3
/ping 203.0.113.10 size=1400 do-not-fragment count=3
In RouterOS the ping size is the whole IP packet, so the largest size that passes is the usable MTU of the path. A ping tool that counts only the data needs 28 bytes of header added to give the same number. Test each segment in turn to find the hop with the smaller value.
Common causes
| Cause | What happens |
|---|---|
| Mismatched MTU on two ends of a link | Large packets are dropped by the side with the smaller limit |
| Too small L2MTU on a switch port | Tagged or jumbo frames are dropped |
| Tunnel or PPPoE overhead | The inner packet no longer fits in the outer frame |
| ICMP blocked by a firewall | Path MTU discovery cannot work |
| VLAN tag or QinQ tags on a port with no spare room | Full size frames are dropped |
OSPF and MTU
Some protocols check the MTU when they form a neighbour relationship.
OSPF compares the interface MTU in its database description packets. If the two routers disagree, the adjacency can get stuck while exchanging the database, even though hellos work. If OSPF stalls after a link or tunnel change, compare the MTU on both ends.
Fixing the problem
Choose the fix that fits the situation.
- Make the MTU and L2MTU consistent on every device on the path.
- Lower the MTU at the edge so packets are small enough everywhere.
- Clamp the TCP segment size, so hosts never build packets that are too large.
The third option is common on tunnels and PPPoE links. A mangle rule changes the maximum segment size in TCP handshakes.
/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu out-interface=pppoe-out1
This rule only helps TCP, and only for traffic that is routed. Bridged traffic is not changed by it.
If only TCP stalls and small pings work, suspect an MTU problem before you suspect the application.
Checking the interfaces
Compare the values on every interface of the path.
/interface print detail
/interface vlan print detail
/interface bridge print detail
Look for any interface whose mtu or l2mtu is lower than the others. The odd one out is usually the cause.
What to remember for the exam
Seven facts cover most questions on this topic.
- MTU faults show as small packets working and large packets failing.
- Bridges and switches drop oversized frames without telling the sender.
- Path MTU discovery needs ICMP messages to reach the sender.
- The largest working RouterOS ping size, which includes the headers, gives the path MTU.
- Tunnels, PPPoE and VLAN tags add overhead that lowers the usable size.
- OSPF neighbours can stick when their interface MTU values differ.
- MSS clamping with
change-mssfixes TCP on routed paths.
Blocking all ICMP on a firewall breaks path MTU discovery, and produces exactly the stalls that this topic describes.
Common mistakes
These four mistakes appear often.
Blaming the application. If a connection works for small packets only, test the path MTU first.
Blocking all ICMP. The error messages that tell hosts to send smaller packets never arrive.
Forgetting overhead. Tunnels and tags reduce the room for payload on the path.
Expecting MSS clamping to fix everything. It helps TCP traffic only, and not bridged or UDP traffic.
Check yourself
Work through these three questions.
What is the typical symptom of an MTU problem?
Small packets work while large packets are lost, so connections hang after the handshake.
Why can a firewall make path MTU discovery fail?
It blocks the ICMP messages that tell the sender to use smaller packets.
What does an MSS clamp do?
It lowers the TCP segment size in the handshake so packets fit the path, using
change-msswithclamp-to-pmtu.
Topic 3 of 3 in MTU
Test yourself on MTU
The full MikroTik MTCSWE question bank has 484 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by MikroTik. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.