Small Pings Work, Large Transfers Stall: Finding an MTU Mismatch

A successful small ping can create false confidence. The address is reachable, the link is up and the first application connection opens. Then a backup stalls, a file transfer repeatedly retries, or a device sends short status messages while larger messages disappear. One possible explanation is an MTU mismatch somewhere along the actual traffic path.

Jumbo-frame support on a switch does not settle that question. The endpoints, intervening Ethernet ports, routed interfaces and any tunnel all impose limits. A useful investigation identifies which size fails, in which direction and at which boundary, before changing a network-wide setting.

Start by agreeing on what the number includes

An IP MTU describes the largest IP packet carried without fragmentation on that link. An Ethernet frame also has link-layer fields around that packet. Vendor settings do not always count these bytes in the same way: a maximum frame size may include or exclude particular headers or the frame check sequence. VLAN tagging adds further link-layer overhead.

Consequently, an endpoint configured for a 9000-byte IP MTU and a switch described as supporting “9K frames” are not automatically an approved pair. Obtain the exact byte definition and maximum supported frame size for the selected hardware and firmware. Cisco's Catalyst MTU troubleshooting guide illustrates why platform-specific interpretation matters; its commands and limits should not be copied onto another manufacturer's switch.

A procurement requirement should state the intended IP MTU, VLAN encapsulation and forwarding path. “Jumbo supported” leaves too much room for two suppliers to answer different questions with the same word.

The smallest usable part of the path sets the limit

Imagine two storage hosts configured for 9000 bytes, connected through switches capable of carrying the associated Ethernet frames. Their local transfer works. A second destination sits behind a routed link whose IP MTU is 1500 bytes. The first test says nothing about that second path.

A tunnel can introduce another boundary because its outer headers consume space on the underlying network. A backup route may also differ from the normal route. Testing only a direct connection or only the preferred uplink can therefore miss the condition that appears during failover.

The illustration shows a routed bottleneck, where protocol feedback may tell the sender to reduce its packet size. An Ethernet switch dropping an oversized frame is a different case: do not expect that switch to generate an IP “packet too big” response merely because a frame exceeded its forwarding limit.

For IPv4, RFC 1191 describes path MTU discovery using the Don't Fragment mechanism and ICMP feedback. For IPv6, RFC 8201 describes Packet Too Big feedback; IPv6 routers do not fragment a packet to squeeze it through a smaller next link. Filtering the necessary feedback can leave small exchanges working while larger transfers fail. Security policy should handle the required control messages deliberately rather than treating all ICMP as disposable.

Build a test that changes packet size, not five other variables

Choose a source and destination that reproduce the fault. Record their interfaces, addresses, VLANs, route and current MTU. Preserve the application configuration and traffic conditions while varying only packet size. Use the operating system's documented test options, including its treatment of fragmentation and payload length; a utility's “size” argument may describe its payload rather than the complete IP packet.

Start below the suspected boundary, increase in controlled steps, and narrow the interval around the first repeatable failure. Test both directions. Save the command, operating system version, requested size and observed result so another engineer can repeat it. A screenshot saying “ping successful” without those details cannot establish jumbo-frame compatibility.

A failed probe alone is not a diagnosis. Some devices limit diagnostic responses. Correlate the probe with interface discard counters, a suitable packet capture and the failing application. Keep the capture point and its own maximum frame support in the record.

Avoid three misleading fixes

Increasing every switch limit without checking the hosts. This may allow larger Ethernet frames through, but it does not make an endpoint transmit the intended size or repair a routed MTU boundary. It can also introduce a change across equipment that was previously stable.

Reducing one endpoint and declaring the problem solved. A lower MTU can be a useful controlled workaround. Document the reason, quantify the application's result and verify the reverse direction. Otherwise the next replacement host may restore the original setting and recreate the incident.

Using a single throughput number as proof. A workload may happen to use small segments, follow a different route or exercise only one direction. Record the transferred data, packet sizes, duration and application result. The relevant question is whether the intended workload works reliably, including recovery and alternate paths.

There is also no general rule that larger frames improve every industrial network. Small cyclic messages may gain little from a larger limit. A change justified by bulk transfer efficiency should be evaluated alongside the latency and coexistence requirements of the other applications sharing those links.

Make the acceptance criterion specific enough to repeat

For a new installation, document the endpoint IP MTU and the required Ethernet forwarding size separately. List tagged links, routed boundaries and tunnels, then test the normal and backup paths. Include a sustained application transfer and check error and discard counters before and after it.

An effective result might read: “This host pair completed the defined transfer using the agreed MTU over both documented paths, with the recorded encapsulation and firmware versions.” It should not become “the entire network supports jumbo frames” unless the evidence actually covers the entire network.

When discussing a TODAHIKA managed industrial switch, ask for the exact order code's frame-size definition, configuration scope and restart requirements. A family-level feature list is a starting point for selection. The final answer is a consistent path and a repeatable application test, with enough detail to survive a future router, tunnel or spare-switch change.