Virtual Network Management

Overview

This chapter contains documentation on how to create and manage Virtual Networks.

HyperCX uses at least 3 different networks,

  • Management Network. This network will interconnect HyperCX’s services and resources. It is not meant to be accessible by workloads so it is not configured on the orchestrator.
  • Client Network. All the VMs created by users use Client Network and this Network will give Private IP for VM. All network traffic from this Network is behind a firewall. One or several client networks can exist. This is used as a Virtual Network.
  • Public Network. This Network contains public IPs. It is accessed by the firewall and optionally, by workloads, giving the user the option to directly assign public IPs to VMs/containers. Might be used as a Virtual Network.

Physical Design

HyperCX supports both physical and virtual firewall designs

Physical Firewall scheme

Components are interconnected as described on the following diagram: Users

Note

Bridge names can change.

Virtual Firewall scheme

Components are interconnected as described on the following diagram: Users

Note

Bridge names can change.

Logical Design

Virtual Networks

Virtual instances use virtual networks for connectivity. These can be manually created from scratch or by instantiating a VNET Template. Most HyperCX clusters provide a pre-configured VNET Template called Private IPv4. If possible, it is recommended to use that template since it will abstract most of the complexity of the underlying network, and in certain environments like off-premise deployments might be the only option. Creating Virtual Networks from scratch is primarily meant for on-premise deployments where users have full control of the underlying physical network.

Virtual Network Definition

A Virtual Network consists of three different parts:

  • The underlying physical network infrastructure that will support it, including the network driver.

  • One or more address ranges. Addresses associated to a Virtual Network can be IPv4, IPv6, dual stack IPv4-IPv6 or Ethernet (MAC only).

  • The guest configuration attributes to setup the Virtual Machine network, that may include for example network masks, DNS servers or gateways.

Physical Network Attributes

To define a Virtual Network include:

  • NAME to refer this Virtual Network.
  • VN_MAD the driver to implement this Virtual Network. Depending on the driver you may need to set additional attributes. Different HyperCX clusters can use different drivers. For small to medium size private clusters VLAN (802.1Q) will most likely be used for its increased performance. If the cluster is hosted on-prem, users can add their network and do any required configurations on the network infrastructure. When cluster is hosted off-prem, this might require assistance from Virtalus. Supported drivers are:
  • QoS parameters (optional) for each NIC attached to the network, to limit the inbound/outbound average and peak bandwidths as well as the burst data size that can be transmitted at peak speed.

Address Space

HyperCX incorporates an IPAM that will handle IP addresses to workloads. The addresses available in a Virtual Network are defined by one or more Address Ranges (AR). Each AR defines a continuous address range and optionally, configuration attributes that will override the first level attributes defined in the Virtual Network. There are four types of ARs:

  • IPv4, to define a contiguous IPv4 address set (classless).
  • IPv6, to define global and ULA IPv6 networks.
  • IPv6 no-SLAAC, to define fixed 128 bits IPv6 address.
  • Dual stack, each NIC in the network will get both a IPv4 and a IPv6 address (SLAAC or no-SLAAC).
  • Ethernet, just MAC addresses are generated for the VMs. You should use this AR when an external service is providing the IP addresses, such a DHCP server.

Guest Configuration Attributes

To setup the guest network, the Virtual Network may include additional information to be injected into the VM at boot time. These contextualization attributes may include for example network masks, DNS servers or gateways. For example, to define a gateway and DNS server for the virtual machines.

These attributes are automatically added to the VM and processed by the contextualization.

Virtual Network Types

Bridged Network

In this type, the virtual machine traffic is directly bridged through the Linux bridge in the nodes. Bridged networks can operate in three different modes depending on the additional traffic filtering made by HyperCX:

  • Bridged, no filtering is made, managed bridge
  • Bridged with Security Groups, iptables rules are installed to implement security groups rules.
  • Bridged with ebtables VLAN, same as above plus additional ebtables rules to isolate (L2) each Virtual Network.
Considerations & Limitations

The following needs to be considered regarding traffic isolation:

  • In the Bridged and Bridged with Security Groups modes you can add tagged network interfaces to achieve network isolation. This is the recommended deployment strategy in production enviroments in this mode.
  • The Bridged with ebtables VLAN mode is targeted to small environments without proper hardware support to implement VLANS. Note that it is limited to /24 networks and that IP addresses cannot overlap between Virtual Networks. This mode is only recommended for testing purposes.

