What Is MTU? Understand Packet Size and Network Performance

MTU stands for Maximum Transmission Unit. It describes the largest Internet Protocol packet that a network interface or link can carry in a single transmission without dividing it into smaller fragments. Understanding what is MTU can help you diagnose slow websites, failed VPN connections, interrupted downloads and other unusual network problems.

Every packet contains data plus protocol headers that help devices route and process it. When a packet exceeds the allowed MTU, it may need to be fragmented, reduced by the sender or discarded. The exact result depends on the IP version, packet settings, network equipment and whether Path MTU Discovery is functioning correctly.

A larger MTU can carry more useful data in each packet, potentially reducing the number of packets and headers needed for a transfer. However, setting the MTU higher than the path can support may create packet loss or connectivity failures. A smaller MTU may work reliably but can introduce unnecessary overhead and reduce network efficiency.

This guide explains MTU size, common values, packet fragmentation, TCP MSS and Path MTU Discovery. It also covers how to test MTU on Windows and Linux, how VPNs affect packet size and how to fix MTU mismatch problems. The aim is to help you choose a reliable setting rather than assuming the largest number is always best.

What Does MTU Mean?

Maximum Transmission Unit is the size, measured in bytes, of the largest IP packet that can cross a particular link. The measurement includes the IP header and its payload but normally excludes Ethernet headers and other link-layer framing. This distinction matters because the complete frame transmitted over a cable can be larger than the stated IP MTU.

For example, an Ethernet interface with an MTU of 1500 can carry an IP packet containing up to 1500 bytes. Part of that space is occupied by the IPv4 or IPv6 header, while the remaining space carries TCP, UDP and application information. The amount available to the application is therefore smaller than the interface MTU.

The MTU is applied separately to each interface or link. A laptop’s Ethernet connection may use one value, while its Wi-Fi adapter, virtual private network and tunnel interfaces use different values. Microsoft documentation confirms that a different MTU can be configured for each interface used by the TCP/IP stack.

MTU is not a measurement of internet speed, bandwidth or latency. It is a packet-size limit that can influence efficiency and reliability. Two connections can have the same MTU but very different speeds, while two connections with similar bandwidth may behave differently because of tunnels, protocol overhead or an incorrect packet-size configuration.

How MTU Works

When an application sends information, the operating system divides that information into transport-layer segments or datagrams. TCP or UDP adds its own header, after which the IP layer adds an IPv4 or IPv6 header. The resulting IP packet must be small enough to fit within the outgoing network interface’s MTU.

The packet may cross several links before reaching its destination. Each link can support a different maximum packet size, so a packet accepted by the first interface may be too large for another link farther along the route. The smallest supported MTU in the complete route determines the usable Path MTU.

When the packet is small enough, routers forward it normally. When it is too large, IPv4 may permit a router to fragment it unless fragmentation has been prohibited. IPv6 routers do not fragment packets in transit, so the sender must reduce the packet size after receiving appropriate network feedback.

Modern systems try to discover the usable limit automatically rather than fragmenting every oversized packet. Path MTU Discovery uses network feedback or controlled probes to determine how large a packet can travel successfully. The sender then adjusts future packet sizes to stay within the discovered limit.

Common MTU Sizes

A standard Ethernet network commonly uses an IP MTU of 1500 bytes. The original specification for carrying IP over Ethernet identifies 1500 bytes as the maximum IP datagram size transmitted within a standard Ethernet data field. This value remains the most common default for ordinary wired and wireless networks.

PPPoE connections traditionally use an MTU of 1492 bytes because the Point-to-Point Protocol over Ethernet header requires eight bytes of additional space. Some modern PPPoE environments support a larger maximum receive unit, but 1492 remains a common value when the underlying Ethernet frame size is limited.

IPv6 requires every link to support an MTU of at least 1280 bytes. This is a minimum requirement rather than the recommended value for every IPv6 network. IPv6 devices can use larger packets when the route permits them, and Path MTU Discovery helps a sender take advantage of paths supporting more than the minimum.

