To add an additional network interface to an instance or to remove an interface from your instance perform the steps described below.

Please note: The steps below only provide a basic overview. The exact tasks required will vary depending on your network design. Please refer to the GCP documentation for details.

Contents

When an instance is created, a default Ethernet interface is attached to the system. This default network interface is mandatory. During the creation of the instance, you can add additional network interfaces.

General Information

The rules for Google cloud instances with respect to network interfaces are strict:

• Interfaces can only be added during instance creation.
• Each network interface configured in a single instance must be attached to a different VPC network.
• The additional VPC networks that the multiple interfaces will attach to must exist before an instance is created. See Using VPC Networks for instructions on creating additional VPC networks.
• You cannot delete a network interface without deleting the instance.

Therefore the required VPCs and subnets must exist before the instance is created.

To create additional VPCs (if required), perform the steps below.

Create VPCs and Subnets for Instance

Step 1: Open the VPC network section by clicking on the Navigation menu, then selecting VPC network, and clicking on VPC networks - as illustrated below.

This will open the VPC overview page with the already existing VPCs. If all required VPCs and subnets already exist, continue with creating the new VM instance. Otherwise, continue with step 2.

Step 2: If you need to create a new VPC, click on CREATE VPC NETWORK at the top of the VPC overview list.

This opens the VPC configuration window.

Step 3: Create VPC and subnets.

In the VPC configuration window, enter

• the VPC name,
• the subnet name, region and address, and
• optionally, an alternative MTU size (at the bottom of the window). The default MTU is 1460 bytes. If you want to dedicate an interface in this VPC to the emulator, this may cause problems as the default MTU size of the legacy guest systems is usually 1500 bytes. The interface dedicated to the emulator must not have an MTU smaller than the MTU used by the legacy guest system.

Click on Create at the bottom of the window to create the VPC.

The new VPC should appear in the VPC overview list. Selecting the VPC in the overview list will open the detail information window. Example:

Step 4: Create firewall rules for the VPC.

With the detail information open, click on Firewall. This will allow you to define the required firewall rules for the VPC.

An example of a small set of firewall rules that allow incoming SSH and ICMP is shown below:

Adding Additional NICs to an Instance

Additional NICs are added during instance creation. Perform the following steps in the instance creation window:

• Open the advanced settings at the bottom of the VM creation window by clicking on Management, security, disks,... at the bottom of the page.
• Select Networking from the advanced settings section.
• Click on Add network interface.
• Select the correct subnet (created before).
• Set the information about internal and external IP address (static or ephemeral) as required.

After adding all the required information, click on Done.

The second interface is now visible in the details page of the VM instance:

Assigning a Static IP Address to a Network Interface

During the creation of a VM instance, when you add the default and optional additional NICs, you can determine if the IP addresses assigned to a NIC are static (persistent across restarts) or ephemeral (non-persistent across restarts). The process to add a static IP requires reserving the IP address. The public IP address may also have to be created first.

If you choose to add a static private IP address to an interface, you will get the following window to reserve a static private IP address:

If you choose to add a static public IP address to an interface, you will get the following window to create (if needed) and reserve an address:

You can also manage external IP addresses from the VPC network management section (Navigation menu > VPC network > External IP addresses):

Detaching a Network Interface from an Instance

You cannot delete a network interface without deleting the instance it is attached to. So if you do not need a network anymore, but do not want to delete the instance, you can only disable it from the operating system level.

Address Assignment Information

General information

Each VM instance interface can have one primary internal IP address, one or more secondary IP addresses, and one external IP address.

Addresses can be static (persistent) or ephemeral (non-persistent):

• Ephemeral external IP addresses:
  • For VM instances, the ephemeral external IP address is released if you stop the instance. After you restart the instance, it is assigned a new ephemeral external IP address.
• Static external IP addresses:
  • Static external IP address can be reserved and thereby assigned a project indefinitely until they are explicitly released. You can reserve a new static external IP address or promote an existing ephemeral external IP address to a static external IP address.
• Ephemeral internal IP addresses:
  • Ephemeral internal IP addresses remain attached to VM instances until the instance is deleted.
• Static internal IP addresses:
  • For VM instances, static internal IP addresses remain attached to stopped instances until they are removed.

Address Ranges

When creating a VPC and its subnets, subnet address ranges are assigned to these subnets. There are some restriction regarding permitted address ranges:

Restricted address ranges:

Restricted ranges include Google public IP addresses and commonly reserved RFC ranges, as described below. These ranges cannot be used for subnet ranges.

• Public IP addresses for Google APIs and services, including Google Cloud netblocks: You can find a link to these IP addresses in this Google FAQ.
• 199.36.153.4/30 and 199.36.153.8/30: private Google access-specific virtual IP addresses
• 0.0.0.0/8: Current (local) network RFC 1122
• 127.0.0.0/8: Local host RFC 1122
• 169.254.0.0/16: Link-local RFC 3927
• 224.0.0.0/4: Multicast RFC 5771
• 255.255.255.255/32: Limited broadcast destination address RFC 8190 and RFC 919

