Maximum transmission unit overview
Virtual Private Cloud (VPC) networks have a default maximum transmission unit
1460 bytes. However, you can configure your VPC networks to
have a different MTU.
The MTU is the size, in bytes, of the largest packet supported by a network layer protocol, including both headers and data. In Google Cloud, you can configure the MTU for each individual VPC network. VM interfaces that use that network must also be configured to use that MTU. This MTU value refers to the size of the IP packet (datagram) and thus excludes the Ethernet header.
VPC networks have a default MTU of
1460, but can be configured
to support an MTU of
1500 (standard Ethernet), up to
frames), or down to
1300. However, MTUs higher than
1600 can be used only if
the source and destination interfaces are in the same subnet and are
communicating using internal IPv4 addresses from the primary IPv4 range of
The following table describes the maximum packet sizes that a VM can use when communicating with another VM.
|Location of destination VM||IP address types||Permitted packet size||Notes|
Same VPC subnet as sending VM
GKE clusters using the IP masquerade agent to make traffic use the Node IP address
|internal IPv4 from primary subnet range||
||If both VM interfaces have the same MTU as the network and if the addresses used are from the primary range of the subnet, then both TCP and UDP traffic proceeds at the network MTU.|
Different subnet of same network
Same subnet using a secondary IP address
GKE clusters not using the IP masquerade agent
Same subnet using internal or external IPv6 addresses
internal or external IPv6
external IP address of another VM
|external IPv4 or IPv6||
|On-premises over a Cloud VPN tunnel||internal||
||See MTU differences with Cloud VPN|
|On-premises over a Cloud Interconnect connection||internal||
||See MTU differences with Cloud Interconnect|
Handling of packets that exceed MTU
The MTU impacts both UDP and TCP traffic:
- If an IP packet exceeds the MTU of any link on the path to the
destination, then the packet is dropped if the Don't-Fragment (DF) bit is
set. In addition, if the link is within Google Cloud then
the packet is dropped even if the DF bit is not set. When
the packet gets dropped, an ICMP packet of type 3, code 4
Fragmentation-Neededis sent back to the sender indicating what MTU is acceptable to the link. For more information on path discovery, see path MTU discovery (PMTUD).
- TCP negotiates the MSS during connection setup time. Packets are then segmented into the smaller MTU size of both endpoints of the connection. Additionally, for some network paths, Google Cloud performs MSS clamping, where the system lowers the advertised MSS values of SYN and SYN ACK packets so that communication can take place.
VMs and MTU settings
Linux VMs based on Google-provided OS images automatically have their interface MTU set to the MTU of the VPC network when they are created. If a VM has multiple network interfaces, each interface is set to the MTU of the attached network. If you change the MTU of a VPC that has running VMs, you must stop and then start those VMs to pick up the new MTU. When the VMs start up again, the changed network MTU is communicated to them from DHCP. DHCP Option 26 contains the network's MTU.
Windows VMs do not automatically configure their interfaces to use the
VPC network's MTU when they start. Instead, Windows VMs based
on Google-provided OS images are configured with a
fixed MTU of
1460. If you change the MTU of a VPC network that
contains Windows VMs based on Google-provided OS images, you
must change the MTU setting for the Windows
Verify MTU settings on any VMs that use custom images. It is possible that they might honor the VPC network's MTU, but it is also possible that their MTUs might be set to a fixed value.
For instructions, see Change the MTU setting of a VPC network.
Consequences of mismatched MTUs
A mismatched MTU is defined as two communicating VM instances that have different MTU settings. This can, in a limited number of cases, cause connectivity problems. Specific cases involve the use of instances as routers and the use of Kubernetes inside VMs.
In most common scenarios, TCP connections established between instances with different MTUs are successful due to the MSS negotiation, where both ends of a connection will agree to use the lower of the two MTUs.
This applies whether the two VMs are in the same network or peered networks.
MTU differences with Cloud VPN
Cloud VPN always uses an MTU of 1460 bytes. If the VMs and networks on either side of the tunnel have higher MTUs, then Google Cloud uses MSS clamping to reduce the TCP MTU setting to 1460.
In the event a VM does send a TCP or UDP packet larger than the configuration can handle, Google Cloud drops the packet and sends an ICMP error messages to enable PMTUD, thus setting a lower MTU for UDP packets.
For information about Cloud VPN and MTU, see Tunnel MTU.
MTU differences with Cloud Interconnect
Cloud Interconnect can have an MTU of
If the communicating VMs have an MTU of higher than
1460 and the VLAN
attachment has an MTU of
1440, MSS clamping reduces the MTU of TCP
1440 and TCP traffic proceeds.
MSS clamping does not affect UDP packets, so if the VPC network
has an MTU of higher than
1460 and the VLAN attachment has an MTU of
1440, then UDP datagrams with more than 1412 bytes of data (1412 bytes UDP
data + 8 byte UDP header + 20 byte IPv4 header = 1440) are dropped. In such a
case, you can do one of the following:
- Lower the MTU of the attached VPC network to
- Adjust your application to send smaller UDP packets.
- If the VPC network has an MTU of
1500, you can modify the MTU of the existing VLAN attachment to
1500bytes or create a new VLAN attachment with an MTU of
For more information about Cloud Interconnect and MTU, see Cloud Interconnect MTU.
- To see a different MTU working, see Create and verify a jumbo frame MTU network.
- Create a VPC network with a specified MTU.
- Change the MTU setting of a VPC network.
Try it for yourself
If you're new to Google Cloud, create an account to evaluate how VPC performs in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.Try VPC free