Compute instance netmasks

This page provides an overview of Compute Engine instance netmask configurations.

In a physical network, machines are usually configured with the same netmask as the subnet that they are connected to, which lets them broadcast Address Resolution Protocol (ARP) requests. As a result, machines can discover the MAC addresses of other machines within the same subnet and directly communicate with them by using destination MAC addresses.

In Cloud de Confiance by S3NS, broadcast traffic is not supported. By default, compute instance netmasks are configured as follows:

  • Linux: Instances are configured with a /32 netmask. As a result, even for traffic within the same subnet, instances communicate exclusively with the gateway's MAC address instead of the destination instance's MAC address. Using a /32 netmask hides the MAC address of remote instances, preventing Layer 2 discovery and creating problems for some applications.
  • Windows: Instances are configured with a netmask that matches the subnet's netmask. Instances can communicate with MAC addresses of other instances that are connected to the primary IPv4 address range, but communicate exclusively with the gateway's MAC address when sending traffic to instances that are connected to secondary ranges.

Consider the following before you configure larger instance netmasks:

  • Configuring larger instance netmasks is an advanced configuration and isn't required for most use cases. Unless your operating systems or applications need communication between instances to operate the same way as direct communication on a physical network, we recommend keeping the default configuration.

  • If you need larger instance netmasks, we recommend that you configure larger instance netmasks for all instances that are connected to the subnet. By using this configuration, you avoid the need to maintain custom images.

Configuration options

The following table summarizes the configuration options for compute instance netmasks. You can change the default configuration by either configuring larger netmasks for all instances in a subnet or by creating a custom image and using it to create individual instances that have larger netmasks.

Item No subnet or instance-level configuration

Default behavior for Linux

Subnet-level configuration with --resolve-subnet-mask Instance-level configuration with MULTI_IP_SUBNET

Default behavior for Windows

Instance interface netmask configured by DHCP /32 Matches netmask of subnet's primary IPv4 address range Matches netmask of subnet's primary IPv4 address range

Instances receive ARP replies for the following IP addresses:

  • Metadata server (169.254.169.254)
  • Link local range (169.254.0.0/16)
  • Subnet's gateway IP addresses
Instances receive ARP replies where the source and destination IPv4 addresses are the same in the ARP request packet
Instances receive ARP replies from primary internal IPv4 address destinations and alias IP address destinations that come from the subnet's primary IPv4 address range Both settings (ARP_PRIMARY_RANGE and ARP_ALL_RANGES)
Instances receive ARP replies from destination internal forwarding rule IPv4 addresses used by internal passthrough Network Load Balancers or internal protocol forwarding Both settings (ARP_PRIMARY_RANGE and ARP_ALL_RANGES)
Instances receive ARP replies from destination alias IP addresses in one of the subnet's secondary IPv4 address ranges Requires ARP_ALL_RANGES

For more information, see Subnet configuration

Subnet configuration

You can create a subnet that configures larger instance netmasks for all connected compute instances by using the Resolve subnet mask (--resolve-subnet-mask) setting, which you set to either Primary range only (ARP_PRIMARY_RANGE) or All ranges (ARP_ALL_RANGES). Use the Resolve subnet mask setting to create a subnet that has the following behavior:

  • DHCP configures instances that are connected to the subnet with the same netmask as the subnet (instead of /32).

  • Cloud de Confiance intercepts and responds to ARP requests according to the following rules:

    • If the source and destination IPv4 addresses of an ARP request packet are identical, no ARP response is generated.
    • If the destination IPv4 address of an ARP request packet matches a primary internal IPv4 address of an instance's network interface, an ARP response is generated if the resolve subnet mask setting is either ARP_PRIMARY_RANGE or ARP_ALL_RANGES.
    • If the destination IPv4 address of an ARP request packet matches an internal IPv4 address from an alias IP range of an instance's network interface:

      • If the alias IPv4 address range comes from the subnet's primary internal IPv4 address range, an ARP response is generated if the resolve subnet mask setting is either ARP_PRIMARY_RANGE or ARP_ALL_RANGES.

      • If the alias IPv4 address range comes from one of the subnet's secondary internal IPv4 address ranges, an ARP response is generated if the resolve subnet mask setting is ARP_ALL_RANGES.

    • If the destination IPv4 address of an ARP request packet matches an internal forwarding rule IPv4 address, for internal passthrough Network Load Balancers or internal protocol forwarding, an ARP response is generated if the resolve subnet mask setting is either ARP_PRIMARY_RANGE or ARP_ALL_RANGES. The resolve subnet mask setting of the subnet that the forwarding rule uses is relevant, even if the backend instance's network interface uses a different subnet.

Limitations

Configuring larger instance netmasks for all instance in a subnet has the following limitations:

  • You can configure the Resolve subnet mask setting only at subnet creation time. You can't update a subnet to configure it later.
  • The subnet must be a regular, IPv4-only subnet:
    • The subnet's purpose must be set to None (PRIVATE).
    • The subnet's stack type must be set to IPv4 (single stack) (IPV4_ONLY)
  • Virtual machine (VM) instances and bare metal instances are supported.
  • Instance NICs must be in a regular VPC network. NICs in a VPC network that uses any other network profile, such as an RDMA VPC network, aren't supported.
  • The ARP behavior in a VPC network is different from the behavior on a physical network.
  • This configuration adds support for ARP, but Cloud de Confiance doesn't support any other Layer 2 protocols.

For more information, see Configure larger instance netmasks for a subnet.

Single instance configuration

If you configure a single compute instance with a larger netmask by using a custom image with the MULTI_IP_SUBNET feature, the following applies:

  • DHCP configures instances that are connected to the subnet with the netmask of the subnet (instead of /32).
  • Cloud de Confiance intercepts and responds to ARP requests that come from the primary IPv4 address range.

Limitations

Configuring larger instance netmasks for single compute instance has the following limitations:

  • You must maintain custom images to configure the MULTI_IP_SUBNET option.
  • VM instances and bare metal instances are supported.
  • The instance NIC must be a vNIC or a Dynamic Network Interface. RDMA-type NICs aren't supported.
  • The ARP behavior is different from the behavior on a physical network.
  • This configuration adds support for ARP, but Cloud de Confiance doesn't support any other Layer 2 protocols.

For more information, see Configure a larger netmask for a single instance.

How ARP works in a VPC network

If you configure compute instances with larger netmasks through either the Resolve subnet mask or MULTI_IP_SUBNET settings, instances can send and receive ARP messages. However, the behavior of ARP in Cloud de Confiance differs from the behavior in a physical network in the following ways:

  • When an instance sends an ARP request, Cloud de Confiance intercepts the request. Even though the instance interface is configured with a netmask that matches the subnet's netmask, the ARP request is not sent to other instances.
  • Cloud de Confiance sends an ARP reply with a MAC address even if no instances are using the IP address in the ARP request.

What's next