Jumbo-frame networks often use an MTU near 9000 bytes, although jumbo frame size is not universally standardised across all equipment. Every switch, server, network card and intermediate device in the intended local path must support the chosen size. Linux driver documentation provides 9000 as a common example for enabling jumbo frames.

MTU vs Packet Size

MTU and packet size are closely related but are not always interchangeable. MTU defines the largest IP packet allowed on an interface or link, while an actual packet may be any size up to that limit. Most network traffic includes a mixture of small control packets and larger packets carrying application data.

An IP packet includes an IP header and payload. For IPv4, the basic header is normally 20 bytes without options, while the basic IPv6 header is 40 bytes. Transport headers and application information sit inside the IP payload, reducing the amount of space available for the user’s actual data.

A network frame operates below the IP layer and contains additional headers and trailers. On Ethernet, the frame carries the IP packet along with Ethernet addressing and error-checking information. Linux networking documentation specifically notes that the network-interface MTU excludes link-layer protocol overhead.

This is why an Ethernet interface can report an MTU of 1500 even though more than 1500 bytes are physically transmitted for the complete frame. When diagnosing MTU issues, confirm whether a tool or vendor is discussing the IP packet, transport payload or complete link-layer frame before comparing its values.

MTU vs TCP MSS

TCP MSS stands for Maximum Segment Size. It describes the largest amount of TCP data an endpoint is prepared to receive in one segment. Unlike MTU, the MSS does not include the IP header or TCP header, making it smaller than the network interface’s MTU.

On a basic IPv4 connection with a 1500-byte MTU, the commonly calculated MSS is 1460 bytes. The calculation subtracts a 20-byte IPv4 header and a 20-byte TCP header. TCP options or additional encapsulation can increase header overhead, so the actual amount of application data carried may be lower.

For basic IPv6 with a 1500-byte MTU, the corresponding calculation gives an MSS of 1440 bytes because the IPv6 header is 40 bytes. Extension headers, TCP options and tunnel overhead can reduce the effective amount further. These simplified values are useful starting points rather than guarantees for every packet.

TCP endpoints advertise MSS values during connection establishment so each side can avoid sending segments larger than the other endpoint can accept. MSS clamping is sometimes used on routers or VPN gateways to reduce TCP segment size when Path MTU Discovery is unreliable or encapsulation creates a lower effective MTU.

What Is Path MTU?

Path MTU is the smallest link MTU found anywhere between a source and destination. A local interface may support 1500-byte IP packets, but the usable Path MTU could be 1492, 1400 or another value because traffic passes through PPPoE, a VPN, a tunnel or another lower-MTU link.

Path MTU can also change over time because internet routes are dynamic. If a router or link fails, traffic may follow a different route containing another packet-size limit. Systems should not assume that a previously discovered value will remain correct forever, particularly across mobile, cloud and internet-based connections.

IPv4 Path MTU Discovery is defined by RFC 1191. The sender uses packets that should not be fragmented and reacts when a router reports that fragmentation would be required. The feedback allows the sender to lower its packet size according to the restrictive link discovered along the route.

IPv6 uses ICMPv6 Packet Too Big messages to report the limiting next-hop MTU. RFC 8201 defines the standard IPv6 discovery process and explains that the Path MTU equals the lowest link MTU in the route. Blocking the required ICMPv6 messages can therefore cause serious connectivity problems.

How Path MTU Discovery Works

The sender begins with an estimated packet size, often based on the outgoing interface. It transmits packets without allowing inappropriate in-path fragmentation. When every link supports the size, the packets reach the destination and the sender can continue using that value.

When an IPv4 router cannot forward a packet that has the Don’t Fragment setting, it can return an ICMP message indicating that fragmentation was needed. For IPv6, an intermediate router sends an ICMPv6 Packet Too Big message. The feedback can contain the next-hop MTU that caused the problem.

The sender reduces its effective packet size and tries again. It may cache the discovered value for the destination so later packets avoid the same failure. Because routes can change, discovery mechanisms may periodically reconsider or probe the path rather than treating one result as permanent.

