Every network interface is set with an MTU (Maximum Transmission Unit) value that defines the byte size of the largest protocol data unit that is allowed to pass.
So what happens when a frame or packet is larger in size than the MTU value of the interface?
It depends on whether the interface is switched (layer 2) or routed (layer 3), and, in the case of a routed interface, whether the IPv4 packet carried by the Ethernet frame has the Don’t Fragment (DF) bit set or not. The DF bit tells a router whether or not it is allowed to fragment the packet into smaller units if its size is larger than the interface’s MTU value.
If the interface is layer 2, it will switch frames smaller or equal to its MTU value and it will silently discard larger ones.
If the interface is layer 3, it will forward packets whose size is within the IP MTU value, it will fragment packets larger than the MTU size and with the DF unset, and it will drop IP packets that have the DF bit set. Packets dropped will be signaled to the sender via the ICMP Fragmentation Required message (Type 3, Code 4).
| Packet Size | Interface MTU | DF option (IP header) |
Layer 2 interface (switched) | Layer 3 interface (routed) |
| <= 1500 | 1500 | 0 (unset) | Pass | Pass |
| <= 1500 | 1500 | 1 (set) | Pass | Pass |
| >= 1500 | 1500 | 0 (unset) | Discard | Fragment |
| >= 1500 | 1500 | 1 (set) | Discard | Discard and Notify |
While everybody expects the MTU value to govern both ingress and egress traffic, some routers apply the MTU restrictions only in the egress direction. That means, such routers will drop only in the egress direction all DF-set packets that are larger in size than the IP MTU of the interface.
Let me prove this behavior with the following lab scenario.
I connected two NetBeez agents to two separate router interfaces that were configured with the default MTU value of 1500 bytes:
- Agent A sits on a subnet where the default gateway has the interface MTU set to 1500 bytes (Interface Fa0/0.10)
- Agent B sits on a subnet where the default gateway has the interface MTU set to 1500 bytes (Interface Fa0/0.20)
As a way to test and validate the MTU settings of the interface, I configured each agent with the following tests:
- On agent A: An extended MTU PING test to agent B with 1472 bytes of ICMP payload and the DF bit set;
- On Agent B: An extended MTU PING test to agent A with 1472 bytes of ICMP payload and the DF bit set.
The packets generated by the extended MTU PING tests I pushed to my agents will look like this:
It is not surprising that these tests are successful because the total size of the packets conforms to the IP MTU of the router’s interfaces, as NetBeez confirms on the real-time PING graph:
Then I reduce the IP MTU interface to 1300 bytes on FastEthernet 0/0.20, which corresponds to the default gateway of Agent B with the following command:
After this change, the test network I configured looks like this:
As a result, as you can see from the graphs below, only the extended MTU PING test from agent A to agent B fails and not vice versa:
This confirms that agent B can still send 1500 byte packets to agent A even though the IP MTU of its default gateway is set to 1300 bytes.
MTU and Protocols overhead
Each data-link or network layer protocol uses a certain number of overhead that reduces the number of bytes available to carry the payload. That means, if you (or your service provider) don’t properly configure the MTU value of the network interfaces along the path, you might affect your applications. Here are some examples of encapsulation overhead:
- VLAN tagging (802.1q) adds 4 bytes to the frame, that means a 1514 bytes frame (without the FCS field) will increase its size to 1518;
- MPLS can add up to 12 additional bytes to the frames in the case where RSVP with Traffic Engineering and Fast Re-Route is enabled;
An engineer can use PING or Traceroute to discover and monitor the amount of payload that your network links can carry from one endpoint to another.
Traceroute for path MTU detection and troubleshooting
Traceroute can be used to measure the path MTU. The discovery will be affected by two factors:
- MTU value of the interface that the probe is using;
- MTU value of the interfaces traversed along the route to destination.
On both cases the principle is very simple: When your probe packets traverse a link with small MTU value, from that point after, your probe cannot detect links with larger MTU.
Here below I wanted to prove this behavior by running a traceroute test in NetBeez. I set the interface MTU of the third router along the path to 1200 bytes (hop 3). As you can notice, any link behind the third hop will appear with an MTU 1200 bytes.
I hope this post was beneficial to helping you learn more about MTU path detection and what you should keep in mind when troubleshooting this type of problems. If you want to test NetBeez to solve MTU issues, just request a demo.
