Subnets

Subnet Introduction

In the VPC Networking > Subnets view, an IP subnet can be defined in a standard CIDR format, and assigned a name for easy reference throughout the UI. It is used primarily for association with a VPC as described in VPC Introduction. VPC subnets are defined by the following constraints:

1. The first four IP addresses and the last IP address in each subnet CIDR block are not available for users, and cannot be assigned to an instance.

2. The second address of the subnet is reserved for the router.

3. The CIDR block of a subnet may be either identical to the VPC’s CIDR block, which is the case when there is a single subnet, or a subset of the VPC’s CIDR block, when there are multiple subnets. In the latter case, the CIDR blocks of the subnets cannot overlap. The permitted block size ranges from a /28 netmask to a /16 netmask.

4. Every subnet that is created is automatically associated with the main route table of the VPC. You can change the association. A subnet can be associated with only one route table at a time.

Creating a Subnet

See the video introducing the basics of creating and configuring zCompute VPC Subnets:

To create a subnet:

1. Navigate to the VPC Networking > Subnets view.

2. From the top toolbar, click Create.

3. In the Create Subnet dialog, enter the following:

   • Name - name of the subnet.

   • Description - optional description of the subnet.

   • VPC - VPC which is associated with this subnet.

   • CIDR - subnet in CIDR format based on IP/mask.

   • Tags - optionally add tags by selecting them from the dropdown, or creating them in this field.

Subnet Operations

After creating a subnet, it is displayed in the subnet list in the VPC Networking > Subnets view. The following operations can be performed by selecting a subnet from the list, and clicking the appropriate icon.

From top toolbar:

• Modify - change the name of the subnet.

• Set Default - set the subnet as the default for a VPC, to be used for

  provisioning new entities within the VPC. For example, if a new VM instance is associated with a VPC, it will be configured with an IP from the default subnet.

• Delete

• Test connectivity - use ping or arping to test connectivity to a specific IP within the selected subnet. For more information on subnet testing, see Testing Subnet Connectivity.

• Soft Reset - rebind all DHCP ports on the network.

• Hard Reset - recreate DHCP servers on the network.

From lower toolbar:

• VMs - view information on VMs associated with the selected subnet.

• Events - view configuration events (info) or alarms for the subnet.

In the displayed subnet list, there is an indication of Direct Subnet.

Direct Subnet

In zCompute, a Direct Subnet provides the ability to share the same layer 2 network (VLAN) between the hosting data center’s network and a VPC subnet.

This allows end users who require it, to achieve L2 connectivity over a given VLAN ID to resources external to the zCompute cluster, or direct access to zStorage resources available at the data center.

For example, a direct subnet allows the establishment of external and dedicated VPSA Storage Arrays and Object Storages while bypassing unnecessary internet routers. This is extremely common and useful where a dedicated and high-speed NAS/Object Storage solution is required.

Important

• Due to physical network resource allocation, Direct Subnets are managed by the MSP or Zadara Operations team.

  Typically, the Direct Subnet’s CIDR is provided by the MSP partner that manages the data center’s routing and IP allocations.

• The Direct Subnet’s CIDR and the VPC’s CIDR must be foreign to each other and must not overlap.

• DHCP must not be used on this VLAN or subnet, otherwise unexpected DHCP VM configurations might occur.

• The VMs’ default GW of VMs attached to the Direct Subnet is always set to the VPC’s internal GW, i.e. the internal vRouter and not the external GW of the Direct Subnet.

• The VPC Internal Router IP and all IPs in a Direct Subnet’s Allocation Pool must be managed by zCompute. None of these IPs can be used by external systems on the Direct Subnet VLAN.

See the video introducing the basics of connecting local networks into your VPC with Direct Subnets:

Creating a Direct Subnet

To create a direct subnet (MSP or Zadara Operations team only):

1. Navigate to Account Networking > Direct Subnets and click + Create.