Packetization Layer Path MTU Discovery provides another approach that does not rely entirely on receiving ICMP feedback. The transport or application sends controlled probe packets and confirms whether they reached the destination. Current IETF guidance describes PLPMTUD as more robust where traditional Packet Too Big messages may be lost or blocked.

IPv4 Fragmentation

IPv4 allows a packet to be divided into smaller fragments when it cannot fit across the next link. The receiving endpoint reassembles those pieces into the original packet. Fragmentation can occur at the sending device and, under traditional IPv4 behaviour, at an intermediate router unless the Don’t Fragment flag prevents it.

Each fragment requires its own IP header and must be routed independently. If one fragment is lost, the original packet cannot be fully reassembled, potentially forcing the transport protocol to retransmit the data. The additional packets and processing can reduce efficiency and increase the impact of ordinary packet loss.

Fragments may also be handled inconsistently by firewalls, tunnels, load balancers and security systems. Some network devices discard fragments or cannot inspect them as effectively as complete packets. The IETF describes IP fragmentation as fragile and recommends that applications avoid depending on it whenever possible.

Path MTU Discovery helps IPv4 senders avoid fragmentation by choosing a packet size supported from end to end. When PMTUD fails, administrators may reduce the interface MTU, adjust a tunnel or clamp TCP MSS. The correct response is to identify the restrictive path rather than reducing every device blindly.

IPv6 Fragmentation

IPv6 routers do not fragment oversized packets while forwarding them. When a router encounters a packet larger than the next link supports, it discards the packet and returns an ICMPv6 Packet Too Big message. The original sender is then responsible for transmitting smaller packets.

A source device can use an IPv6 Fragment extension header when fragmentation is required, but the fragments are created by the sender rather than an intermediate router. This design moves packet-size responsibility toward endpoints and makes correct Path MTU Discovery particularly important for IPv6 communication.

Every IPv6 link must support packets of at least 1280 bytes. A minimal implementation can restrict its outgoing packet size to that value, but doing so may waste capacity when the actual path supports larger packets. RFC 8201 notes that using unnecessarily small packets can reduce throughput and waste network resources.

Firewalls must not block all ICMPv6 traffic indiscriminately. Packet Too Big messages are essential for discovering a smaller Path MTU. A connection may complete its initial TCP handshake successfully but then appear to freeze when larger data packets are discarded and the sender never receives the required feedback.

Why MTU Affects Performance

Larger packets can carry more application information relative to the number of protocol headers. Sending one large packet may require less processing than sending the same amount of data through several smaller packets. This can improve efficiency on reliable networks with equipment designed to support the larger size.

Smaller packets increase the number of headers, packet-processing events and acknowledgements required for a transfer. They may place more work on network interfaces, operating systems and intermediate equipment. RFC 8201 notes that sending packets much smaller than the supported Path MTU wastes network resources and can produce suboptimal throughput.

An oversized MTU can produce a more serious performance problem. Packets may be fragmented, repeatedly retransmitted or discarded completely. The user may experience slow page loading, incomplete downloads, unreliable cloud applications or connections that work for small messages but fail when larger amounts of data begin moving.

The ideal MTU is therefore the largest value that works reliably across the intended path without unwanted fragmentation. Increasing the number beyond that limit does not increase internet bandwidth. It merely creates packets the route cannot handle, which can make a fast connection perform worse rather than better.

Signs of an MTU Problem

A common symptom is that small packets work while larger transfers fail. A user may successfully resolve a domain, connect to a server and load part of a website, but images, downloads or form submissions remain stuck. The initial packets fit through the path, while later data packets exceed its effective MTU.

VPN users may connect successfully but lose access to certain websites, remote desktops or internal applications. Encryption and tunnelling add headers that reduce the space available to the original packet. When the VPN interface or gateway does not account for this overhead, the encapsulated packet may become too large.

Another warning sign is a connection that completes the TCP three-way handshake and then hangs during data transfer. RFC 8201 identifies this behaviour as a black-hole connection that can occur when Packet Too Big feedback is blocked or not delivered to the sender.

