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.

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, and
the subnet name, region and address.

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 (on-persistent):

Ephemeral external IP addresses:
- For VM instances, the ephemeral external IP address is also 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 Solaris guest system, this automatic configuration can be suppressed by disabling the setup in the file /etc/default/instance_configs.cfg.

Important information:

Currently, the Charon-SSP marketplace images are based on CentOS 7.
NetworkManager is disabled by default in these images.
If you disable the automatic interface setup as shown above, 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.
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 or using nmcli commands.

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

After restarting the network (systemctl restart network), the configuration as defined in the ifcfg-files should be set for the interfaces. On RHEL/CentOS 8 systems restart the NetworkManager instead (systemctl restart NetworkManager).

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 Solaris guest system, that is, the internal IP address of the interface is not configured on the Linux level, but on the Solaris level, please note the following points:

The netmask on Solaris has to be set to a value that includes the default gateway (e.g., /24). Otherwise, Solaris will return an error when setting the default gateway (network unreachable).
If Solaris should 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 Solaris 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

The VPC network has a maximum transmission unit (MTU) of 1460 bytes. Interfaces should be configured to this value to avoid the increased latency and packet overhead caused by fragmentation. Client applications that communicate with GCP instances over UDP should have a maximum payload of 1432 bytes to avoid fragmentation.

Charon-SSP 4.2 for Google Cloud - Getting Started

Network Management

Contents