2. In the Create Direct Subnet window, enter:

   • Name: The name of the direct subnet.

   • Description: Optional description for the direct subnet.

   • Project: From the dropdown, select the project to which this direct subnet will be associated.

     Note

     A project can have only one Direct Subnet.

   • VPC: Optionally, from the dropdown, select the VPC for this direct subnet.

   • Node Network: Select the network from the dropdown.

   • VLAN ID: The VLAN ID of the physical switches that the direct subnet will use. This VLAN ID should also be configured on Zadara switches by Zadara Operations, for all the switch ports attached to zCompute nodes as well as the switches’ uplinks to the partner’s upstream switches, and the partner’s switches’ links to Zadara’s switches.

   • Subnet (CIDR): The direct subnet’s CIDR block. Typically, this CIDR is provided by the partner, to make it routable from the partner’s data center.

   • VPC Internal Router IP: The first IP address of the CIDR block. The subnet’s virtual router is created by zCompute, and used by payloads created within zCompute to route traffic from the subnet.

     Note

     This is not an external gateway, but a virtual router created by zCompute.

     The Direct Subnet cannot overlap the VPC network prefix.

     Similar to other subnets, two IPs are consumed by internal services, so nothing smaller than a /29 can be used.

   • External Router IP: Optional IP address for the VPC’s external router.

   • Allocation Pools:

     One or more ranges of IP addresses allocated for zCompute payloads of this subnet.

     Enter the start and end IP addresses of the range of addresses comprising the pool of addresses, from which subnets can be allocated.

     To configure an additional pool of IP addresses, click Add and enter the pool’s start and end IP addresses.

     Note

     IPs in the allocation pool are managed by zCompute and should not be used by anything on the customer’s side of the network.

     The purpose of this configuration is to avoid any potential IP collisions with other IP addresses external to zCompute that might be in use on this subnet, for example, physical L3 switch gateway, physical firewall appliance gateway, and physical servers.

     The Internal Router IP address, and the first and last IP addresses of the CIDR block are not permitted in the allocation pool.

3. Click Finish.

   The subnet is immediately available on the specified VPC.

Routing traffic through an external router

If you want to route traffic from the VPC through an external router connected to the Direct Subnet, the VPC route table associated with the Direct Subnet should be modified.

This can be configured with end user’s tenant permissions.

1. If an External Router IP was defined in Creating a Direct Subnet, skip to the next step to update the Route Table.

   Otherwise, create an Elastic Network Interface:

   1. Navigate to VPC Networking > Network Interfaces and click + Create.

   2. In the Create Elastic Network Interface dialog, enter:

      • Name: The interface name.

      • Description: Optional description text.

      • VPC: The VPC for which the external router is being added.

      • Subnet: From the dropdown, select the Direct Subnet.

      • Private IP: The external router’s IP address.

      • Security Groups: From the dropdown, select the security groups to apply to the network interface.

   3. Click Finish.

2. Navigate to VPC Networking > Route Tables and click the name of the Route Table to update.

   1. In the selected Route Table’s lower pane, click + Create.

      • Destination CIDR: The destination network or networks.

      • Target Type: Select Network Interface from the dropdown, to display the Network Interface input prompt.

      • Network Interface: From the dropdown, select the network interface created in the previous step.

   2. Click OK.

Testing Subnet Connectivity

Connectivity between a VPC Subnet and a specific IP address can be tested by ping using either the GUI or CLI.

Note

A VM connected to more than one Subnet, one of which has an Elastic IP (EIP) attached to its Elastic Network Interface (ENI), might suffer from an unpredictable Internet connectivity problem.

The reason is the two ENIs receive a DHCP configuration which includes a default GW (i.e. a default route).

For example:

A VM has all of the following configured:

• A Network Interface on a Direct Subnet

• A Network Interface on the VPC Public Subnet

• An Elastic IP associated with the Network Interface on the VPC Public Subnet

• Security Groups to allow desired Internet traffic to reach the VM via the Elastic IP, for example port 22

As a result, the following symptoms could be expected:

• There are two listings for default route/0.0.0.0 in the guest VM O/S:

  • One points to the GW on the Direct Subnet

  • One points to the GW on the VPC Public subnetO

• Outbound requests work correctly, such as ping to Internet sites and requests from the VM to external websites.

• Inbound request replies do not work. The VM has two bound network interfaces, but it cannot accept and reply to connections from the Internet via the Elastic IP.

• If the admin manually deletes the default route/0.0.0.0 in the guest VM pointing to the GW on the Direct Subnet, the inbound Internet connections on the Elastic IP start working. But DHCP refreshes all the time, and it repopulates the entry for the default route/0.0.0.0 to the GW on the Direct Subnet soon after it is manually deleted, effectively reinstating prevention of replies to connections from the Internet via the Elastic IP.

Using the GUI

1. Navigate to the VPC Networking > Subnets view.

2. Select a subnet from the displayed list and click Test Connectivity in top toolbar.

3. In the Test Connectivity window, enter a Destination IP address.