Reserved subnet addresses:

Every subnet has four reserved IP addresses in its primary IP range. There are no reserved IP addresses in the secondary IP ranges.

• Network: first address in the primary IP range for the subnet 10.1.2.0 in 10.1.2.0/24
• Default gateway: Second address in the primary IP range for the subnet 10.1.2.1 in 10.1.2.0/24
• Second-to-last address: second-to-last address in the primary IP range for the subnet that is reserved by Google Cloud for potential future use 10.1.2.254 in 10.1.2.0/24
• Broadcast: last address in the primary IP range for the subnet 10.1.2.255 in 10.1.2.0/24

Please note:

• The default gateway does not respond to ping.
• The default gateway does not decrement TTL headers (used for traceroute).
• Only IPv4 unicast traffic is supported.

Interface Configuration on Linux

By default, Google cloud tools installed on the Linux instance automatically start the attached network interfaces and configure them using DHCP.

Should this be undesirable, for example, because a NIC is to be dedicated to the guest operating system running in the emulator, this automatic configuration can be suppressed by disabling the setup in the file /etc/default/instance_configs.cfg.

Important information:

• Older Charon-SSP marketplace images are based on CentOS 7, newer ones are based on Linux 8.x.
• The NetworkManager is disabled by default in instances based on Charon marketplace images that use Linux 7.x.
• If you disable the automatic interface setup by GCP on instances running Linux 7.x, you must make sure that the correct ifcfg-files for every interface exist in /etc/sysconfig/network-config. Failure to do so, can make your instance unreachable after the next network restart. On instances based on Charon marketplace images using Linux 8.x you can use the NetworkManager manually or via the Charon Manager to configure the IP setup for additional interfaces.
• If you use a RHEL/CentOS 8 image as the base image for your Charon host, the interface must be controlled by the NetworkManager. You can set up the appropriate configuration by editing the interface configuration files, using nmcli commands, the nmtui utility or the Charon Manager.

To disable automatic interface configuration by the cloud tools, edit the file and set the parameter setup to false as shown in the example below:

# vi /etc/default/instance_configs.cfg
[NetworkInterfaces]
dhclient_script = /sbin/google-dhclient-script
dhcp_command =
ip_forwarding = true
setup = false

Linux 7.x: after restarting the network (systemctl restart network), the configuration as defined in the ifcfg-files should be set for the interfaces.

Linux 8.x: on these systems with the NetworkManager enabled, instead

• reactivate the connection on which the changes were performed:
  nmcli example: # nmcli con down <connection_name> && nmcli con up <connection_name>)
  (the command syntax is to ensure that the connectivity is not lost by executing the commands separately)
• To reload a changed configuration file into the NetworkManager, use the command # nmcli connection reload. The Charon Manager will perform these steps automatically.

Please note: if your instance normally would detect the network MTU automatically, this will not work if DHCP is disabled, and the correct MTU must be set manually.

Additional GCP-specific Information

IP Interface Netmask

Please note: The latest images provided by Stromasys use a /24 netmask for additional NICs. Therefore, the following information no longer applies to instances created with these images.

However, other base images used to create an instance, may use a netmask of /32 for additional NICs on the VM instance. This means that only ARP requests for the default gateway are answered by the Google metadata server. In such cases, when providing a dedicated NIC to the legacy guest system running in the emulator (i.e. the internal IP address of the interface is not configured on the Linux level, but on the guest OS level) please note the following points:

• If the guest OS returns a network unreachable error when configuring the default gateway, the netmask on the guest OS NIC has to be set to a value that includes the address of the default gateway (e.g., /24).
• If the workaround above was required and the guest OS must communicate with systems on the same subnet, it needs a static ARP entry for these systems (arp -s <target-ip> <target-mac>). This is because the ARP requests sent by by the guest OS for the MAC addresses of these systems will not be answered by the Google metadata server and they will not be forwarded to the target system.

Routing between VPCs

If a VM instance has more than one NIC, each NIC must be in a different VPC. Routing between VPCs is not enabled by default. It has to be enabled through a mutual VPC peering configuration as shown in the sample below:

The example shows one rule for each routing direction between the two VPCs.

If this is not enabled, host and guest system can only communicate via the external IP addresses, not via the internal IP addresses.

Network Interface MTU

A VPC network has a default transmission unit (MTU) of 1460 bytes for Linux images and Windows Server images. During the creation of a VPC you can set the MTU to a different value (e.g., 1500). In your instance (especially, if it does not rely on DHCP), set the MTU to the same value as configured for the VPC to avoid the increased latency and packet overhead caused by fragmentation, or even connectivity problems. For an MTU size of 1460, client applications that communicate with GCP instances over UDP must have a maximum payload of 1432 bytes to avoid fragmentation.
In particular, ensure that the MTU used on any Linux interface dedicated to the emulator is not smaller than the MTU used by the legacy guest system. Failing to do so will cause network problems. For more information refer to the section Interface MTU Considerations in this guide.