Multiple network interfaces

This page provides an overview of multiple network interfaces for Compute Engine VM instances. VMs with multiple network interfaces are referred to as multi-NIC VMs.

A VM instance always has at least one virtual network interface (vNIC). Depending on the machine type, you can configure additional network interfaces.

Use cases

Multi-NIC VMs are useful in the following scenarios:

• To connect to resources in separate VPC networks: Multi-NIC VMs can connect to resources located in different VPC networks that aren't connected to each other through VPC Network Peering or Network Connectivity Center.

  • Because each interface of a multi-NIC VM is in a separate VPC network, you can use each interface for a unique purpose. For example, you can use some interfaces to route packets between VPC networks that carry production traffic and another interface for management or configuration purposes.

  • Within the guest OS of each multi-NIC VM, you'll need to configure route policies and local route tables.

• Routing packets between VPC networks: Multi-NIC VMs can be used as next hops for routes to connect two or more VPC networks.

  • Software running within the guest OS of a multi-NIC VM can perform packet inspection, network address translation (NAT), or another network security function.

  • When connecting VPC networks using multi-NIC VMs, it's a best practice to configure two or more multi-NIC VMs, using them as backends for an internal passthrough Network Load Balancer in each VPC network. For more information, see Use cases in the Internal passthrough Network Load Balancers as next hops documentation.

Specifications

The following specifications apply to VMs with multiple network interfaces:

• Instances and network interfaces: Every instance has a nic0 interface. The maximum number of network interfaces varies depending on the instance's machine type.

  • You can only add or remove network interfaces when creating an instance.

  • Each interface has an associated stack type, which determines the supported subnet stack types and IP address versions. For more information, see Stack type and IP addresses.

• Unique network for each network interface: Except for VPC networks that are created with an RDMA network profile, each network interface must use a subnet in a unique VPC network.

  • For VPC networks created with an RDMA network profile, multiple RDMA NICs can use the same VPC network, as long as each RDMA NIC uses a unique subnet.

  • A VPC network and subnet must exist before you can create an instance whose network interface uses the network and subnet. For more information about creating networks and subnets, see Create and manage VPC networks.

• Project of instance and subnets: For multi-NIC VMs in standalone projects, each network interface must use a subnet located in the same project as the VM.

  • For VMs in Shared VPC host or service projects, see Shared VPC .

  • Private Service Connect interfaces provide a way for a multi-NIC VM to have network interfaces in subnets in different projects. For more information, see About network attachments.

• IP forwarding, MTU, and routing considerations: Multi-NIC VMs require careful planning for the following instance and interface specific configuration options:

  • The IP forwarding option is configurable on a per instance basis, applying to all network interfaces. For more information, see Enable IP forwarding for instances.

  • Each network interface can use a unique maximum transmission unit (MTU), matching the MTU of the associated VPC network. For more information, see Maximum transmission unit.

  • Each VM receives a default route using DHCP Option 121, as defined by RFC 3442. The default route is associated with nic0. Unless manually configured otherwise, any traffic leaving an instance for any destination other than a directly connected subnet will leave the instance using the default route on nic0.

    On Linux systems, you can configure custom rules and routes within the guest OS using the /etc/iproute2/rt_tables file and the ip rule and ip route commands. For more information, consult the guest OS documentation. For an example, see the following tutorial: Configure routing for an additional interface.

Stack types and IP addresses

When you create a network interface, you specify one of the following interface stack types:

• IPv4-only
• IPv6-only (Preview)
• Dual-stack

The following table describes supported subnet stack types and IP address details for each interface stack type:

Interface	IPv4-only subnet	Dual-stack subnet	IPv6-only subnet (Preview)	IP address details
IPv4-only (single-stack)				IPv4 addresses only. See IPv4 address details.
IPv4 and IPv6 (dual-stack)				Both IPv4 and IPv6 addresses. See IPv4 address details and IPv6 address details
IPv6-only (single-stack) (Preview)				IPv6 addresses only. See IPv6 address details.

Changing network interface stack type

You can change the stack type of a network interface as follows:

• You can convert an IPv4-only interface to dual-stack if the interface's subnet is a dual-stack subnet or if you stop the instance and assign the interface to a dual-stack subnet.

• You can convert a dual-stack interface to IPv4-only.

You can't change the stack type of an IPv6-only interface. IPv6-only interfaces (Preview) are only supported when creating VMs.

IPv4 address details

Each IPv4-only or dual-stack network interface receives a primary internal IPv4 address. Each interface optionally supports alias IP ranges and an external IPv4 address. The following are the IPv4 specifications and requirements:

• Primary internal IPv4 address: Compute Engine assigns the network interface a primary internal IPv4 address from the primary IPv4 address range of the interface's subnet. The primary internal IPv4 address is allocated by DHCP.

  • You can control which primary internal IPv4 address is assigned by configuring a static internal IPv4 address or by specifying a custom ephemeral internal IPv4 address.

  • You must ensure that each network interface has a unique primary internal IPv4 address. This means that each interface's subnet must use a unique, non-overlapping primary IPv4 address range.

