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
In a nutshell
  • 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.

Clientsends large packetcrossesSwitchsmaller L2MTUdrops frameServernever receives it

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

CauseWhat happens
Mismatched MTU on two ends of a linkLarge packets are dropped by the side with the smaller limit
Too small L2MTU on a switch portTagged or jumbo frames are dropped
Tunnel or PPPoE overheadThe inner packet no longer fits in the outer frame
ICMP blocked by a firewallPath MTU discovery cannot work
VLAN tag or QinQ tags on a port with no spare roomFull 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.

  1. Make the MTU and L2MTU consistent on every device on the path.
  2. Lower the MTU at the edge so packets are small enough everywhere.
  3. 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.

Exam tip

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-mss fixes TCP on routed paths.
Watch out

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-mss with clamp-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.