4. Select ping or arping.

   Note

   • ping checks layer 3 connectivity, and is blocked by Security Group filtering if traffic is not allowed from any IP in the Subnet.

   • arping checks layer 2 connectivity, and bypasses Security Group filtering.

5. Click OK.

6. Click OK. A message is displayed that the connectivity test is taking place.

7. A few seconds later, the test results will be displayed indicting success or failure as well as other relevant details. This status report is also available in the right-hand sidebar.

Using the CLI

1. The ‘guestnet-admin-tool ping-ip create’ command with which you can test a subnet’s connectivity requires the ID of the given subnet (see ‘entity_id’ below). Note: ‘–command-type’ is either ‘ping’ (default) or ‘arping’

   guestnet-admin-tool ping-ip create [-h]
                                      [-f {adaptive_table,json,shell,table,value,yaml}]
                                      [-c COLUMN] [--max-width <integer>]
                                      [--noindent] [--prefix PREFIX]
                                      [-m [NAME=VALUE [NAME=VALUE ...]]]
                                      [--command-type COMMAND_TYPE]
                                      [--name NAME]
                                      entity_id dest_ip
   

2. Run the ‘vpc network list’ command to locate the ID of Subnet-1.

   vpc network list -c id -c name
   

3. This returns a list of subnets and their IDs.

   +--------------------------------------+-----------------------------------------------------+
   | id                                   | name                                                |
   +======================================+=====================================================+
   | ceff2b60-fb75-44d0-8b1a-ac4034b260dc | Subnet-1                                            |
   +--------------------------------------+-----------------------------------------------------+
   

4. Test the connectivity of Subnet-1 to the destination IP address 8.8.8.8.

   guestnet-admin-tool ping-ip create ceff2b60-fb75-44d0-8b1a-ac4034b260dc 8.8.8.8
   

5. This returns a temporary, pending status of the subnet’s connectivity.

   +--------------+--------------------------------------+
   | id           | 2ce18cc5-b1a8-401c-ae98-99e484f99b3e |
   | name         | none                                 |
   | status       | pending                              |
   | command_type | ping                                 |
   | created_at   | 2019-05-12T13:39:56.650560           |
   | dest_ip      | 8.8.8.8                              |
   | entity_id    | ceff2b60-fb75-44d0-8b1a-ac4034b260dc |
   | output       | -                                    |
   | project_id   | 07650a05e9dd47c8a3b874a2132e178c     |
   | updated_at   | 2019-05-12T13:39:56.650581           |
   | user_id      | admin                                |
   +--------------+--------------------------------------+
   

6. Wait a few seconds and then request the final status of Router-1’s connectivity test by using the ‘guestnet-admin-tool ping-ip get ping_ip_id’, as follows:

   guestnet-admin-tool ping-ip get 2ce18cc5-b1a8-401c-ae98-99e484f99b3e
   

7. This returns the final, succeeded/failed status of Router-1’s connectivity test with relevant output details.

   +--------------+----------------------------------------------------------------+
   | id           | 2ce18cc5-b1a8-401c-ae98-99e484f99b3e                           |
   | name         | none                                                           |
   | status       | succeeded                                                      |
   | command_type | ping                                                           |
   | created_at   | 2019-05-12T13:39:56                                            |
   | dest_ip      | 8.8.8.8                                                        |
   | entity_id    | ceff2b60-fb75-44d0-8b1a-ac4034b260dc                           |
   |              +----------------------------------------------------------------+
   | output       | PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.                   |
   |              | 64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=55.1 ms         |
   |              | 64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=53.3 ms         |
   |              |                                                                |
   |              | --- 8.8.8.8 ping statistics ---                                |
   |              | 2 packets transmitted, 2 received, 0% packet loss, time 1001ms |
   |              | rtt min/avg/max/mdev = 53.335/54.219/55.104/0.914 ms           |
   |              |                                                                |
   |              +----------------------------------------------------------------+
   | project_id   | 07650a05e9dd47c8a3b874a2132e178c                               |
   | updated_at   | 2019-05-12T13:39:59                                            |
   | user_id      | admin                                                          |
   +--------------+----------------------------------------------------------------+
   

   Note

   This information is automatically deleted after approximately one hour.

Additional options for Subnet (VPC) Connectivity Testing

1. Delete a specific subnet connectivity test

   guestnet-admin-tool ping-ip delete ping_ip_id
   

2. List all ping_ip requests

   guestnet-admin-tool ping-ip list