• Alias IP ranges: Optionally, you can assign the interface one or more alias IP ranges. Each alias IP range can come from either the primary IPv4 address range or a secondary IPv4 address range of the interface's subnet.

  • You must ensure that each interface's alias IP range is unique. This means that the primary and secondary IPv4 address ranges of each interface's subnet must be unique and not overlap.

• External IPv4 address: Optionally, you can assign the interface an ephemeral or reserved external IPv4 address. Google Cloud ensures the uniqueness of each external IPv4 address.

IPv6 address details

Compute Engine assigns each dual-stack or IPv6-only network interface (Preview) a /96 IPv6 address range from the /64 IPv6 address range of the interface's subnet:

• Whether the /96 IPv6 address range is internal or external depends on the IPv6 access type of the interface's subnet. Google Cloud ensures the uniqueness of each internal and external IPv6 address range. For more information, see IPv6 specifications.

  • If an instance needs both an internal IPv6 address range and an external IPv6 address range: You must configure two dual-stack interfaces, two IPv6-only interfaces, or one dual-stack interface and one IPv6-only interface. The subnet used by one interface must have an external IPv6 address range, and the subnet used by the other interface must have an internal IPv6 address range.

• The first IPv6 address (/128) is configured on the interface by DHCP. For more information, see IPv6 address assignment.

• You can control which /96 IPv6 address range is assigned by configuring a static internal or external IPv6 address range. For internal IPv6, you can specify a custom ephemeral internal IPv6 address.

Maximum number of network interfaces

For most machine types, the number of virtual network interfaces scales with the number of vCPUs with a minimum of 2 and maximum of 10. The following are exceptions:

• Compute Engine bare metal instances support a single vNIC.

• The maximum number of vNICs for the A3 and A4 machine series is different. For more information, see Accelerator-optimized machine family.

Use the following table to determine how many network interfaces can be attached to an instance:

Number of vCPU	Number of vNICs
2 or less	2
4	up to 4
6	up to 6
8	up to 8
10 or more	up to 10

Product interactions

This section describes interactions between multi-NIC VMs and other products and features in Google Cloud.

Shared VPC

The subnet and project relationship of a multi-NIC VM in a Shared VPC host or service project is as follows:

• Each network interface of a multi-NIC VM located in a Shared VPC host project must use a subnet of a Shared VPC network in the host project.

• Each network interface of a multi-NIC VM located in a Shared VPC service project can use either of the following:

  • A subnet of a VPC network in the service project.
  • A subnet of a Shared VPC network in the host project.

For more information about Shared VPC, see:

• Shared VPC overview
• Provision Shared VPC

Compute Engine internal DNS

Compute Engine creates internal DNS name A and PTR records only for the primary internal IPv4 address of the nic0 network interface of an instance. Compute Engine doesn't create internal DNS records for any IPv4 or IPv6 address associated with a network interface different from nic0.

For more information, see Compute Engine internal DNS.

Static routes

Static routes can be scoped to specific VM instances by using network tags. When a network tag is associated with an instance, the tag applies to all network interfaces of the instance. Consequently, adding a network tag to or removing a network tag from an instance might change which static routes apply to any of the VM's network interfaces.

Load balancers

Instance group backends and zonal NEG backends each have an associated VPC network as follows:

• For managed instance groups (MIGs), the VPC network for the instance group is the VPC network assigned to the nic0 interface in the instance template.

• For unmanaged instance groups, the VPC network for the instance group is the VPC network used by the nic0 network interface of the first VM instance that you add to the unmanaged instance group.

The following table shows which backends support distributing connections or requests to any network interface.

Load balancer	Instance groups	GCE_VM_IP NEGs	GCE_VM_IP_PORT NEGs
Backend service-based External passthrough Network Load Balancer The backend service isn't associated with a VPC network. For more information, see Backend services and VPC networks.	nic0 only	Any NIC	N/A
Internal passthrough Network Load Balancer The backend service is associated with a VPC network. For more information, see Backend service network specification and Backend service network rules.	Any NIC	Any NIC	N/A
External proxy Network Load Balancer For more information about backend service and network requirements, see Backends and VPC networks.	nic0 only	N/A	Any NIC
Internal proxy Network Load Balancer For more information about backend service and network requirements, see Backends and VPC networks.	nic0 only	N/A	Any NIC
External Application Load Balancer For more information about backend service and network requirements, see Backends and VPC networks.	nic0 only	N/A	Any NIC
Internal Application Load Balancer For more information about backend service and network requirements, see Backends and VPC networks.	nic0 only	N/A	Any NIC

Target pool-based External passthrough Network Load Balancers don't use instance groups or NEGs and only support load balancing to nic0 network interfaces.

Firewall rules

The set of firewall rules—from hierarchical firewall policies, global network firewall policies, regional network firewall policies, and VPC firewall rules—are unique to each network interface. To determine which firewall rules apply to a network interface, and the source for each rule, see Get effective firewall rules for a VM interface.

Firewall rules can be scoped to specific VM instances by using network tags. When a network tag is associated with an instance, the tag applies to all network interfaces of the instance. Consequently, adding a network tag to or removing a network tag from an instance might change which firewall rules apply to any of the VM's network interfaces.

Firewall rules in a global network firewall policy or regional network firewall policy support secure tags, which apply per network interface. For more information, see Comparison of secure tags and network tags.

What's next

• Create VMs with multiple network interfaces