Other possible signs include repeated retransmissions, inconsistent file transfers, gaming disconnections and services that work through one network but fail through another. These symptoms are not exclusive to MTU, so administrators should also investigate DNS, packet loss, firewalls, routing, congestion and application errors before changing settings.

What Is an MTU Black Hole?

An MTU black hole occurs when packets larger than the actual Path MTU are silently discarded and the sender does not receive useful feedback. The sender continues transmitting packets that cannot reach the destination because it remains unaware that a lower packet-size limit exists.

Classical Path MTU Discovery depends on ICMP Fragmentation Needed or ICMPv6 Packet Too Big messages. Firewalls, middleboxes or incorrect router policies may block those messages. The original data disappears along the path, while the sender waits, retransmits or eventually allows the connection to time out.

Black holes can be difficult to recognise because basic connectivity tests may still succeed. Small DNS queries, handshake packets and lightweight requests fit under the restriction, creating the impression that the route is healthy. Problems emerge only when the application transmits a packet large enough to exceed the hidden limit.

Allowing necessary ICMP feedback is the preferred solution. Packetization Layer Path MTU Discovery can also detect failure through transport-level probes instead of depending entirely on ICMP messages. As a workaround for affected TCP connections, administrators sometimes lower the MTU or apply carefully calculated MSS clamping.

How to Test MTU on Windows

Windows includes the ping command for testing connectivity and packet sizes. The /l option specifies the ICMP Echo Request data size, while /f sets the IPv4 Don’t Fragment flag. Microsoft documents both options for current Windows client and server versions.

A common starting test is ping example.com /f /l 1472. The 1472-byte payload combines with a basic 20-byte IPv4 header and an 8-byte ICMP header to create a 1500-byte IP packet. A response suggests that this size passed, while a fragmentation message indicates that the payload is too large.

Reduce the payload gradually until the test succeeds without fragmentation. You can then add 28 bytes to the successful IPv4 payload to estimate the tested Path MTU. For example, a maximum payload of 1464 suggests an estimated MTU of 1492 under basic IPv4 and ICMP header conditions.

The result is only as reliable as the destination and test route. Some hosts block ICMP Echo Requests, and different destinations can have different Path MTUs. Test the actual server or service path whenever possible, and repeat the measurement through the VPN or connection where the problem occurs.

How to Test MTU on Linux

Linux systems commonly provide the ping utility from the iputils project. The packet-size option controls the number of data bytes, while the -M setting controls Path MTU Discovery behaviour. The Linux manual documents modes that can set the Don’t Fragment behaviour or allow different probing approaches.

A typical IPv4 test is ping -M do -s 1472 example.com. As with the Windows example, the data combines with basic IPv4 and ICMP headers to create a 1500-byte packet. Reduce the -s value when the system reports that the message is too long or packets receive no response.

Linux also provides tracepath, which is designed to discover properties of the route, including Path MTU changes. It can be useful when you need to see where a lower limit may appear, although firewalls and routing behaviour can affect the information returned by any diagnostic tool.

Do not assume that the local interface MTU and discovered Path MTU must match. Run ip link show to inspect interface settings, then test the destination separately. A 1500-byte local interface can communicate across a lower-MTU route when discovery and packet sizing work correctly.

How to Find the Best MTU

Begin with the default supplied by the operating system, router or internet provider. Standard Ethernet commonly uses 1500, while PPPoE commonly uses 1492. VPN providers may recommend a lower value based on their encapsulation protocol, so review their documentation before making manual changes.

Test the real path using non-fragmenting packets and reduce the payload until consistent responses are received. Add the relevant IP and ICMP header sizes to estimate the Path MTU. Perform several tests because an isolated packet loss event does not necessarily prove that the packet size is unsupported.

Choose a value that remains reliable across the required destinations. The mathematically largest successful probe may not be ideal when paths change or additional headers are introduced. A small safety margin can be reasonable for tunnels, but reducing the value far below the path limit creates avoidable overhead.

Change one interface or device at a time and document the original value. Test browsing, file transfers, video calls, VPN access and important business applications after each adjustment. Restore the default when the change provides no improvement, because an unrelated networking issue may be causing the symptoms.