802.1Q Network

This driver will create a bridge for each HyperCX Virtual Network and attach a VLAN tagged network interface to the bridge. This mechanism is compliant with IEEE 802.1Q

The VLAN id will be the same for every interfaces in a given network. It is configured at the time of creation of the Virtual Network by configuring VLAN_ID in Manual and entering the the vlan number.

VXLAN Network

This driver will create a bridge for each HyperCX Virtual Network and attach a VXLAN tagged netwrk interface to the bridge.

The VLAN id will be the same for every interfaces in a given network. It is configured at the time of creation of the Virtual Network by configuring VLAN_ID in Manual and entering the the vlan number.

Additionally each VLAN has associated a multicast address to encapsulate L2 broadcast and multicast traffic. This address is assigned by default to the 239.0.0.0/8 range as defined by RFC 2365(Administratively Scoped IP Multicast). In particular the multicast address is obtained by adding the VLAN_ID to the 239.0.0.0/8 base address.

Considerations & Limitations
  • The driver works with the default UDP server port 8472.
  • VXLAN traffic is forwarded to a physical device, this device can be set (optionally) to be a VLAN tagged interface, but in that case you must make sure that the tagged interface is manually created first in all the host. Virtalus takes care of this entire process in off-prem cases and on-prem cases only deals with compute nodes, physical devices are the responsability of customers.
  • The physical device that wiil act as the physical device must have an IP.
  • Each VXLAN is associated with one multicast group. There is a limit on how many multicast groups can be a physical host member of at the same time. That also means, how many different VXLAN can be used on a physical host concurrently. The default value is 20.

Open vSwitch Network

Open vSwitch provide network isolation using VLANs by tagging ports and basic network filtering using OpenFlow. Other traffic attributes that may be configured through Open vSwitch are not modified.

The VLAN id will be the same for every interfaces in a given network. It is configured at the time of creation of the Virtual Network by configuring VLAN_ID in Manual and entering the the vlan number.

Add/Modify Virtual Networks

General

On the tab administrator can setup

  • Name of the virtual network

  • Select the cluster it’s meant for (if nothing specific is defined it’ll use “0:default”)

  • High level description for the end user and administrators.

Conf

Network related capabilities are set using this tab,

  • Bridge id is defined here for example “br100”

  • Network mode is defined.

  • Manual VLAN ID and hardware ids are defined.

Note

Off-prem clients must contact Virtalus support team before create a Virtual Network from cero. Because the latter must prepare conditions in the physical devices.

Warning

Although contextualization runs automatically with every change made to the VM, some VMs with specific OS, such as Windows, must be turned off and back on for the changes to take effect. Please note that in these cases a reboot will not work.

  • Address range

Here Administrators can add one or more address ranges, which are structured in Address Ranges (AR). Address Ranges can be dynamically added or removed from a Virtual Network. In this way, you can easily add new addresses to an existing Virtual Network if the current addresses are exhausted,with the following options:

  • First IPV4 address defines the starting point and then size defines how many IP addresses are reserved for this virtual network (for example 192.168.10.2/24 can be specified here as “Starting IP address:192.168.10.2” and “Size:254”)

  • Starting MAC address is also defined for the NIC. You can leave it empty and the system will automatically assign one.

QOS

This tab enables HyperCX administrators limit a virtual network so every VM connected to this Virtual network will be individually capped and for both inbound and outbound traffic, by default HyperCX does not cap any bandwidth for any virtual network.Following are some of the features that HyperCX provides for capping bandwidth,

  • Average Bandwidth

  • Peak Bandwidth

  • Burst Bandwidth

Context

Context plays a vital role in defining the VMs so if a NIC is attached to a VM user shouldn’t worry about the initial configurations as HyperCX will take care of it, context variables define the initial configurations if this Virtual network is attached

  • Network address

  • Network mask

  • Gateway

  • IPv6 Gateway

  • DNS

  • MTU of the Guest interfaces

  • Custom attributes lets the administrator define if some custom context variables that might be needed if this virtual network is attached to a VM.

Updating a Virtual Network

