Maximum transmission unit overview

Virtual Private Cloud (VPC) networks have a default maximum transmission unit (MTU) of 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.

Valid MTUs

VPC networks have a default MTU of 1460, but can be configured to support an MTU of 1500 (standard Ethernet), up to 8896 (jumbo 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 subnet.

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 8896 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

Peered 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 IPv4

internal or external IPv6

 1600
  • TCP: If a VM sends a TCP SYN packet with a maximum segment size (MSS) that would make the datagram size larger than 1600 bytes, Google Cloud performs MSS clamping by rewriting the MSS value such that the datagram size becomes 1600. It does the same for a SYN ACK packet. In addition, if the VM does send a TCP packet larger than 1600 bytes, Google Cloud drops the packet and returns an ICMP Fragmentation-Needed message back indicating an MTU of 1600.
  • UDP: If a VM sends an IP datagram larger than 1600 bytes, Google Cloud drops the packet and returns an ICMP Fragmentation-Needed message back indicating an MTU of 1600.

internet

external IP address of another VM

 external IPv4 or IPv6 1500, but packets of up to 1600 bytes are not dropped
  • TCP: If a VM sends a TCP SYN packet with an MSS that would make the datagram size larger than 1600 MTU, Google Cloud performs MSS clamping by rewriting the MSS value such that the datagram size becomes 1500. It does the same for a SYN ACK packet. In addition, if the VM does send a TCP packet larger than 1600 bytes, Google Cloud drops the packet and returns an ICMP Fragmentation-Needed message back indicating an MTU of 1500.
  • UDP: If a VM sends an IP datagram larger than 1600 bytes, Google Cloud drops the packet and returns an ICMP Fragmentation-Needed message back indicating an MTU of 1500.
On-premises over a Cloud VPN tunnel internal 1460 See MTU differences with Cloud VPN
On-premises over a Cloud Interconnect connection internal 1440 or 1500 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-Needed is 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 VM.

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 more information about Cloud VPN and MTU, see Tunnel MTU and MTU considerations.

For information about Cloud VPN and MTU, see Tunnel MTU.

MTU differences with Cloud Interconnect

Cloud Interconnect can have an MTU of 1440 or 1500.

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 connections to 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 1460.
  • 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 1500 bytes or create a new VLAN attachment with an MTU of 1500 bytes.

For more information about Cloud Interconnect and MTU, see Cloud Interconnect MTU.

What's next

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