How to Change MTU

On Windows, administrators can inspect interfaces and modify their network-layer MTU with the netsh interface commands. Microsoft documents the ipv4 set subinterface function and its mtu parameter. A typical format is netsh interface ipv4 set subinterface "Ethernet" mtu=1492 store=persistent.

Use an elevated Command Prompt and replace the interface name and number with values appropriate for the device. A persistent setting remains after restart, while an active-only setting is temporary. Record the original configuration before changing it so you can reverse the adjustment if connectivity becomes worse.

On Linux, ip link show displays network interfaces and their current MTU values. A temporary adjustment can use a command such as sudo ip link set dev eth0 mtu 1400, replacing the interface and value as needed. The iproute2 manual documents this MTU-setting syntax.

Permanent Linux configuration depends on the distribution and network manager. Routers usually provide an MTU field within WAN, internet, PPPoE or VPN settings. Avoid changing every client and router simultaneously, because inconsistent modifications make troubleshooting more difficult and may hide the actual restrictive link.

MTU for PPPoE Connections

PPPoE places Point-to-Point Protocol information inside Ethernet frames. The additional overhead traditionally reduces the maximum PPP payload from the standard 1500-byte Ethernet IP packet size to 1492 bytes. This is why many DSL and other PPPoE-based internet connections use an MTU of 1492.

When a router uses PPPoE but local computers continue sending 1500-byte packets, the router may fragment IPv4 traffic, adjust TCP MSS or rely on Path MTU Discovery. A failure in these mechanisms can make certain websites, secure connections or uploads behave inconsistently.

Some networks support RFC 4638, which allows PPPoE to negotiate a larger receive unit when the Ethernet service can carry frames beyond the traditional size. Both ends and the intermediate network must support that capability. Users should not manually select 1500 for PPPoE merely because their router interface displays the option.

When troubleshooting a PPPoE connection, confirm the value recommended by the internet provider. Test 1492 and calculate the matching TCP MSS where necessary. A lower value such as 1480 may avoid a problem, but it should be treated as a tested workaround rather than a universal PPPoE requirement.

MTU for VPN Connections

VPNs encapsulate an original packet inside new protocol headers. Encryption, authentication, UDP, TCP and tunnel headers consume additional bytes, leaving less space for the original packet. The effective tunnel MTU must account for this overhead before the complete outer packet crosses the physical network.

The exact reduction depends on the VPN technology and configuration. IPsec, WireGuard, OpenVPN, GRE and other tunnels use different headers and security fields. IPv4 versus IPv6 transport, optional features and multiple layers of tunnelling can also change the total overhead.

An oversized VPN packet may be fragmented before encapsulation, fragmented after encapsulation or discarded. The user may see a tunnel that connects normally but fails with large web pages, cloud storage, remote desktops or database traffic. These symptoms often appear when ICMP feedback cannot travel through the tunnel correctly.

Use the VPN provider’s recommended MTU as the starting point, then test the real destination through the active tunnel. Packetization Layer Path MTU Discovery accounts for security-related overhead when determining the maximum usable application packet size. Avoid copying another VPN’s MTU without comparing the protocols and route.

What Are Jumbo Frames?

Jumbo frames allow Ethernet networks to carry IP packets larger than the standard 1500-byte MTU. A value around 9000 bytes is common in data centres, storage networks and high-performance local environments. Larger packets can reduce per-packet overhead and processing for large, continuous transfers.

Jumbo frames are most useful on controlled networks where every participating interface and switch supports the same size. A server sending 9000-byte packets through a switch port limited to 1500 may experience drops, fragmentation or failed communication, depending on the protocol and configuration.

They do not automatically improve ordinary internet browsing or gaming. Public internet paths generally cannot be assumed to support a 9000-byte MTU from end to end. Routers and endpoints must still use Path MTU Discovery or smaller packets when traffic leaves the jumbo-enabled local network.

Enable jumbo frames only for a measured workload and verify the complete path. Check network cards, virtual switches, physical switches, storage devices, hypervisors and tunnel interfaces. Linux driver documentation shows 9000 as a configurable example, but equipment-specific maximums and terminology must still be confirmed.