After creating a Virtual Network, you can update the following attributes:

  • Any attribute corresponding to the context or description
  • Physical network configuration attributes, e.g. VLAN_ID.
  • Any custom tag.

Note

On-prem Administrator can modify the network as they can manage the physical devices. But, Off-prem Administrator should not, as they don't know all the infrastructure specs.

Managing address ranges

Addresses are structured in Address Ranges (AR). Address Ranges can be dynamically added or removed from a Virtual Network. In this way, you can easily add new addresses to an existing Virtual Network if the current addresses are exhausted.

Adding, removing or modifying an address ranges:
  1. Click Network > Virtual Networks.

  2. Select the Virtual Network.

  3. Go to Addresses section > Address Range. Users

Add or remove Address Range. Users

Modify Address Range size. Users

Hold and Release Leases

Address can be temporarily be marked as hold. They are still part of the network, but they will not be assigned to any virtual machine.

To do so, go to Leases within the desired virtual network, enter the ip and press the Hold IP button.

You will see the the hold ips in Leases as follows:

Using a Virtual Network

Once the Virtual Networks are setup, they can be made available to users based on access rights and ownership. By default, all Virtual Networks are automatically available to the group users.

Virtual Network can be used by VMs in Manual way: NICs in the VMs are attached to a specific Virtual Network.

Attach a Virtual Network to a Virtual Machine.

To attach a Virtual Machine to a Virtual Network simply we can do this from Sunstone:

  1. Go to Portal and Login as SuperAdmin or Admin group.

  2. Click Instances > VMs.

  3. Select the VM that will attach a Virtual Network.

  4. The network card can be attached with the VM in running state.

  5. Go to Network Section > Click Attach NIC. Users

  6. Select the NIC. Then Power ON the VM. Users

For Virtual Machines with multiple interfaces there is an important issue to keep in mind, which interface will manage the default gateway? Usually, the default gateway will be owned by the first interface, but there are cases, such as Centos, where it belongs to the last interface. Therefore, there may be cases in which, when clients add a new interface, the default gateway will change. This could be avoided by adding a Custom Var within the virtual machine or Template configuration, GATEWAY_IFACE = the number of desired interfaces.

In addition, Templates could be modified with this parameter to ensure that all Virtual Machines that are deployed from it have solved this issue.

Automatic Network Selection

You can delay the network selection for each NIC in the Vm to the deployment phase. In this case the Scheduler will pick the Virtual Network among the available networks in the host selected to deploy the VM.

This strategy is useful to prepare generic VM templates.

To set the automatic selection mode, simply enable Automatic selection within Network section

Also you can add Requirements when this mode is actived.

Virtual Networks Templates

The Virtual Network Templates allows the end user to create virtual networks without knowing the details of the underlying infrastructure. Typically the administrator sets the templates up with the required physical attributes, e.g. driver or physical device information and let the end user to add all the logic information like address ranges or gateway.

Virtual Network Templates can be instantiated several times and shared between multiple users.

Virtual Network Template Definition

A Virtual Network Template is a representation of a Virtual Network, so a template can be defined by using the same attributes available for a Virtual Network. Virtual Network Templates and Virtual Networks also share their required attributes depending on driver they are using (see the requirements here, Physical Network Attributes section).

When a network is created by instantiating a Virtual Network Template is associated to the default cluster. You can control which clusters the networks will be in with the CLUSTER_IDS attribute.

Using Virtual Network Templates

By default just oneadmin can create Virtual Network Templates, if other users need permissions for creating Virtual Network Templates it can be provided by creating a specific ACL.

Once the Virtual Network Template is created the access to it can be managed by its permissions. For example, if a end user needs to instantiate an specific template, it would be enough to give the template USE permmission for others.

Operations

The available operations for Virtual Network Templates are the following:

  • allocate
  • instantiate
  • info
  • update
  • delete
  • chown
  • chmod
  • clone
  • rename
  • lock
  • unlock

Note

Note that for using the newly created Virtual Network, the user needs to define an Address Range either during the Virtual Network Template instantiation or just updating the Virtual Network.

Private IPv4 VNET Template

Most clusters have a preconfigured VNET Template called Private IPv4. This VNET Template contains the most important elements from the underlying physical network infrastructure where the cluster is deployed. If this VNET template exists, it is recommended to create new VNETs by instantiating it as many times as needed instead of manually creating the new VNETs.