Common MTU Mistakes

One common mistake is increasing MTU because a larger number appears faster. A packet exceeding the Path MTU can be discarded or fragmented, creating more overhead and retransmissions. The best setting is the largest reliable size supported across the intended path, not the highest number an interface accepts.

Another mistake is blocking every ICMP message at a firewall. Path MTU Discovery depends on specific ICMP and ICMPv6 feedback. Blocking Packet Too Big messages can create black-hole connections where handshakes succeed but application data cannot move.

Administrators may also change MTU on one endpoint without checking routers, tunnels or peer devices. This can hide the symptom temporarily while leaving the actual path misconfiguration unresolved. Review every layer that adds encapsulation and determine where the packet first exceeds the available size.

The final mistake is assuming every failed ping proves an MTU problem. Firewalls may block ICMP, routes may change and packet loss may occur for unrelated reasons. Combine packet-size testing with captures, interface counters, retransmission data, application logs and route analysis before making permanent network-wide changes.

MTU Best Practices

Keep the default MTU when the connection works reliably. Standard values are selected to provide broad interoperability, and unnecessary changes can introduce problems that did not previously exist. Manual adjustment is most appropriate when testing identifies a repeatable packet-size failure or a documented tunnel requires another value.

Allow the necessary ICMP Fragmentation Needed and ICMPv6 Packet Too Big messages through security devices. Filtering should be specific rather than disabling essential control traffic. IPv6 Path MTU Discovery relies on Packet Too Big messages, and blocking them can prevent endpoints from learning the correct limit.

Prefer Path MTU Discovery or Packetization Layer Path MTU Discovery over routine IP fragmentation. The IETF considers fragmentation fragile and advises applications to use known path information or an appropriate discovery method. Datagram PLPMTUD can probe the path and recover from packet black holes without relying entirely on ICMP.

Document interface values, tunnel overhead and MSS policies across the network. Monitor fragmentation, retransmissions and failed Packet Too Big processing after changes. Re-test critical routes when deploying new VPNs, cloud connections, internet providers or network equipment because every new encapsulation layer can affect the usable packet size.

FAQs

What is MTU in simple terms?

MTU is the largest IP packet a network interface or link can transmit without dividing it into smaller pieces. It is measured in bytes and commonly defaults to 1500 on Ethernet.

What is the best MTU size?

The best MTU is the largest value that travels through the complete network path without unwanted fragmentation or packet loss. Common values include 1500 for Ethernet and 1492 for traditional PPPoE.

Does changing MTU increase internet speed?

Changing MTU does not increase your connection’s bandwidth. Correcting an MTU mismatch may improve reliability and throughput, while choosing an unsuitable value can make performance worse.

What happens when MTU is too high?

Packets may be fragmented or dropped because a link cannot carry them. This can cause failed downloads, slow websites, VPN problems, retransmissions or connections that stop after initially succeeding.

What happens when MTU is too low?

The connection may still work, but more packets and headers are required to transfer the same amount of data. This increases overhead and can reduce network efficiency.

What Is MTU? Final Takeaways

To understand what is MTU, remember that it is the largest IP packet a specific interface or link can transmit in one piece. It includes the IP header and payload but normally excludes link-layer framing. Standard Ethernet commonly uses 1500 bytes, while other technologies may use lower or higher values.

Path MTU is the smallest supported packet size across the complete route to a destination. Path MTU Discovery allows a sender to learn that limit and adjust its packets. When essential feedback is blocked, oversized packets may disappear silently and create an MTU black hole.

An MTU that is too high may cause fragmentation, packet loss and failed connections. An unnecessarily low value increases packet and header overhead. Testing with controlled, non-fragmenting packets can help identify the largest size that works reliably through the required network or VPN path.

Keep default settings unless you have evidence of a mismatch. When changes are needed, document the original value, adjust one point at a time and test important services afterward. Correct MTU configuration improves reliability by matching packet sizes to what the complete network path can actually carry.